需求工程是一个不断反复的需求定义、文档记录、需求演进的过程 ,并最终在验证的基础上完成需求规范。
需求工程相关的方法和技术：
-
结构化需求抽取方法
需求工程支持结构化的需求抽取过程，为需求的抽取过程提供构型未来系统的理念,提供需求抽取的线索、需求描述的框架和需求抽取方法论,明确指出需求抽取过程中所涉及的有关问题及其正确的处理方法,从而保证抽取过程的质量，并提供系统化、工程化的指南和有效的支持工具 ,使得需求信息的无二义性、完整性和一致性。 -
系统化的需求建模方法
需求工程支持系统化的需求建模过程和途径,为软件需求模型提供预定义的语义解释和预定义的语义约束,支持需求提供者和系统开发者从语义上正确地理解所获得需求信息的含义,使得需求提供者可以正确地判断当前已提供的需求信息是否真正表达了他们自己的意图,也使得系统开发者可以了解自己对需求提供者所提供需求信息的理解程度。软件项目成功的关键是开发者真正理解并在软件中正确地表达用户的意图。 -
形式化的需求验证技术
形式化的验证技术是在形式化需求模型基础之上进一步保证需求信息正确性的手段。 它采用精确的数学语言来表达需求模型,并借助于数学推导的手段 ,使得需求模型中含糊的、不完整的、矛盾的以及无法实现的表述能够被准确地发现,从而尽早得到纠正。形式化需求验证技术一般分为3类,分别是代数方法、基于模型的方法和基于进程代数的方法 ,它们分别适用于描述和分析不同类型的软件系统。
形式化需求验证技术的作用分为两个方面: 一方面是验证需求提供者的意图可满足性 (即需求模型的有效性）;另一方面是验证需求模型的可实现性 (即需求模型的正确性)，这一点使得形式化需求验证技术和一般的形式化方法得以区别开来。形式化需求验证的意义在于: 如果方法被正确使用的话，对于特定的语义是有充分定义的。 -
用户访谈
用户访谈是一种最基本的需求获取手段，它是指分析人员以个别访谈或小组会议的形式与用户进行初步的沟通。用户访谈的形式包括结构化和非结构化两种，结构化是指分析人员按照一定准则事先准备好一系列问题，通过用户对问题的回答来获取有关目标软件方面的内容；非结构化则是只列出一个粗糙的想法，根据访谈的具体情况来进行发挥。
优点：灵活性强，可以不拘于形式，问题内容较有弹性，又可随时补充，这是填写问卷达不到的。
缺点：被访谈者回答问题可能会有所保留；访谈时信息量大，难以记录；时间安排等等。 -
用户调查
在进行用户访谈时，由于很多关键人员的时间有限，不易安排过多的时间或者项目涉及的客户面较广，不可能一一访谈。因此，就需要借助用户调查的方法，通过精心设计要问的问题，然后下发到相关的人员手中，让他们填写，再从所填写的内容中获取系统的需求信息，这样就可以克服上述的问题。
优点:预测来源于用户期望,较好地反映了市场需求情况;可以了解用户对产品优缺点的看法,也可以了解一些用户不喜欢这种产品的原因,有利于改进与完善产品、开发新产品和针对性地开展促销活动。
缺点:很难获得用户的通力合作;用户期望不等于实际购买,而且其期望容易发生变化;由于对用户知之不多,调查时需耗费较多的人力和时间；缺乏灵活性，而且可能存在受调查人员不能很好表述自己想法的限制。。 -
现场观摩
俗话说，百闻不如一见，对于许多较为复杂的流程和系统而言，是很难用自然语言表达清楚的。因此，为了能够对系统的需求获得全面的了解，实际观察用户的操作过程就是一种行之有效的方法。现场观摩就是走到客户的工作场所，一边观察，一边听客户讲解，甚至可以安排人员跟随客户一起工作一段时间。这样就可以使得分析人员对客户的需求有更加直观的理解。但是，在现场观摩过程中必须切记：建造软件系统不仅仅只是为了模拟客户的手工操作过程，还必须将最好的经济效益、最快的处理速度、最合理的操作流程和最友好的用户界面等作为软件设计的目标。
优点：百闻不如一见，能够对需求与业务流程建立直观的认识。
缺点：消耗时间长，而且由于“被观摩”的微妙心理变化，会使得“观摩”失真。 -
文档考古
文档考古是指对历史存在的一些文档进行研究，从带有数据的文件、表单、报表等文档中获取所需信息的过程。对于一些数据流程比较复杂的、工作表单较多的项目来说，就可以应用这种方法。
优点：可以比较贴合现代的技术直观的分析数据流细节进行分析等。
缺点：一般文档都会有很多，会消耗大量的时间等。 -
建立联合分析小组
在系统开发时，系统分析员和用户之间由于知识结构的差异，难免存在难逾越的交流鸿沟。
用户提供的需求信息，在系统分析员看来可能是零散和片面甚至无法理解的。因此，为了能够减少交流上的问题，就需要一个领域专家来帮助进行沟通，即可以建立一个由用户、系统分析员和领域专家参加的联合分析小组来共同完成需求的获取。
优点：客户、开发人员直接的头脑风暴，是击破需求盲点的关键手段。
缺点：成本高，如果缺乏控制会变成一次闲扯大会。 -
原型法
原型是在软件开发中被广泛使用的一种工具，在软件系统的很多开发阶段都起着非常重要的作用。原型法就是尽可能快地建造一个粗糙的系统，这系统实现了目标系统的某些或全部功能，但是这个系统可能在可靠性、界面的友好性或其他方面上存在缺陷。建造这样一个系统的目的是为了考察某一方面的可行性，如算法的可行性，技术的可行性，或考察是否满足用户的需求等。原型是在最终系统产生之前的一个局部真实表现，可以让人们能够对一些具体问题进行基于实物的有效沟通，从而帮助人们尽早解决软件开发中存在的各种不确定性。
原型主要有三种类型：探索型，实验型，进化型。探索型的目的是要弄清楚对目标系统的要求，确定所希望的特性，并探讨多种方案的可行性，实验型是用于大规模开发和实现前，考核方案是否合适，规约说明是否可靠；进化型的目的不在于改进规约说明，而是将系统建造得易于变化，在改进原型的过程中，逐步将原型进化成最终系统。
对于原型法的使用也有两种不同的策略：废弃策略和追加策略。废弃策略是指先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改，形成比较好的思想，据此设计出较完整、准确、一致、可靠的最终系统，系统构造完成后，原来的模型系统就被废弃不用。探索型和实验型属于这种策略。追加策略则与之不同，它是指在原模型的基础之上不断增加和修改，最终产生实用的系统。
在需求模糊的不确定性较大的情况下，使用原型方法来进行需求信息的获取尤其有效。
优点：用户与开发者思想易于沟通；使用软件工具效率高，摆脱了传统方法。
缺点：原型法不适用于开发大型的信息系统；如果用户合作不好，盲目纠错，会拖延开发进程。 -
模型驱动
前面的面谈、原型、观察以及文档审查等方法可以通过执行一些具体的获取行为来对系统需求进行认知和理解。但是大多数软件系统，尤其是对于复杂的系统而言，它们的需求获取任务绝不是可以通过一两次这样简单的获取行为就能够完成的。为了能够使得获取行为相互配合、减少不必要的精力耗费和防止出现获取信息的遗漏，可以采用模型驱动的方法。
模型驱动方法是一类以定义明确的模型为理论基础，依据模型指导和组织活动开展的需求获取方法。这些方法的模型定义确定了所要收集的信息类型，模型的建立和完善的过程就是进行需求获取的过程。常见的模型驱动方法有面向目标的方法(Goal-Oriented Methods)、基于场景的方法(Scenario-Based Methods)和基于用例模型的方法(UseCase-Based Methods)。
这里主要讨论一下基于用例模型的方法。建立用例模型是一种需求获取的有效方法，其简洁清晰的描述方式容易被软件人员和用户共同理解和接受。在用例模型中，角色和用例是两个基本概念，分别代表着系统外部的执行者和系统应包含的功能，因此，建立用例模型的主要工作是确定角色、确定用例和描述用例。用例模型以用户和任务为中心，将整个工作的焦点集中在从用户的角度说明系统能够干什么，完全不考虑具体的实现细节，从而达到准确地理解客户需求的目的。这种方法已经在许多大型系统的开发中取得成效，实践证明它能有效地解决用户参与的问题。 -
基于上下文的方法
软件系统是作为一个整体存在的，它通过和环境的交互来解决用户的问题，满足用户的需求。软件系统中的每项功能都是依存于一定的背景和上下文环境，因此，要正确地理解系统的功能就必须要正确地理解它的背景和上下文知识。基于上下文的方法就是注重于系统的环境、开发组织的业务背景、涉众的特征以及目标等。与前面的方法相比，它更加注重用户在一定环境下表现出来的行为，通过分析用户的行为得到信息。 -
功能分解方法。
将新系统作为多功能模块的组合。各功能义可分解为若干子功能及接口，子功能再继续分解。便可得到系统的雏形，即功能分解—功能、子功能、功能接口。
功能分解法是以系统提供的功能为中心来组织系统。首先定义各种功能，然后把功能分解为子功能，同时定义功能之间的接口。数据结构是根据功能/子功能的需要设计的。其基本策略是以分析员的经验为依据，确定新系统所期望的处理步骤或子步骤，然后将问题空间映射到功能和子功能上。 -
结构化分析方法。
结构化分析方法是一种从问题空间到某种表示的映射方法，是结构化方法中重要且被普遍接受的表示系统，由数据流图和数据词典构成并表示。此分析法又称为数据流法。其基本策略是跟踪数据流，即研究问题域中数据流动方式及在各个环节上所进行的处理，从而发现数据流和加工。结构化分析可定义为数据流、数据处理或加工、数据存储、端点、处理说明和数据字典。问题域被映射为由数据流、加工以及文件、端点等成份构成的数据流图（DFD），并用数据字典对数据流和加工进行详细说明。
优点：逻辑设计与物理设计分开；开发过程中形成一套规范化的文档，便于后期的修改和维护缺点
缺点：开发周期长；系统难以适应环境的变化；开发过程复杂繁琐 -
信息建模方法。
它从数据角度对现实世界建立模型。信息建模分析方法的核心概念是实体和关系，主要工具是语义数据模型，其基本策略是找出现实世界的对象，然后用属性来描述对象，增添对象与对象之间的关系，定义父类与子类，用父类型/子类型提炼属性的共性，用关联对象关系作细化的描述，最后进行规范化处理。其实质是将问题空间直接映射成模型中的对象，基本工具是E-R图，其基本要素由实体、属性和联系构成。该方法的基本策略是从现实中找出实体，然后再用属性进行描述。
大型软件较复杂；很难直接对其分析和设计，常借助模型。模型是开发中常用工具，系统包括数据处理、事务管理和决策支持。实质上，也可看成由一系列有序模型构成，其有序模型通常为功能模型、信息模型、数据模型、控制模型和决策模型。有序是指这些模型是分别在系统的不同开发阶段及开发层次一同建立的。建立系统常用的基本工具是E-R图。经过改进后称为信息建模法，后来又发展为语义数据建模方法，并引入了许多面向对象的特点。 -
面向对象的分析方法。
面向对象的分析方法的关键是识别问题域内的对象，分析它们之间的关系，并建立三类模型，即对象模型、动态模型和功能模型。面向对象主要考虑类或对象、结构与连接、继承和封装、消息通信，只表示面向对象的分析中几项最重要特征。类的对象是对问题域中事物的完整映射，包括事物的数据特征(即属性)和行为特征(即服务)。
面向对象分析的基本策略是通过信息隐藏将比较容易变化的元素隐藏起来，分析员基于比较稳定的元素建立其思想和规格说明的总体结构。
面向对象分析的主要特性是加强了对问题域和系统责任的理解；改进与分析有关的各类人员之间的交流；对需求的变化具有较强的适应性；支持软件复用。
优点：与人们习惯的思维方法一致；稳定性好；可重用性好; 可维护性好。
缺点：对系统开发的人力、财力和物力要求比较高；由于缺乏全局性控制，会造成系统结构不合理、各部分关系失调等问题。 -
面向本体分析方法
面向本体的需求分析，是面向对象分析方法的有效补充和提升。面向本体方法强调相关领域的本质概念以及这些概念之间的关联。其实质是在面向对象方法中引入对象关联，并给出各种关联的语义语用。
面向本体的需求分析方法由4个阶段来完成。第一阶段：用一种自然语言BIDL（Bisiness Information Description Language）描述事务；第二阶段：确认隐含在BIDL文本中的本体和对象；第三阶段：将这些本体和对象转换成另一种语言Ononet（Ontology and Object-Ori-entedNetwork），得到用Ononet书写的需求预定义；第四阶段：在采用Ononet作为知识表示形式的领域本体知识库中搜索相关的知识，并和前面的需求预定义合并，得到软件完整的需求定义。 -
形式化分析方法
形式化分析方法广义上讲，是应用数学的手段来设计、模拟和分析，得到像数学公式那样精确的表示。从狭义上讲，就是使用一种形式语言进行语言公式的形式推理，用于检查语法的良构性并证明某些属性。在需求分析阶段，利用形式化方法得到需求规格说明书，可以规范软件开发过程，为获得更好的系统性能提供重要保证。
优点：形式化说明以逻辑精确性为特色, 除去了在非形式化说明中不可避免的大部分含糊不清的描述, 这种精确性为开发人员与用户对需求的一致性理解, 及需求的正确执行提供了更大的可能性；形式化证明通过对需求分析中所描述的系统行为提供逻辑的精确论证, 除去了需求分析中的模糊性和主观性。
缺点：形式化方法中所包含的数学理论，限制了大多数程序设计人员的学习和使用；许多流行的形式化方法对于较小规模的项目是有效的，但却很难应用于一些大型系统；形式化方法不能确保开发出完全正确的软件。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
