软件需求工程——学习笔记（完）

软件需求工程

编辑时间：2023/12/4
来源：ISBN9787111669470
图片来源：百度

1.1需求工程的重要性

1.2什么是软件工程

IEEE的说法
1.用户解决问题或达到目标所需的条件能力
2.系统或系统软件部件要满足合同，标准规则或其他正式规定文档所需要具有的条件或能力。

1.3软件需求分类

目标需求：反映组织机构或客户对系统和产品提出高层次的目标要求。
业务需求：主要描述软件系统必须完成的任务，实际业务或工作流程等。
功能需求：开发人员必须实现软件功能或软件系统应具有的外部行为。
性能需求：指实现的软件系统功能要达到的技术指标。
约束与限制：指软件开发人员在设计和实现软件系统时的限制。

1.4需求规格说明

需求规格说明特征
完整性，正确性，可行性，必要性，划分优先级，无二义性，可验证性。

1.5需求工程定义

需求工程是指应用工程化的方法，技术和规格来开发和管理软件的需求。需求工程的目标就是获取高质量的软件需求。

需求工程的任务：
1.确定待开发系统的用户类，并获取他们的需求信息。
2.分析用户的需求信息，并按软件需求的类型对这些需求信息进行分类，同时，过滤掉的不是需求的信息。
3.根据软件需求信息建立软件系统的逻辑模型或需求模型，并确定非功能需求和约束条件及限制。

1.4需求规格说明

需求规格说明的特征应满足：完整性、正确性、可行性、必要性、划分优先级、无二义性、可验证性

1.5需求工程定义

需求工程是应用工程化的方法、技术和规格来开发和管理软件的需求。
需求工程的目标获取高质量的软件需求。
需求工程的任务：

1. 确定待开发的软件系统的用户类、并获取他们的需求信息
2. 分析用户需求信息，并按需求类型对这些需求分类，同时过滤掉不是需求的信息。
3. 根据需求信息建立软件系统的逻辑模型或需求模型，并确定非功能需求和约束条件及限制
4. 根据手机的需求信息和逻辑模型编写需求规格说明及其文档
5. 评审需求规格说明
6. 当需求发生变更时，对需求规格说明及需求变更实施进行管理

1.6其他：客户 用户 软件开发人员 项目相关人员

2软件工程与需求工程

2.1软件工程

软件工程：用工程方法开发和维护软件的工程和有关技术；出现1968；基本内容为软件开发过程、软件开发和维护的方法和技术、软件开发和维护工具系统、质量评价和质量保证、软件管理和软件开发环境等。
软件危机：实质是人们难以控制软件的开发和维护
软件危机具体表现：大型软件复杂难以维护；软件开发周期长；大型软件系统的可靠性差；软件费用超预算

2.2软件开发过程模型

软件开发过程模型：为了获取高质量的软件系统所需完成的一系列任务的框架，规定完成各项任务的工作步骤。
软件生命期：标注形式定义了软件生存的过程；从软件计划开始，经历需求分析和定义、设计、编码、测试、运行、维护直到废止的时间。
1.瀑布模型
最早的开发模型，也叫做“软件生命期模型”。
六个阶段：软件开发技术，需求分析与定义，设计（总体设计、详细设计），编码，测试，维护。

瀑布模型特点：阶段间具有顺序性和依赖性，并非线性可能重复的过程等
瀑布模型问题：

1. 在实际开发过程中，用户不可能一开始使自已的需求很清晰，通常在开发过程中完善，容易从头开始
2. 各阶段开发人员就比较独立容易产生误解与用户需求产生偏差
3. 用户的参与程度不够

2.快速原型模型
原型：一种接近原物的结构大小和一般功能接近的形式或设计
软件原型：待开发的软件系统和部分实现
快速原型模型的思想：快速建立一个实习哪里若干功能（不要求完全）的可运行模型来启发，
揭示和不断完善用户的需求

快速原型模型的目的：明确并完善需求、探索设计选择方案、发展最终产品。
快速原型模型的特点：弥补用户参与度不够、通过原型系统使用户需求明确化、减少开发周期，加速开发过程，节约软件开发成本。

优点：克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险。
这种模型适合预先不能确切定义需求的软件系统的开发。
缺点：所选用的开发技术和工具不一定符合主流的发展；快速建立起来的系统结构加上连续的修改可能会导致产品质量低下。
使用这个模型的前提是要有一个展示性的产品原型，因此在一定程度上可能会限制开发人员的创新。

3.渐增式模型（增量模型）
增量模型是把待开发的软件系统模块化，将每个模块作为一个增量组件，从而分批次地分析、设计、编码和测试这些增量组件。运用增量模型的软件开发过程是递增式的过程。相对于瀑布模型而言，采用增量模型进行开发，开发人员不需要一次性地把整个软件产品提交给用户，而是可以分批次进行提交。

快速原型模型根据用户需求较为模糊的部分优先开发模型。
增量模型从功能明确、设计技术上不确定因素很少的核心功能优先出发，并且分批逐步向用户提交产品。

增量模型的特点：

1. 短时间向用户提交可完成部分功能的产品
2. 逐步增强产品的功能，使用户有充裕的时间学习和适应新的软件系统

4.螺旋式模型
思想：瀑布模型+快速原型模型+风险分析。可看做每一个阶段前都有风险评估。

螺旋式模型的特点：

1. 使用开发大规模的软件项目
2. 提高软件质量
3. 减少过多测试或测试不足带来的风险

5.敏捷模型

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

敏捷模型的特点：

1. 轻量、响应快、快速相应需求变化
2. 支持快速编码，对于可能错误进行快速重构
3. 系统内外部复杂因素增加时，项目额开发成功率更高。

有很多特定变种的敏捷模型：Scrum、极限编程、动态系统开发方法、敏捷统一过程、特性驱动开发等。最常用的敏捷模型为极限编程和Scrum或者这两者的混合模型

6.基于组件的模型
软件组件是自包含、可编程、可重用、与语言无关的软件单元，作为构造软件的“零部件”，可被用来构造其他软件。
开发过程：需求定义——>组件分析——>需求修改——>使用复用的系统设计——>开发和集成——>测试——>维护

2.3需求工程在软件开的地位

1.需求工程对软件开发的影响

1. 需求是制订项目计划的基础
2. 需求工程产生的最终产物（需求规格说明）是软件设计和软件实现的基础
3. 需求规格说明是测试工作和用户验收软件系统的依据
4. 需求规格说明是软件维护工作的依据

2.需求工程面临的困难

1. 需求获取与需求分析的困难
2. 需求描述语言和规范化的困难
3. 需求验证的困难性
4. 需求管理的困难性

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

软件需求的开发和管理过程是导出、确认和维护软件系统需求规格说明的一系列活动组成的。
需求过程的开发和管理过程分为需求开发和需求管理
需求开发主要产生正式的需求规格说明

需求开发分为两个阶段：用户的意图分析、需求规范化
细分四个阶段：
1.需求获取：确定和收集与软件系统相关的来自不同来源和对象的用户需求说明
2.需求分析：对获得的用户需求信息进行分析和综合，即提炼，分析，仔细审查已收集到的用户需求信息，找出错误不足，获取真正需求，建立逻辑模型或需求模型。
3. 需求定义：使用适当的描述语言，按标准的格式描述软件系统的需求产生需求规格说明及其相应的文档
4. 需求验证：审查和验证需求规格说明是否正确和完整地表达了用户对软件系统的需求

需求管理主要根据需求的变化对需求规格说明的内容及版本进行管理。任务是有效的管理软件系统的需求规格说明及其相应文档，评估需求变更带来的潜在影响及其可能得成本费用，跟踪软件需求的状态，管理需求规格说明的版本等。

3需求获取

过程：确定需求开发计划——>建立项目的目标和范围——>确定调查对象——>实地收集需求信息——>确定非功能需求

3.1确定需求开发计划

确定需求开发计划的基本任务是确定需求开发的实施步骤，给出收集需求活动的具体安排和进度，只考虑需求开发相关的工作

3.2确定项目目标和范围

基本任务是根据项目目标把相关人员定位在一个共同的和明确的方向上，并决定软件系统的范围。
项目目标：包括项目开发的目的和意义
项目的范围：软件系统具体应包括和不应包括的部分

3.3确定调查对象

基本任务是明确来自不同层次的需求来源和用户，将其分类。
软件需求层次：目标需求、业务需求、功能和非功能需求
用户一般包括：提出目标需求的用户、提出业务要求和功能需求的用户、软件开发人员（主要是系统分析员）
软件需求几个典型的来源：直接或间接使用软件系统的用户、系统规格需求说明、市场调查和用户问卷调查、同类软件系统的描述文档、对人工系统中存在的问题报告、观察在工作的用户、用户工作内容分析。

3.4实地收集需求信息

基本任务是到现场实地调查和用户交流，收集需求信息。
1.实地调查的困难

1. 没有充分时间交流
2. 用户和开发人员只考虑自已的利益
3. 用户本身不能提出明确的需求

2.实地调查的步骤

1. 向掌握“全局”的负责人调查
2. 向部门负责人调查
3. 向业务人员调查

3.实地收集需求信息的方式

1. 座谈会方式
2. 书面咨询方式
3. 利用用例表示法方式

4.需求信息分类

1. 目标需求
2. 用例说明
3. 业务规则
4. 功能需求
5. 性能需求
6. 外部接口需求
7. 限制
8. 数据定义
9. 解决方案

3.5确定非功能需求

非功能需求是衡量软件是否良好运行的定性指标。
例举一些用户关心的非功能需求有：可靠性、可扩充性、安全性、互操作性、 健壮性、易使用性、可维护性、可移植性、可重用性

3.6搜集需求要注意的问题

1. 适当调整收集的范围
2. 尽量把用户所做的假设解释清楚
3. 尽量理解用户用于表达对他们需求的思维过程
4. 尽量避免不熟悉的细节影响
5. 尽量避免讨论一些具体的解决方案
6. 需求信息收集工作的结束

3.7使用场景技术的需求获取

1.场景的定义及构成
2.场景的表示
3.场景的种类
4.场景技术的特点

3.8基于用例的需求获取

用例是场景的集合，用例描述可发生的所有事件的序列，场景只是描述一部分。
（插入用例图）
结构化形式：
用例名：用例的名称
执行者：用例的主导者
目的：用例的目的
前提条件：启动用例的条件
结束条件：用例结束时应当满足的条件
基本序列：按照时间顺序现场发生的执行者与软件系统的相互作用
异常序列：按时间序列描述正常序列的相互作用发生的异常情况，系统与执行者的相互作用
备注：除功能需求以外的非功能需求、设计约束条件和限制或者其他事项等。

4.需求分析(待补充)

基本任务：分析和综合收集到的需求信息
具体工作

4.1建立系统关联图

关联图就是把现象与问题有关系的各种因素串联起来的图形。通过连图可以找出与此问题有关系的一切要图，从而进一步抓住重点问题并寻求解决对策。
例如：

4.2分析需求的可行性

实际要考虑的风险有：性能风险、安全风险、过程风险、数据库风险、日程风险、外部接口风险、稳定风险等。

4.3构建用户接口的原型

构建接口原型的三种方法：

1. 纸上原型法
2. 人工模拟原型化方法
3. 自动原型化方法（构建原型的工具和环境有Visual Basic、Smalltalk、Perl、Python等）

4.4确定需求的可行性

4.5需求建模

SA方法：结构化分析方法（Structured Analysis，SA）是面向数据流进行需求分析的方法，采用自顶向下、逐层分解，建立系统的处理流程，以数据流图和数据字典为主要工具，建立系统的逻辑模型。

4.6建立数据词典

数据词典是定义目标系统中使用的所有数据元素和结构的含义，类型，数量值，格式和度量单位，精度及允许取值范围的共享数据仓库。
例如：

5需求建模方法和技术

5.1什么是数据模型

模型分类：
描述性模型
规约性模型：需求模型为规约性模型
探测性模型

5.2软件工程模型

模型分为：
开发过程模型（规约性）：瀑布式模型、增量模型、螺旋式模型等
信息流模型（描述性）：DFD、SADT等
设计模型：类图、功能层次图
交互作用图：实例图、交互作用图、时序图等
状态迁移模型：状态图、Petri网等
用于构造细节的原理模型：设计模型、实体关联图
过程成熟度模型：CMM,SPICE(模型集合）
其他模型：可靠性模型、成本估算模型等

5.3结构化的需求建模方法

SA方法的特点：

• 尽可能使用图形
• 设计数据流图只考虑要完成的基本功能

1.SA基本思想
把复杂的系统分解为易于理解的若干个子系统，从抽象到具体，逐层分解，确定内部数据流，变换（或加工）的关系，并用数据流图表示的基本思想。分解过程中，被分解的上层是下层的抽象，下层是上层的细节。
2.SA方法的描述手段
一套分层的数据流图：主要说明系统由哪些部分组成，以及各部分之间的联系。
一本词典：为数据流图中出现的每个元素提供详细的说明
其他补充材料：具体补充和修改文档的说明
3.示例说明
（1）建立系统的DFD
… …
（2）数据词典说明
… …
4.SA方法的分析步骤
（1）理解分析当前的现实环境，以获得当前系统的具体模型
（2）建立当前系统的逻辑模型
（3）建立目标系统的逻辑模型
（4）进一步完善目标系统的逻辑模型

5.4面向对象的需求建模方法

面向对象设计方法（OOD）
面向对象的软件工程（OOSE）
面向对象的分析/设计方法（OOAD）
统一建模语言（UML）
1.面对对象的基本概念
对象：客观世界存在的大量实体。…
类：对具有相同性质和操作的一个或者多个对象的描述，是一组对象的集合。…
性质继承：能够直接获得已有的性质与特征，不需要重复定义他们。…
消息：系统运行过程中对象之间相互传递、请求服务的信息。…
类之间的关系：泛化、组成、静态、动态
2.面向对象需求分析
（1）问题分析
（2）应用分析：OMT、OOAD等
3.OMT方法的图形描述工具
三个模型：
描述系统静态数据结构的对象模型——实体与实体之间的联系
描述系统控制结构的动态模型——交互和时序、状态转换
描述系统功能的功能模型——DFD等
4.基于OMT方法的需求建模步骤
（1）构建对象模型
（2）构建动态模型
（3）构建功能模型
（4）定义类和对象的操作

5.5基于图形的需求建模技术

1.UML概述
UML-Unified Modeling Language 统一建模语言，又称标准建模语言。是用来对软件密集系统进行可视化建模的一种语言。UML的定义包括UML语义和UML表示法两个元素。

静态结构：用例图、类图、构件图等
动态结构：状态图、活动图、序列图、协作图等
2.用例图
包含include：a调用子功能b，a包含b
拓展extend：a的功能比b多，a和b相似，a通过b的动作序列插入附点得到的，a扩展b
继承inherit：a是通过b改写的部分动作,a继承b

文档化描述：
用例名称+用例简要描述+与用例有关的执行者+用例执行前所需的前置条件+交互动作的过程+后置条件
例子：

3.活动图
动态图（activity diagram，活动图）是阐明了业务用例实现的工作流程。状态图的特殊形式。与流程图类似，但有以下区别：

1. 能用于描述概念级模型
2. 能描述并行动作
   
   

4.协作图
协作图，又作“通信图”。即Communication Diagram，而“协作”作为一个结构事物用于表达静态结构和动态行为的概念组合，表达不同事物相互协作完成一个复杂功能。故UML 2.0以后通信图不再是协作图，没有专门的”协作图“，只有”协作“。

面向对象动态建模，用于建立行为的实体间行为交互的四种图：状态图(State Diagram)，序列图(Sequence Diagram)，协作图(Communication Diagram)，活动图(Activity Diagram) 。其中，“顺序图”与“协作图”表述的是相似的消息，“活动图”是“状态图”的一种。协作图(Collaboration Diagram /Communication Diagram，也叫合作图)是一种交互图（interaction diagram），强调的是发送和接收消息的对象之间的组织结构。一个协作图显示了一系列的对象和在这些对象之间的联系以及对象间发送和接收的消息。对象通常是命名或匿名的类的实例，也可以代表其他事物的实例，例如协作、组件和节点。使用协作图来说明系统的动态情况。协作图使描述复杂的程序逻辑或多个平行事务变得容易。
例子：

6需求定义

需求规格说明是整个需求工程的最终输出，并以文档的形式给出在需求获取和需求分析阶段所获得的所有用户需求和需求模型。
需求定义的基本任务：根据用户需求编写出需求规格说明。

6.1需求规格说明的作用

• 是软件设计和实现的基础
• 是软件设计和实现的基础
• 能为软件维护提供重要的信息

6.2需求规格说明特性

• 正确性
• 无含糊性
• 完整性
• 一致性
• 可验证性
• 可行性
• 必要性

6.3需求规格说明的结构和内容

一般为

• 引言（目的+文档约定+预期读者与阅读建议+产品范围+参考文献）
• 综合描述（产品前景+产品功能+用户类别及特征+运行环境+设计与实现约束+假设与依赖）
• 系统特性（说明与优先级+功能需求）
• 数据需求（数据逻辑模型+数据字典+报告+数据获取整合保存与处理）
• 外部接口需求（用户界面+硬件接口+软件接口+通信接口）
• 质量属性（可用性+性能+安全性+保密性+其他）
• 国际化与本地化需求
• 其他需求（附录A 词汇表 +附录B 分析模型 +附录C 待确定问题列表）

6.4需求规格说明文档的编写要求

最基本的

• 保持语句简短
• 采用主谓宾结构
• 使用术语与对照表一致

6.5需求规格说明的描述语言

1.自然语言
2.形式化需求描述语言
3.结构化语言
例如：伪语言、PSL、RSL

7需求的形式化描述

7.1形式化规格说明及其方法

1.基于系统特性的方法
2.基于模型的方法
3.基于进程代数的方法

7.2形式化规格说明与软件开发

1.规格说明变换
2.规格说明执行

7.3基于公理或推理规则的形式化规格说明

7.4基于代数的形式化规格说明

7.5形式化语言Z

7.6形式描述语言LOTOS

7.7B方法

8需求验证

8.1需求验证的目的和任务

8.2需求验证的内容和方法

从下面4个方面验证：

• 一致性
• 完整性
• 现实性
• 有效性

8.3需求评审

需求评审就是技术评审，是由非软件开发人员对软件系统进行检查，以发现该系统所存在的问题。

• 非正式评审
• 正式评审
  1.审查人员的缺点和分工
  2.正式审查过程
  3.审查内容
  4.需求评审面临的困难

8.4需求测试

8.5编制用户使用手册草案

8.6解释需求模型

8.7需求可视化

9需求管理

需求管理最主要强调的管理内容如下：

• 控制对基准需求规格说明的变动
• 保持项目计划与需求一样
• 控制单个需求的更改和需求规格说明文档的更改
• 管理需求和需求间的联系，以及需求与设计和实现等方面的依赖关系
• 跟踪需求更改的状态，控制多个需求同时更改的复杂性
• 跟踪需求更改的状态，控制多个需求同时更改的复杂性

9.1需求变更控制

1.控制项目范围的扩展
2.建立变更控制的策略
3.实施变更控制的步骤

9.2需求规格水门文档的版本控制

9.3需求变更状态的跟踪

9.4需求跟踪

1.可跟踪信息分类
2.需求跟踪技术

10面向软件行为和视点需求建模与检测能力

10.1基本原理

面向软件行为和视点需求建模方法是一种可用于建立复杂的软件系统（简称复杂系统）需求模型方法。

基于软件行为和视点的需求分析过程将主要考虑如何发现软件需求信息中的行为，然后有步骤的实施需求模型，具体为：

1. 如何工具自然语言描述需求，建立相应的场景信息
2. 如何根据场景信息抽取与行为相关的信息，并利用行为描述语言建立行为表达式
3. 如何建立行为描述语言的语义模型，未检验复杂系统的一些特性
4. 如何利用模型检验方法和技术检测复杂系统的一些特性

1.基本概念
视点：一个观察者（视点源）根据其关注点和某个问题域而提出的需求信息的集合构成的一个视点
视点模板：视点模板是视点信息的存放形式，并由一些信息槽构成，每个信息槽记录了视点某方面的信息
视点间关系：视点间关系是指两个视点之间在问题域或者需求信息方面的联系。可分为重叠关系、顺序关系、无关关系。
软件行为
行为主体
行为客体
主体的行为踪迹
行为的分类
场景
行为的描述
行为的操作语义
2.基本步骤
划分问题域
标识视点
描述需求
建立场景
使用BDL建立行为模型
建立异类需求模型
检测所有视点
修改需求及行为模型
检测软件系统的部分特性

10.2视点表示模型和视点管理

视点表示模型规定了视点的描述内容。并以视点模板的形式来表达视点
视点管理包括六大管理功能：问题域管理、视点生存过程管理、视点关系表管理、术语表及行为表管理、用户管理、日志管理。
1.视点表示模型
视点表示模型被表示成模板的形式，并称为视点模板
2.划分问题域和标识视点的具体步骤
3.视点管理

10.3需求建模的具体构建方法

1.行为描述语言
2.行为描述语言的动态语义
3.构建行为模型的具体过程
4.实例说明
5.图形化输入
6.异类视点需求模型的转换实现

10.4需求模型的检测方法

1.检测内容
2.检测过程
3.检测过程中各检测方法的具体实现

10.5基于行为模型的需求可视化

10.6需求建模的方法特点

10.7进一步研究

1.方法实现
2.有待研究的问题

11面向问题域的需求分析方法

面向问题域的需求分析方法（PDOA）

11.1问题域

11.2问题域的划分

11.3问题框架

11.4问题框架的类型

11.5PDOA方法分析步骤

1.问题及问题域的界定与描述
2.基于问题框架的问题域划分

11.6问题框架实例间的关系及其组合

1.问题加实例间的关系
2.问题框架实例的组合

12面向多视点的需求工程

12.1什么是视点

12.2多视点与需求工程

12.3多视点需求工程的过程模型

1.视点的标识
2.视点的表示
3.视点的分析
4.视点的集成

12.4示例

13需求工程与软件开发管理

13.1需求与估算

13.2需求与项目进度安排

13.3基于需求的软件规模估算

13.4基于需求的工作估算