业务需求获取的方式方法探究

企业管理信息系统项目的实施，无论按何种方式来组织，都必须经历需求分析阶段。因为需求是系统开发的源头，是信息系统开发过程中关健的一环，只有真正弄清楚企业信息化需求的目标和要求，才能做到对症下药、在后续的开发中设计出达成目标的系绕体系构架和实现方式，并且不断改进，使之逐步完善。需求获取是需求工程的第一阶段。对于较大型的开发项目，其复杂性主要来自客观和主观两个方面。

从客观上说，需求工程面对的问题几乎是没有范围的。由于企业信息系统的应用涉及企业管理的各个层面和广泛的活动领域，与其管理活动的特征和施行过程的习惯性密切相关；

客观上的难度还体现在非功能性需求及其与功能性需求的错综复杂的联系上，当前对非功能性需求分析建模技术的缺乏也大大增加了需求获取的难度。

从主观意义上说，需求工程需要方方面面人员的参与（如领域专家、领域用户、系统投资人、系统分析员、需求分析员等等），各方面人员有不同的着眼点和不同的知识背景，沟通上的困难也人为增加了需求获取的难度。

信息系统的需求不像制造产品要原材料那样简单，本文试图通过规范需求获取的行为，帮助需求分析人员把握好方法与技巧，恰当地后发引导用户表达自己的需求，以便为项目的成功奠定一个好的基石

1、需求定义

需求定义是将用户的非形式化的信息系统需求变为形式化的需求规范的过程。用户需求是指用户对目标系统在功能、行为性能、设计约束等方面的期望。

需求定义是需求工程的第一步，它通过对应用问题及其环境的理解与分析，将用户需求精确化、标准化，最终形成规范的需求说明书，从而为问题涉及的信息、功能及系统行为建立模型。

企业信息系统的需求是开发项目最难把握的问题之一，许多开发项目的经验证明，用户对系统的需求始终处于变化之中，有些开发项目都快完成了，而用户还有新的需求在提出。特别是目前大部分较小的开发项目往往轻视系统调查或者调研过程过于简单，造成用户需求定义不准，使得系统难以达到预期目标，有的还需要二次开发和修改，浪费了大量的人力和财力。

影响需求定义的因素很多。首先是不符合国际通行的规范，主要症状表现为需求内容的层次不清晰，往往是庞杂软件需求细节的简单堆砌，很难从高层次上理解软件产品“为什么做和做什么“。

其次是需求对象的不确定性，可以说需求是一种模型，是产品的早期雏形，通过进行需求分析，我们可以对最终产品做出优化，需要始终保持注意的是，需求是始终处于变化之中的。

再就是系统分析人员和用户之间的沟通问题，由于他们的知识背景不同，看问题的角度不一样，造成了沟通上的差异。

需求工程无疑是当前系统开发中的关健问題，美国在2005年开始对全国的8000个轼件项目进行跟踪调查，结果表明，有1/3的项目没能完成，而在完成的2/3项目中，又有1/2的项目没有成功实施。仔细分析这些失败的原因后发现，与需求过程相关的原因占了45％，而其中缺乏最终用户的参与以及需求定义不准又是两大首要原因，各占13％和12。

用户需求是整个开发项目最关键的一个输入，和一般的工程项目相比较，信息系统的需求具有模糊性、不确定性、变化性和主观性的特点，他不像水利工程、建筑工程等实体项目的需求，是有形的、客观的可描述的、可检测的，所以，需求定义是系统开发最难把握的问题，主要表现在以下方面：

需求描述：不幸的是，在我们开发的项目中，大多数系统的需求事先都难以说清，更谈不上完整的定义。

一方面，用户心目中的“需求”只是一个模糊概念，即使在开发者开发者的再三启发下，用户也只能把有关系统的功能等一些模糊概念加以重新阐述，使之成为具体细节。

另一方面，系统分析人员只起着询问者或顾问的作用，他们不可能很难楚地了解具体业务细节和全部要求，因此，在大量与用户交换意见的过程中，传错信息和发生误解的可能性极大，尽管需求定义过程一直强调需求获取是一个不断地启发、揭示和判断过程，然而，问题是我们应如何进行这个过程，人们对已经存在的事物总是容易作出评价的，却不善于描述不存在的东西。

更不幸的是，不同的业务人员对同一业务过程的描述也会是不尽相同的。不同层次的用户关心的问题也是不一样的，想要每个用户都成为需求专家是不现实的。

有这样一个案例当系统开发完成后，业务部门讲“这不是我们最初所反映的需求，我们说的不是这样的！”。缺少正式的完整的需求文档浪费了大量的人力、物力，但是有了需求文档又出现了新的问题。曾经有不少项目经理抱怨过，在用户方进行的需求评审会完全是走形式，因为用户根本不去听他们读那上百页的需求文档。

需求完备程度：如何准确划定系统的范围？如何使需求做到没有遗漏？这确实是一个两难问题，稍大点系统要想穷举需求几乎是不可能的，每次开需求评审会时，总会冒出新的需求，以至于系统没有一个准确的范围界定。即使这样，系统还是要开发，没办法，系統的范围还要硬性划定一个，从而建立一个基线。

需求细致程度：需求到底描述到什么程度，才算可以结束了？仁者见仁，智者见智，并没有定论，如果时间允许，要想细致就总可以细下去。这样，需求定义的周期就越长，可能的变化越多，对设计的限制越严格，对需求的共性提取要求也越高，所以只要大家（客户、用户、需求分析人员、设计人员、测试人员）一致认为描述清楚了，就可以进入下阶段工作。

需求变化：在系统开发过程中如果只有一条真理的话，那一定是；需求的变化是永恒的，需求不可能是完备的。信息系统开发的过程实际上就是在不断满足变化的需求的过程，需求的变更不一定都是坏事，需求变化的原因很多，如：“开始对项目认识不全，现在需要增加需求”“用户的业务发生了变化，需求必须变化”“开始的需求弄错了＂，“需求定义不清楚”等。需求变化的问题是每个开发人员、每个项目经理都会遇到的问题，也是最头痛的问题，一旦发生了需求变化，你不得不修改你的设计、重写你的代码、修改你的测试用例、调整你的项目计划等等，需求变化的代价常常使项目搁置，为项目的正常进展带来无数的麻烦。

2、需求获取的管理

需求获取是指需求定义的过程。由于需求定义的复杂性和变化性，常常会影响到系统开发的成效，使得人们越来越重视需求获取的管理问题。使需求在受控的状态下发生变化，而不是随意变化，需求获取的管理就是要按照标准的流程来控制需求的变化。

2.1需求调研步骤

　　第一步：调研开发对象系统的组织结构、岗位设置、职责范围，可采用UC图等从功能上区分有多少个子系统，划定系统的边界，明确系统的目标。

　　第二步：调硏每个子系统所需的工作流程、功能与处理规则，收集单据、报表、帐本等原始资料，分析物流、资金流、信息流三者的关系，以及如何用数据流来表示这三者的美系。

　　第三步：设计调研方案，针对不同管理层次的用户询问不同的问题，列出问题清单或事先准备好问卷。将操作层、管理层、决策层的需求既联系又区分开来，形成一个金字塔，使下层能满足上层的需求。

　　第四步：尽量熟悉用户的业务情况，对与用户沟通的情况及时总结归纳，整理调研结果，找出新的疑点，初步构成需求基线。

　　第五步：若基线符合要求，则需求获取完毕。反之返回到第一步或第二或第三步，如此循环多次，直到需求定义使双方满意为止。

2．2需求引导　　

需求获取阶段是和用户交往最多的一段时间，而绝大部分用户是不懂得需求分析方法的，他们不知道怎样全面而又准确无误地表达自己的需求，因而对于需求分析人员来讲，需要掌握很好的方法与技巧，恰当地启发引导用户表达自己的需求，以便准确的定义需求。

1）在调研前和用户讲清楚调研的意义、过程、以及需要注意的问题。调研过程要经过多次反复，用户不一定理解这个过程，调查时一定要对用户讲清楚。

2）做好调查前的准备工作。在每次和用户见面前，要准备好问题单，对问题进行合理的分类，安排提问的次序，并事先提供给用户，便于用户准备，以提高工作效率。减少用户的反感情绪。

3）发问时要以一人为主，其他人注意记录与查找问题。

4）在用户讲解时，不要中断用户，使对方有充分的演说机会。

5）对询问的问题要有记录，这样便于整理文档，也便于统计工作量。

6）调研时注意以“IPO”图作为总体主线。在与用户接触时，最容易和用户交流的是他们的业务，即每天他们在干什么？这些业务流程基本是一样的：收到别人传来的单据报表，进行加工处理，再传给其也人。就这样“接受、处理、传出”，如此循环，就象车间里的流水生产线，原材料“输入“（input）、生产线加工、“处理process、产成品“输出＂(Output），就是＂IPO＂的基本思想，因而在调研时采用这种思想易于同用户交流。

7）注意交谈的技巧．并尽可能多的记住用户的姓名、职务、爱好等。要在用户提供的单据中提炼出其中最本质的内容来。在调研开始、结束、中间疲劳时适当的闲侃，拉近和用户的距离，尽量与用户交朋友

2．3需求获取管理的要点

需求共识：需求管理的首要任务在于使开发人员和用户双方对于需求都有一个明确的认识。因此用来进行需求定义的语言组织应当使所有相关人员都能够理解，进而对整个项目有一个整体把握，并明确每个人在项目中所起的作用。要使所有相关人员达咸共识，首要的任务，就是与用户共同制定需求定义表述的规范，必要时可对项目参加者进行基础知识培训，使用户尽可能通过术语的形式表述需求，这种表述应当使每一位开发者明确自己的职责所在，并且清楚知道不同开发工作之间的关联。

以流程为主线：在与用户交流的过程中，应该用流程将所有的内容串起来如单据、信息、组织结构、处理规则等，这样便于交流沟通，符合用户的思维习惯。流程的描述既要有宏观，又要有微观。即要强调总体的业务流程、全生命周期的业务流程，又要对流程细化，有分支的业务流程。

在分析企业流程并进行优化时，要注意把握以下几方面的问题

　　1）该流程中是否存在不必要的环节？

　　2）是否可以将决策的权力下放到作业部门？

　　3）流程是否可以简化？

　　4）是否可以省略一些环节？

　　5）流程中的每个处理环节是否起到了增值的作用？

　　6）哪些流程可以并行处理？

　　7）与需求并行可提前做的设计工作有哪些？例如：数据库概念模型设计？基础数据字典设计？

需求整理与表达：需求整理可以采用穷举、归纳、抽象等方法。

采用穷举的方法可以避兔遗漏，可通过列出各种情况的排列组合达到穷举目地；

采用归納的方法可以使问题更条理化，可通过对各种情况进行综合分类达到归纳的目地；采用抽象的方法，可以发现问题实质，抓住问题的主要矛盾，忽略其次要矛盾。

在整理时可以多种手段共用，如组织结构图、业务流程图、多叉树、关系矩阵、文字叙述（对其他描述手段的一种补充）、表格（如单据调查表、帐本调查表、业务调查表、报表调查表等）图形等多种手段。对需求的描述可以从组织结构与岗位定义、业务流程、处理规则、数据项、处理功能以及相互之间的关系方面来进行。

需求变化的控制：将来用户需求的变化是很正常的现象，如果仅仅着眼于现在，而不对将来有所考虑，系统的寿命便不会长久，对用户的投资是一种浪费，故此要”防患于未然＂，将以后可能的变化予以充分的考虑。

需求中的变化一般不是突发性的变化，最常见的是项目需求的渐变问题，这种渐变很可能是用户与开发方都没有意识到的，当达到一定程度时，双方才猛然惊醒，发现已经物是人非。控制需求渐变需要把握以下几点原则：

　　1）需求一定要与投入有明确联系，否则如果需求变更的成本由开发方来承担，则项目需求的变更就成为必然了。所以，在项目的开始无论是开发方还是出资方都要明确这一条：需求变，软件开发的投入也要变。

　　2）需求的变更要经过出资者的认可，需求的变更会引起投入的变化，所以要通过出资者的认可，这样才会对需求的变更有成本的概念，能够慎重地对待需求的变更。

　　3）小的需求变更也要经过正规的需求管理流程，否则会积少成多。在实践中，人们往往不愿意为小的需求变更去执行正规的需求管理过程，认为降低了开发效率，浪费了时间。正是由于这种观念才使需求的渐变不可控，最终导致项目的失败

　　4）精确的需求与范围定义并不会阻止需求的变更。并非对需求定义的越细，越能避免需求的渐变，这是两个不同层面的问题。太细的需求定义对需求渐变没有任何效果。因为需求的变化是永恒的，并非由于需求写细了，它就不会变化了。

需求复用：需求获取是一个需要高度合作的活动，而并不是用户所说的需求的简单拷贝。作为一个分析者，必须透过用户所提出的表面需求理解他们的真正需求。询问一个可扩充的问题有助于你更好地理解用户目前的业务过程并且知道新系统如何帮助或改进他们的工作。

需求获取要充分利用所有可用的信息来源以提高效率，这些信息描述了问题域或在系统解决方案中有许多合理的特性。典型的问题是分析人员往往受其业务背景的局限并不重视领域专家的意见，尤其是对业已形成的需求文档没有很好的复用。基于此，必须对需求进行管理，使需求能够真正成为需求工程和管理的基线，使开发计划、活动和工作产品同系统需求保持一致，使需求可以复用。所以需求管理一个很重要的目标就是提高需求的复用率。

结语：

需求管理恰如裁缝的量体裁衣，它直接关系到最终产品的成型。如果一个产品满足了客户需求，那它无疑就是成功的。

需求管理的过程，从需求定义开始贯穿整个开发项目始终，力图实现最终产品同需求的最佳结合。需求获取的管理冋项目管理是密不可分的，通过对需求管理在项目进程中实施的不同任务进行分析，不难看出需求管理所起的作用。

因为对需求定义的任何改进，设计上都必须大量的返工。无序的，没有经过精心策划的需求管理是不可能产生效益的。如果我们把每一个需求的解决看作一个里程碑，并以此出发对整个开发进程进行监控，就应该对整体开发工作进行精密细致的划分，从而将需求分析具体化。从这层意义上来说，需求获取的管理是保证系统产品质量的基础。