系统需求文档

什么是系统需求文档？

系统需求文档也称为系统需求规格。系统需求文档是一套描述软件或系统行为和功能的文档。它包含各种元素，试图表征客户为了满足其用户而需要的功能。换句话说，系统需求文档（SRD）描述了系统的系统级性能和功能需求。

系统需求文档或系统需求规格定义为一份文档，它定义了软件将做什么以及它需要如何执行，并且还定义了软件需要满足所有利益相关者（用户、业务）需求的功能。

系统需求文档包含什么？

虽然 SRD 作为项目范围管理的纲要，但它最终定义了系统的功能和非功能需求。该文档不概述设计或技术解决方案。这些决定将由开发人员稍后做出。

写得好的系统需求文档应该

• 将问题分解为可管理的几部分。
• 通知设计规范，即 SRD 需要包含关于软件需求的足够信息，以便提出有效的设计。
• 向客户或用户提供反馈。
• 作为测试和验证的参考。

根据 IEEE 标准，SRD 必须涵盖以下重要主题。

• 质量
• 安全/隐私
• 功能能力
• 安全性
• 性能水平
• 约束和限制
• 数据结构/元素
• 可靠性
• 接口

系统需求文档的主要组成部分

根据采用的流程（瀑布式 vs. 敏捷式），SRS 的约定和细节程度会有所不同，但总的来说，系统需求文档或系统需求规格包含系统需求、功能需求、技术需求、验收标准、假设和约束的描述。我们已在下面详细解释了其中每个部分。

约束和假设

约束和假设部分将强调客户对系统设计施加的任何设计限制，导致开发人员无法考虑某些选项。本节还包括需求工程团队在需求收集和分析时所做的假设。如果存在错误假设，则需要重新评估系统需求规格，以确保记录的需求仍然有效。

功能和系统需求

此部分通常包含需求的层级结构，功能/业务需求位于最高层，详细的系统需求作为其子项列出。

需求主要以陈述的形式编写，如“系统需要具备执行 x 的能力”，并附带必要的支持信息。

技术要求

本部分用于列出任何非功能性需求，这些需求基本上体现了产品运行所需的技术环境，并包含了其运行所需的技术限制。这些技术要求对于决定高级功能需求如何分解为更明确的系统需求非常重要。

业务驱动因素

本部分描述了客户希望构建系统的原因。新系统的逻辑很重要，因为它将指导业务专家、工程师和系统架构师的决策。记录业务逻辑和系统背后的另一个令人信服的原因是，在项目过程中，客户的员工可能会发生变动。完全识别系统业务原因的文档将有助于在原始赞助人离职后继续支持该项目。

驱动因素可能包括问题和机遇。通常，问题和机遇的结合是推动新系统的动力。

系统质量

系统质量是非功能性需求，用于定义系统的质量。这些质量通常被称为“ilities”（能力），因为许多这些质量的结尾是“ility”。它们包括可用性、可维护性、安全性、可靠性和可扩展性等项目。

与功能需求不同，系统质量通常包含系统应满足以获得认可的特定指标的表格。

业务模型

本部分描述了系统需要支持的客户的基本业务模型。这包括当前状态、未来状态和组织上下文状态图、关键业务功能、业务上下文和流程图。本部分通常在功能分析阶段创建。

验收标准

本部分将描述客户“批准”最终系统的标准。根据流程，这可能发生在测试和质量保证阶段的末尾，或者在敏捷方法中，在每个迭代的末尾。

通常，此度量标准指的是完成所有用户验收测试并修复所有符合预定优先级或严重性限制的错误/缺陷的需求。

业务和系统用例

此部分通常包含一个 UML 用例图，该图显示了将与系统交互的主要外部实体以及应满足的各种用例。每个用例将有正式的步骤定义，以实现业务目标，以及必要的先决条件和后置条件。

通常，系统用例是从系统需求派生出来的，业务用例是从功能需求派生出来的。通过使用流程图，表示了用例的步骤。

良好的系统需求文档的特点

良好的系统需求具有多种特点

1. 完整性
2. 正确性
3. 可修改性
4. 一致性
5. 可测试性
6. 设计独立性
7. 客户可理解性
8. 可追溯性
9. 可验证性
10. 无歧义性

1. 完整性

系统需求规格或系统需求文档的完整性表示完成的每个意义，包括页数，它恰当地涵盖了所有功能和非功能性需求，并在可能的情况下解决了各个部分。

2. 正确性

用户评审用于确保系统需求文档中需求陈述的准确性。当系统需求文档包含系统实际预期的所有需求时，该文档才被认为是正确的。

3. 可修改性

系统需求文档应可修改并能适应系统变化。修改必须被适当索引和交叉引用。

4. 一致性

在系统需求文档中，当需求之间没有冲突时，需求被认为是连贯的。冲突示例：逻辑冲突，例如报告生成的时段、在不同地方使用的术语等。

5. 可测试性

系统需求文档的书写方式必须易于从中创建测试计划和测试用例。

6. 设计独立性

对于最终系统，必须可以选择不同的设计方案。特别是，系统需求文档不应包含任何实现细节。

7. 客户可理解性

最终用户可能是其特定领域的专家；但可能不是计算机科学专家。因此，应尽可能避免使用形式化符号。必须使用简单明了的语言。

8. 可追溯性

必须能够设计程序中的一个组件，然后检测对代码片段的需求。同样，需要能够检测对相关测试用例的需求。

9. 可验证性

当系统需求文档中存在一种特定技术，可以量化测量系统满足每个需求程度时，该系统需求文档即被验证。例如，表达系统易于使用的需求是不可验证的，应避免列出此类需求。

10. 无歧义性

如果系统需求文档中的每个需求只有一种解释，那么该系统需求文档就是无歧义的。如果我们想避免无歧义性，我们必须使用一些建模技术，例如适当的评审、ER 图、结对检查等。