如何编写软件需求文档（SRD） - SRS软件需求规格指南系列

2.1 为什么使用SRS文档来满足软件需求？

在软件需求规范文档 ⁵中，您需要定义构建目标、讨论创建内容、详细说明每个软件需求，并将其提交审批。一份合适的需求文档会概述所有细节，包括与其他软件连接的期望以及软件嵌入硬件后如何交互。创建SRS报告时，应考虑实际用户和人际沟通。

深入的SRD提供了开发团队可以依赖的单一事实点，它可以作为您的策略，并保持所有团队（包括开发、测试和维护）之间的沟通。

2.2 需要软件需求文档的示例

想象一下，您是一位业务分析师，正在领导一个开发先进电商平台的项目。该项目的成功很大程度上取决于一份精心编写的软件需求文档。为了确保清晰准确，您召集了开发团队、QA测试人员和利益相关者，召开了一次需求研讨会 ⁶。

除了需求研讨会之外，还可以使用软件需求收集工具。在这种情况下，您可以使用功能强大的软件来促进协作式需求收集和文档记录，例如此处的这款。该工具允许团队成员实时输入和审查需求，方便远程团队成员访问，并适应不同的时区。

在研讨会中或通过该工具，您可以系统地将需求分解为功能性、非功能性和技术性规范。您将讨论用户故事 ⁷、用例和系统图，以创建系统行为的可视化表示。您还将详细说明性能、安全性和可扩展性要求，以解决非功能性方面的问题。

在记录这些需求时，请确保它们清晰、明确且可测试。每项需求都应明确说明其需求对象、需求内容以及其必要性。此外，还应包含验收标准 ⁸，以衡量需求的满足程度。

结构良好的软件需求规范文档，无论是来自研讨会还是需求收集工具，都是项目所有参与者的单一真实来源。开发人员拥有清晰的路线图，测试人员可以创建有效的测试用例，利益相关者也了解预期结果。变更通过正式流程进行管理，以避免范围蔓延。

这种方法利用需求收集工具，最终确保项目按时、按预算交付，不仅满足了利益相关者的期望，也超出了最终用户的满意度。这充分证明了一份精心编写的软件需求文档（无论是通过研讨会还是工具创建）对于指导项目成功的重要性。关键在于投入时间和精力编写一份全面的软件需求文档，必要时借助需求收集工具，确保所有参与者都了解需要构建什么以及为什么构建，从而确保项目取得成功。

3.1 主要区别：功能性需求与非功能性需求

在SRS文档中，区分两种主要类型的需求至关重要：功能性需求和非功能性需求。

• 功能性需求：描述软件必须具备的具体特性和功能。它们定义了当某些操作或输入发生时软件的行为。例如，在电子商务应用程序中，功能需求可能指定用户应该能够将产品添加到购物车中。
• 非功能性需求：关注软件应该“如何”运行，而不是“做什么”。它们涵盖性能、安全性 ¹¹、可用性和可靠性等方面。例如，非功能性需求可能规定电商平台必须在两秒内加载产品页面。

通过明确定义功能性和非功能性需求，SRS提供了软件功能和性能标准的整体视图。

3.2 确定利益相关者

在为SRD编写软件需求规范时，识别利益相关者是该流程中的重要一步。利益相关者是对正在开发的软件感兴趣或关注的个人或团体。利益相关者的一些示例包括：

• 最终用户：日常使用该软件的个人。
• 客户：将购买或使用该软件的个人或组织。
• 开发团队：负责设计、开发和测试软件的人。
• 运营和维护团队：负责软件部署后的维护和支持的人员。
• 管理层：负责对项目做出决策并确保项目的成功。

在编写SRD时，识别所有利益相关者并考虑他们的需求和要求非常重要。这将有助于确保软件满足所有利益相关者的需求和系统要求，并取得成功。

3.3 项目范围：通过详细描述来定义范围

在编写SRD时定义范围是流程中的重要一步，因为它有助于软件需求规范确定软件的边界以及软件的功能和限制。范围应具体、可衡量、可实现，并应包含以下内容的描述：

• 软件的用途：包括软件将做什么以及它将如何使利益相关者受益的明确说明。
• 特性和功能：包括软件的特性和功能列表，例如用户界面、数据输入和输出以及性能规格。
• 限制和排除：包括软件的任何限制或排除的列表，例如硬件或软件要求，以及任何已知问题或限制。
• 验收标准：包括软件必须满足的标准列表，以便被视为完整并准备部署。

在SRD中明确定义外部接口要求和范围，将有助于确保软件开发满足利益相关者的需求，并且项目保持正常进行并在预算之内。

3.4 收集需求

在为SRD编写软件需求规范时，收集需求是重要的一步，因为它有助于确保软件满足利益相关者的需求。有几种技术可用于收集需求，包括：

• 访谈 ¹²：采访利益相关者以更深入地了解他们的需求和要求。
• 调查：使用调查从大量利益相关者收集信息。
• 研讨会和探索会议：与利益相关者举行研讨会和探索会议，以收集需求并集思广益寻找解决方案。
• 原型设计 ¹³：创建软件原型以收集利益相关者的反馈和要求。
• 观察 ¹⁴：观察利益相关者使用类似的软件来了解他们的需求和要求。
• 用例：确定软件的使用场景、涉及的参与者以及操作和事件的顺序。

收集所有利益相关者（包括最终用户、用户、客户和开发团队）的需求至关重要，以确保软件满足所有相关人员的需求。此外，以清晰、简洁且可验证的方式记录所有需求也至关重要，以避免任何混淆。

然而，收集需求最有效、最高效的方法是使用软件，请阅读我们的博客“为什么应该在需求收集过程中使用软件”了解更多信息。

3.5 替代选项：软件需求规范自动化

传统上，SRS文档是手动创建的，而SRS自动化工具则为生成、管理和维护这些关键文档提供了更高效的选择。这些工具可以简化流程，降低错误风险，并增强项目利益相关者之间的协作。通过自动化SRS创建流程并利用现有的软件需求规范模板，组织可以节省时间、降低成本并提高软件开发项目的整体质量。

3.6 审查并验证软件需求规范

审查和验证SRD是确保所有软件需求文档完整、一致且可验证的重要步骤。可以采取以下步骤来审查和验证SRD：

• 同行评审 ¹⁵：让开发团队的其他成员审查SRD以检查其完整性、一致性和准确性。
• 利益相关者审查：让利益相关者审查SRD，以确保他们的需求和要求得到满足。
• 演练：与开发团队一起演练SRD，以确保理解并满足所有要求。
• 测试：根据SRD中的需求制定测试用例，并对软件进行测试，确保其满足需求。
• 可追溯性：验证所有需求从SRD到设计、实施和测试文档是否可追溯。
• 反馈：将审阅者和利益相关者建议的任何反馈或更改纳入SRD。

在软件开发开始之前，审查和验证SRD至关重要，这样才能在流程早期发现并解决任何问题。这将有助于确保软件产品满足利益相关者的需求，并按时且在预算之内完成开发。

3.7 更新和维护软件需求规范文档

更新和维护SRD是软件开发过程中的重要步骤，用于保存软件需求文档，确保软件满足利益相关者不断变化的需求，并跟踪对软件所做的更改。可以采取以下步骤来更新和维护SRD：

• 监控变更请求：跟踪开发过程中所做的任何变更或新功能请求。
• 修改SRD：将任何更改或新要求纳入SRD。
• 审查和验证：审查和验证更新后的SRD，以确保所有要求完整、一致且可验证。
• 传达变化：将对SRD所做的任何更改传达给所有利益相关者，以确保他们了解更新。
• 更新项目计划：更新项目计划以反映对SRD所做的任何更改。
• 跟踪版本：跟踪SRD的不同版本，以了解整个开发过程中所做更改的历史记录。

在整个软件开发过程中，更新和维护软件需求文档 (SRD) 非常重要，这样可以确保软件满足利益相关者不断变化的需求，并跟踪软件的变更。这将有助于确保软件按时、在预算内开发完成，并满足所有利益相关者的功能需求。

3.8 SRS中的软件用例：如何编写弥合需求与实施之间的差距

用例是SRS文档的重要组成部分，因为它们有助于理解用户如何与软件交互。它们弥合了高层需求与实际实现之间的差距。编写软件用例时，请考虑以下几点：

• 识别参与者：定义将与软件交互的不同参与者或用户。例如，在银行应用程序中，参与者可以是客户、出纳员和管理员。
• 描述用例：详细描述参与者在软件中可以执行的各种操作或任务。例如，客户可以登录、查看余额、转账等等。
• 指定场景：为每个用例提供具体的场景或步骤，概述参与者与软件交互时会发生什么。使用清晰简洁的语言描述预期行为。

通过在SRS中包含软件用例，您可以确保参与项目的每个人都清楚地了解软件在实际场景中的运行方式。

3.9 工程中的软件需求规范的主要特征是什么？

成功的SRS的标志是软件工程中优秀的SRS具有以下特点：

• 明确：要求清晰明确，不存在任何解释或误解的余地。
• 可衡量：需求应该是可量化的，以便进行测试和验证。
• 完整：该文件涵盖了项目的所有必要方面，没有遗漏任何关键要求或功能。
• 可行：要求应该在项目的限制范围内实现，包括预算和时间表。
• 灵活：需求应该允许一定程度的灵活性，以适应项目开发期间可能出现的变化。
• 可验证：每个需求都必须是可测试的，这样才可以确认软件是否符合指定的标准。
• 一致性：SRS中的需求不应相互矛盾，并且整个文档中应使用一致的术语。
• 无实施约束：避免在软件需求规范 (SRS) 中规定具体的实施细节。专注于软件应该做什么，而不是如何做。
• 准确：确保文件中的所有信息均为最新且正确。任何不准确的信息都可能导致误解和延误。

精心设计的SRS展现了这些特征，为成功的软件开发项目奠定了基础。

3.10 软件需求规范示例

为了更好地说明所讨论的原则，让我们提供一个SRS结构的简短示例：

1. 介绍：简要概述了该文件的目的和范围，解释了其重要性以及它如何为参与该项目的所有利益相关者提供参考。
2. 项目描述：描述软件项目，概述其目标、拟解决的问题以及预期成果。创建引人入胜的叙述以阐明项目背景 ¹⁶至关重要。
3. 客户的详细说明：目标用户和利益相关者是谁、他们的需求以及他们将如何从软件中受益。本节旨在清晰地了解目标受众。
4. 选择正确的功能：列出并描述软件的特性和功能，包括具体的用例。例如，在电子商务应用程序中，本节将详细介绍浏览商品、将商品添加到购物车以及结账的功能。
5. 选择平台：提供有关技术堆栈、软件平台、外部组件、硬件接口以及有效运行软件所需要求的技术假设和信息。这有助于基础设施规划。
6. 开发职责：概述开发团队的角色和职责，明确项目内各项任务的负责人。本部分旨在确保开发流程的责任明确性和透明度。
7. 用户类别和特征：定义不同的用户组及其独特特征。例如，在医院管理软件中，用户类别可能包括医生、护士和行政人员，每个类别都有不同的需求。
8. 系统功能和要求：这是SRS的核心，您需要在此详细说明功能性需求和非功能性需求。对于功能性需求，您需要指定用户如何安排预约、访问病历或生成报告。对于非功能性需求，您可以概述响应时间预期、安全协议和可扩展性要求。
9. 编写SRS文档时应避免的常见错误：重点介绍创建SRS时应避免的常见陷阱。这些陷阱可能包括要求模糊、声明矛盾或过多的技术术语等问题。

3.11 结论

创建需求需求文档 (SRD) 可能是一个充满挑战且耗时的过程，如果做得不好，会给企业带来高昂的成本。因此，使用软件进行需求收集可以帮助提高流程的效率和效果，从而为项目带来更好的结果，创建最完整、最准确的需求需求文档 (SRD)。

4.1 SRS文档由什么组成及其重要性？

软件需求规范 (SRS) 文档是软件开发领域的关键工具，它概述了驱动项目的完整需求。理解SRS的定义及其重要性对于有效的项目管理、沟通和开发至关重要。

4.2 软件需求规范的基本组成部分

软件需求规范 (SRS) 包含各种关键要素，它们共同定义软件的功能、特性和约束。这些要素是精确项目规划和执行的基础。

4.3 参与制定软件需求规范的利益相关者

软件需求规范 (SRS) 的创建需要多个关键利益相关者的通力合作。确定合适的贡献者至关重要，以确保文档准确体现项目的目标和需求。

4.4 哪些特征被认为是SRS文档的良好特征？

• 清晰度：应该清晰、明确、易于理解。
• 完整性：它必须涵盖所有必要的方面，不遗漏任何关键要求或功能。
• 可验证性：每个需求都应该是可测试的，以便进行验证以确认软件系统是否符合指定的标准。

4.5 谁准备SRS文件？

软件需求规范通常由多位利益相关者共同协作制定，包括业务分析师、项目经理、软件工程师和行业专家。这些专家齐心协力，确保文档准确反映项目的目标和需求。

4.6 软件需求规范文档的关键要素是什么？

软件需求规范 (SRS) 文档的关键要素包括：

• 介绍
• 总体描述
• 顾客
• 功能
• 平台
• 开发职责
• 用户类别和特征
• 系统功能和要求
• 应避免的常见错误