软件工程期末知识点整理（更新中）

第一章 软件与软件工程

1.1软件

1.1.1

软件是能够完成预定功能和性能，并对相应数据进行加工的程序和描述程序及其操作的文档。

软件=程序+数据+文档

程序=算法+数据结构

程序是用程序设计语言描述的、适合于计算机处理的语句序列。

程序设计语言：面向机器：机器语言、汇编语言、面向过程：Fortran、Pascal、面向问题：sql、面向对象

前三代的计算机语言或过程式语言：机器语言、汇编语言、高级语言

非过程式语言或第四代语言4GL 数据库查询语言、报表语言、机床控制专用语言、电路设计专用语言

文档是一种数据媒体和其上所记录的数据。

规范、准确、清晰、简洁

表现形式：

1.1.2软件的特点

软件是什么

1软件是计算机系统的重要组成部分

2 软件是逻辑产品而不是物理产品，需要计算机硬件和系统软件的支持

3软件是计算机控制的指挥中枢

4软件是信息转换器，对信息加工处理变换

5软件是工具在生活中起重要作用

软件的本质特性：复杂性、一致性、可变性、不可见性

软件维护 纠错性维护、完善性维护、适应性维护

1.1.3软件的分类

系统软件

实时软件

嵌入式软件

科学和工程计算软件

事务处理软件

人工智能软件

个人计算机软件

Case工具软件

1.1.4软件的发展

四个阶段

第一阶段 20世纪五十年代初期到20世纪六十年代初期 批处理

第二阶段 20世纪六十年代中期到20世纪70年代末期 多用户多道程序人机交互 第一代数据库管理系统

第三阶段 20世纪70年代中期到20世纪80年代末期 微处理器广泛应用 个人计算机和工作站

第四阶段 20世纪80年代末期 面向对象技术 MIMD

1.1.5软件危机

1成本高 2质量无法保证 3开发效率低 4 难以控制开发进度

原因

1 软件规模加大、复杂性提高、性能增强

2 软件是逻辑产品，尚未完全认识其本质和特点

3 缺乏有效和系统的开发与维护大型软件项目的技术手段和方法

4 用户对软件需求的描述不精确，可能有遗漏，有二义性，有错误，甚至在软件开发过程中用户开提出软件功能、界面、支撑环境等方面的要求

5 软件开发的技术人员和管理人员缺乏软件工程化素质

1.2 软件工程

1.2.1软件工程的定义

软件工程是用工程、科学和数学的原则与方法研制、维护计算机软件的有关技术及管理方法。

软件工程三要素 方法 工具 过程

1.2.2软件工程的目标

十个目标

可修改性 有效性 可靠性 可理解性 可维护性 可重用性 可适应性 可移植性 可追踪性 可互操作性

1.2.3 软件工程的原则

七个原则

抽象 抽取最基本的

信息隐藏 黑箱 接口

模块化 耦合度 内聚度

局部化 松耦合紧内聚

一致性 一致的概念符号术语

完整性

可验证性

1.3软件生存周期

软件产品从形成概念开始，经过开发、使用和维护，直到最后退役的全过程称为软件生存周期。

软件生存周期都包括软件定义、软件开发、软件使用与维护。

1.3.1软件定义

软件系统的可行性研究和需求分析两个阶段

1、 可行性研究

任务：了解用户的要求及现实环境

技术可行性、操作可行性、经济可行性

阶段性产品：可行性论证报告、初步的项目开发计划

2、 需求分析

任务：确定待开发软件的功能需求、性能需求和运行环境约束

软件需求不仅是软件开发的依据，而且也是软件验收的标准

需求分析过程，系统分析员和软件开发人员不得不与用户反复讨论、协商，使用户需求逐步精确化、一致化、完全化。面向数据流的分析方法、面向对象的分析方法

阶段性产品：软件需求规格说明SRS、概要用户手册

1.3.2 软件开发

软件开发：概要设计、详细设计、实现、组装测试和确认测试

（1） 概要设计

任务：根据软件需求规格说明书建立系统软件的总体结构和模块间的关系，定义各功能模块的接口，设计全局数据库或数据结构，规定设计约束，制定组装测试计划。

低耦合高内聚

层次结构 结构图 节点代表功能模块 自顶向下逐步求精的设计思想

阶段产品：概要设计说明书、数据库或数据结构设计说明书、组装测试计划

（2） 详细设计

任务：对概要设计产生的功能模块逐步细化，形成若干个可编程的程序模块。

阶段性产品：详细设计规格说明书、单元测试计划

软件设计原则：设计应与软件需求保持一致，设计的软件结构应支持模块化、信息隐藏等。

软件设计方法：结构化的设计方法、面向对象的设计方法

（3）实现

任务：根据详细设计文档讲详细设计转化为所要求的编程语言或数据库语言的程序，并对这些程序进行调试和程序单元测试，验证程序模块接口与详细设计文档的一致性。

将模块的详细设计转化为某种编程语言源程序的过程就是编程和调试的过程。

阶段性产品：源程序代码

（4）组装测试

任务：根据概要设计中各功能模块的说明及制定的组装测试计划，将经过单元测试的模块逐步进行组装和测试。

阶段性产品：满足概要设计要求、可运行的系统源程序清单和组装测试报告。

（5）确认测试

任务：根据软件需求规格说明定义的全部功能和性能要求及软件确认测试计划对软件系统进行测试，测试系统是否达到了系统需求。

方法：应有客户参加，以SRS为依据进行确认测试。

阶段性产品：可供用户使用的软件产品（文档、源程序）

1.3.3软件使用、维护和退役

SDLC软件开发生命周期

v模型 验证确认模型

可行性研究<----------------------------------->运行

​ 需求分析<---------------------------->确认测试

​ 概要设计<------------------->组装测试

​ 详细设计<--------->单元测试

​ 编码与调试

1.4软件开发模型

软件开发具有迭代性

以软件需求完全确定为前提的瀑布模型

在软件开发初始阶段只能提供基本需求时采用的渐进式开发模型：原型模型、螺旋模型

以形式化开发方法为基础的变换模型

1.4.1 瀑布模型

也称软件生存周期模型

上一阶段的变换结果是下一阶段变化的输入，相邻两个阶段具有因果关系

每一阶段任务完成后，都必须对它的阶段性产品进行评审

优点：1）围绕软件生命周期建立模型，使软件开发过程可在分析、设计、编码、测试和维护的框架下进行

2）使软件开发过程具有系统性、可控性，克服了软件开发的随意性

缺点：1）项目开始用户很难精确提供产品需求，修改需求情况普遍

2）开发晚期修改需求的代价很大

1.4.2原型模型

软件开发人员根据客户提出的软件定义，快速地开发一个原型

软件重用技术

客户和软件开发人员共同设计和评审，统一客户和软件开发人员对软件项目需求的理解，有助于需求的定义和确认

快速原型建模的开发过程：业务建模-》数据建模-〉过程建模-》应用生成-〉测试修正

1.4.3螺旋模型

螺旋模型=线性模型（瀑布）+迭代模型（原型）+系统化

每一周期四个部分：1需求定义 2风险分析 3工程实现 4评审

从螺旋中心出发

第一圈 产生产品规格说明

第二圈 产生一个用于开发的模型

第三圈 产生软件产品的初始版本

第四圈 产生软件产品比较完善的新版本

优点：1）符合认识现实世界和软件开发的客观规律

2）支持软件整个生命周期

3）保持瀑布模型的系统性、阶段性

4）利用原型评估降低开发风险

5）开发者和用户共同参与开发，尽早发现软件中的错误

第二章 软件项目管理

特点：重要性、特殊性、复杂性

1为了使项目能够按照预定成本、进度、质量顺利完成，需要对成本、人员、进度、质量、风险等进行分析和管理。

2 软件产品是有逻辑的，而不是物理的，软件项目的施工是开发小组集体的智力劳动，使用的开发工具是建立在计算机系统上的软件。

3 度量 无法度量的事物和过程不能进行有效的、科学的管理和控制。

2.1 软件度量

2.1.1度量、测量和估算

软件工程的定量描述：度量、测量和估算

度量具有数字特征，软件工程范围内的度量是软件产品、软件开发过程或资源简单属性的定量描述。

测量和估算是简单属性度量的函数

测量用于事后或实时状态。估算是对软件产品、过程、资源进行预测，可以采用经验公式，也可以参考历史资料。

外部属性，体现了产品、过程、资源与环境的关系。由软件的内部属性决定。

内部属性，软件产品、过程和资本本身的属性

软件测量：直接测量 不依赖于其他属性的简单属性，代码行数、操作符个数； 间接测量 涉及一个或若干个其他属性的软件要素、准则或属性，如软件复杂性、模块性，必须建立一定的测量方法或模型。

2.1.2面向规模的度量

用软件项目的代码行（LOC）数表示软件项目的规模

生产率P1 每人月完成的代码行数 公式（1）

工作量E 人月（PM）

软件项目的代码行数L 千行代码kLOC
$$P1=L/E$$
软件项目的总开销S

软件项目每行代码的平均成本C1 公式（2）
$$C1=S/L$$
软件项目的文档页数Pd

每千行代码的平均文档页数D1 公式（3）
$$D1=Pd/L$$
代码错误数Ne

每千行代码的平均错误数 公式（4）
$$EQR1=Ne/L$$
优点：用软件代码行估算软件规模简单易行

缺点：代码行数的估算依赖于程序设计语言的功能和表达能力；对设计精巧的软件项目产生不利的影响；开发前或初期估算代码行数十分困难；只适用于过程式程序设计语言

2.1.3 面向功能的度量

间接度量方式

根据五个信息量 14个因素计算功能点FP

Fi表示在FP中起作用的程度

$$Pf=FP/E$$
软件项目的总开销S

平均成本Cf公式（6）
$$Cf=S/FP$$
软件项目的文档页数Pd

文档与功能点比Df 公式（7）
$$Df=Pd/FP$$
代码错误数Ne

代码出错率 公式（8）
$$EQRf=Ne/FP$$
FPs 简单功能点

FP 功能点 （算法复杂性因素）

优点：1）与程序设计语言无关，不仅适用于过程性语言，也适用于非过程性语言

2）因为软件开发初期就能确定系统的输入输出等参数，所以功能点度量能用于软件项目的开发初期

缺点：1）它涉及到的主观因素比较多，如各种权函数的取值；

2）信息领域中的某些数据有时不容易采集

3）FP的值没有直观的物理意义

2.1.4代码行度量与功能点度量的比较

代码行度量依赖于程序设计语言，功能点度量不依赖。

2.2软件项目估算

2.2.1代码行、功能点和工作量估算

软件项目的规模是影响软件项目成本和工作量的重要因素。

软件项目代码行和功能点估算是成本和工作量估算的基础。
$$e=(a+4m+b)/6$$

2.2.2经验估算模型之一：CoCoMo模型

构造性成本模型

基本CoCoMo模型 系统开发初期整个系统

中间CoCoMo模型 各个子系统

详细CoCoMo模型 子系统内部的各个模块

1.基本CoCoMo模型
$$E=a（L{）}^b$$

$$D=c{E}^d$$

公式（10）（11）给出了软件代码行数与工作量、工作量与开发时间之间的函数关系。

Boehm把软件划分为组织型、半独立型和嵌入型三类。

2.中间CoCoMo模型

EAF 工作量调节因子
$$E=a（L{）}^{b}EAF$$
工作量调节因子与四个属性、15个要素有关

软件产品属性：

计算机属性

人员属性

项目属性

每个要素调节因子的值分为很低、低、正常、高、很高、极高 六级。
$$EAF=\prod _{i=1}^{15}{F}_i$$
CoCoMo II
$$E=a（L{）}^{b}EAF+PM$$

2.2.3经验估算模型之二：Putnam模型

大型软件项目工作量估算模型

动态多变量模型，适用于软件开发的各个阶段
$$L=C_k{E}^{1/3}{t}_d^{4/3}$$

$$E=L^3/(C_k^3{t}_d^4)$$

交付时间对应于曲线最大值，表示软件交付时工作量最大，参与软件项目的人最多。

软件开发过程中人员与时间的折衷是一个十分重要的问题。

软件开发时间与人力投入的关系曲线表明软件开发工作量随着时间t的增加不呈线性增长趋势，参加软件开发的工作人员数不是一成不变的。

Putnam模型虽然揭示了软件项目的工作量、软件开发时间和程序代码长度三折之间的关系，但它没有反应软件产品属性、软件项目属性、软件开发人员属性、计算机软硬件资源属性等。

2.4软件复杂性度量

2.4.1软件复杂性及其度量

原则

循环结构比选择结构复杂，选择结构比顺序结构复杂。

控制结构、数据结构复杂的程序较复杂

2.4.2 控制结构的复杂性度量

巡回秩数V（G）
$$V(G)=e-n+2$$
一个模块的V（G）不要大于10。

分支结构数和循环结构数增加，控制结构图中的区域数会增加，程序的结构会变得更复杂，V（G）的值也会相应增大。

2.4.3文本复杂性度量

程序是由操作符和操作数组成的符号序列。

操作符是语法符号，操作数是操作对象。

2.5软件可靠性度量

2.5.1软件可靠性的概念

在某个给定的时间间隔内，程序按照规格说明成功运行的概率定义为软件的可靠性。

搁这给我复习概率论呢

2.5.2软件修复和软件有效性

软件修复：发现故障、纠正错误、测试和系统重新启动

MTTR 平均修复时间

有效性函数A（t）系统在时刻t正常运行的概率

可靠性函数R（t）系统在[0，t]时间间隔正常运行的概率

R比A严格得多。

对于不可修复系统或没有修理能力的部门A（t）=R（t）；对于允许修理并有一定修理能力的部门A（t）>=R（t）。

三种测量软件有效性的方法：

（3）系统处于稳态时，程序正常运行时间的平均值，也就是程序平均故障间隔时间（MTBF），程序平均停机时间也是程序平均修复时间（MTTR）

系统稳态时的程序有效性A=MTBF/（MTBF+MTTR）

可以用于软件开发阶段。

2.5.3软件可靠性估算

宏观方法

1错误植入模型

改进前：

Mills将播种模型用于程序中残留错误的估算，称为错误植入模型。

N 程序开始排错时残留错误数，包括统计人员设置在程序中的Nt个错误，这些错误对于程序排错人员是未知的。

排错工作进行数天后，统计人员发现共查处n个错误，其中nt个属于植入错误.

利用（18）估算程序的残留错误。
$$N=\frac{n}{n_t}{N}_t$$
这里要求残留错误随机并均匀出现，不现实。

改进后：

Hyman

两名程序测试员同时对一个程序进行独立测试。

E0两位测试员在时间段内不约而同发现的错误数
$$E_T=E_1{E}_2/E_0$$
用Hyman的改进方法估算程序的残留错误，无论技术上还是经济上都比原始的错误植入模型优越。

改进的方法没有人为植入错误，改进前的方法不能保证植入的错误与原错误没有同质性。

2.6软件开发过程的管理

2.6.1 风险分析

软件工程的风险分析包括风险识别、风险估算、风险评价、风险管理。

1风险识别

对待风险不能采取回避态度

宏观上看，风险可分为项目风险、技术风险和商业风险三类。

风险检测表

2风险估算

加权

R接近于0，风险比较小；R接近于1，风险比较大。

2.6.2进度安排

制定软件项目进度表

1 软件开发小组根据提供软件产品的最后期限从后往前安排时间

2 软件项目开发组织根据项目和资源情况制定软件项目开发的初步计划和交付软件产品的日期

软件项目的进度安排必须妥善处理以下几个问题：

1任务分配、人力资源分配和时间分配要与工程进度相协调

使用较少的人员，在可能的情况下，相对延长一些工作时间可以去的较大的经济效益。

任务、人力、时间三者最佳组合

2任务分解与并行化

并行处理方式

顺序的 并行的

菱形 里程碑 产生相应文档并进行评审

3 工作量分布

4-2-4分布原则

4 工程进度安排

项目进度安排方法：

程序评估与审查技术（PERT）

关键路径方法（CPM）

关键路径 完成关键路径上所有任务时间的总和，就是项目开发所需要的最短时间。

2.6.4软件质量保证

高质量的软件应该具备下列三个条件：

（1）满足软件需求定义的功能和性能

（2）文档符合事先定义的软件开发标准

（3）软件的特点和属性遵循软件工程的目标和原则

软件质量保证活动SQA包括八个活动

软件工程正式技术评审FTR，正式会议，3至5人。

2.6.5软件开发人员的组织和分工

原则：

降低管理系统的复杂性

按树形结构组织软件人员开发

树的节点是程序员小组，每层节点不要超过七个，尽量降低树的层数，程序员小组的人数一般是2-5人。

必须引起项目负责人的高度重视

方法一：主程序员

方法二：无我程序设计

人员-时间折衷定律：在时间允许的情况下，适当减少人员会提高工作效率，降低软件开发成本。

减少人员之间的通信开销

2.7软件过程及软件成熟度模型CMM

2.7.1引言

承接美国国防部大型软件项目的承包商必须具备CMM成熟度3级的认证。

2.7.2CMM的概念

（1）组织 管理软件项目，能对项目进行评估和过程改进的实体，如政府机关、公司、服务部门等。

（2）项目 由组织承担的，并需要组织中各部门通力合作完成的指定产品的开发和维护任务。

（3）软件过程 软件开发人员为开发和维护软件及其相关产品所实现的一系列步骤，设计设计方法、工具、人的组织和行为。

（4）组织的标准软件过程

（5） 项目的软件过程

（6）组织的软件过程资产

2.7.3能力成熟度模型CMM

五级：L1初始级 L2可重复级 L3己定义级 L4己管理级 L5优化级

关键过程域 评估软件成熟度的基本单元 18个

组织的成熟度级别越高，其软件开发能力越强，产品质量越好，效率越高，成本越低，时间越短。

美国多数软件开发组织处于L2和L3级。

2.7.4能力成熟度模型集成CMMI

阶段式模型，保持5个成熟度等级，扩充至24个过程域

连续式模型，没有与组织成熟度相关的几个阶段。将24个过程域按照功能划分为过程管理、项目管理、工程和支持四个过程组。每个过程域代表组织某一方面的能力，均分为5级。能力特征图。

2.7.5CMM和CMMI的选择和应用

SW-CMM是阶段式模型

优点：概念清晰、层次分明、易于操作；为组织负责人和管理者提供指导组织逐步成熟的、明确的、有效的单一路途。

缺点：CMM过程域的度量只有通过或不通过，度量比较粗糙，没有反映优势和一般。

CMMI-SE/SW和CMMI-SE/SW/IPPD 综合了系统工程、软件工程、集成化产品和过程开发三个过程改进模型。

优点：1）综合了阶段式和连续式两种结构

2）过程域可进行剪裁，采用0-5分的记分法则

3）建立能力特征图，取24个过程域作为横坐标，取它们的成熟度等级作为纵坐标，制定一份组织过程域“谱图”，直观地反映了当前组织过程成熟度的优势和不足。

缺点：是两种结构、三种模型的综合，在这些结构和模型尚处发展阶段还不十分成熟的情况下，照顾各方面的意见显得复杂、臃肿，给使用和评估带来困难。

CMM和CMMI是提高组织的成熟度和软件过程能力的有效模型和工具，结论应是基本一致的。

第三章 计算机系统工程

3.1计算机系统工程

计算机系统工程是指与构造基于计算机系统有关的过程、方法和技术，他是一种问题求解活动。

用户定义的目标、约束条件

3.1.2软件和软件工程

软件与硬件、软件工程与硬件工程分别是基于计算机系统和基于计算机的系统工程的重要组成部分

软部件由源程序、数据和文档三部分组成。

从软部件功能上看，分为系统软件和应用软件两类软部件。

1人机交互

2系统和数据库的界面

3基于计算机系统的功能靠软件执行一系列算法实现

软件工程模型都包括软件项目的定义阶段、软件开发阶段、软件的验证、提交和维护阶段

定义阶段：

定义软件需求 1采用形式化的信息分析方法；2为软件开发原型

开发阶段：

任务 将系统需求转化为可操作的系统要素，主要工作有软件总体结构设计和数据设计、过程设计、编码三部分。

3.1.3人机工程

是开发基于计算机系统的一项重要内容

人机友好

设计高质量的人机界面要使用计算机技术、心理学、美学

3.2可行性研究

3.2.1引言

开发任何一个基于计算机的系统，都会受到时间和资源和技术上的限制。根据客户可能提供的时间、资源和技术条件进行可行性研究

可行性研究包括经济可行性、技术可行性、发了可行性、时间可行性、资源可行性

资源分析的任务 论证是否具备系统开发所需的各类人员、软件、硬件资源和工作环境

3.2.2经济可行性

成本-效益分析

基于计算机的成本：

1购置并安装软硬件及有关设备的费用

2系统开发费用

3系统安装、运行和维护费用

4人员培训费用

估算成本 系统分析和设计阶段只能得到上述费用的预算

实际成本 系统开发完毕并交付用户后，上述费用的统计结果

系统效益包括 经济效益和社会效益

经济效益指应用系统为用户增加的收入，直接的或统计的方法估算。

社会效益只能用定性的方法估算。

AB段 在完成用户需求的条件下尚有一定潜力支持附加的功能和特性

BC段 在增加功能和性能，附加成本会急剧增加，原有的计算机系统已经没有能力再支持这些新的功能和性能，必须增加新的软硬件资源。

3.2.3 技术可行性

风险分析

判断在给定的约束条件下能否设计并实现系统所需的功能和性能

资源分析

是否具有开发所需的人员、软件、硬件和工作环境

技术分析

当前的科学技术条件是否支持系统开发全过程

途径

系统分析员通过对现实世界的观察和分析建立技术分析模型

3.2.4方案选择

方法 分治法

系统分解和实现的方案不是唯一的，不同方案开发出来的系统在系统功能和性能方面会有很大差异

折衷手段

3.3系统模型与模拟

3.3.1系统模型

系统工程师将基于计算机的系统功能和性能分解，定义若干个子系统及其界面之后，开始建立系统模型，为需求分析和设计阶段的工作奠定基础。

输入-处理-输出（IPO）结构是系统建模的基础

用结构模型开发系统模型，结构模版由用户界面处理、输入处理、处理和控制功能、输出处理、维护和自测试五部分组成。

结构模版帮助分析人员按照系统工程和软件工程的建模技术自顶向下、由粗到细地建立基于计算机系统的系统模型。

系统总体结构关系图SCD位于系统模型图的最顶层。

SCD 有向边表示系统的信息流和控制流

圆角方框表示系统或子系统

方框表示外部实体，即系统信息的生产者和消费者。

各子系统的结构流图SFD

3.3.2系统建模和模拟

现实系统模型 分为物理模型（形象模型）和数学模型（抽象模型）

静态模型和动态模型

确定模型和随机模型

模型：a是现实系统的抽象和简化 b模型必须反映现实系统的本质和实际 c模型必须由现实系统的有关元素组成 d模型必须反映这些元素之间的关系 e力求简单易修改 f应指明系统的约束条件 g用户必须参与和确定模型开发

第四章 需求分析基础

软件需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望

需求分析的3个主要阶段：问题分析、需求描述、需求评审

ieee给出的需求定义

1）需求是用户要解决某个问题或达到某种目的所需的条件或能力

2）需求是系统或系统组成部分为满足某种合同，标准，规范必须满足的条件或具备的能力

3）需求将作为系统开发，测试，验收，提交的正式文档依据

4.1分析的任务与原则

问题分析阶段 分析人员和用户

存在问题的需求描述实例：无法测试的 含糊的 错误的 不完整的 矛盾或不一致的

单个需求项的质量 精简 正确 明确 可行 可证

整个需求集合的质量 现实 精简 全面 一致

问题分析阶段生成的需求模型构成需求规格说明书的主体。

需求描述阶段

任务 以需求模型为基础，考虑到问题的软件可解性，生成需求规格说明SRS和初步的用户手册。

需求评审阶段

分析人员 用户 软件设计人员

全面性 精确性 一致性

4.2初步需求获取技术

4.2.1访谈与会议

个别访谈或小组会议

（1）循序渐进，一般性整体性问题到细节性问题

（2）客观公正，不应限制用户在回答过程中进行自由发挥

（3）汇总后反映应用问题或其子问题的全貌，覆盖要求

4.2.2观察用户工作流程

调查研究

学习用户的有关业务知识

了解用户的业务流程

结合软件开发经验提出新的用户需求

4.2.3用户和开发人员共同组成联合小组

4.3需求建模

建立软件模型是分析活动的焦点，模型以一种简洁、准确、结构清晰的方式系统地描述了软件需求

4.4问题抽象、问题分解与多视点分析

抽象 分析人员捕捉用户描述或问题本身所固有的一般-特殊关系

分解 由于问题的规模和复杂度，往往要对各个子问题的理解和分析实现对整个问题的理解

问题分析的原则：紧内聚，松耦合

多视点分析 系统观点与用户观点，信息观点，功能观点与行为观点

4.5支持需求分析的快速原型技术

核心思想：在软件开发的早期快速建立目标软件系统的原型，让用户对原型进行评估并提出修改意见。

快速建造原型步骤：

1）生成一个简化的需求规格说明

2）生成设计规格说明，只关心软件的总体结构、用户界面和数据设计，不注重过程内部的控制流设计

3）快速生成可运行的软件原型并进行测试、改进

4）将原型提交用户评估并征询改进意见

5）上述过程将反复进行，直到用户完全认可。

4.6需求规格说明与评审

功能性需求、非功能性需求

在结束需求分析阶段之前，必须要形成需求规格说明书并进行评审

4.6.1需求规格说明书的目标与内容

目标：

（1）便于用户、分析人员、软件开发人员进行理解和交流。用户通过需求规格说明书在分析阶段即可初步判定目标软件是否满足其原来的愿望；设计人员将需求规格说明书作为软件设计的基本出发点。

（2）支持目标软件系统的确认。软件开发目标是否完成不应由系统测试阶段的人为因素决定，而应根据需求规格说明书中确立的可测试标准决定。需求规格说明书中的各项需求都应该是可测试的。

（3）控制系统进化过程。在需求分析完成后，如果用户追加需求，那么需求规格说明书将用于确定追加需求是否为新需求。如果是，开发人员必须针对新需求进行需求分析，扩充需求规格说明书，再进行软件设计。

需求规格说明书的主体：功能与行为需求描述、非行为需求描述

功能与行为需求描述 说明系统的输入、输出及其相互关系

非行为需求 软件系统在工作时应具备的各种属性

4.6.2需求评审

衡量需求规格说明书好坏的标准按照重要性次序

（1） 正确性

（2）无歧义性

（3）完全性

（4）可验证性

（5）一致性

（6）可理解性

（7）可修改性

（8）可追踪性

需求评审以用户、分析人员和系统设计人员共同参与的会议形式进行

说明书的核心部分：需求模型

第八章 软件设计基础