为什么要区分功能需求和非功能需求？

我理解两者之间的区别，但是我的同事质疑将标签要求标记为功能性或非功能性（或过渡性）的好处。为什么要这样做呢？他花了两天的时间仔细检查了一个项目的需求清单，但没有发现任何好处，因为最终结果是将文件提交给另一个业务实体，并下达命令“全部完成”。

我担心的是，要求汇总在一个文档中。我试图用实际的方式来解释好处，但是无法出售。如何出售记录哪些需求有效和哪些需求无效的好处。

明确分离需求将使设计正确的系统更加容易。

对于非功能性需求（我更喜欢概念/术语质量属性 -应该提供功能性与非功能性以外的新见解），您更关注软件的属性而不是功能。这是怎样的系统执行某些功能，不是简单的什么系统呢。质量要求对系统体系结构的影响很大，而功能要求却没有，因此应以不同的方式对待它们。

将质量属性与功能需求分开可以让您以不同的方式分析，指定和区分不同种类的需求。例如，质量属性通常是使用质量属性场景指定的，而功能需求可能采用故事，用例，须声明或其他任何格式的形式。我研究过的大多数系统都具有不到十二个质量属性，并且功能需求还很多。

我实际上将介绍另一种需求- 技术约束。再次，将需求明确地分为这三个存储桶，为您提供了在构建系统时如何进行正确权衡的线索。功能需求通常是可以商量的，质量属性将严重影响您的体系结构和您选择的结构，技术约束是不可商量的。

如果这是我的团队，我会告诉他们要求应该按类型清楚地注解，以确保我们不会错过体系结构中的重要内容。考虑一下架构驱动程序，而不仅仅是功能。

安东尼·拉坦兹（Anthony Lattanze）在《软件密集型系统架构师：从业人员指南》中概述了架构驱动程序以及为何应区别对待它们，这比我在此处的总结要全面得多。

当每个需求具有相同的优先级/权重（尤其是“强制性”）时，您可能会担心的不仅仅是分散功能需求和非功能需求。

尽管如此，还是有几个理由将这两种要求分开：

实现的责任 我发现，许多非功能性需求（尤​​其是那些注重性能的非功能性需求）仅适度适用于开发人员。尽管设计可以支持可伸缩性和速度（并且可以调整特定的代码段），但总体上能够满足任何性能要求取决于体系结构，并且经常需要硬件配置。

测试的责任 用户或质量保证团队在审查满足安全性，容错性，安全性和可靠性要求方面有多熟练？

不要重复自己的说明 文档应遵循与代码相同的DRY原则。常见的UI样式要求应归为一组。如果负责需求的人确实想要，他们可以在功能需求中引用非功能需求（单独或成组）。

版本控制 如果您处于具有许多“标准”的公司环境中，则可以编写可以进行版本控制的特定UI或安全性（仅举几例）需求文档。这样，您可以编写应用程序特定的要求（主要是功能要求）：“应用程序必须遵守XYZ-Company-SecReq-​​DocumnentNamingStandard.docx中定义的安全要求V2.3”。

为什么要区分功能需求和非功能需求？

区分的原因之一是两种类型之间的抽象级别。非功能性需求是在系统级别上的，它说明了系统作为一个整体的行为方式。功能需求指的是特定功能，以及必须向客户端提供哪些功能。

非功能需求也限制了系统，而功能需求说明了系统必须执行的操作。非功能需求提供了有关如何稍后设计和实现功能需求的限制。通过将它们分开，可以从约束和限制中清楚地识别特征。

我担心的是，要求汇总在一个文档中。我试图用实际的方式来解释好处，但是无法出售。如何出售记录哪些需求有效和哪些需求无效的好处。

以我的经验，功能性需求和非功能性需求实际上归为同一文档或在同一系统中进行跟踪。但是，它们有各自独立的文档部分，以及满足每个部分的成功标准。

通常，您对需求进行分类以帮助团队兑现他们的要求。如果有专门针对体系结构需求的需求，则将其称为“体系结构”需求应有助于团队在体系结构上工作。

一份包含所有要求的大型文档不一定是一件坏事...花2天的时间对其进行审核也不错。问题通常是，一旦一个人查看了需求，他们就会理解了需求，但是其他人做同样的事情并不容易。使用元数据开始标记需求可以有很大帮助，这将帮助其他参与项目的人。

也许尝试将其描述为一个抽象问题。如果您需要使用旧版代码库，则不仅要阅读所有现有代码行，然后再开始工作。您可以按照代码的结构为您提供帮助。在需求中具有某种结构可以以相同的方式帮助您。

分离有多个好处。

1. 节省测试时间（即仅测试功能要求）
2. 节省了将来对需求进行更改的时间（即，非功能性需求将花费更少的时间来审核/批准/实施/测试）
3. 在规范的（例如FDA等）世界中，非功能性要求需要功能性要求的文书工作量的1/10。
4. 使团队能够在高级（职能）和初级（非职能）团队成员之间划分工作。

我可以继续...

从表面上看，两天似乎很长，从长远来看，它可以节省数周甚至数月的未来工作。