我知道在瀑布中，它们是在 SDLC 的早期阶段收集和记录的，我相信是第一阶段。因此，它们甚至在开发和测试开始之前就被捕获并记录在案。
但我很困惑在敏捷中这是如何完成的？
如果我理解正确，用户故事应该使用能够捕捉非功能性需求的验收标准来编写。但是在敏捷中，我们选择项目，创建它，然后立即开始工作。
所以，我的猜测是，有人（可能是产品所有者）浏览用户故事并将验收标准收集到一个格式化的文档中，然后变成非功能性需求文档？
【问题讨论】：
标签： agile requirements
首先，要回答您的问题，我必须明确没有任何敏捷框架或方法试图定义团队可能需要做的所有事情（尤其是 Scrum），因此添加团队发现的额外工件或实践并没有错只要它们不违背既定的惯例，它们就很有用。
我通常会在一些地方看到非功能性需求的记录。以下是一些最常见的：
完成的定义
完成的定义包含应该应用于所有通过的积压项目的质量标准。通常这包括“n% 的代码单元测试覆盖率”、“代码和配置更改已经过同行评审”和“所有自动化回归测试都已运行并通过”。我有时会看到更广泛的非功能性需求，例如“没有更改会导致应用程序加载时间超过 X 毫秒”。
建筑设计文件
您仍然可以在敏捷中拥有这些。他们没有在项目开始时建立完成的架构，而是引入了架构必须保持的约束。随着项目的进展和架构决策的制定或更改，这些文档会更新以反映该信息。约束的示例可能包括“系统 X 被认为是客户个人数据的权威来源”或“支付处理所需的详细信息绝不应提供给面向公众的服务器，以减少对该数据的攻击机会。”
产品章程
根据项目的不同，“立即开始”有点不稳定。在非常大的项目或产品上，花几天时间（根据我的经验，1 - 3 是一个很好的数字）来安排项目的情况并不少见。这将包括识别角色，确保业务利益相关者和团队成员对愿景有共同的理解，在高层次上讨论一些预期的用户体验和问题等。非功能性需求出现在这里是很常见的，应该记录在国防部、现有的架构文件中，或者在某些情况下，记录在待办事项中。这种情况的一个很好的例子是权衡矩阵。在构建权衡矩阵时，我们会讨论对项目的约束，例如性能、适应性、功能集、预算、时间等。我们将一个约束确定为主要约束，两个作为次要约束，所有其他约束都被视为第三约束。这不是一成不变的规则，但它建立了对如何在工作中决定非功能性需求的权衡的一般理解。
待办事项
好的，最后一个。并非所有积压项目都必须是用户故事。如果您有可操作的非功能性需求（设置服务器、重新配置防火墙、团队需要转换到新版本的 IDE），那么没有什么可以阻止您为此创建积压项目。这不是用户故事，但没关系。我会警告说，大多数团队发现待办事项中作为用户故事的项目数量与他们有效交付价值和适应沿途变化的能力之间存在相关性，所以不要忘乎所以。但我宁愿看到一个团队在他们的待办事项中加入非美国，也不愿尝试将这些东西作为用户故事传递，例如“作为防火墙，我想更新，所以我们没有得到 h@XX0rD”
最后一点：请记住，在敏捷中，我们努力适应变化，所以不要担心第一次就完美地完成 DoD 或架构文档。随着您了解更多，它可能会发生变化。
【讨论】：