似乎存在一个潜在的假设，即敏捷团队在没有规范的情况下工作，因为他们接受变化并专注于快速交付产品而不是提供大量文档。
事实并非如此。敏捷项目仍然需要结构，模糊的假设不能用于实现关键功能。
这就是 SRS 发挥作用的地方。Agile中的软件需求规范 (SRS)是随项目发展而发展的动态需求集合。与传统开发方法相比，它具有灵活性和迭代性。
1 什么是软件需求规范（SRS）？
软件需求规范 (SRS)是一份详细说明软件功能及其预期行为的文档。本质上，它描述了软件如何通过其功能为所有相关利益者提供价值。
SRS 文件可以说主要是四个核心要求：
- 定义产品的用途
- 描述正在构建的产品
- 详细说明系统和用户要求
- 将其交给利益相关者 1以供批准
最佳的 SRS 文档力求定义软件产品与硬件和其他嵌入式第三方系统/架构交互的整个范围，甚至考虑到一定程度的现实生活中的人机交互和用户之间的交互。
2 为什么 SRS 对于 Agile 很重要？
假设一个敏捷团队需要创建一个具有定义的 UI 和功能的聊天应用程序，以满足企业而不是个人客户的需求 2。
这可能是一项艰巨的任务，其中一些工作可能必须外包才能及时推出产品。鉴于远程工作和全球分散团队的增加，所有利益相关者都必须确切地知道需要做什么，以便能够在最佳时间和成本情况下完成。
如果缺乏足够的清晰度和可见性，从事单个史诗工作的人们很容易失去对大局的把握，事情就会失控。每一个错误的决定最终都会造成障碍，并减慢整个 CI/CD 管道的速度，因为人们不断地重新处理他们认为作为一个整体运行良好的组件。
SRS 文档有助于将更大的想法写在纸上，并以业务团队、开发团队和 QA 团队能够理解的语言涵盖所有基础知识。这也符合客户心中的设想，并确保三人齐心协力，交付所需的确切产品。
SRS 文档允许将所有这些想法详细地写在纸上，并有助于增强测试人员和开发人员之间的沟通。
这也有助于客户估算 3完成工作和涵盖的整个项目范围的总成本。
- 对于设计师来说，它可以帮助他们了解他们的用例如何与 SRS 中概述的设计相匹配。
- QA 人员了解需要构建的测试套件，以确保产品满足所有业务需求 4。
- 明确最终用户旅程，并根据 SRS 对最终用户如何与产品交互的描述创建指南文档。
- 投资者可以概览系统功能，以便对进一步的投资途径做出明智的决策。
因此，清晰的 SRS 文档可以作为唯一的信息来源，并有助于管理所有 Agile 利益相关者之间的期望。
3 软件需求规范 (SRS) 的组成部分
SRS 应包含足够的细节，以便软件开发人员创建所描述的预期成品。它应该描述正在开发的软件的技术组成、所述软件的用途以及其性能将如何影响利益相关者。
通常它包括:
- 该软件的用途概述。
- 软件本身的一般描述。
- 软件功能的细节取决于利益相关者的需求。
- 软件在生产场景中所需的性能。
- 作为利益相关者期望的一部分，非功能性需求 5需要得到涵盖。
- 软件与硬件和/或第三方系统等外部接口的交互。
- 产品的局限性取决于设计约束和运行环境。
4 如何编写软件需求规范（敏捷中的 SRS）
4.1 步骤 1. 创建大纲
敏捷软件开发方法并不强调繁琐的文档。相反，它们专注于尽快交付“可用于生产”的软件。在这种情况下，必须直截了当地确定一个能够被整个利益相关者小组接受的大纲。
鉴于敏捷团队中紧密结合的工作文化，大纲应该涵盖所有基础，以便利益相关者能够达成共识。
一般来说，有可用的模板，但如果团队从头开始，那么可以使用以下内容:
- 介绍
- 目的
- 目标读者
- 预期用途
- 范围
- 定义
- 总体描述
- 用户需求
- 假设和依赖关系
- 系统功能和要求
- 功能要求
- 外部接口要求
- 系统功能
- 非功能性需求
4.2 步骤 2：定义文档的目的
敏捷团队通常以 1-2 周的短冲刺方式开展工作。每个冲刺都有一定数量的用户故事 6，这些故事是从一组较大的关注点（称为史诗）中挑选出来的。
在描述文档的目的时，这种语言需要保持一致。需要用这些术语概述项目的范围、它将提供的价值、预期的最终用户以及每个用户的价值主张。
这种评论越精确，就越容易将目的分解为可实现的任务并确定其优先顺序。
4.3 步骤 3：定义目标受众
任何敏捷项目的核心都是用户故事。用户故事是敏捷框架中最小的工作项目，它从特定用户的角度描述最终目标。
Agile 相信以人为本，而用户故事则使开发以用户为中心。这些故事通常都是非技术性的，它们为开发和 QA 团队提供了更大的背景。
购物中心应用可能根据不同的受众群体拥有不同的用户故事。例如，一组故事针对在线客户，一组故事针对商品零售商，一组故事针对网站管理员。
为了便于开发，在 SRS 中清楚地整理此上下文非常重要。
4.4 步骤 4. 了解受众的预期用途
用户故事通常以“作为 [角色 7]，我 [想要]，[以便]”的形式记录。一旦我们定义了不同的用户角色，SRS 就需要向工程团队明确独特的价值主张。
以同样的例子来说，一个购物中心，一般的在线用户会希望用它来购物，而零售商则希望展示他们的产品。这两种用户角色对应用程序的用途不同，必须清楚地列出这些用途。
4.5 步骤 5. 范围
一旦定义了用户角色以及针对这些角色的产品用途，了解产品满足其要求的范围就很重要。
与传统的瀑布模型不同，敏捷过程依赖于短暂的开发冲刺，并且通常在几次冲刺后就能切实实现最终目标。在这种情况下，创建用户验收标准 8来定义产品范围非常重要。
Dean Leffingwell 将验收标准定义为对系统提出的“满意条件”。这些是从用户的角度编写的。如果某个故事满足所有用户验收标准，则认为它已按预期运行。
这对于左移测试 9非常重要，因为 QA 团队可以基于此结构创建测试套件，而开发团队可以为这些用户故事创建任务，从而满足用户验收标准。
4.6 步骤 6. 定义
除了定义常用的缩写词以防止广泛的混淆之外，还需要定义项目中的风险。这是测试覆盖率的一个重要方面，称为风险覆盖率，并且还需要制定这些风险的缓解政策。在编写 SRS 的这一部分时，需要考虑这些风险的优先级 10、严重性和发生概率。
4.7 步骤 7. 总体描述
敏捷开发方法使用看板和 Scrum 等技术来跟踪项目进度。Scrum 将用户故事添加到“冲刺”中，并在冲刺期间“将其烧毁”。
看板团队将一定数量的用户故事分配给“待办事项”，然后根据工作流程中的优先级完成它们。
这对于预测项目时间表和冲刺规划至关重要。
用户故事也可用作大型敏捷框架元素（如史诗和计划）的构建块。史诗是基于主题的大型工作项目，而计划则源自组织目标和宗旨。
4.8 步骤 8.假设和依赖关系
与传统的开发方法不同，从客户那里获得的想法会与产品所有者和软件工程团队共享。这要求整个团队了解基于任何现有系统或这些系统的局限性所做的任何假设。
此外，需要列出项目完成所需的任何遗留系统或第三方结构，以便更好地与它们集成并执行更好的系统集成测试。
4.9 步骤 9. 系统功能和要求
一旦从用户角度详细描述了功能，记录以下内容就很重要：
- 功能要求：从技术角度来说，包括系统的核心功能
- 外部用户界面要求：基于前端和后端组件的需求
- 非功能性需求：包括性能校准、安全属性以及其他需要遵守的质量标准。
敏捷流程的灵活性允许在开发过程中更改项目范围 11。这可以避免从头开始的返工，并使项目能够更灵活地适应不断变化的形势。
一旦产品所有者了解了客户的用户需求，并且项目积压已完成，他们就会根据冲刺点或 RICE 或 MoSCoW 模型等模型确定其优先顺序。
SRS 一开始就根据可用信息尽可能充实，并随着项目的进行根据任何新的发展或范围的变化进行修改。
5 敏捷软件需求的类型
以下是敏捷需求的主要类型和特征：
- 用户故事：用户故事从用户的角度讲述可操作的小目标。
- 示例：格式为，作为 [用户类型]，我想要 [操作] 以便 [受益]。这可以转化为 – 作为用户，我想要查看产品演示，以便做出正确的决定。
- 史诗：这些是涉及更大特性/功能的高级需求。史诗由多个用户故事组成。
- 示例：像“购买”这样的史诗可能包括查看购物车和添加商品等用户故事。
- 验收标准：这些条件描述了需求何时被视为完整且按需要运行。
- 示例：登录功能的验收标准之一可以是“用户可以使用密码和电子邮件登录”。
- 非功能性需求 (NFR)：它们定义解决方案的运行情况。NFR 与性能、可扩展性和安全性 12等质量属性密切相关。
- 示例：“该应用程序应同时支持 100 名用户。”
- 技术要求：技术要求是指系统中用户看不到的部分，但在功能方面却是决定性因素。
- 示例：“构建云基础设施以提高可扩展性”
- 完成定义 (DoD)：敏捷团队使用名为“完成定义”的清单来确保在将功能标记为完成之前满足所有质量标准和要求。
6 末语
由于 Agile SRS 更符合 Agile 的“以人为本”和“工作软件是衡量进步的主要标准”的理念，因此它对任何所需的更改都反应更快，并且可以在不需要彻底改革的情况下纳入这些更改。
一般来说，敏捷开发要求团队在结束每个冲刺之前彻底测试他们的产品，这涉及跨浏览器测试，以确保产品能够在所有可用选项上无缝运行。