“UML应用实作细节”(by Think, UMLChina)复习笔记(4)——通过用例组织需求

类别:软件工程 点击:0 评论:0 推荐:
 通过用例组织需求
 首先,最最重要的是,我们必须有一份愿景:一家企业的愿景就是里程碑似的战略目标(Microsoft:让每个桌面都有一台电脑),同样,开发一个软件系统的愿景也是它的战略目标。识别愿景的时候,可以问3个问题:
 1.为什么要开发这个系统
 2.谁出钱买这个系统
 3.怎样才会觉得值
 这些问题不但要提给自己,更要以各种方式提给客户,来求证他们心目中期待的软件给他们带来的价值。这并不意味着客户说什么是什么,他们嘴里说的和潜意识中期望的往往并不一样。比如提出要把信息电子化的人,真正想要的可能是快捷的查询和可靠的保存。因此不要让虚假的愿景蒙蔽了,注意,真正的愿景目标必须是可度量的(否则以后怎么判断是否达到了这个目标?)
 确立了愿景之后,我们就可以着手识别和组织需求了。用例是一种有效的表达需求的手段,它帮助甚至是”强迫“我们从用户的视角来思考问题,使需求真正体现对用户的价值。用例本身提供了形式化的表示规范,这个规范体现了需求的组织层次:
 
 在这种形式下,所有的需求都是围绕用例来组织的。
 
 
 通过用例组织需求可以分为以下几个步骤:
 1.识别执行者:这一步的关键在于确认”边界“——执行者一定要在边界之外,并且这个边界是从责任上划分的,不是从物理上划分的;另外要注意的一点就是要避免“不甘心”心理——由于执行者直接与系统交互,他们往往是一些打工者,或者代办人,例如银行的职员,而直接顾客或者老板却不是执行者(注意这里与业务建模时的区别),这是正常现象。
 2.识别用例:这一步的关键是“价值”——已经反复强调过了,只有为执行者提供了完整的价值动作,才能提取为用例;而且,这一价值必须是由软件系统提供的,而不仅仅是用户要求的。识别用例常犯的错误是把操作步骤当用例,特别是把“增删改查”操作统统当成用例来看,事实上,这些CRUD操作很有可能不足以构成用例(不足以向执行者提供价值),即使能构成用例,用一个“管理××”的用例来表示也足够了。
 3.书写用例文档:用例文档不等于用例图,用例图只是总的组织结构。一份标准的用例文档应当包含以下内容:
  
  描述用例时要考虑到涉众利益,并且需要平衡涉众利益。经典定义:“Cockburn:用例是涉众之间达成的契约,以执行者为达成特定目标和系统交互的方式演绎“—— 这句写得实在太精彩了!
“ 4.通过关系整理用例:特别注意不要滥用用例之间的关系,越简单易理解越好。
 5.用例的排序和分包:通过对用例进行排序,可以确定以后迭代开发的次序
 

本文地址:http://com.8s8s.com/it/it31544.htm