优秀的需求是完备的，它不需要做更多的扩展就可以充分说明用户需要的系统功能。完备性的判断标准是：需求是否描述了开发人员设计和实现这项功能所需的所有信息。只有完备的需求在开发中才可能被独立出来，单独对待。需求必须能够在系统及其运行环境的已知条件和约束下实现，用户无法判断需求的技术可行性，所以需求的可行性是由开发人员进行检查的。在检查的过程中，开发人员可能需要进行一定的分析和研究，而不是单纯的凭借经验和直觉。对于难以判断的需求，必要时要通过开发原型来加以验证。不可行的需求又被称为不切实际的期望，是实践中常见的需求定义问题，畏怯它在很大程度上影响着项目的成败。面对不切实际的期望，要求软件开发者提供可行性、成本等足够的技术参考信息，帮助用户对其进行取舍和调整。

    每一项需求都应该是必要的，它是满足用户的业务需求所必须的。如果一个需求被忽略之后，系统仍然能够以同样的效果解决用户的问题，那么它就不值得在开发的过程中消耗额外的资源。而这种不必要的需求也是实践中常见的一个问题，可能因为多种原因而出现，需要多加注意。每一项需求都必须正确描述所需要的系统功能，这也就是需求的正确性，要真是反映用户的意图，所以需求的正确性又常常被称为真实性。需求的正确性只有提出需求的人才能加以判断，所以需求在传递给开发人员之前，必须请需求的提出者加以确定。正确性是一个看上去简单，但是实现上很难满足的特性。实践一再表明，不真实的需求量是最为常见的需求错误之一，必须得到足够的重视。

    需求获取阶段产生的主要成果有业务需求、项目前景和范围、用户需求以及问题域特性。它们都需要被及时记录下来。项目前景和范围文档记录了业务需求和前景与范围信息。获取笔录记录了用户需求和问题域特性。需求分析的主要工作是通过建模来整合各种信息，以使人们更好的理解问题。同时，需求分析工作还会为问题定义一个需求集合，这个集合能够为问题定一个有效的解决方案。需求分析还需要检查需求中存在的错误、遗漏和不一致等各种缺陷，并加以修正。需求分析活动最后会产生一个需求的基线集，它制订了系统开发需要完成的任务。在资源受限的情况下，这个基线集往往知识用户所需求的功能的一个子集。

    系统是作为用户业务问题的解决方案得以被开发的，但仅靠系统本身无法帮助用户达成目标，它必须和部署的环境形成互动才能解决用户的问题。获取的需求需要被编写成文档。业务需求被写入项目前景和范围文档，用户需求被写入用户需求文档。编写文档的主要目的是在系统涉众之间交流需求信息，因此编写的文档应该具有一定的质量。

    最后是需求验证阶段，主要是两个方面：执行验证和问题修正。在需求开发活动后，设计测试实现等后续的软件系统开发活动都需要围绕需求展开工作。需求的影响力贯穿于整个软件的产品生命周期，而不是单纯的需求开发阶段。