老师的大作两个版本我都买来学习了，给我的工作帮助非常大。我有个问题，第一版里面您说需求分为功能需求，非功能需求，设计约束，第二版把非功能需求改成质量需求，我也看过您写的CTO糊涂术语文章，您认为非功能需求属于什么术语呢？
UMLChina潘加宇
我现在的观点是，“非功能需求”属于模糊术语，不过这个模糊是表达上的模糊，来源于历史习惯，继续使用的害处比“功能模块”、“用户需求”之类的术语要小。
模糊之处在于，针对“需求”集合，“功能需求”是一个子集，“非功能需求”的字面意思就是“功能需求”的补集，所以这两个相加就是全集了，“需求分为功能需求，非功能需求，设计约束”的表述是不严谨的。
但是，类似于功能需求 非功能需求 设计约束的表述方式由来已久，我自己应该是从2002年开始使用这样的表述。当然，我肯定也是从教材上看的，具体哪一本教材现在不记得了。事实上，这么多年来，不少书籍依然是这样表述的，甚至更加混乱。翻阅手边有的软件工程和需求专著，截几个图：
图1 摘自 软件工程（第4版 修订版），Shari Lawrence Pfleeger 等 著，杨卫东 译，人民邮电出版社，2019
图2 摘自 软件工程导论（原书第4版），Frank Tsui 等 著，崔展齐 等 译，机械工业出版社，2018
图3 摘自 AOSD中文版-基于用例的面向方面软件开发，Ivar Jacobson 等 著，徐锋 译，电子工业出版社，2005
图4 摘自 The Requirements Engineering Handbook, Ralph R. Young, Artech House, 2003
以上都是国外作者的书籍，国内作者的书籍也有的，例如：
图5 摘自 软件需求最佳实践，徐锋 著，电子工业出版社，2008
要表述严谨一点，做法可以有：
（1）设计约束不是需求。这个不合适，把它们摆在一起，说明属于一类东西，不管这东西叫“需求”还是“阿猫”、“阿狗”。它们都属于“系统不这样不行，否则会损害涉众利益”。
（2）设计约束是非功能需求的一种。这个可以，但是习惯上说到“非功能需求”，想到的是速度、可靠性等等，这也是出现模糊表达的原因。
（3）把“非功能需求”改名。“非功能需求”这样的口袋式命名本来就不合适，例如可以改为Pfleeger书（图1）中的表达方式——“质量需求”，不过，“质量”这个词也模糊得很。
“需求分为功能需求、质量需求和设计约束”也还是不合适，凭什么前面两个都有“需求”二字收尾，最后一个就没有？还可以把“需求”这个尾巴去掉——需求分为功能、性能、设计约束三种，然后就往这三个筐里分吧。
