浅谈需求捕获的技术和方法

浅谈需求捕获的技术和方法
摘要：需求捕获(Requirements elicitation)属于需求工程范畴，是收集、获取、提取、发掘客户或用户需求的过程。

常见的需求获取技术包括面谈和问卷调查、需求专题讨论会、观察用户的工作流程、基于场景的方法、原型法等。

本文详细阐述和分析了上述几种需求捕获技术方法，并比较其优缺点，同时通过案例验证了上述方法的有效性。

关键词：需求分析需求捕获场景原型面谈头脑风暴涉众
1、前言
在建筑行业中开发商和客户会详细讨论各种细节，并会反复论证建筑方案等，因为他们明白完工以后修改或变更细节的危害性。

然而，在软件开发行业中，软件项目中50%左右的问题都是在需求工程阶段埋下的祸根。

我们正处在问题定义阶段，即需求捕获阶段，在这一阶段我们必须从客户的角度，用客户的语言描述所有的东西，但是需求捕获阶段往往会面临如下几个方面的困难：
1、不清楚的客户需求
客户对需求只有朦胧的感觉，需求很难被描述清楚。

就算一些客户心里清楚想要什么，但有时却说不明白，无法阐述真正的需求。

如果客户不懂软件开发，客户也可能会提出不切实际的需求，这样就导致沟通和协商方面的困难。

2、需求自身经常变动
软件开发过程中必然会存在需求的变更，这些变化给需求捕获和分析带来很大的困难。

3、分析人员或客户理解有误
客户表达的需求，不同的分析人员可能有不同的理解，如果理解有误就会导致最终的软件产品与用户期望存在很大差异。

同时由于客户可能不懂软件系统，也可能会误解软件系统分析人员的建议或答复。

4、需求捕获阶段考虑解决方案
在需求捕获过程中，软件系统分析人员惯性思维是马上开始考虑各种可能的解决方案，但解决方案的设计应该等到需求分析阶段完成之后才开始进行，即用可能的解决方案来重新设计需求捕获产生的结果。

针对存在的各种困难，在传统的需求分析过程中，需求分析专家可以通过面谈(interviews)、场景(scenarios)、观察和社会分析（observations and social analysis）、头脑风暴(brainstorming)、原型法(prototyping)等需求捕获技术和方法，生成用户需求的基线，作为后续阶段的工作基础。

2、需求捕获技术比较
2.1面谈(interviews)
用户访谈一般需要与客户进行大量的知识交流和面对面会谈。

需求和分析工程师需要与不同的项目干系人讨论和沟通，建立对用户需求的理解。

这通常会经历5个阶段：准备访谈、计划和安排访谈日程、访谈开始和结束、引导访谈、后续的访谈整理工作等。

面谈涉众必须是思想开放的，明确真正的需求是什么，不应该有先入为主的概念。

而且必须给项目干系人一个讨论点，可能是一个问题，一个要求提案或现有系统的一个情况。

面谈涉众必须了解政治因素，许多实际需求可能因为政治因素无法进行讨论。

所以面谈的缺点：出于技术和政治因素，面谈的技术方法对于理解应用程序域和组织问题效果不好。

2.2场景(scenarios)
基于场景的需求捕获方法，又称情景实例的分析方法，是基于对应用环境的某一特定情景的描述来阐述用户的需求。

关键在于场景的抽取和描述，从场景的结构化描述中抽取活动图、场景、角色、数据关系图等，从而形成需求模型。

各种场景也是现实世界的实例，可以用语言、图表、视图等媒介来表示，是最终用户来模拟实际交互的一种场景实例。

从现实的实例出发，又归结到形式化的表示，将需求捕获过程中的所有利益相关者组织在一起，以不同类型的场景作为诱导，自然的诱导出用户对于系统的需求，并通过从场景中定义各种角色、数据以及其中的关系验证用户的描述，最终形成需求模型。

基于场景的需求捕获有点在于它从具体的应用场景出发，给出软件系统与环境的主要交互活动的客观描述。

它强调从客户熟悉的场景中，发现需求，并将场景作为一种沟通方式，使需求捕获更加直观，易于需求提供者理解和识别，充分发挥需求提供者的主动性。

但是，目前基于场景的需求捕获方法缺少公认的场景结构，不利于建立有效的场景需求分析方法。

2.3观察和社会分析（observations and social analysis）
人们常常发现很难描述他们为什么这么做，因为那看起来非常自然。

对于需求分析人员来说，客户认为很自然的事情往往不会被提到，从而该类需求可能会被忽略掉，但是这确实需求的一部分内容。

所以有时，最好的需求捕获方式就是去了解和观察客户实际的工作流程，且实际的工作流程往往不同于正式的，预先规定的流程。

通过观察业务中的过去数据包含对未来有用的信息，软件需求捕获人员分析历史数据及当前数据，从中发现隐藏的关系即关联规则等，进而预测未来可能发生的行为或发展趋势。

2.4头脑风暴(brainstorming)
由于头脑风暴使用了没有拘束的规则，大家就能够更自由地思考，进入思想的新区域，从而产生很多的新观点和问题解决方法。

参加者有了新观点和想法并大声说出来，或者在其他人提出的观点之上建立新观点。

所有的观点都会被记录下但不进行批评。

只有头脑风暴会议结束的时候，才对这些观点和想法进行评估。

头脑风暴的特点是让与会者敞开思想，使各种设想在相互碰撞中激起脑海的创造性或者发行其现实可行性，这是一种集体开发创造性思维和需求获取方法。

采用头脑风暴的需求获取方法优点在于在最短的时间内每一个人思维都能得到最大限度的开拓，能有效开阔思路，激发灵感，同时面对任何难题时再也不必一个人冥思苦想，孤独求索。

2.5原型法(prototyping)
软件的界面是人与计算机之间的媒介。

在软件开发的前期，用户对于待开发的系统很模糊，甚至没有自己的理想模型，对于软件分析人员来说，用户提出的要求就很难量化，需求细节很容易被需求分析人员忽略。

界面原型法可以使用户在较短的时间内看到待开发系统的雏形，并帮助用户完善自己的理想模型。

根据软件系统的需求产生出的软件系统界面原型，用户可以感性的认识到未来系统的功能、界面风格以及操作方式，从而能够做出判断：系统是否符合自己的期望，是否满足自己工作的需要。

针对需求分析人员来说，可以利用界面原型，通过对操作界面所完成的功能得到进一步的功能需求，并诱导用户修正自己的理想系统，提出新的需求，从而尽早获得更完整、更正确的需求。

建立软件界面原型一般需要以下2个步骤：首先是界面需求分析，即一个软件界
面的元素包括界面的主颜色、字体颜色、字体大小、界面布局、界面交互方式、界面功能分布、界面输入输出模式等。

其次是建立用户角色，指软件系统按照项目划分用户类型，能够代表某种用户特征、便于统一描述的众多用户个体的集合。

将用户集合定义为角色模型，同时赋予不同的优先级，了解记录其界面需求。

3、案例及分析
本文将通过一个医疗保险中心报销系统来解释各种方法的具体内容。

用户初始的想法和项目背景是：
XX市现医保中心统筹医疗保险报销还主要以人工的方式来完成日常业务。

不但效率低下，而且浪费大量的人力和财力。

XX市府领导经过仔细研究决定，要投入大量资金，研发一套可以完全满足本市社保新需求的，高效的，安全的，易用的，可大量降低人力物力成本的和适合本市特殊需求的医保中心统筹医疗保险报销系统。

系统功能有：
首先由业务分析师确定需求获取活动计划，为需求捕获过程提供准备，并指导需求捕获
活动的实施。

采用观察和社会分析的方法，理解当前目标组织的工作流程及结构，从当前流程、工具、人员能力、人们的态度、客户、问题以及有待改进之处等方面入手，来描述组织的当前状态，了解已有系统以怎样的方式适合于组织的，并形成业务需求记录表。

即目前的医疗报销系统主要以人工的方式来完成日常业务，包括医保中心报销、信息查询、公共业务、医疗基本信息和医疗待遇审批功能列表等。

其次，业务分析师整理出提问清单，制定访谈计划，组织协调用户进行访谈活动，根据用户的不同背景，对他们进行分类，选择用户代表，避免遗漏某一用户群的特定需求。

例如：现有软件系统存在哪些问题？
系统设计允许的最大在线用户数？
为了便于用户理解需要使用什么语言？
产品的功能有哪些？
是否授权不同用户？
用户有哪些操作？
系统设计使用对象是哪些人？等等问题清单。

同时，针对不同的用户群，准备提问单，作为用户访谈的参考。

注明访谈的对象和时间、确定准备提问的问题，问题设计不但应当关于功能需求，还应当考虑到非功能需求。

用户访谈可迭代进行，每次访谈结束，所获得的信息和问题需要进一步整理，并准备进行下一次访谈，直至访谈全部结束。

再次，系统架构师基于需求的各种场景和界面风格，制作界面原型，并确定产品的功能框架，即产品的具体功能。

同时，针对每个底层功能，说明其所处理数据项及其表现形式、数据约束，说明该功能对应的业务规则、算法，异常事件处理办法等。

在原型制定完成后，需要再跟用户进行确认原型，用户确认后需要再进行修改原型，这样反复执行，直到将用户需求调查明确、清楚。

例如：中心报销原型图
报销分类
最后，将各项需求捕获的材料送交客户，并制定会议流程召开会议，以共同确定所提出的需求，避免出现矛盾的地方，保证需求的完整性、一致性。

4、结论
需求捕获是软件工程项目的基础部分，对后继的需求分析设计及开发实施有重大影响。

如果做的好，会减少需求的变更和返工。

此外，需求捕获过程的质量也将决定客户对需求的完整性、正确性的认可。

因为这个阶段的困难性和影响力，需要需求分析人员按一个合理的模式来完成需求捕获过程，也可以灵活使用本文中介绍的一种或几种技术方法进行需求捕获。

参考文献：
[1] 李军伟. 需求捕获和需求分析方法探析[J] . 承德民族师专学报, 2010,(02).
[2] 宋礼鹏,张建华编著. 软件工程：理论与实践. 2011, 7
[3] 徐锋,陈暄编著. UML面向对象建模基础. 2006, 9(1)
[4] 刘锋,张伟,赵海燕,梅宏. 企业信息系统中基于场景的协同式需求获取方法[J] .电子
学报, 2009,(S1).
[5] 符丁,尹卓英. 关联规则挖掘发现问题的协同式需求获取方法[J]，计算机与数字工
程,2011,(04).
[6] 房彩丽,马宇翔,韩道军. 场景与视点结合的需求获取方法及应用分析[J] . 计算机时代,2011,(09).
[7] 鱼滨,张琛,郝克刚. 支持MDA的交互式需求获取方法及辅助工具[J]. 计算机科学, 2008,(08).
[8] 黄晨量,高建华. 基于场景驱动方法的跟踪依赖关系的研究[J]. 计算机工程,
2005,(19).
[9] 张伟,刘峰,赵海燕,梅宏. 一种问题驱动基于场景的协同式需求诱导方法[J]. 计算机
学报, 2008,(09).
[10] 胡树玮,张修如. 使用用例分析技术捕获需求[J]. 微机发展, 2005,(07).
[11] 陈小红,尹斌,金芝. 从交互情景出发的需求捕获方法及其支撑工具[J].计算机学报, 2011,(02).。