需求开发过程

需求开发过程

需求开发（Requirement Development）包括了从需求调研到需求文档交付的整个过程。

1           需求调研

需求调研是需求开发的第一步。调研本身非常重要，它是需求开发的源头。但不幸的是，调研没有模式可言，也没有按部就班的指导，只能依靠调研人员本身的沟通技巧和行业经验。

沟通技巧越高明的调研人员越能提高需求的准确性和完整性。需求不是凭空得来的，客户也不会把需求按1、2、3……帮你清晰地列出来。绝大多数的时候，客户对需求的表述不是一次到位的，往往需要你不断提问、反复追问，他们才能慢慢地浮出水面。甚至有时候调研对象会把需求颠三倒四、词不达意，给调研人员造成误解。

需求调研人员面对的常常是一个陌生的行业，对行业内的专业知识非常陌生。当领域专家谈到的需求涉及专业知识时，调研人员就会如坠五里雾，两眼一抹瞎。比如财务管理软件中的移动加权平均法、零售连锁行业的最优配送法、制造行业的生产安排等，都需要花时间深入理解其前后的意义和算法。至于客户表述不清导致的需求错误更是普遍。因为有的客户，特别是终端用户，他们的综合素质和计算机使用水平不高，在表述他们需要的东西时，往往词不达意，调研人员理解起来费劲不说，还常常理解错误，而终端用户又以为调研员已经完全理解了。

行业经验能帮助调研人员判断需求是否“到位”。调研员在和客户讨论业务时，客户都是凭经验和记忆做讲解，极少有预先制作的讲解稿。这就导致客户常常遗漏某些重要的步骤，有些业务完全没有提及，甚至是记忆错误，业务被完全错误的描述。如果调研人员有行业经验，那么就能及时地向客户提问，追问那些存疑的细节，挖掘出未被提到的业务。

MIS的门槛太低了，一个新手经过半年的磨炼就可以胜任开发工作。编程语言越来越容易、编程工具越来越强大，编程技术有“傻瓜化”的趋势。一项新语言、新技术出现后，少则半月、多则半年的时间就能掌握。但唯有行业经验不能自学获得，你没有锻炼的机会，就不可能获得行业经验。而且行业经验没办法快速掌握，行业经验是很难得的，一个行业只有做过三个以上项目时才称得上熟悉。我们的目标是计算机专家和领域专家，成为复合性人才，才不会被不断涌入的“后浪”拍死在沙滩上。

值得庆幸的是，虽然不同行业的需求大相径庭，但MIS有许多东西是相通的，你在服装店连锁行业获得的知识，在药店连锁行业也能部分重用。能否做到举一反三，这就看需求调研人员的水平和素质了。

 

2           需求调研方法

需求调研方法是通过一系列规范的方法来调研需求，这些方法被证明是行之有效、且可以重复遵循的。注意，方法是规范的、行之有效、可重复遵循的。

2.1       交谈和记录

需求调研的第一步是与涉众交谈。交谈最好不要有什么固定模式和步骤，针对不同的调研对象采用不同的方式。

调研的过程中最好有一个客户代表全程陪同。通常客户代表是甲方的信息部（电脑部）的工作人员，他们既了解企业的组织构架，也了解业务流程。注意，客户代表常常只了解大概流程，并不熟悉、也不精通业务，或者仅仅只熟悉某一部分业务。不能只和客户代表沟通，调研人员需要下到“基层”和“一线”，既要调查各部门负责人的统筹和大局业务，也要调查终端用户的操作细节。

交谈不要搞成严肃的会议，应该以随意、面对面的方式交谈。参与交谈的人也不要太多，太多人七嘴八舌最后还会产生争执。最好是客户派出两三个业务代表，双方面对面坐下，边喝茶边聊天。每次交谈的时间不要太长，一是避免客户疲惫导致表述准确度下降，二是需要整理记录。

记录交谈的文档格式可以随意，只要能准确、简明扼要地记下交谈的内容即可。最好是整理之后复述一次，由客户再进行补充和修订。

每天再整理一次调研记录，尽量拆分需求的粒度，以短语（动宾结构）的形式归纳需求。动宾结构的短语最能减少歧义、最容易转换为需求用例。

 

交谈的技巧：

交谈需要技巧，才能避免与客户“搞僵”。关系搞僵最后是客户不配合调研，双方有对立情绪，真实的业务需求也就无从谈起。很多时候，与客户的关系融洽是项目顺利验收的最大保障。

1)        任何时候都不要直接反驳客户

有时候客户会提出不恰当、明显是谬误的要求，更有自视甚高或者身居高位颐指气使者，盛气凌人不容置疑。这时候，不要当面反驳，但也不能忍气吞声地同意，不能阻挡的非法需求会像洪水一样漫延，冲垮软件的堤岸。怎样合情、合理地婉拒就要看调研人员的沟通技巧了。

2)        善于倾听

倾听是对客户的最大尊重，但客户容易犯滔滔不绝的毛病，如何从杂乱无章的言谈中抓住有价值的核心和要点是需要能力的。如何判断哪些东西有价值，那就要靠个人素质和经验了。

3)        言简意赅

发言要简明扼要、语言精准，长篇大论还是留到需求总结大会上再发表吧。

4)        掌控导向

跑题是很常见的事情，参与交谈的人越多越容易跑题。适当的跑题是允许的，中间讲讲笑话调节一下气氛更有必要。但不要让跑题太久，也不要偏离得太远，调研人员要适当地把客户“拉”回业务介绍上。

 

与所有涉众代表交谈之后，需求调研算是告一段落，接下来开始编写需求文档。

2.2       编写需求文档

需求文档以交谈笔记为客户的业务核心，参考行业特点编写。

需求文档最终是要正式提交给客户签字验收的，所以一定要格式规范，用语专业。需求文档尽量表达“客户需要做什么、怎么做”，不要牵扯“系统怎么做”，描述的时候假设业务是完全没有信息管理系统的情况下完成的。

需求文档不是闭门造车、一次性编写完之后再提交给客户。在编写的过程中肯定会不断地遇到当初调研不清晰的东西，这时候需要立即联系客户代表，要对方安排能够解答疑问的业务代表。

编写需求文档也提倡“敏捷”，最好能随时联系到客户代表和业务专家，文档每完成一个模块就交付客户评审，根据评审意见修订之后再发给客户……如此反复迭代，直至客户评审通过。

 

需求文档的编写技巧和规约：

需求文档一般用Word编写。Word的版本视客户的版本而定。

1)        列出大纲

如果是多人合作编写，每人可以领取大纲的一个章节，最后再合并起来。大纲很重要，没有大纲的约束，文档就容易散乱。而且大纲还有一个好处：以后在需求验收大会上，给领导讲解的PPT，就是根据大纲来制作的。

2)        格式统一

文档的章节格式、字体、字体大小、颜色、段落间距、正文格式、表格模板都要统一。

3)        适量地增加图表

一图抵千言。好的图表既美观，又能给人专业的感觉，而且图表无形中能增加篇幅（需求文档的页数也很重要，许多客户都会注意这一点）。

图表可以用Visio和PowerPoint来绘制，既快又好看。但千万要记得留图表的底稿，免得以后修改时重绘。

4)        修订模式

一定要在“修订”模式下编写，特别是合并文档时，修订模式尤为重要。

5)        封面、目录、页眉、页脚、页码

一定要有封面、目录、页眉、页脚、页码，封面要有公司的Logo，页码要显示“第X页/共X页”格式。

6)        版本管理

把编写文档当作编写代码一样管理。用SCM（Source Code Management）进行多人协作；每次提交都要增加版本号。

3           需求分析

需求调研完毕（开会调研调研总结大会、客户在需求文档上签字）之后，就可以做需求分析了。

 

4           需求分析方法

需求分析方法是利用专业的语言和工具分析需求，进而得到领域模型。需求分析跨越了需求与模型之间的鸿沟。