《需求规格说明书》(用例)陷阱
说明:
1、这里的用例指的是需求用例,不是设计用例;
2、引入“需求用例”目的在于核心功能的补充描述;
3、核心功能最好的描述方式仍然是语言文字;
概要:
需求用例的使用会有很多误区,即便是老手也容易出现问题!如果刚开始接触需求分析、撰写《需求规格说明书》或起步从事业务需求分析工作,那么业务需求用例会是一个好的工具。需要强调的是,它只是一个辅助工具而已,用的不好对项目发展时有阻碍作用的;
具体内容,如下:
1、业务用例想当然
我看到有人用这样一个用例图来做案例,一眼感觉很别扭,一时说不出问题出在哪里。
索性我自己根据内容画了一个,如下:
对系统管理员来说:分类管理与用户管理是一个层级上的;而作者及读者也同样会存则信息分类的问题;
所以把握用例的层次非常重要!
2、用例分析过度
用例分析的目的我们说啦,是为了对核心功能做补充;在用例的基础上核心功能目标概念清晰了即可;如下:
首先,上图整体看上去有点吓人了。东西太多,谁能一下看清楚?而且上面的用例是可以合并的;
因此,上图是过度的业务用例;
插一句牢骚话:
项目分析阶段,我宁可用绘制上图的分析人员,也不会去用满嘴空谈的“高手”、“行业专家”, 一切从实际出发,对项目有意义的弯路可以走!
3、正确识别用例的标准-从用例标准入手
上图中的几个错误
1、所有的维护项都应该从新描述;
2、维护管理员登录权限,应该被定义为更新管理员权限与查看管理员权限;
修改上图如下:
结论:
1、业务用例不是设计用例;
2、业务用例是描述用户对系统的操作,不应包括系统自身实现的造作;
3、业务用例的修辞要准确,用户一眼看不懂、词汇模糊的用例是无效的用例;
4、没有业务用例定义的标准的用例,都是没有价值的用例;
5、增删改(更新)不是一个用例,是系统必须做出的机器操作(“序列项”);
6、查询是一个“序列项”,与更新不同的是,在这个用例中即使没有也可以;如:更新管理员权限,不一定非要查询;
附录:我的规格描述模板
(完)