需求工程方法与技术

1、需求工程概述

软件需求工程划分为需求开发和需求管理

1.1、需求开发

需求开发过程可 进 一 步 分 为 需 求 获 取(Elicitation)、需求分析(Analysis)、规格说明(Specification)和需求验证(Validation)。

1.2、需求管理

需求管理活动

2、需求工程方法与技术

2.1、问题获取

1、用户访谈

访谈是最早开始使用的获取用户需求的技术，也是迄今为止仍然广泛使用的需求获取方法。访谈有两种基本形式，分别是正式的和非正式的访谈。正式访谈时，系统分析员将提出一些事先准备好的具体问题。在非正式访谈中，分析员将提出一些用户可以自由回答的开放性问题，以鼓励被访问人员说出自己的想法。

2、用户调查

当需要调查大量人员的意见时，向被调查人分发调查表是一个十分有效的做法。经过仔细考虑写出的书面回答可能比被访者对问题的口头回答更准确。分析员仔细阅读收回的调查表，然后再有针对性地访问一些用户，以便向他们询问在分析调查表时发现的新问题。在访问用户的过程中使用情景分析技术往往非常有效。所谓情景分析就是对用户将来使用目标系统解决某个具体问题的方法和结果进行分析。

3、现场观摩

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

4、文档考古

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

5、建立联合分析小组

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

6、原型法

原型是在软件开发中被广泛使用的一种工具，在软件系统的很多开发阶段都起着非常重要的作用。原型法就是尽可能快地建造一个粗糙的系统，这系统实现了目标系统的某些或全部功能，但是这个系统可能在可靠性、界面的友好性或其他方面上存在缺陷。建造这样一个系统的目的是为了考察某一方面的可行性，如算法的可行性，技术的可行性，或考察是否满足用户的需求等。原型是在最终系统产生之前的一个局部真实表现，可以让人们能够对一些具体问题进行基于实物的有效沟通，从而帮助人们尽早解决软件开发中存在的各种不确定性。
　　原型主要有三种类型：探索型，实验型，进化型。探索型的目的是要弄清楚对目标系统的要求，确定所希望的特性，并探讨多种方案的可行性，实验型是用于大规模开发和实现前，考核方案是否合适，规约说明是否可靠；进化型的目的不在于改进规约说明，而是将系统建造得易于变化，在改进原型的过程中，逐步将原型进化成最终系统。
　　对于原型法的使用也有两种不同的策略：废弃策略和追加策略。废弃策略是指先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改，形成比较好的思想，据此设计出较完整、准确、一致、可靠的最终系统，系统构造完成后，原来的模型系统就被废弃不用。探索型和实验型属于这种策略。追加策略则与之不同，它是指在原模型的基础之上不断增加和修改，最终产生实用的系统。在需求模糊的不确定性较大的情况下，使用原型方法来进行需求信息的获取尤其有效。

7、模型驱动

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

8、基于上下文的方法

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

2.2、需求分析

一、功能分解法

1.以系统需要提供的功能为中心来组织系统。
2.首先定义各种功能，然后把功能分解为子功能。
3.对较大的子功能进一步分解，知道可给出明确的定义。
4.设计功能/子功能所需要的数据结构
5.定义功能/子功能之间的接口。
6.作为一种早期的建模方法，没有明确地区分分析与设计。

优点与缺点：
1.直接地反映用户的需求，所以工作很容易开始。
2.不能直接地映射问题域，很难检验结果的正确性。
3.对需求变化的适应能力很差。
4.局部的错误和修改很容易产生全局性的影响。
二、结构化方法

1、结构化分析，又称数据流法，其基本策略是跟踪数据流，即研究问题域中数据如何流动，以及在各个环节上进行何种处理，从而发现数据流和加工。得到的分析模型是数据流图（DFD），主要模型元素是数据流、加工、文件及端点，外加处理说明和数据字典。
2、结构化设计，与功能分解法基本相同，基于模块的概念建立设计模型，分为概要设计和详细设计。
（a）概要设计：确定系统中包含哪些模块以及模块之间的调用关系，得到模块结构图（MSD）。
（b）详细设计：描述每个模块内部的数据结构和操作流程。

优点与缺点：
i. 优点：强调研究问题域，并且有严格的法则。
ii. 缺点：仍然是间接映射问题域；分析与设计的概念不一致，从分析到设计的过渡比较困难；数据流和加工的数量太多，引起分析文档的膨胀。
三、信息建模法

1.由实体-关系法（E-R方法）发展而来。
2.核心概念是实体和关系。实体描述问题域中的事物，关系描述事物之间在数据方面的联系，都可以带有属性。
3.发展之后的方法也把实体称作对象，并使用了类型和子类型的概念，作为实体的抽象描述。
4.信息建模法已经很接近面向对象方法，因此有的文献也把它称为一种面向对象方法，但有一些差别。

四、面向对象的分析

运用对象、类、继承、封装、聚合、关联、消息、多态性等概念来构造系统。把问题域中的事物抽象为对象，作为系统的基本构成单位，其属性和操作刻画了事物的静态特征和动态特征——完整地刻画了问题域中事物。用类作为对象的抽象描述，建立它们之间的继承、聚合、关联、消息等关系——如实地表达了问题域中事物之间的各种关系。封装、继承、聚合、关联、消息通讯等原则符合人类的日常思维——使系统的复杂性得到控制。

优点：
A.对问题域和系统责任的复杂性具有较强的处理能力
B.提供了便于各类相关人员交流共同语言
C.对需求变化具有比较强的适应性
D.为实现分析与设计级别的软件复用提供了有力支持
E.贯穿软件生存周期全过程的一致性

2.3、规格说明

目前的软件规格说明方法大致可分三类：形式化、半形式化及非形式化。
一、形式化的规格说明方法

随着对软件质量和软件生产效率的要求的提高，目前广泛使用的非形式化的需求规格说明方法中存在的问题愈加突出，如需求规格说明潜在二义性，大量文档无法用计算机分析和管理，另外也无法检查规格说明的一致性与完整性。人们渐渐地认识到，彻底解决这些问题的最终措施是用数学的概念和方法来进行软件规格说明。

形式化规格说明方法一般具有如下的优点：
1 . 使用形式化规格说明语言，能在软件开发早期检查规格说明的一致性和完整性；
2 . 可对软件进行形式化的正确性证明，保证可靠性；
3 . 可按某些规则把形式化的规格说明变换成目标软件，提高软件的生产率；
4 . 对于形式化的可执行的规格说明语言，可以把需求规格说明作为系统的原型。
二、半形式化的规格说明方法

形式化方法的最大优点是便于检验最终软件产品是否与其需求规格说明一致，同时有可能使软件开发自动化。半形式化方法的出发点是使便于形式化的部分形式化，同时辅助以非形式化的手段。它有形式化的规格说明语言语法，但没有严格的数学语义。半形式化方法大都以real—world模型为基础，因而规格说明能较好地反映问题域的现实环境中对象间的关系，故较易理解。另外，模型中的对象间关系相对稳定，因此对需求的变化较为有效。

三、定义规格说明

半形式化方法，均是从问题域建立real-world模型，然后定义规格说明的。而形式化方法都假设已给定明确的用户需求。这样开发人员必须先想方法获取用户需求，然后用形式化方法进行严格定义。不过，采用快速原型技术，这一问题可得到解决。快速原型是一种为了弥补需求分析的不彻底性，保证软件的需求规格说明符用户的要求的有效手段。采用可执行的规格说明，把规格说明作为系统原型运行，既可符合达到快速原型的目的，又不增加很多额外的工作量。

2.4、验证

需求分析阶段的工作结果是开发件系统的重要基础,大量统计数字表明,软件系统中15%的错误起源于错误的需求,为了高软件质量,确保软件开发成功,降低较件开发成本,一旦对目标系统提出一组要求之后,必须严格验证这些需求的正确性,一般说来,应该从下述4个方面进行验证：
(1)一致性 所有需求必须是一致的,任何一条需求不能和其他需求互相矛。
(2)完整性 需求必须是完整的,规格说明书应该包括用户需要的每一个功能或性能。
(3)现实性 指定的需求应该是用现有的硬件技术和软件技术基本上可以实现的。对硬件技术的进步可以做些预测,对就件技术的进步则很难做出预测,只能从现有技术水平出发判断需求的现实性。
(4)有效性 必须证明需求是正确有数的,确实能解决用户面对的问题。
需求验证的方法：
1、验证需求的一致性

当需求分析的结果是用自然语言书写的时候,除了靠人工技术审查验证软件系统规格说明书的正确性之外,目前还没有其他更好的“测试”方法。但是,这种非形式化的规格说明书是难于验证的,特别在目标系统规模度大、规格说明书篇幅很长的时候,人工审查的效果是没有保证的,冗余、遗楼和不一致等问题可能没被发现而继续保留下来,以致软件开发工作不能在正确的基础上顺利进行。
为了克服上述困难,人们提出了形式化的描述软件需求的方法。当软件需求规格说明书是用形式化的需求陈述语言书写的时候,可以用软件工具验证需求的一致性,从而能有效地保证软件需求的一致性。

2、验证需求的现实性

为了验证需求的现实性,分析员应该参照以往开发类似系统的经验,分析用现有的软、硬件技术实现目标系统的可能性。必要的时候应该采用仿真或性能模拟技术,辅助分析件需求规格说明书的现实性。

3、验证需求的完整性和有效性

只有目标系统的用户才真正知道软件需求规格说明书是否完整、准确地描述了他们的需求。因此,检验需求的完整性,特别是证明系统确实满足用户的实际需要,只有在用户的密切合作下才能完成。然而许多用户并不能清楚地认识到他们的需要不能有效地比较陈述需求的语句和实际需要的功能。只有当他们有某种工作着的软件系统可以实际使用和评价时,才能完整确切地提出他们的需要。

2.5、管理

需求变更，相信大家一定都遭遇过，即使项目在启动时已经具备完整的需求，在项目启动后还是可能会变动。而且由于管理模型的不同，在项目启动后对需求变更会是件特别耗时费力的事。这就是为什么我们需要一个持续的需求管理流程，这样能不仅能帮助控制成本，避免规模失控，还能保证完整的可追溯性。好的需求管理系统在需求变化时，能够实现灵活地管理，还能高效地交付功能。我们在实践中总结了一些能帮助我们避免需求的频繁变更的方法，下面就来简单介绍。
一、尽可能多的渠道搜集需求

首先是搜集需求。这个过程要包含所有相关的渠道：比如新老用户、管理人员、业务分析师和其他的参与人员。尤其是注意那些会真正使用系统的用户，因为在系统性能和用户界面方面，他们会给你提供最可用的信息。把他们作为最高级别的需求来源能让你的产品或服务真正解决客户的痛点。

二、确定需求优先级

分类需求并不是一件简单的事。当项目成熟时，我们要把需求文档化，并把所有信息保持在最新状态，来保证其在测试和验证时可追溯。需求的优先级整理，能确保团队发现缺失，矛盾或者是重复。清晰的需求结构有助于测试管理期间更容易的决定执行哪些操作，包括指定相关的测试用例。这两个流程彼此紧密关联，只有在受控和良好的计划下进行，才能达到项目目标。

三、尽可能邀请所有相关人员参与评审，并达成共识

一旦需求整理完毕，与所有相关人员开会评审是必须的。并且尽可能确保项目成员都参与进来。这个过程中中即使是在会议的最后一刻需求也可会发生变动，而这恰好是大家取得共识的关键时刻。在整个应用生命周期中，我们需要确保系统的开发不只是盲目的在符合一组宽泛的需求，而是应该灵活处理，优先减少成本，尽早交付。这就是为什么要尽早确定需求的优先级，然后再是是集齐需求，等待最终评审。这些需求以及他们的优先级将指明项目未来的方向。在此之后，剩下的就是让那些具备丰富需求管理经验的同事来检验你的需求规范。

四、需求验证

通常，要时不时的让提出需求的相关人员来审核文档，并且要尽力帮助他们理解需求。当这些需求实现时，还要准备好相关的说明文件。根据不同的工作流程，你要提供不同格式的比如活动图，工作流模型图以及流程图来说明。最好是把需求以文件夹形式的来组织，并以树状图显示，方便用来验证。这样你就能构建一个包含少数功能的可用环境，用户就可以在需求最终评审之前尝试不同的方法来验证。另外，这种组织形式还能让参与者明了，具体的需求是如何代表他们的工作目标，以及它们是如何组成项目的总体目标。

五、评估需求变更的影响

这种类型的评估会让团队认识到需求变更带来的影响，能帮助团队做出最有效的业务决策。影响力分析在那些重视质量和安全性的项目中非常重要。这种分析用来检查需求的变更会导致哪些组件也需要更改。
大体来说，影响力分析是指： 理解需求变更带来的影响，例如在产品中新增一组功能会降低性能，对部分用户来说是不可接受的；
如果需求变更了，要指出哪些文档，模型，和文件可能需要修改。明白哪些任务涉及到变更的需求，以及要实现这个变动要花费的成本，两者同样重要。