软件需求规格应该满足的要求
（1）内部属性（INTERNAL）
描述了应该如何规定需求。 它们应该包括什么以及它们如何影响它人属性。
（2）无歧义（Unambiguous）
当且仅当其中所述的每个要求只有一个解释时，要求文件才是明确的。 像英语这样的自然语言有许多固有的含糊的词汇。 Scott等人 [24]建议使用确定性有限状态机（FM），Pertinens和决策树。 虽然它们固有的含义较少，但是它们被用于形式化的规范。
（3）正确（Correct） - 为了成为一个需求文档，系统需要修改文档中提到的每个句子或者需求。 例如，客户指定如果他们的早期2次试验错误，应允许用户输入3次密码。 如果要求文件说应该允许用户输入5次密码，那么这是不正确的
。 正确也指的是例如公式。 2 + 2 = 4，如果结果不是4，则不正确。
（4）完整性（Complete）
包括全部有意义的需求，功能的、设计的、性能的、约束的属性或外部接口等方面的需求。
（5）可理解性（Understandable）
需求说明书必须简明易懂，尽量少包含计算机的概念和术语，以便用户和软件人员都能接受它。
（6）可验证性（Verifiable）
描述的每一个需求都是可以验证的，即存在有限代价的有效过程验证确认。
（7）内部的一致性（Internal Consistent）
各个需求的描述不矛盾。
（8）可追踪性（Traceable）
可以实现向前和向后追踪，向前追踪到需求，向后追踪到设计和代码。
（9）可修改性（Modifiable）
SRS的结构风格在需求有必要改变时是易于实现的
（10）注明相对重要性（Annotated by Relative Importance）
要求文件可以通过相对重要性来注明。 应该按照客户重要性的重要性排序。 他们可以被标记为强制性的，推荐的和可选的[24]。
（11）注明相对稳定性(Annotated by Relative Stability)
需求文档可以通过相对稳定性进行注释，具体取决于设计人员的帮助。 需求的变化是特征的稳定性的原因，这些特征可能容易发生早期变化，或者哪些特征能够保持更长时间。
（12）按版本注释( Annotated by Version )
如果读者可以确定在哪个版本的软件中可以实现哪些功能，则要求文档被称为版本注释。 该属性可以取决于应用程序。
(13)不冗余(Not Redundant)
如果需求文档具有存储在多个地方的相同信息，则称其为冗余。冗余一方面有助于可读性，另一方面可能产生问题。如果在一个地方完成更改，而在其他地方没有更改则会导致不一致。
(14)在正确的细节层面(At right level of detail)
需求文档可以提供不同级别的细节。它可以从一般到非常具体。它应该涵盖客户指定的最小功能。例如，1.系统应该接受付款。 2.系统应该接受现金支付。 3.系统应该使用信用卡接受以前的帐单。
(15)精确(Precise)
为了成为精确的需求文档，它不应该包含模糊的细节。例如系统不应该让用户等待确认时间不够精确，而应该有2分钟的确定的数字。
(16)有组织的(Organized )
如果要求文件的内容是为便于用户轻松导航信息而组织的。 Overmyer [24]提出了很少的方法来组织文件。按用户类别分组功能要求。按对象分组功能需求。按功能分组功能要求。
(17)可实现（Achievable）
当且仅当存在至少一个正确实现文档中所述的所有要求的系统设计和实现时，需求文档才是可实现的。这可以通过建立系统原型来完成
（18）电子存储（Electronically Stored）
如果使用文字处理器存储需求文档，则以电子方式存储[24]。它可以从需求数据库中生成。
（19）简明（Concise）
如果文件的长度缩短而不影响其他质量，则要求文件简明扼要。例如有两个要编写的软件需要相同的软件。如果一个文件由25页组成，另外30页。那么第一个显然是简洁的。
（20）设计独立（Design Independent）
需求文档应该独立于设计。这意味着，如果有很多方法可以解决问题，那么就不应该采取单一的解决方案。应该只提到要求的功能，而不是强加设计。
（21）可重复使用（Reusable）
当需求文档的一部分用于将来的需求文档时，它被认为是可重用的。 这可以帮助减少时间。 可重用性可以是非类似项目的一般术语，可以专门用于类似的项目。 例如，由于大部分信息是相似的，工资系统的需求可以被重用到其他项目中。
原文链接：/A1342772/article/details/78875567
