软件需求获取

出自 MBA智库百科(https://wiki.mbalib.com/)

软件需求获取(Software Requirement Elicitation)

　　软件需求获取是需求工程的主体。对于所建立的软件产品来说，获取需求是一个确定和理解不同用户类的需要和限制的过程。获取需求的一个必不可少的结果是对项目中描述的客户需求的普遍理解。一旦理解了需求，分析者、开发者和客户就能探索出描述这些需求的多种解决方案。参与需求获取者只有在他们理解了问题之后才能开始设计系统，否则，对需求定义的任何改进，设计上都必须大量的返工。

　　需求获取是在问题及其最终解决方案之间架设桥梁的第一步。获取需求的一个必不可少的结果是对项目中描述的客户需求的普遍理解，一旦理解了需求，分析者、开发者和客户就能探索出描述这些需求的多种解决方案。

　　需求包括业务需求、用户需求和功能需求以及非功能需求，在需求开发之前，需要先定义好需求开发的过程，形成文档，内容包括：需求开发的步骤，每一个步骤如何实现，如何处理意外情况，如何规划开发资源等。需求获取就是进行需求收集的一个活动，它从人员、资料和环境中得到系统开发所需要的相关信息。

　　需求获取是一个需要高度合作的活动，并不是客户所说的需求的简单誊本。作为一个分析者，你必须透过客户所提出的表面需求理解他们的真正需求。需求获取不是一个简单地进行知识转移的活动，为了能够解决需求获取中普遍存在的问题，获取活动至少要做到：确定待获取信息的内容；确定待获取信息的来源；确定应采取的获取方法；执行获取；记录获取成果。

　　需求获取可能是软件开发中最困难、最关键、最易出错及最需要交流的方面。需求获取只有通过有效的客户一开发者的合作才能成功。

　　在需求分析的初期，分析人员对问题知之甚少，用户对问题的描述、对目标软件的要求通常也是相当零乱和模糊的。更为严重的是，分析人员与用户的知识领域不同，从而造成相互理解方面的困难。因此，在需求分析过程中，为了能够获得系统真正的需求，往往需要进行需求捕获，也就是去寻找需要与软件系统开发有关的系统信息。

　　对需求问题的全面考察需要一些相关的技术和方法，这些技术和方法不但考虑了问题的功能需求方面，还可通过讨论获得项目的非功能需求。

　　常用的需求获取方法包括以下几种：

　　1、用户访谈

　　用户访谈是一种最基本的需求获取手段，它是指分析人员以个别访谈或小组会议的形式与用户进行初步的沟通。用户访谈的形式包括结构化和非结构化两种，结构化是指分析人员按照一定准则事先准备好一系列问题，通过用户对问题的回答来获取有关目标软件方面的内容；非结构化则是只列出一个粗糙的想法，根据访谈的具体情况来进行发挥。

　　2、用户调查

　　在进行用户访谈时，由于很多关键人员的时间有限，不易安排过多的时间或者项目涉及的客户面较广，不可能一一访谈。因此，就需要借助用户调查的方法，通过精心设计要问的问题，然后下发到相关的人员手中，让他们填写，再从所填写的内容中获取系统的需求信息，这样就可以克服上述的问题。

　　用户调查最大的不足就是缺乏灵活性，而且可能存在受调查人员不能很好表述自己想法的限制。

　　3、现场观摩

　　俗话说，百闻不如一见，对于许多较为复杂的流程和系统而言，是很难用自然语言表达清楚的。因此，为了能够对系统的需求获得全面的了解，实际观察用户的操作过程就是一种行之有效的方法。现场观摩就是走到客户的工作场所，一边观察，一边听客户讲解，甚至可以安排人员跟随客户一起工作一段时间。这样就可以使得分析人员对客户的需求有更加直观的理解。但是，在现场观摩过程中必须切记：建造软件系统不仅仅只是为了模拟客户的手工操作过程，还必须将最好的经济效益、最快的处理速度、最合理的操作流程和最友好的用户界面等作为软件设计的目标。

　　4、文档考古

　　文档考古是指对历史存在的一些文档进行研究，从带有数据的文件、表单、报表等文档中获取所需信息的过程。对于一些数据流程比较复杂的、工作表单较多的项目来说，就可以应用这种方法。

　　5、建立联合分析小组

　　在系统开发时，系统分析员和用户之间由于知识结构的差异，难免存在难逾越的交流鸿沟。

　　用户提供的需求信息，在系统分析员看来可能是零散和片面甚至无法理解的。因此，为了能够减少交流上的问题，就需要一个领域专家来帮助进行沟通，即可以建立一个由用户、系统分析员和领域专家参加的联合分析小组来共同完成需求的获取。

　　6、原型法

　　原型是在软件开发中被广泛使用的一种工具，在软件系统的很多开发阶段都起着非常重要的作用。原型法就是尽可能快地建造一个粗糙的系统，这系统实现了目标系统的某些或全部功能，但是这个系统可能在可靠性、界面的友好性或其他方面上存在缺陷。建造这样一个系统的目的是为了考察某一方面的可行性，如算法的可行性，技术的可行性，或考察是否满足用户的需求等。原型是在最终系统产生之前的一个局部真实表现，可以让人们能够对一些具体问题进行基于实物的有效沟通，从而帮助人们尽早解决软件开发中存在的各种不确定性。

　　原型主要有三种类型：探索型，实验型，进化型。探索型的目的是要弄清楚对目标系统的要求，确定所希望的特性，并探讨多种方案的可行性，实验型是用于大规模开发和实现前，考核方案是否合适，规约说明是否可靠；进化型的目的不在于改进规约说明，而是将系统建造得易于变化，在改进原型的过程中，逐步将原型进化成最终系统。

　　对于原型法的使用也有两种不同的策略：废弃策略和追加策略。废弃策略是指先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改，形成比较好的思想，据此设计出较完整、准确、一致、可靠的最终系统，系统构造完成后，原来的模型系统就被废弃不用。探索型和实验型属于这种策略。追加策略则与之不同，它是指在原模型的基础之上不断增加和修改，最终产生实用的系统。

　　在需求模糊的不确定性较大的情况下，使用原型方法来进行需求信息的获取尤其有效。

　　7、模型驱动

　　前面的面谈、原型、观察以及文档审查等方法可以通过执行一些具体的获取行为来对系统需求进行认知和理解。但是大多数软件系统，尤其是对于复杂的系统而言，它们的需求获取任务绝不是可以通过一两次这样简单的获取行为就能够完成的。为了能够使得获取行为相互配合、减少不必要的精力耗费和防止出现获取信息的遗漏，可以采用模型驱动的方法。

　　模型驱动方法是一类以定义明确的模型为理论基础，依据模型指导和组织活动开展的需求获取方法。这些方法的模型定义确定了所要收集的信息类型，模型的建立和完善的过程就是进行需求获取的过程。常见的模型驱动方法有面向目标的方法(Goal—Oriented Methods)、基于场景的方法(Scenario—Based Methods)和基于用例模型的方法(Use Case—Based Methods)。

　　这里主要讨论一下基于用例模型的方法。建立用例模型是一种需求获取的有效方法，其简洁清晰的描述方式容易被软件人员和用户共同理解和接受。在用例模型中，角色和用例是两个基本概念，分别代表着系统外部的执行者和系统应包含的功能，因此，建立用例模型的主要工作是确定角色、确定用例和描述用例。用例模型以用户和任务为中心，将整个工作的焦点集中在从用户的角度说明系统能够干什么，完全不考虑具体的实现细节，从而达到准确地理解客户需求的目的。这种方法已经在许多大型系统的开发中取得成效，实践证明它能有效地解决用户参与的问题。

　　8、基于上下文的方法

　　软件系统是作为一个整体存在的，它通过和环境的交互来解决用户的问题，满足用户的需求。软件系统中的每项功能都是依存于一定的背景和上下文环境，因此，要正确地理解系统的功能就必须要正确地理解它的背景和上下文知识。基于上下文的方法就是注重于系统的环境、开发组织的业务背景、涉众的特征以及目标等。与前面的方法相比，它更加注重用户在一定环境下表现出来的行为，通过分析用户的行为得到信息。

• 李彤，王炜，郁湧编著,软件工程概论,科学出版社,2012.02,第42页