需求开发的最终成果是：客户和开发小组对将要开发的产品达成一致协议。这一协议综合了业务需求、用户需求和软件功能需求。就像我们早先所看到的，项目视图和范围文包含了业务需求，而使用实例文档则包含了用户需求。你必须编写从使用实例派生出的功能需求文档，还要编写产品的非功能需求文档，包括质量属性和外部接口需求。只有以结构化和可读性方式编写这些文档，并由项目的风险承担者评审通过后，各方面人员才能确信他们所赞同的需求是可靠的。
你可以用三种方法编写软件需求规格说明：
• 用好的结构化和自然语言编写文本型文档。
• 建立图形化模型，这些模型可以描绘转换过程、系统状态和它们之间的变化、数据关系、
逻辑流或对象类和它们的关系。
• 编写形式化规格说明，这可以通过使用数学上精确的形式化逻辑语言来定义需求。
由于形式化规格说明具有很强的严密性和精确度，因此，所使用的形式化语言只有极少数软件开发人员才熟悉，更不用说客户了。虽然结构化的自然语言具有许多缺点，但在大多数软件工程中，它仍是编写需求文档最现实的方法。包含了功能和非功能需求的基于文本的软件需求规格说明已经为大多数项目所接受。图形化分析模型通过提供另一种需求视图，增强了软件需求规格说明。
软件需求规格说明，也称为功能规格说明、需求协议以及系统规格说明。它精确地阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件。软件需求规格说明不是系统测试和用户文档的基础，也是所有子系列项目规划、设计和编码的基础。它应该尽可能完整地描述系统预期的外部行为和用户可视化行为。除了设计和实现上的限制，软件需求规格说明不应该包括设计、构造、测试或工程管理的细节。许多读者使用软件需求规格说明来达到不同的目的：
• 客户和营销部门依赖它来了解他们所能提供的产品。
• 项目经理根据包含在软件需求规格说明中描述的产品来制定规划并预测进度安排、工作
量和资源。
• 软件开发小组依赖它来理解他们将要开发的产品。
• 测试小组使用软件需求规格说明中对产品行为的描述制定测试计划、测试用例和试过
程。
•软件维护和支持人员根据S R S了解产品的某部分是做什么的。
• 产品发布组在S R S和用户界面设计的基础上编写客户文档，如用户手册和帮助屏幕等。
• 培训人员根据S R S和用户文档编写培训材料。
软件需求规格说明作为产品需求的最终成果必须具有综合性：必须包括所有的需求。开发者和客户不能作任何假设。如果任何所期望的功能或非功能需求未写入软件需求规格说明，那么它将不能作为协议的一部分并且不能在产品中出现。
你在编写软件需求文档时，应牢记以下几点建议：
• 保持语句和段落的简短。
• 采用主动语态的表达方式。
• 编写具有正确的语法、拼写和标点的完整句子。
• 使用的术语与词汇表中所定义的应该一致。
• 需求陈述应该具有一致的样式，例如“系统必须……”或者“用户必须……”，并紧跟一个行为动作和可观察的结果。例如，“仓库管理子系统必须显示一张所请求的仓库中有存货的化学药品容器清单。”
• 为了减少不确定性，必须避免模糊的、主观的术语，例如，用户友好、容易、简单、迅速、有效、支持、许多、最新技术、优越的、可接受的和健壮的。当用客说“用户友好”或者“快”或者“健壮”时，你应该明确它们的真正含义并且在需求中阐明用户的意图。
• 避免使用比较性的词汇，例如：提高、最大化、最小化和最佳化。定量地说明所需要提高的程度或者说清一些参数可接受的最大值和最小值。当客户说明系统应该“处理”、“支持”或“管理”某些事情时，你应该能理解客户的意图。含糊的语句表达将引起需求的不可验证。