2.2 需求获取的技术

2.2.1 需求分析中出现的问题

在需求获取的过程中，可能会发现对产品范围的定义存在误差，不是太大就是太小。如果范围太大，则将要收集比真正需要更多的需求，以传递足够的业务和客户的值，此时获取过程将会拖延。如果项目范围太小，那么客户将会提出很重要的但又在当前产品范围之外的需求。由于当前的范围太小，以致不能提供一个令人满意的产品。需求的获取将导致修改项目的范围和任务，但做出这样具有深远影响的改变，一定要小心谨慎。正如人们常说的，需求主要是关于系统做什么，而解决方案如何实现是属于设计的范围。这样说虽然很简洁，但似乎过于简单化。需求的获取应该把重点放在“做什么”上，但在分析和设计之间还是存在一定的距离。可以使用假设“怎么做”来分类并改善对用户需求的理解。在需求的获取过程中，分析模型、屏幕图形和原型可以使概念表达得更加清楚，然后提供一个寻找错误和遗漏的办法，把在需求开发阶段所形成的模型和屏幕效果看成是方便高效交流的概念性建议，而不应该看成是对设计者选择的一种限制。因此，需求获取面临的挑战主要是对问题空间的理解、人与人之间的通信，以及需求的不断变化。需求分析阶段的结果是开发的基础，关系到系统的成败和质量，在实现这一阶段任务时必须要注意三个问题。

1．交流障碍

一个项目的参与者既包括系统分析员，又包括系统用户、问题领域专家和项目管理者，这些人具备不同的背景知识，处于不同的角度，扮演不同的角色，造成了相互之间的交流的困难。

2．问题的复杂性

造成问题复杂性的原因，一方面是由于用户需求所涉及的因素繁多引起的，如运行环境和系统功能等；另一方面是应用领域本身的复杂性。

3．不完整性和不一致性

由于用户对于系统的要求所处的角度不一样，所以对问题的陈述往往是不完备的。如果用户使用了不易理解的专门术语，或用户与分析员对要求的内容做出不同的解释，则可能造成分析的不一致。

为了克服需求分析的困难，就要求双方必须在需求分析过程中加强沟通和协调，开发人员必须花费足够的时间，全面了解用户的需求，绝不能在需求模糊的情况下仓促进行软件设计和编程。不适当的需求过程所引起的一些风险如下：

（1）无足够用户参与。每个软件产品都是为了使其用户能以某种方式改善他们的工作和生活环境，因此，必须让更多的用户参与需求分析。用户并不明白为什么收集需求和确保需求质量要花费大量的时间，而开发人员可能也不重视用户的参与。通常开发人员认为已经了解了用户的需求，并且还有一些是很难直接与用户接触的。但是无论何种情况，用户参与对于成功的软件开发是有必要的。

（2）用户需求的不断增加。在开发中不断补充需求，项目就会越变越大，并不断补充新的代码，造成系统的整体结构混乱，且难以理解和维护。如果尽早区别可能带来的需求变更，更容易开发出一个更为健壮的软件系统。

（3）模棱两可的需求。模棱两可的需求是软件需求分析的最大问题，主要是指不同的人员对需求说明产生不同的理解，并且对所理解的需求说明产生不同的解释，使开发人员为错误问题而浪费时间，造成不可避免的返工，重做一些认为已经完成的事情。处理这一类问题的办法最好是组织从不同角度审查需求的人员，不同的审查者从不同的角度对需求说明给予解释。

（4）不必要的特性。“画蛇添足”常是开发人员为增加一些用户欣赏但需求说明中并未有的功能，在其上耗费了大量的精力，结果是用户并不认为这些功能有用。为了将“画蛇添足”的危害尽量减少，应明确为什么要包括这些功能，以及这些功能的来源，使得需求分析过程始终是注重那些能使用户完成业务任务的核心功能。

（5）过于简练的需求说明。客户和开发人员经常不清楚需求说明文档的重要性，只是做一份简略的规格说明，然后让开发人员在项目进展过程中去完善，结果可能出现开发人员先建立产品的结构之后再完成需求说明。往往造成客户并不满意最终的产品，给开发人员带来很大挫折。

（6）忽略了用户分类。大多数产品是由不同的人使用其不同的特性，使用频繁程度也有所差异，使用者受教育程度和经验水平也不尽相同。如果不能在项目早期就针对所有这些主要用户进行分类，必然导致有些用户对产品不满意。因此，依据不同的用户细分相应的需求有助于开发出满意的产品。

（7）不准确的计划。对需求分析缺乏理解会导致过分乐观的估计，特别是完成时间和成本的估计往往不足。主要原因是频繁的需求变更、遗漏的需求、与用户交流不够、质量低下的需求规格说明和不完善的需求分析等方面。未经准备的估计通常作为一种猜测给出的，应尽力给出可达到的目标并坚持完成它。

2.2.2 需求获取的基本原则

需求获取的基本原则如下。

1．深入浅出

对企业的需求调研要尽可能的全面细致，调研的需求是个全集，系统真正实现的是个子集。所做的工作可能一时看不到有什么作用，但是这样做可以对应用领域的业务吃得很透，能够避免一些不必要的麻烦，如可以保证系统的灵活性等。调研细致并不等于在分析时都面面俱到地将调研的内容纳入到新系统中，而有可能实现得很少，但再向细处扩充时将会很容易。即当新系统设计出来时，开发人员很清楚新系统与旧系统相符合的程度，还有多大的余地或工作可以做，对用户提出的一些细致的问题都能够在系统中找到解决方法。

2．以流程为主线

在与用户交流的过程中，应该用流程将所有的内容串起来，如单据、信息、组织结构和处理规则等。这样便于交流沟通，符合用户的思维习惯。流程的描述既要有宏观，又要有微观。既要强调总体的业务流程、全生命周期的业务流程，又要对流程细化，添加相应的分支业务。在分析企业流程并进行优化时，要把握如下几个方面。

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

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

（3）流程是否可以简化？

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

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

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

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

因此，需求分析的原则是：

（1）分析人员要使用符合用户语言习惯的表达方式，更多地了解用户的业务知识和系统实现的目标，获得用户功能和质量要求的系统。

（2）分析人员对所获得的需求进行解释说明，形成软件需求报告。

（3）分析人员同时兼顾开发人员的建议和解决方案，尊重开发人员的需求和成本估计。

（4）分析人员要考虑可能存在的需求变更，遵照需求变更的控制过程。

（5）认真评审需求分析文档。

2.2.3 需求获取的常用技术

在需求工程中，需求获取阶段是和用户交往最多的一段时间。而绝大部分用户不懂得需求分析方法，他们不知道如何全面而又准确无误地表达自己的需求。因而对于需求分析人员来讲，需要掌握很好的方法与技巧，恰当地启发引导用户表达自己的需求，以便为项目的成功提供一个很好的基石。系统分析员为了获取正确的需求信息，通常使用一些基本的需求获取方法和技术，包括以下几种常见技术。

1．跟班作业

通过亲身参加业务工作来了解业务活动的情况。这种方法可以比较准确地理解用户的需求，但比较耗费时间。首先确定谁、什么、哪里、什么时候、为什么、如何观察；并从相应的主管和经理那里获得许可；通知被观察的人观察的目的；并且保持较少的记录。

2．开调查会

通过与用户座谈来了解业务活动情况及用户需求。座谈时，参加者之间可以相互启发。分析员可以使用它从回答者那里收到信息和观点。

3．请专人介绍

请有经验的人介绍情况。

4．询问

对某些调查中的问题，可以找专人询问。面谈是最重要和最常用的方法。

5．设计调查表，请用户填写

如果调查表设计得合理，这种方法是很有效的，用户也很易于接受。

6．查阅记录

查阅记录是指查阅与原系统有关的数据记录，包括原始单据、账簿、报表等。对现有文档、表格和文件进行抽样，包括办公室的便函、建议箱、客户抱怨、任务陈述、战略计划、工作目标、政策条款、操作规程、手册、报表样本等相关的原始文件。

比如，学生档案管理系统。

（1）跟班作业。需求分析人员和档案管理人员在一起工作，了解业务流程，咨询和记录业务活动。

（2）开调查会。约定时间和有关部分进行沟通，理解需求。

（3）请专业人员进行培训，讲解档案系统工作内容的方方面面。

（4）不清楚的时候，询问相关负责人或处理相关档案手续的人。

（5）根据前面的分析，设计合理的调查表，请用户填写。

（6）查询以前管理模式下的文档、数据记录。比如学生档案表所涉及的内容、相关需要打印的表等。