非功能性需求分析（重新认识“非功能性需求”）

作者最近在看《需求工程-基础、原理和技术》中，对“非功能性需求”这一概念有了新的认识，发现自己对“非功能性需求”有很多误区，想想自己编写需求规格说明书时使用过的“非功能性需求”，现在想起来不知道对开发人员造成了多少困扰。接下来，我们一起看看“非功能性需求”是什么？会带来什么影响？如何去避免它？

其实，“非功能性需求”这词的应用，并没有对错之分；在很多实践或很多书籍中，都经常看到。结合作者经历来说，工作中也经常使用功能性需求和非功能性需求来进行区分需求，但看到该书中解释后，让我重新认识它。仔细分析或回想这些所谓的非功能性需求，大概可以分成两类：

非功能性需求分类

① 不明确的功能需求：非功能性需求很多时候都是在描述一个不明确的功能性需求；

② 质量需求：所谓的非功能性需求还可能是描述质量需求。

因此，它要么是一个明确的功能性需求，要么是一个质量需求。非功能性需求经常掩盖了不明确的功能性需求，并导致了对所期望的系统属性多种不同的解读或误读。强烈建议不要使用“非功能性需求”。结合课本中一个实例，它的需求是这样描述“系统应该是安全的”。

如果这样一个不明确需求没有在需求工程中进行精化和细化，那么就造成不同涉众以完全不同的方式理解该需求，从而导致潜在的风险。

通过精化原来不明确的需求，所期望的系统功能和质量都被明确的定义了。

因此，我们强烈建议在书写规范说明的时候，避免这类“非功能性”需求，建议进行仔细的检查系统存在的“非功能性”需求的地方。

如何处理这类“非功能性需求”呢？答案是不要偷懒，要细化、精化，要明确。这本书的作者也给了如下建议：

1. 避免这类“非功能性”需求出现在需求规格说明书中；
2. 相反，要对功能性需求和质量需求进行区分；
3. 非功能性需求中通常隐藏着不明确的功能性需求；
4. 只有很少一部分所谓的非功能性需求是质量需求；
5. 对每个“非功能性”需求，检查是否表示某个不明确的功能性需求，如果是则对其进行充分精化。

文档化、明确的需求是执行所有其他开发活动的基础，因此对任何开发项目而言都是根本性的。