一. 需求获取概述

需求获取：进行需求收集的一个过程或者活动，它从人员，资料和环境中得到系统开发所需要的相关信息。

1.1 为什么要进行需求分析

传统上：开发不重视需求获取,将需求分析放在首位。
实践表明：需求分析，其前应有需求获取，其后至少要包括需求验证。
原因：系统规模和应用领域的不断扩大，需求获取的信息逐渐庞杂，需求分析人员在需求获取的过程中要面对的困难不断增加。
由于需求获取不够充分、全面所造成的项目变更工作不断升级，并导致项目无法继续进展的现象突出。

1.2 需求获取的非平凡性

普通用户缺乏概括性、综合性的表述能力；
专家用户的知识结构因渊博而具有概括性和广泛性；
开发人员在与用户接触前,先确定获取的内容主题，然后设计具体的应用环境和场景条件，由用户根据细节业务的执行来描述问题、表达期望。

1.3 需求获取的主要活动

研究应用背景，建立初始的知识框架；
根据获取的需要，采用必要的获取方法和技巧；
先行确定获取的内容和主题，设定场景；
分析用户的高（深）层目标，理解用户的意图；
进行涉众分析，针对涉众的特点开展工作。

二. 需求获取的策略

2.1 需求获取的主动性策略

“获取”强调需求分析人员在整个过程中应该充分发挥主动性。
主动性取决两点：对用户和系统的理解（对业务的理解），掌握相关的获取技巧。
如果没有对业务系统的知识了解，难以组织和发挥技巧的作用。
对业务系统的知识理解，是需求获取的基础。

总而言之：需求获取要主动，表现为有计划性，要针对不同的用户层次选择不同的方法。

2.2 需求协商

在需求获取的过程中，往往会遇到需要协商的问题。需要需求开发人员具有一定的技巧和沟通能力。

差异问题协调法则

不同的业务层面（有时即使是相同业务层面）的用户对同样的概念或者流程有不同的认识和理解，会出现一些差异，在需求整理时应该将这些差异明确标识出来，并展示给用户高层管理人员，由他们来确定如何消除这些差异，并将这些情况记录。

消除变更问题协调法则

上面法则提到的问题，从消除变更的角度考虑仍然存在问题。仅仅将差异标识并展示给高层并不能消除变更的可能，应该考虑这些差异形成背后的问题，应该从开发角度考虑如何消除这些差异，并提供给高层管理人员。要有主动性。

需求协商时机法则

不要在需求冻结前开展需求协商工作。需求协商应该在需求获取过程中不断开展，出现就考虑消除。如果都等到冻结前，将所有矛盾集中体现对工作是非常不利的。

三. 需求获取的主要方法

一般主要的需求获取的方法有如下几种：

3.1 用户调查

用户调查技术实际上是与用户访谈相关的一组技术和方法。在市场调查领域应用非常广泛。
主要优点在于调查面比较宽，用户反馈多。这恰好能够成为用户访谈的有效补充，能够克服用户访谈的片面性。
而其缺点主要是大家都认识到的往往不易深入，而这恰好是用户访谈所能避免的。用户调查是用户访谈的有效、有益的补充。

3.2 文档分析

文档分析又称文档考古或者文档审查，是一种专门针对文档进行需求获取的活动。其主要获取对象包括相关产品的需求说明书、客户需求文档、相关数据及流程说明等。
其主要优点是能够详细、直观地对数据流细节进行了解和分析。缺点也比较明显，企业机构中，文档量通常非常大，由此容易使需求获取人员陷入文山书海中不能自拔，甚至引起误导。

3.3 原型法

“原型是一个系统，它内化了（capture）一个更迟系统（later system）的本质特征。原型系统通常被构造为不完整的系统，以在将来进行改进、补充或者替代。”
如果在最终的物件（final artifact）产生之前，一个中间物件（mediate artifact）被用来在一定广度和深度范围内表现这个最终物件，那么这个中间物件就被认为是最终物件在该广度和深度上的原型。

1）原型的类别——按照开发方式分类

2）原型的类别——按照开发方式分类

探索式和实验式方法产生的原型产品又被称为抛弃式原型

花费最小的代价，争取最快的速度
可能会使用简易的开发工具和不成熟的构造技术
可能会忽略或简化处理原型目的不相关的功能特征
要坚决的抛弃

演化式原型方法产生的原型产品被称为演化式原型（evolutionary prototype）

质量要从一开始就能达到最终系统的要求
要易于进行扩展和频繁改进，因此开发者必须重视演化式原型的设计
仅应该被用于处理清晰的需求、规格说明和技术方案

3）原型方法的过程

3.4 模型驱动

指导和组织需求获取行为的开展：模型可以用于指导后续需求获取行为的开展
整理和归类需求获取行为得到的信息：模型是进行信息整理和归类的很好的框架依据
为详细信息的分析提供背景基础和上下文知识：模型驱动方法则是侧重于前期需求阶段的方法，是传统需求分析方法的一个很好的补充
帮助组织需求文档的结构
作为需求验证的知识基础：发现细节知识与模型内容的偏差和错误和指导需求验证行为的开展