软件工程第三章——需求分析（仅记录我所认为重要的知识点）_需求获取提炼描述验证

什么是需求分析

确定你要开发的系统所必须具有的功能和性能,系统要求的运行环境,并且预测系统发展的前景等一系列分析

如何来做需求分析

需求分析的过程
按顺序（需求确认）

1. 需求获取
2. 需求提炼
3. 需求描述
4. 需求验证

1. 需求获取

我们需要j获取两种需求

1. 功能性需求
2. 非功能性需求

功能性需求

描述系统应该完成那些功能，为用户提供哪些服务

非功能性需求

开发系统必须遵守的标准。规范细节，质量等约束条件

常见需求获取出现的问题

1. 客户无法清楚的表述需求
2. 需求易变
3. 对于问题的复杂性和对问题空间理解的不完备性与不一致性（开发人员或分析人员理解不同）

2.需求提炼

对应用问题及环境的理解和分析，为问题涉及的信息、功能及系统行为建立模型。将用户需求精确化、完全化，最终形成下一步的需求规格说明书。

1. 需求提炼（需求分析)的核心在于建立分析模型
2. 需求提炼（需求分析）采用多种形式描述需求，通过建立需求的多种视图，揭示出一些更深的问题。
3. 需求提炼（需求分析)）还包括与客户的交流以澄清某些易混淆的问题，并明确哪些需求更为重要，其目的是确保所有风险承担者尽早地对项目达成共识并对将来的产品有个相同而清晰的认识。
   

需求规格说明书

是对待开发系统的行为的完整描述。它包含了功能性需求和非功能性需求。
需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求规格说明书。
需求规格说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。

4.需求验证

对于需求文档需要在完成后进行及时的检查
检查类型

1. 有效性检查（检查不同用户使用不同功能的有效性）
2. 一致性检查（在文档中，需求之间不应该冲突）
3. 完备性检查（需求文档应该包括所有用户想要的功能和约束）
4. 现实性检查（检查保证能利用的现有技术实现需求）

需求验证技术

需求评审
利用原型检验系统是否符合用户的真正需要
对每个需求编写概念性的测试用例。
编写用户手册。用浅显易懂的语言描述用户可见的功能。
自动的一致性分析。可用CASE工具检验需求模型的一致性。

需求变更

需求分析的任务

软件需求规格文档编制

沟通活动通用任务集

1. 识别主要客户和共利益者
2. 与主要客户会谈“上下文无关的问题”,以确定

a.业务需要和商业价值
b.最终用户的特性\需要
c.需要的用户可见输出
d.业务约束

3. 写一页项目范围的说明
4. 评审范围说明，并应客户要求做出相应修改
5. 与客户/最终用户进行协作，确定:

采用标准格式记录客户可见的使用场景
输入和输出
重要的软件特性、功能和行为
客户定义的商业风险

6. 描述场景、输入/输出、特性/功能以及风险
7. 与客户细化场景、输入/输出、特性/功能以及风险
8. 为每个用户场景、特性、功能和行为分配客户定义的优先级
9. 回顾搜集的所有信息并修订
10. 为计划活动做准备

软件需求规格说明的原则

1. 从现实中分离功能，即描述要“做什么”而不是“怎样实现”
2. 要求使用面向处理的规格说明语言（或称系统定义语言)
3. 如果被开发软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中
4. 规格说明必须包括系统运行环境
5. 规格说明必须是一个认识模型
6. 规格说明必须是可操作的
7. 规格说明必须容许不完备性并允许扩充
8. 规格说明必须局部化和松散耦合

软件需求规格说明的结构

1. 引言
2. 综合描述

a.产品前景
b.产品功能与优先级
c.用户特征
d.运行环境
e.设计与实现上的限制f.假设和依赖性

3. 需求描述

a.功能需求
b.数据需求:与功能有关的数据定义和数据关系
c.性能需求:响应时间、容量要求、用户数等
d.外部接口:用户界面、软硬件接口、通信接口
e.设计约束:软件支持环境、报表、数据命名等
f.软件质量属性（可维护性、可靠性、可移植性、可用性、安全性等)
g.其他需求

4. 附录（分析模型，待定问题）
5. 索引

需求分析建模

面向过程分析模型

其基本思想是用系统工程的思想和工程化的方法,根据用户至上的原则，自始自终按照结构化、模块化，自顶向下地对系统进行分析与设计。

结构化分析方法

面向数据流进行需求分析的方法
结构化分析方法适合于数据处理类型软件的需求分析
具体来说，结构化分析方法就是用抽象模型的概念，按照软件内部数据传递、变换的关系，自顶向下逐层分解，直到找到满足功能要求的所有可实现的软件为止

数据流图

加工

表示对数据进行的操作,如“处理选课单”“产生发票”等
加工的编号，说明这个加工在层次分解中的位置(分层DFD)

外部实体

位于系统之外的信息提供者或使用者,称为外部实体。即存在于系统之外的人员或组织。如“学务科”等
说明数据输入的源点(数据源)或数据输出的终点(数据终点)
起到更好的理解作用，但不是系统中的事物

数据流

表示数据和数据流向,由一组固定成分的数据组成如“选课单”由“学号、姓名、课程编号、课程名”等成分组成
数据流可从加工流向加工，也可在加工与数据存储或外部项之间流动;两个加工之间可有多股数据流
数据流必须要么从某个加工流出、要么流入某个加工，而不能直接从外部项流向数据存储等等。

数据存储

简单数据流图

分层数据流图
步骤1

步骤2

步骤3加工

步骤4合成

最后进行检查

面向对象分析模型

由5个层次（(主题层、对象类层、结构层、属性层和服务层)和5个活动(标识对象类、标识结构、定义主题、定义属性和定义服务)组成。

面向对象的软件开发模型

数据模型（对象模型）：描述系统数据结构的对象模型
行为模型（动态模型）：描述系统控制结构
功能模型：描述系统功能

功能模型——用例图

参与者：
参与者(actor）是指系统以外的、需要使用系统或与系统交互的东西，包括人、设备、外部系统等。

用例：
对一组动作序列的描述，系统通过执行这一组动作序列为参与者产生一个可观察的结果
用例特征
说明了系统具有的一种行为模式
说明了一个参与者与系统执行的一个相关的事件序列
提供了一种获取系统需求的方法
提供了一种与最终的用户和领域专家进行沟通的方法
提供了一种测试系统的方法
图形表示
用椭圆形表示

用例之间的关系

1. 关联

2. 泛化

3. 包含

4. 扩展

建立用例图

1.确定谁会直接使用该系统。这些都是参与者(Actor)。
2.选取其中一个参与者。
3.定义该参与者希望系统做什么，参与者希望系统做的每件事成为一个用例。
4.对每件事来说，何时参与者会使用系统，通常会发生什么，这就是用例的基本过程。
5.描述该用例的基本过程。
6.考虑一些可变情况，把他们创建为扩展用例。
7.复审不同用例的描述，找出其中的相同点，抽出相同点作为共同的用例。8.重复步骤2~7找出每一个用例。