浅谈需求管理

一、需求捕获

之所以用捕获这个词,而不是获取、获得一类词汇,仅仅是想说明需求不是信手拈来的、它是跳动的、不稳定的,你必须下点功夫才可能有所收获。

获取需要的几种主要方式:

圆桌会议:最常见、最普通的需求获取方式,就是需求人员与用户(代表)坐下来就某个(业务)主题展开培训或讨论,用户称述、需求人员提问的方式,这种方式通常能获得业务问题的基本流程等整体感性认识,但要形成明确的需求陈述,一、两次是远远不够的。其优点是快速切入主题,使需求人员对用户业务有粗粒度的整体性认识。这种方式的另一种常见场景是:需求人员对于当前业务已形成一定程度的认知,但仍存在一些不确定或不理解的业务问题,此时主要是需求分析人员提问、用户回答的方式,这种互动的过程中,很多情况下都会出现新的业务问题或引出用户潜在需求(这种需求用户没有直接表述或指出),这个过程是需求分析前期的重要过程,是需求不断深入、不断细化、不断明朗的过程,个人认为,必须通过这种方式解决需求前期的如下问题:

用户当前是否已使用或正在使用其他系统?

是:当前系统的使用状况如何,解决了哪些业务问题;还有哪些业务问题没解决。当初引入旧系统的出发点是什么;现在要引入新系统,最急切要解决的业务问题是什么(例如出现了旧系统不能胜任的新业务需求、产生了需求变更,但是在原系统上修改又无法满足等等,旧系统数据吞吐量不足、旧系统可能是C/S的想要迁移到B/S上以适应异地办公的需要等等)。在需求前期可以利用旧系统挖掘用户需求,保留其合理的部分,如有可能,可以构造出系统原型,要充分利用旧系统所包含的业务信息和业务数据处理流程;根据实际情况同用户确认。

否:引入(新)信息系统实现什么或者要达成什么目标?大部分用户会告诉你他们想信息化、提高效率、降低成本,诸如此类。个人认为,这个和没问这个问题的效果是一样的。大多数需求人员也知道他们不可能从这个问题得到什么实质性的东西,因为这个问题所涵盖的内容相当泛,很多时候这个问题都被有意或无意的被忽略了,但这是一个必须面对且需要明确陈述的问题,最好能够有定量的描述(数据才是最客观的)。

用户管理层的参与:能取得用户的主动参与自然是相当好的事情,事实上,这比较困难。退而求其次,锁定几个关键用户,这几个关键用户必须对所在业务领域的业务流程相当清楚并有可能协助业务流程再造,如有可能,可以通过msn、qq等类似IM工具和他们建立实时联系,提高需求沟通效率。

业务资料搜集:用户业务资料,最主要的是各种日常业务单据(牵涉到业务流程)、报表,因为各种业务处理最终通过这些纸质媒体上的数据反应出来,整理、归类、分析这些单据、报表可以找出数据源头(映射到系统的原始数据录入)、流转、存档及分析、提取等,资料上面的公式、表达式等直观反应了现实的业务规则。

获取需求是任何一个需求团队都不能避开的步骤。将搜集到的用户需求不断分析、比较才可能发现问题;因此这是需求细化的一个前提条件。如果用户有遗留系统,分析现有遗留系统的业务功能也能对目标系统提供帮助,理清用户当前的业务逻辑。

头脑风暴:这里借用一下brains storm,简单的说,就是需求人员充分发挥主观能动性、各抒己见、甚至异想天开对于业务问题给出自己的认知和解决方案,如果有对该行业业务熟悉的同事参加更好,这样大家在一起讨论的效率会更高,否则极有可能出现“公说公有理、婆说婆有理”的僵持局面,这种情况下,头脑风暴的主持人必须作出仲裁,结束争端。

这种方式在需求人员对于行业业务缺乏认识或者认识较少的时候充分发挥团队成员想象力、利用集体智慧和常识、逻辑构造出一个业务问题模型和解决方案模型,这种模型具有很大的主观性,在对行业的真实需求逐渐明朗的过程中,往往可能要将以前的假想全部否定(这是一件极其痛苦的事情),而且真实的业务问题比构想出来的业务问题要复杂的多;但是这种方式在早期对行业需求缺乏认知的时候能积极推动需求工作向前进行,同时通过对比也能让需求人员对需求过程的理解获得更深入的认知,一定程度的采用是不无裨益的。

辅助方式:

问卷调查:草拟用户可能关注的目标系统特性、业务问题解决方案等

个别访谈:就某一具体业务问题刨根究底的明确

需求导出:用户很多时候很难表达出他想要什么,一旦你把软件交付给他使用时,他会说:“我们,这里不是这样处理的”、“还有一种情况,你们的系统不能够支持啊”等等;其实,这种现状反应的是系统需求的不完整性,这种不完整性有用户本身的原因,也有需求分析人员不可逃脱的责任,如何尽可能降低这种需求不完整性(因为这种情况是不能杜绝的),要从两个方面入手:

??? 需求分析人员:需求人员的责任就是从用户那里取得需求并表达、组织,因此需求人员要尽一切可能从用户那里获得完整认识,要获得相对完整的认识,如下的工作必须做到位

1、分析各需求之间的关系,有制约、依赖、关联等

2、构造业务流程图,仔细分析每个可能的业务路径,每个业务路径触发条件是什么,如何处理,需要哪些前置条件,其结果是什么,对其他需求有何影响

3、开发需求导出工具或系统原型

以当前流行的B/S架构,可以用html生成简单的业务demo,简单的表达目标系统可能的“模样”,对于现时业务的处理方式,UI等等,用户更多的喜欢这种直观明了的方式,也更易于帮助他们清理出“藏在他们心底的”需求

二、需求定义、表达与组织

描述用户的某个需求看似一件简单易做的事情,感觉上只需要指出用户想要干什么,系统能够提供什么就可以了,实则不然。

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

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

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

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

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

?????? ……….

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

系统词汇表

在需求定义时,系统词汇表是必不可少的组成部分。系统词汇表是系统(业务)术语的集合,词汇一般是行业相关专业术语或公司业务词汇,这些术语的含义用自然语言表达出来,寻求需求人员和用户对该词汇有一致的认识并固定下来。有些系统词汇本身就是对业务规则的一种表达,这种性质的系统词汇应给予更多重视。系统词汇一旦固定下来,决不能任意修改;除非有不得已的原因,但也要通过评审功能项/模块。传统的需求表达方式,把用户的业务需求按业务性质(映射成系统的功能模块,比如采购模块、销售模块、库房模块等等)分解成一个个小的业务特性/功能(feature/function)一一间接描述系统要支持的功能(以解决用户的现时业务问题),以文字直接陈述为主。

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

系统可由用户录入店铺资料建档,审批通过的店铺在系统中启用;审批未通过的店铺,用户可编辑后提交审批或者删除。对于已经申请的店铺资料或审批通过的店铺资料,系统要提供编辑功能;对于已审批店铺资料的编辑要重新审批业务单据数据字段或业务列表显示字段信息。

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

??? 其中经营性质字段的取值由系统定义为扣率或租金,用户店铺建档时选择其一,可在整个系统内使用,管理归属、店铺定位字段的取值范围由用户自定义,因为不同地区用户的业务要求及命名方式不一致,仅在地区范围内使用,协议为当且仅当店经营性质为“扣率”时出现有两个明细项;扣率为用户手工填写,以%计,比如32%;结算为设定结算日期,用户录入。

这种定义和表达需求的方式形式上比较自由、功能相对离散,用模块将近似需求组织起来。但是,这种表达不能够直观的体现出需求之间的若干关系;在需求发生变更等情况时,如果需求管理没有借助有效的RM工具,很难有效跟踪其产生的连锁反应(对其他依赖此需求的需求产生的影响)

其描述的系统需求还比较抽象,由于完全依赖于文字载体描述功能,需求人员和用户也可能对同一种描述产生不同的理解,这种分歧可能导致后来系统部门模块重写。作为补充手段,可以结合系统原型或者业务demo与用户沟通以达成一致

三、需求评审

需求评审就是评审人员审核用户需求的过程,这个用户需求是经过需求分析人员整理后的。为什么要评审?换句话说,就是评审很重要,其重要性体现在如下几个方面:

1、评审过程本身也是一个知识传递过程,评审人员与需求分析人员一起讨论用户需求,这有助与评审人员获得用户需求的前期认识。

2、评审过程中可能发现不明确的或者遗漏的需求,这需要需求分析人员向用户确认。

3、评审过程中可能发现某些特殊需求,这时需求分析人员和评审人员可以群策群力共同思考解决问题的方式。

4、当局者迷、旁观者清。再powerful的需求分析人员也可能犯错,评审人员可以提出更合理或者更有建设性的想法供需求分析人员参考。

如何评审

评审人员有用户代表(这是最理想化的)、系统设计人员、项目负责人(通常是项目经理)、开发人员代表、测试人员代表。评审过程和普通的开会没什么区别,需求分析人员陈述需求,评审人员思考或者提问,以取得对需求有一致的理解,这是一个互动的过程,可以适当的营造轻松的氛围,有助于大家充分思考。

评审是一个迭代过程,很多情况下不能一步到位,事实上,这不是什么坏事,我们都知道,需求失真发现的越早,系统修复成本越低。评审人员在多次迭代的过程中,或许能够发现解决现实问题更好的方案,而且他们对每次评审中出现的情况也比较清楚,知道哪些需求导致评审不通过,哪些需求可能还会有进一步变更、等等;这对系统设计人员、开发人员是不无裨益的,参考历史可以把握现在,立足现在可以前瞻未来,这个对需求分析、软件开发也同样适用。

四、需求发布

内部评审通后的用户需求经用户确认后(若评审阶段有用户直接参与并可现场确认则不需要用户确认了,否则需要电话、email等方式由用户确认),就可以发布给开发部、测试部;需求一旦确定下来,就形成需求的一个里程碑milestone,不能再修改;若有修改,按需求变更处理。
???

点此下载

评论已关闭!