如何区分优秀的软件需求和软件需求规格说明书（SRS）与可能导致问题的需求和规格说明书？在这篇文章中，我们将首先讨论单个需求应该具有的几种不同特性。然后，我们将讨论成功的SRS整体应具有的理想特征。
1.有效需求的特性
在理想的环境下，每个单独的用户需求、业务需求和功能需求都会展现出以下各节所述的特质。
完整性
每个需求都必须全面地描述预期交付的功能，必须包含所有开发者需要用于设计和实施该功能的信息。如果发现某些信息缺失，最好用“待定”（TBD）标记出。在继续推进项目前，必须解决每个需求中标记“待定”的问题。
没有任何规定你需要在建构开始之前让整个需求集合完整。在大多数情况下，你永远无法达到这个目标。然而，使用迭代或增量开发生命周期的项目应该有一套完整的需求集合，供每次迭代使用。
如果使用的是最低规格要求，不同的人可能会基于不同的假设和决策来填补空缺部分，每个人就会按照自己的理解来执行任务。口头保留需求信息也会导致业务分析师、开发者和测试人员对需求集的理解不同。
正确性
每个需求都必须准确地描述预期构建的功能。
我们应当依据真实世界的需求作为参考，如真实用户或更高级别的系统需求。如果软件需求与父系统需求冲突，则该需求就是错误的。只有用户代表能决定用户需求（例如用例）是否正确，所以用户或其代理人必须认真要审查需求。
可行性
每个需求的实施必须在系统及其运行环境的已知能力和限制之内。为了避免指开发法达成的需求，让开发人员在整个需求完善过程中与市场部门或BA一起工作是必要的。
开发人员可以提供实际的反馈，告诉你在技术上哪些需求是可以实现的，哪些是不能实现的，以及哪些需求虽然能实现，但成本过高。增量开发方法和概念验证原型是两种可以用来评估需求是否可行的方法。
必要性
每个需求都应该描述利益相关者真正需要的功能，或者为了满足外部系统需求或者标准而必须具备的功能。每个需求都应该由有权力提出需求的人或团体提出。要追溯每个需求的来源，比如用户需求（用例）、业务规则或其他有价值的来源，以确保需求的合理性和必要性。
优先级
对每一个功能需求、特性、用例或用户故事进行优先级排序，以表明它们对于特定产品版本的重要性。如果所有的需求被视为同等重要，那么当面临预算削减、项目超出预定时间、人员流失或在开发过程中新增需求等情况时，项目经理会很难做出决策。因此，对需求进行优先级排序是成功进行迭代开发的关键因素。
明确性
所有阅读需求声明的人都应该得到同样的、一致的理解，但是由于自然语言的复杂性，往往容易产生歧义。所以应当使用简单、明了、直接的语言来编写需求，这种语言应当适应用户领域的特性。”可理解性”是一个和”无歧义性”关联的需求质量目标：读者需要能够理解每个需求所表述的内容。在词汇表中，我们应当对所有的专业术语以及可能引起读者困惑的术语进行定义。使用需求模板，如EARS模型，是确保需求以简洁、明确的语言编写的一种有效方法。
可验证性
你应该考虑是否能设计出一些测试，或者采取其他验证方法，比如检查或者示例演示，以确定产品是否正确地实现了每个需求。如果一个需求不能被验证，那么确定它是否被正确实现就变成了一种主观判断，而不是基于客观事实的分析。那些不完整的、矛盾的、无法实现的或者含糊不清的需求也是无法进行验证的。
2.有效软件需求规范说明的特点(SRS)
拥有优秀的个别需求语句并不足够。汇集成软件需求规格说明（SRS）的需求集合应该展示以下各节描述的特性。
完整性
SRS（软件需求规格书）中不应该缺少任何需求或者必要的信息。缺失的需求很难被察觉，因为它们并不存在！将注意力集中在用户的任务上，而不是系统的功能上，可以帮助你防止信息的不完整。Karl Weigers是《软件需求，第三版》的作者，他说：“我不知道有什么方法可以百分之百确定你没有遗漏任何一个需求。”他的书中有一章提供了一些建议，让你可以检查是否漏掉了一些重要的需求。
一致性
一致的软件需求不应该与同类型的其他需求或者更高级别的业务需求、系统需求或用户需求有所冲突。在进一步进行开发之前，需要解决所有的需求冲突。如果你发现两个需求之间存在冲突，你可能需要通过进一步的研究才能知道哪一个（如果有的话）是正确的。记录每个需求的来源可以帮助你在发现软件需求规格说明书中存在冲突时，知道应该去找谁进行讨论。
可修改性
你应当有能力在需要的时候修订软件需求规格说明（SRS），并能追踪到每个需求的修改历史。这意味着每个需求都需要被唯一地标记，并且与其他需求分开表达，以便你可以清晰地引用它。
每个需求应当只在SRS中出现一次。如果在一个复制的需求上只改动一处，很容易产生矛盾。所以，应考虑把后面出现的同样的需求通过交叉引用指向原先的需求，而不是复制需求。目录和索引可以使SRS更易于修改。把需求保存在数据库或者商业需求管理工具中，可以使这些需求变成可重复使用的对象。
可追溯性
可追溯的需求可以向后链接到其来源，向前链接到实现该需求的设计元素和源代码，以及验证实现是否正确的测试用例。可追溯的需求会被赋予独一无二、持久的标识符。它们应当以结构化、细粒度的方式编写，而不是写成长篇的叙述性段落。你应该避免把多个需求整合到一条声明中，因为每个需求可能会关联到不同的设计元素和代码部分。
3.怎么确保需求和软件需求规范（SRS）具备上述特征？
确保需求和软件需求规范（SRS）符合上述标准的最佳方法，是让项目中的多个利益相关者都参与审核编写好的SRS。不同的利益相关者会从不同的角度发现不同类型的问题。例如，分析师和开发人员并不会对需求的完整性或正确性进行评估；而用户也不会去评估技术的可行性。
创建符合所有标准的SRS不是件容易的事。然而，如果在编写和审核需求时我们始终牢记这些标准，那么最终所编写的需求文档质量就会更高，更利于我们交付出优质的产品。
