《需求管理》系列之二需求定义、表达与组织

小老虎菲菲 · 发表于 2007-7-23 10:43:27

《需求管理》系列之二需求定义、表达与组织
描述用户的某个需求看似一件简单易做的事情，感觉上只需要指出用户想要干什么，系统能够提供什么就可以了，实则不然。

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

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

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

   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）并分析其关系可形成最初的系统模型，进而不断深化衍生出系统架构