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