51Testing软件测试论坛

标题: 《需求管理》系列之二需求定义、表达与组织 [打印本页]

作者: 小老虎菲菲    时间: 2007-7-23 10:43
标题: 《需求管理》系列之二需求定义、表达与组织
《需求管理》系列之二需求定义、表达与组织
描述用户的某个需求看似一件简单易做的事情,感觉上只需要指出用户想要干什么,系统能够提供什么就可以了,实则不然。

比如,用户在商品建档时有如下需求

       “用户可以临时调整商品的价格,其规则是:用户申请对某个商品临时调价,并设定临时价格启用期的起止日期,临时调价审批通过后,在该临价格启用期内系统按临时价格开单销售,有效期结束后,系统恢复临时调价前的价格”

       这段话看上去没有任何问题,读起来也很自然,事实上,程序员拿到这个需求后,他/她仍然很痛苦,他/她可能有如下问题不清楚

       1、用户申请对某个商品临时调价,这里的“商品”是尚未报价的还是已经报价的,弄不清楚这个,他/她没办法写SQL语句

       2、设定临时价格启用期的起止日期,起止日期可能会产生歧意,是否包含“止”的那一天,系统从“起”天0:00:000还是9:00:000 AM开始,到“止”天23:59:59还是17:59:59结束,不同行业、不用用户都可能有不同的答案

       3、临时调价审批通过后….,如果审批不通过,系统是删除这个申请还是保留该申请允许用户编辑,这要看用户的使用习惯,有时可能删除比保留来得更合理些

       ……….

       可能还有其他类似问题,每个人考察问题的角度和解决问题的方式都不尽相同,怎么尽可能降低这种语义表达的晦涩,比如不完整和二义性是需求定义和表达的重要目标。

系统词汇表
在需求定义时,系统词汇表是必不可少的组成部分。

系统词汇表是系统(业务)术语的集合,词汇一般是行业相关专业术语或公司业务词汇,这些术语的含义用自然语言表达出来,寻求需求人员和用户对该词汇有一致的认识并固定下来。

有些系统词汇本身就是对业务规则的一种表达,这种性质的系统词汇应给予更多重视。

系统词汇一旦固定下来,决不能任意修改;除非有不得已的原因,但也要通过评审

功能项/模块
传统的需求表达方式,把用户的业务需求按业务性质(映射成系统的功能模块,比如采购模块、销售模块、库房模块等等)分解成一个个小的业务特性/功能(feature/function)一一间接描述系统要支持的功能(以解决用户的现时业务问题),以文字直接陈述为主。

比如,下面是一个描述零售店铺建档的简单需求

系统可由用户录入店铺资料建档,审批通过的店铺在系统中启用;审批未通过的店铺,用户可编辑后提交审批或者删除。

对于已经申请的店铺资料或审批通过的店铺资料,系统要提供编辑功能;对于已审批店铺资料的编辑要重新审批

业务单据数据字段或业务列表显示字段信息

【店铺档案】字段有:代码、名称、简称、经营性质、地址、电话、联系人、管理归属、店铺定位、营业面积、协议

其中

经营性质字段的取值由系统定义为扣率或租金,用户店铺建档时选择其一,可在整个系统内使用

管理归属、店铺定位字段的取值范围由用户自定义,因为不同地区用户的业务要求及命名方式不一致,仅在地区范围内使用

协议:当且仅当店经营性质为“扣率”时出现

有两个明细项

扣率:用户手工填写,以%计,比如32%

结算:设定结算日期,用户录入。



这种定义和表达需求的方式形式上比较自由、功能相对离散,用模块将近似需求组织起来。

但是,这种表达不能够直观的体现出需求之间的若干关系;在需求发生变更等情况时,如果需求管理没有借助有效的RM工具,很难有效跟踪其产生的连锁反应(对其他依赖此需求的需求产生的影响)

其描述的系统需求还比较抽象,由于完全依赖于文字载体描述功能,需求人员和用户也可能对同一种描述产生不同的理解,这种分歧可能导致后来系统部门模块重写。

作为补充手段,可以结合系统原型或者业务demo与用户沟通以达成一致

用例/包
面向对象的分析、设计、编程思想已经成熟并得到广泛应用,OOA中,用例成为表达功能需求的有力方式
OOA从actor(参与者)出发挖掘用户需求,需求分析的第一步是找出目标系统的参与者,其理论逻辑是:
1、识别参与者
2、识别用例
3、书写用例文档
4、建立用例关系,包括泛化、包括、扩展
5、用包逻辑的组织用例
在实际的需求的调研中,要严格的先1后2并不好使,个人感觉先2后1的实际情况可能好一些,如果能够相对明确的得到用户需求,其某个参与者与主参与者其实已经明了,我们更多的会考虑主参与者的想法,完成用例后在考虑其他的参与者,很多情况是,你当初并不知道这个UC还有另外一个参与者,你在开发别的需求时联想到或者得到启发、或者和某个需求有联系时,你才意识到丢失了一个参与者;
能尽可能获得参与者是好事,但实际情况并不是那么乐观,至少有如下原因:
决大多数用户只对自己天天工作的那部分比较清楚,这部分可能同时被别人关注,但他/她可能并没有意识到)
用户可以相对容易的说出他们的需求,但就某个需求(工作项),要他们说出全部的参与者(从事这个工作项的角色或职位)相对模糊一些

用例是基于场景(scenario)的,从这个角度来说,uc直观的表达出用户期望的系统功能及用户与系统的交互细节
关于何如编写用例,可以参考cockburn写的《writing effective use cases》一书。
系统分析员通过分析UC,抽取业务领域(domain)并分析其关系可形成最初的系统模型,进而不断深化衍生出系统架构
作者: 绿野小径    时间: 2007-7-26 09:56
刚开始以为需求说明只要写的烦就好,像唐僧那样说话,看来太幼稚了.
作者: studyboy_0    时间: 2007-8-2 16:40
sdlkfj2
作者: baiking1    时间: 2007-9-21 11:52
受教受教
作者: pbtlight    时间: 2007-9-25 17:46
不错好东西
作者: jysql    时间: 2007-11-20 09:58
又长见识了
作者: 6739    时间: 2008-4-18 15:13
谢谢
作者: sp_0511    时间: 2010-8-29 20:40
学习了




欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2