“非功能需求”属于模糊术语吗

文兵 2020-9-15 10:00

老师的大作两个版本我都买来学习了,给我的工作帮助非常大。我有个问题,第一版里面您说需求分为功能需求,非功能需求,设计约束,第二版把非功能需求改成质量需求,我也看过您写的CTO糊涂术语文章,您认为非功能需求属于什么术语呢?

UMLChina潘加宇

我现在的观点是,“非功能需求”属于模糊术语,不过这个模糊是表达上的模糊,来源于历史习惯,继续使用的害处比“功能模块”、“用户需求”之类的术语要小。

模糊之处在于,针对“需求”集合,“功能需求”是一个子集,“非功能需求”的字面意思就是“功能需求”的补集,所以这两个相加就是全集了,“需求分为功能需求,非功能需求,设计约束”的表述是不严谨的。

但是,类似于功能需求+非功能需求+设计约束的表述方式由来已久,我自己应该是从2002年开始使用这样的表述。当然,我肯定也是从教材上看的,具体哪一本教材现在不记得了。事实上,这么多年来,不少书籍依然是这样表述的,甚至更加混乱。翻阅手边有的软件工程和需求专著,截几个图:

1177.png

图1 摘自 软件工程(第4版 修订版),Shari Lawrence Pfleeger 等 著,杨卫东 译,人民邮电出版社,2019

1176.png

图2 摘自 软件工程导论(原书第4版),Frank Tsui 等 著,崔展齐 等 译,机械工业出版社,2018

1179.png

图3 摘自 AOSD中文版-基于用例的面向方面软件开发,Ivar Jacobson 等 著,徐锋 译,电子工业出版社,2005

1178.png

图4 摘自 The Requirements Engineering Handbook, Ralph R. Young, Artech House, 2003

以上都是国外作者的书籍,国内作者的书籍也有的,例如:

1180.png

图5 摘自 软件需求最佳实践,徐锋 著,电子工业出版社,2008


要表述严谨一点,做法可以有:

(1)设计约束不是需求。这个不合适,把它们摆在一起,说明属于一类东西,不管这东西叫“需求”还是“阿猫”、“阿狗”。它们都属于“系统不这样不行,否则会损害涉众利益”。

(2)设计约束是非功能需求的一种。这个可以,但是习惯上说到“非功能需求”,想到的是速度、可靠性等等,这也是出现模糊表达的原因。

(3)把“非功能需求”改名。“非功能需求”这样的口袋式命名本来就不合适,例如可以改为Pfleeger书(图1)中的表达方式——“质量需求”,不过,“质量”这个词也模糊得很。


“需求分为功能需求、质量需求和设计约束”也还是不合适,凭什么前面两个都有“需求”二字收尾,最后一个就没有?还可以把“需求”这个尾巴去掉——需求分为功能、性能、设计约束三种,然后就往这三个筐里分吧。


weixinpanjiayu2