软件需求工程.doc

第1章 软件需求工程概述

IEEE 关于软件需求的定义

1) 用户解决问题或达到目标所需的条件或能力；（用户的角度 ）

2) 系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条

件或能力。（软件系统的角度 ）

软件需求的分类

1)

目标需求； 2)

业务需求； 3)

功能需求； 4)

性能需求； 5)

约束与限制。 6)

软件需求间的层次关系

需求规格说明

需求规格说明是软件所应满足的全部需求，并可以文档的方式完整和精确陈述这些需求。

一个好的需求规格说明应该具有的特征

1)

完整性。 2)

正确性。 3)

可行性。 4)

必要性。 5)

划分优先级。 6)

无二义性。 7) 可验证性。

第2章 软件工程与需求工程

软件开发过程模型

1) 瀑布式模型

2) 快速原型模型

3) 渐增式模型

4)螺旋式模型

5)面向对象的开发模型

所谓面向对象就是应用对象、类、继承、封装、消息、对象或类之间的关系等面向对象的概念对问题进行分析和求解的软件开发技术，或者说，是以对象（类）为数据中心、对象之间的动态行为模式作为运行机制的一种问题求解方法。

软件需求工程特点

1)有一部分分析工作必须在设计之前进行，而另外一些分析工作则需与其他部

分的设计与实现工作并行地进行，因而呈现出非线性的工作方式。

2)软件系统的表达形式在整个开发模型中都是相同的，即面向对象方法中把类

及其结构作为系统的表达单元，无论哪一个阶段都以渐增的方式不断地进化或细化这些表达单元。

3)开发模型支持软件的重用。

需求工程对软件开发的影响如下：

1)需求是制定项目计划的基础。

2)需求工程所产生的最终产物——需求规格说明——是软件设计和软件实现的

基础。

3)需求规格说明也是测试工作和用户验收软件系统的依据。

4)需求规格说明也是软件维护工作的依据。

软件需求的开发和管理过程

软件需求的开发和管理过程是由导出、确认和维护软件系统需求规格说明的一系列活动组成的。

根据需求工程开发和管理过程可大致划分需求开发和需求管理两个阶段。其中需求开发主要产生正式的需求规格说明，需求管理主要是根据需求的变化对需求规格说明的内容及版本进行管理。

第3章需求获取

实地收集需求信息面临的困难

1)能提出软件需求的用户没有时间与开发人员进行交流和讨论。

2)有时用户不愿意花费太多的时间进行讨论。

3)用户和开发人员考虑自身利益，对需求信息的手机工作采取消极的态度。

4)用户对所面临的工作没有系统的认识和整理，使得开发人员无法整理和分

析。

5)开发人员缺乏用户的业务常识，双方交流困难，收集工作难以进行。

实地调查的步骤

要想获得充分的用户需求信息，就必须实地进行调查并与用户交流。实地调查通常分为三个步骤：

1)向掌握“全局”的负责人调查。

2)向部门负责人调查。

3)向业务人员调查。

2、3步骤是一个反复的过程，调查前应有提纲，调查要有记录，调查后要核实。

实地收集需求信息的方式

开发人员与用户的交流可采取如下几种方式：

1)座谈会的方式：参加人数不宜过多，避免拖延会议速度或偏离会议主题，应

该有人主持会议，提前发给参加人员有关会议的议题和内容等材料，有助于提高会议效率。

2)书面咨询的方式：由软件开发人员将所关心的和有待澄清的问题以书面形式

提交给用户，软件开发人员通过理解和分析用户的回答来收集他们的真正的需求。

3)利用用例表示方法：用例是了解用户的业务流程和澄清含糊细节的好方法。

所谓用例是用于描述软件系统与一个外部“执行者”的交互顺序，体现执行者完成一次任务的过程。

场景的定义及构成

所谓场景是指用户与软件系统实现某个目标而进行交互活动过程的描述。可视为使用系统经历的解释。

由以下几个方面的内容构成：

1)执行者

2)进入场景前系统状态描述

3)执行者的目的

4)动作和事件系列（包括正常和非正常事件流）

场景的表示

场景的表示出了可用自然语言表示外，也可用图形、动画等其它形式。场景也可与快速原型方法结合使用。场景可利用一些已有的半形式化的图形表示方法和技术。

1)非形式化的表示：自然语言、结构化语言、图形、动漫画等。

2)形式化的表示：状态图、流程图、时序图、代数描述图等。

场景技术还具有如下特点：

1)可把当前系统存在的问题作为实例记录下来。

2)可成为项目相关人员间的共同语言

3)由于描述了软件系统的操作，比较具体，易理解性较好

4)通过场景使得提出和获得需求的双方之间能建立起相应的理解。

使用场景技术还应注意以下问题：

1)场景的数量，场景数量过大，易加大分析和理解的难度。

2)场景的冗余问题，应尽量避免场景描述的内容发生重叠。

3)应防止场景描述的内容冗长。

第4章需求分析

需求分析与需求获取的关系：

需求分析和需求获取是密切相关的两个过程。需求分析的基本任务就是提炼、分析和仔细审查已收到的需求信息，找出真正的和具体的需求，以确保所有项目相关人员都明白其含义。此外，在分析过程中，通过建立软件系统的逻辑模型，发现或找出需求信息中存在的冲突、遗漏、错误或含糊问题等。

需求分析的具体工作包括：

1)建立系统关联图；

2)构建用户接口原型；

3)分析需求可行性；

4)确定需求的优先级别；

5)需求建模；

6)建立数据字典。

上述列举的所有工作要视具体的软件系统规模而施行。

第5章需求建模方法与技术

需求建模的概念

需求建模是需求分析中最重要的工作。需求建模主要是根据待开发软件系统的需求利用某种建模方法建立该系统的逻辑模型，也称需求模型或分析模型，以帮助软件开发人员检测软件需求的一致性、完整性、二义性和错误。

需求建模方法的特点

1)提供描述手段：描述形式对人员间的交流和继续进行下一步的工作非常重

要。

2)提供基本步骤：将问题按先后次序进行分解，每一步集中精力解决某个问题，

直至解决所有问题。

需求建模的方法

在目前的需求建模方法中，主要使用的描述手段和技术是自然语言、图形符号语言和形式语言等。

SA方法采用分解策略，把大型和复杂的软件系统分解成若干个易于理解和易于分析的子系统。在分解过程中，被分解的上层是下层的抽象，下层为上层的具体细节。

SA方法的基本思想是按照由抽象到具体、逐层分解的方法，确定软件系统内部的数据流、变换或加工的关系，并用数据流图表示。

复杂的软件系统的描述方法

?当前系统：已经存在的人工系统

?目标系统：待开发的计算机系统

SA方法的分析步骤如下：

1)理解和分析当前的现实环境，以获得当前系统的具体模型。具体模型必须忠

实地反映人工系统的实际情况，软件开发人员在获得需求信息的基础上，利用DFD将现实环境中的人工系统表达出来。

2)建立当前系统的逻辑模型。从系统的具体模型中抽象出当前系统的逻辑模

型，当前系统的逻辑模型应反映当前系统必须满足的性质。

3)建立目标系统的逻辑模型。主要是分析目标系统与当前系统在逻辑系统的差

别，并建立目标系统的逻辑模型。

4)进一步完善目标系统的逻辑模型，完善的工作大致为：

①至今尚未说明的处理细节，如出错处理

②某些需要的输入/输出格式或用户界面的说明

③增加性能需求和其它一些约束限制等

状态转换图

P60-图5-18、P61-图5-19

第6章需求定义

需求规格说明的作用

需求规格说明的作用主要体现在：

1)需求规格说明是软件设计和实现的基础

2)需求规格说明是测试和用户验收软件系统的重要依据

3)需求规格说明能为软件维护提供重要的信息

一个软件系统能否满足用户需求，主要是用户的需求能否全部反映在需求规格说明中。因此，需求规格说明作为需求工程的最终成果必须具有综合性，必须包括所有的需求，开发人员与客户不能做任何假设。

除了设计和实现的限制，需求规格说明不应包括假设、构造或维护阶段的细节；

需求规格说明=技术合同，是软件开发方与用户达成的一致性文档，是基准的规格说明。

需求规格说明的特性

软件的开发是以说明为基础的，如果需求规格说明中出现错误或需求不可能实现等都将导致软件开发工作的返工或失败，因此，需求规格说明必须满足各种各样的特性。

1)正确性：需求规格说明中对每一项需求必须准确地陈述。

2)无含糊性：对所有需求规格说明只能有一种明确和统一的解释。避免自然语

言容易导致的含糊性。

3)完整性：每一项需求都必须将所要实现的功能描述清楚，以便软件开发人员

获得设计和实现这些功能所需的必要信息。

4)一致性：需求规格说明内部要一致，与其它的规格说明不发生矛盾。

5)可验证性：当需求规格说明中所有的需求都可检测时，则该需求规格说明是

可验证的。

6)可行性：每一项需求都必须在已知系统和环境的限制范围内是可以实施的。

7)必要性：每一项需求都会把用户真正所需要的和最终系统所需遵从的标准记

录下来。即每一项需求都是用来授权编写文档的“根据”，要使每项需求都能回溯到某个或某些需求来源。

第8章需求验证

需求验证的目的和任务

需求验证所包括的活动是为了确认以下几个方面的内容：

1)软件需求规格说明是否正确描述了目标系统的行为和特征；

2)从其它来源中（包括硬件的系统需求规格说明书）得到软件需求；

3)需求是完整的和高质量的；

4)需求为进一步的软件开发和测试提供了足够的基础。

上述内容使得需求验证的目的就是要确保需求规格说明具有良好的特性（如完整性与正确性）。

需求验证的任务

1)需求认证的任务就是要求各方人员从不同的技术角度对需求规格说明文档

做出综合性评价。

2)在收集需求并且编写成需求规格说明文档后进行需求验证并不仅是一个独

立的阶段，某些验证活动（如对渐增式软件需求规格说明的初审工作）将在需求获取、需求分析和定义需求规格说明的整个过程中反复进行。

3)大部分需求验证只能通过人工进行检测，以表明需求规格说明将是用户实际

需要的系统。

需求验证的内容一般包括：

1)一致性：所有需求必须是一致的，任何一条需求不能与其它需求相矛盾；

2)完整性：需求必须是完整的，软件需求规格说明应包括用户需要的每一个功

能和性能；

3)现实性：指定的需求应该在现有的硬件基础或软件技术的基础上是可行的；

4)有效性：必须验证需求是正确有效的，确实能解决用户需求间的矛盾。

5)一般可根据软件系统的特点和用户的要求增加一些检验内容，如软件的安全

性、可靠性、正确性等。

需求验证方法：

主要靠人工技术审查和验证软件需求规格说明、形式化验证方法。

第9章需求管理

需求变更的内容主要涉及两个方面

一方面是需求变更只对软件系统内部产生影响，而不影响其它需求；另一方面是在原有软件需求的基础上提出扩充软件系统功能的需求，亦即扩展需求。

扩展需求是指在基准的需求规格说明已确定后，又要增添新的功能或进行较大的功能扩充。

控制变更范围扩展的方法：

1)把扩充系统的视图、范围和限制等文档化，作业务需求或功能需求的一部分，

对新增的每个功能进行评估。

2)利用原型化方法实现扩充部分的预览，以帮助用户与开发人员进行交流和沟

通，准确把握用户需求。

3)应充分考虑需求变更的难度，不能一味应和用户需求。

变更控制策略

变更控制策略与变更的过程和标准相关。这些策略描述了变更以何种形式提出、分析和处理。可供参考的策略有：

1)建立所有需求变更所应遵循的过程和步骤，当一个变更需求在过程中某一步

被拒绝后，则其后步骤不予考虑。

2)对于未获批准的变更，除进行可行性论证外，不应再做其后的工作。

3)对所提出的多个变更请求，应由项目变更小组决定实现哪些变更，以及先后

顺序。

4)项目开发人员和用户应该能了解已变更需求的情况。

5)不准随意删除和修改与需求变更请求和实现相关的原始文档。

每个实施后的变更与一个经核准的变更请求相对应。

变更控制的步骤

第11 章面向多视点的需求工程

面向多视点的需求工程方法的优势

1)复杂系统的本质特性与多视点思想吻合，利用多视点需求工程方法可以有效

地减少某些重要需求被遗漏的可能性，从而保证了需求规约的完备性；2)每个视点只需关心它自己感兴趣的内容，不需或较少地考虑其它因素的影

响，从而有效地降低了需求获取和描述的难度，有利于提高整个需求工程的质量；

3)视点的形式使软件系统以一种更加结构化的形式被描述，从而为自动化的完

备性和一致性检查提供了可能性；

4)多视点为封装软件系统的不同描述模型提供了一个强而有力的手段；

5)通过把需求和表达需求的视点关联起来，可增强需求的可追踪性。

多视点需求工程的需求分析过程

第12章需求工程与软件开发管理

需求与项目进度安排

项目进度安排通常是在软件计划阶段根据软件系统必须完成的日期（由用户规定）来安排开发进度，在进行需求开发工作。

开发进度安排出现问题的主要原因有：

1)不了解项目的需求与规模；

2)低估了要花费的工作量和时间；

3)没有考虑返工（用户需求的变化等因素所需的时间）。

正确按安排软件开发进度的方法

1)对需求清楚理解的基础上根据需求估算软件系统规模；

2)根据以往的开发项目，充分了解开发小组的工作效率；

3)建立项目规划的有效过程和估测方法；

4)积累大量开发经验。

第七章需求的形式化描述

形式化规格说明及其方法

所谓形式化规格说明就是使用受语法和语义限制的、被形式定义的语言描述的规格说明，亦即由严格的数学符号及由符号组成的规则形成的规格说明。

所谓形式化规格说明方法是一种形式化方法，是一种特定的、用于编写形式化规格说明的方法。

第十章面向问题域的需求分析方法

问题框架的类型

1)需求式行为问题框架

需求式行为问题框架的直观思想是：存在客观世界的某个部分，其行为要受到控制，使得它满足特定的条件。

2)命令式行为问题框架

命令式行为问题框架的直观思想是：存在客观世界的某个部分，其行为要依据操作者发出的命令来控制。

3)信息显示问题框架

信息显示问题框架的直观思想是：存在客观世界的某个部分，关于其状态和行为的特定信息被连续的需要。

4)工件问题框架

工件问题框架的直观思想是：需要一个工具，让用户创建并编辑特定类型的计算机可处理的文本或图形对象或简单结构，以便它们随后能被复制、打印、分析或按其他方式使用。

5)变换问题框架

变换问题框架的直观思想是：存在一些计算机可读的输入文件，其数据必须变换，已给出所需要的特定输出文件。