软件工程-3种高效需求获取方法

为了获取正确的需求信息，可以使用一些基本的需求获取方法和技术。

1.建立联合分析小组

系统开始开发时，系统分析员往往对用户的业务过程和术语不熟悉，用户也不熟悉计算机的处理过程，因此在系统分析员看来，用户提供的需求信息往往是零散和片面的，需要由一个领域专家来沟通。因而，建立一个由用户、系统分析员和领域专家参加的联合分析小组，对开发人员与用户之间的交流和需求的获取将非常有用。通过联合分析小组的工作，可极大地方便系统开发人员和用户的沟通。有些学者也将这种面向联合开发小组的需求收集方法称为“便利的应用规范技术”（Facilitated Application Specification Techniques，FAST）。有人主张，在参加FAST小组的人员中，用户方的业务人员应该是系统开发的主体，是“演员”和“主角”；系统分析员作为高层技术人员，应成为开发工作的“导演”；其他的与会开发人员是理所当然的“配角”。切忌在需求获取阶段忽视用户业务人员的作用，由系统开发人员越俎代庖。

2.客户访谈

为了获取全面的用户需求，光靠联合分析小组中的用户代表是不够的，系统分析员还必须深入现场，同用户方的业务人员进行多次交流。根据用户将来使用软件产品的功能、频率、优先等级、熟练程度等方面的差异，将他们分成不同的类别，然后分别对每一类用户通过现场参观、个别座谈或小组会议等形式，了解他们对现有系统的问题和新功能等方面的看法。

客户访谈是一个直接与客户交流的过程，既可了解高层用户对软件的要求，也可以听取直接用户的呼声。由于是与用户面对面的交流，如果系统分析员没有充分的准备，容易引起用户的反感，从而产生隔阂，所以分析员必须在这个过程中尽快找到与用户的“共同语言”，进行愉快地交谈。在与用户接触之前，先要进行充分的准备：首先，必须对问题的背景和问题所在系统的环境有全面的了解；其次，尽可能了解将要会谈用户的个性特点及任务状况；最后，事先准备一些问题。在与用户交流时，应遵循循序渐进的原则，切不可急于求成，否则欲速则不达。

3.问卷调查

所谓“问卷调查法”，是指开发方就用户需求中的一些个性化的、需要进一步明确的需求（或问题），通过采用向用户发问卷调查表的方式，达到彻底弄清项目需求的一种需求获取方法。这种方法适合于开发方和用户方都清楚项目需求的情况。因为开发方和客户方都清楚项目的需求，则需要双方进一步沟通的需求（或问题）就比较少，通过采用这种简单的问卷调查方法就能使问题得到较好的解决。

4.问题分析与确认

不要期望用户在一两次交谈中，就会对目标软件的需求阐述清楚，也不能限制用户在回答问题过程中的自由发挥。在每次访谈之后，要及时进行整理，分析用户提供的信息，去掉错误的、无关的部分，整理有用的内容，以便在下一次与用户见面时由用户确认。同时，准备下一次访谈时的进一步更细节的问题。如此循环，一般需要2～5次。

5.快速原型法

通常，原型是指模拟某种产品的原始模型。在软件开发中，原型是软件的一个早期可运行的版本，它反映最终系统的部分重要特性。如果在获得一组基本需求说明后，通过快速分析构造出一个小型的软件系统，满足用户的基本要求，就使得用户可在试用原型系统的过程中得到亲身感受并受到启发，做出反应和评价，然后开发者根据用户的意见对原型加以改进。随着不断试验、纠错、使用、评价和修改，获得新的原型版本。如此周而复始，逐步减少分析和通信中的误解，弥补不足之处，进一步确定各种需求细节，适应需求的变更，从而提高了最终产品的质量。

作为开发人员和用户的交流手段，快速原型可以获取两个层次上的需求：第一层包括设计界面，这一层的目的是确定用户界面风格及报表的版式和内容；第二层是第一层的扩展，用于模拟系统的外部特征，包括引用了数据库的交互作用及数据操作、执行系统关键区域的操作等，此时用户可以输入成组的事务数据，执行这些数据处理的模拟过程，包括出错处理。

在需求分析阶段采用快速原型法，一般可按照以下的步骤进行：

（1）利用各种分析技术和方法，生成一个简化的需求规约；

（2）对需求规约进行必要的检查和修改后，确定原型的软件结构、用户界面和数据结构等；

（3）在现有的工具和环境的帮助下，快速生成可运行的软件原型并进行测试、改进；

（4）将原型提交给用户评估并征求用户的修改意见；

（5）重复上述过程，直到原型得到用户的认可。

表3-3总结了使用原型实现方法的优点和缺点。(www.xing528.com)

表3-3　原型实现方法的优缺点

由于开发一个原型需要花费一定的人力、物力、财力和时间，而且用于确定需求的原型在完成使命后一般就被丢弃，因此，是否使用快速原型法必须考虑软件系统的特点、可用的开发技术和工具等方面。表3-4中的6个问题可用来帮助判断是否要选择原型法。

表3-4　原型实现方法的选择

先进的快速开发技术和工具是快速原型法的基础。如果为了演示一个系统功能，需要手工编写数千行甚至数万行代码，那么采用快速原型法的代价就太大，变得没有现实意义了。为了快速开发出系统原型，必须充分利用快速开发技术和复用软件构件技术。

1984年，Boar提出一系列选择原型化方法的因素，包括应用领域、应用复杂性、客户特征以及项目特征。如果是在需求分析阶段要使用原型化方法，必须从系统结构、逻辑结构、用户特征、应用约束、项目管理和项目环境等多方面来考虑，以决定是否采用原型化方法。

（1）系统结构。联机事务处理系统、相互关联的应用系统适合于用原型化方法，而批处理、批修改等结构不适宜用原型化方法。

（2）逻辑结构。有结构的系统，如操作支持系统、管理信息系统、记录管理系统等适合于用原型化方法，而基于大量算法的系统不适宜用原型化方法。

（3）用户特征。不满足于预先做系统定义说明、愿意为定义和修改原型投资、不易肯定详细需求、愿意承担决策的责任、准备积极参与的用户是适合于使用原型的用户。

（4）应用约束。对已经运行系统的补充，不能用原型化方法。

（5）项目管理。只有项目负责人愿意使用原型化方法，才适合于用原型化的方法。

（6）项目环境。需求说明技术应该根据每个项目的实际环境来选择。

当系统规模很大、要求复杂、系统服务不清晰时，在需求分析阶段先开发一个系统原型是很值得的，特别是当性能要求比较高时，在系统原型上先做一些试验也是很必要的。

为了有效实现软件原型，必须快速开发原型，以使得客户可以评估其结果并及时变更。可以使用3类方法和工具来进行快速原型实现。

（1）第四代技术（4GT）。第四代技术包含广泛的数据库查询和报表语言，程序和应用生成器，以及其他很高级的非过程语言。4GT使软件工程师能快速生成可执行代码，因此它们是理想的快速原型实现工具。

（2）可复用软件构件。结合原型实现方法和程序，构件复用只能在一个库系统已经被开发以便存在可以被分类和检索的构件的情况下，才可以有效地工作。特殊的是，现有的软件产品可被用做“新的、改进的”替代产品的原型，这在某种意义下也是一种软件原型实现的复用形式。

（3）形式化规约和原型实现环境。过去20年中已经开发出了一系列的形式化规约语言和工具来替代自然语言规约技术。现在，正在继续开发交互式的环境，使得分析员能够交互地创建基于语言的系统或者软件规约；激活自动工具把基于语言的规约翻译成可执行代码，使得客户可以使用原型可执行代码去精化形式化需求。