问如何在用户故事中记录非功能性需求？

EN

非功能性需求有很多种形式，但它们有一个共同点:不描述系统的功能行为，而是对您可以做出的设计选择施加约束。

非功能性需求不适合表示为用户故事，因为当用户故事可以在短时间内实现一次(相对于整个项目的长度)并被认为完成时，它们的工作效果最好。完成一个故事之后，就没有必要定期重温这个故事了。对于非功能性需求，这是行不通的，因为对它们的坚持需要在整个项目中得到维护。您不能说在项目期间只查看一次浏览器兼容性，而在其余时间忽略它。

对于影响几乎所有(功能性)用户故事的非功能性需求，最好的地方是记录它们，这是完成的定义的一部分。

对于影响相对较小的功能子集的非功能性需求，您可以将它们作为相关用户故事的接受标准的一部分。如果这个子集对您的口味仍然相当大(或者它在将来可能会增长，并且您担心您可能错过了对未来故事的一些非功能性需求)，那么您可以将非功能性需求放在某种文档中，并参考相关故事的接受标准。

至于需求本身的格式和放置它们的可能文档，请使用任何对您和您的团队最有效的方法。

“非功能性需求”有点模糊，易于解释。就你的具体例子来说，我想说的是，这些要求应该被用作其他故事的接受标准。

如果您担心一个又一个地重复相同的非功能性需求，另一个解决方案将是将所有这些需求打包到文档中(例如：“应用程序标准”)，并将“必须遵守应用程序标准”作为您定义的“完成”的一部分。

你可以把它们纳入你的国防部“完成的定义”。

但是，在敏捷中，非功能类是有问题的，如果它们改变了，您就无法跟踪哪些故事是根据什么标准完成的。

所以我会试着把它们列为针对每一个故事的测试。即使这意味着大量的复制和粘贴。