软件工程中的软件需求规格说明书 (SRS)

软件开发过程中的需求阶段的产物是软件需求规格说明书 (SRS)（也称为需求文档）。这份报告为软件工程活动奠定了基础，并在收集和分析完所有需求后进行构建。SRS是一份正式报告，作为软件的表示，使客户能够审查它（SRS）是否符合他们的需求。此外，它包含了系统的用户需求以及系统需求的详细规格。

SRS 是针对特定软件产品、程序或执行特定功能、在特定环境中运行的一系列应用程序的规格说明。它根据编写者的不同，服务于几个目标。首先，SRS 可以由系统的客户编写。其次，SRS 可以由系统开发人员编写。这两种方法会产生截然不同的情况，并为文档设定不同的目的。第一种情况，SRS 用于定义用户的需求和期望。第二种情况，SRS 是为各种目的而编写的，并作为客户和开发人员之间的合同文件。

软件需求文档的基本要素

软件需求规格说明书的主要部分如下：

• 业务驱动因素：本节概述了客户构建系统的动机，包括现有系统存在的问题以及他们希望新系统提供的可能性。
• 业务计划：本节解释了系统将支持的业务模式，以及其组织结构、业务背景、关键业务流程和流程图。
• 系统、功能和业务需求：本节中的标准按层级排列。特定的系统需求列为子项或子部分，而功能和业务需求则位于顶层。
• 系统和业务用例：本节的用例图使用统一建模语言创建，显示了将与系统通信的主要外部实体以及它们将提供的各种服务。
• 技术规格：本节列出了非功能性标准，这些标准包括程序将运行的技术环境和技术约束。
• 系统特性：本节涵盖了规定系统质量属性的非功能性需求，例如可靠性、可服务性、安全性、可扩展性、可用性和可维护性。
• 限制和假设：本节包括客户对系统设计设置的任何限制，以及需求工程团队对项目过程中将发生的任何情况的假设。
• 验收标准：本节描述了客户批准完成的系统必须满足的要求。

为什么使用 SRS？

组织的所有项目都建立在 SRS 之上。它为开发团队提供了遵循的结构，并为所有参与的团队——开发、运营、维护和质量保证——提供了重要信息。 这种方法确保了团队的一致性。

企业使用 SRS 来验证是否满足了标准，并帮助管理层就产品生命周期做出决策，包括是淘汰一项技术还是某个功能。编写 SRS 还可以帮助开发人员节省开发成本，并减少实现目标所需的时间和精力。

SRS 的其他替代方案

在使用敏捷方法时，企业通常倾向于要求细节程度较低的文档。这些包括用户故事和过程中的验收测试。为了使这种方法成功，客户必须在整个开发过程中随时可用，以提供可能的任何需求澄清。此外，它还假定与客户合作编写用户故事的开发人员也将是开发系统的开发人员。

另一种优先考虑速度和灵活性而非高级设计的软件工程过程是快速应用程序开发。这种方法需要很短的时间来创建，并且使用此方法创建的项目通常需要 60 到 90 天才能完成。

SRS 的特点

SRS 需要具备以下特点：

1. 它应始终准确地描述产品的特性和规格。
2. 对需求的解释不应有任何歧义。
3. 只有当所有规定的需求都可被验证时，SRS 才是可验证的。如果有一种方法可以量化地确定最终程序是否满足了某个需求，那么该需求就是可验证的。
4. SRS 必须系统地、明确地识别每一个需求。依赖的需求和具体标准可以根据任何修改进行更改，而不会影响其他需求。
5. 如果每个需求的来源都很清楚，并且在后续开发中可以轻松地引用每个需求，那么 SRS 就是可追溯的。

SRS 的目标

以下是 SRS 应实现的一些目标：

1. 为客户提供反馈，以确保 IT 部门了解软件系统应解决的问题以及如何解决。
2. 将需求写在纸上可能有助于将一个挑战分解成更小的部分。
3. 加速验证和测试过程。
4. 鼓励审查。

创建 SRS 时避免这些错误。

在创建 SRS 时，企业经常会犯一些错误。以下是企业应避免的最重要的错误：

1. SRS 文档必须使用清晰、无歧义的语言，并避免使用含糊不清的短语。使 SRS 过度复杂，导致可能不懂技术团队成员无法使用，这也是一个例子。
2. 忽视非功能性需求。许多项目为了满足功能性需求而忽视非功能性需求，例如可用性、速度和安全性，但后者对软件产品的成功同样至关重要。
3. 利益相关者反馈不完整。如果公司没有让所有利益相关者，特别是最终用户和业务分析师参与进来，SRS 中可能会出现重大空白。
4. 未能处理更新。由于 SRS 是动态开发的，需求经常会发生变化。由于需求管理程序薄弱，可能会导致项目延误、返工和误解。
5. 忽视可访问性和可用性。SRS 必须确保其产品用户友好。在创建时应考虑可访问性和可用性标准，以及实际用户将如何与系统交互。