软件工程2-需求分析

Posted on 2025-05-01

需求分析概述

概述

定义

确认系统必须具备的功能、性能、系统要求的运行环境，预测发展的前景；
以一种清晰，简洁，一致性且无二义性的方式，对待开发系统中各个有意义的方面的陈述的集合；

原因

需求分析错误和变更导致软件开发失败占软件失败因素1/3：缺少用户的输入，不完整的需求和规格说明书，需求和规格说明书变更；
希望对开发进行指导；
希望开发人员对用户要求理解；
希望用户理解开发人员；
测试部门有理可依；

过程

需求确认
- 获取-提炼-描述-验证
需求变更
- 随着开发过程，实时发生；
- 变更管理是将个人、团队和组织从现有状态转移/过渡到期望状态的结构化方法。它授权雇员接受并理解当前业务环境中的变更。
- 在项目管理中，变更管理是指项目变更被引入和接受后的项目管理过程，管理和控制需求基线的过程
- 需求变更控制系统：一个正式的文档，说明如何控制需求变更，建立变更审批系统

任务

建立分析模型：清晰准确的语言描述需求；
编写需求说明：《需求规格说明书》

步骤

需求获取
- 软件需求的来源以及获取需求的方法
- 来源：用户目标，领域知识，投资者，运行环境，组织环境；
- 需求获取技术：采访，设定情景，原型，会议，观察商业过程和工作流
需求提炼
- 对应用问题和环境进行理解和分析，为问题设计的信息，功能和系统行为建立模型，将用户需求明确化，完全化
- 核心：建立分析模型
- 采用多种形式描述需求，建立需求的多种视图，解释更深的问题；
- 明确哪些需求更重要，尽早对项目达成共识
需求描述：
- 编写《需求规格说明书》SRS
- 对待开发系统的行为的完整描述，包含功能性需求和非功能性需求
- 完成的基本标志：形成完整规范的需求规格说明书；
- SRS是为了用户和软件开发者双方对软件初始规定有共同理解，成为开发的基础
需求验证
- 后续开发发现前期需求文档的错误，返工的代价很大
- 有效性检查：检查不同功能使用不同功能的有效性
- 一致性检查：需求不应该冲突
- 完备性检查：应该包括所有用户想要的功能和约束
- 可行性检查：保证技术可实现
- 需求验证技术：需求评审，原型，编写测试用例，用户手册，自动化一致性分析

需求分析模型

当前系统-物理模型：模型化；
物理模型-逻辑模型：抽象化；
逻辑模型-逻辑模型：理解需求，表达需求；
逻辑模型-物理模型：实例化；
物理模型-目标系统：具体化；

分析建模

结构化分析模型：结构化，模块化，自顶向下
面向对象模型：5层次（主题层，对象类曾，结构层，属性层，服务层）5活动（标识对象类，标识结构，定义主题，定义属性，定义服务）
面向过程模型；

分析模型描述工具：

数据流图，数据字典和加工规约
控制流图，控制规约和状态变迁图
E-R图
用例图，对象关系图，对象行为图

需求建模工具

	面向对象	面向过程
数据模型	实体-联系图（ERD），数据字典（DD）	类图，类关系图
功能模型	数据流图（DFD）	用例图
行为模型	状态变迁图（STD）	活动图，时序图，状态图

软件需求规格说明原则

描述做什么而不是怎样实现；
系统定义语言；
若软件是大型系统的一个元素，那么大系统也将包括在内；
系统运行环境；
认识模型；
可操作；
容许不完备性和扩充；
局部化和耦合；

结构

引言
- 需求分档的目的；
- 文档约定；
- 预期的读者和阅读建议；
- 产品范围；
- 参考文献；
综合描述
- 产品前景
- 产品功能与优先级
- 用户特征
- 运行环境
- 设计与实现上的限制
- 假设和依赖性
需求描述
- 功能需求
- 数据需求
- 性能需求
- 外部接口
- 设计约束
- 软件质量属性
附录（词汇表，分析模型，待定问题列表）
索引

面向过程的需求分析

结构化分析方法

面对数据流进行需求分析的方法；
适合于数据处理类型的需求分析；
建立模型：
- 功能模型：数据流图（DFD）
- 数据模型：数据字典（DD），实体联系图（ERD），
- 行为模型：状态变迁图（STD）

数据流图

基本成分

数据加工：表示对数据进行的操作；
外部实体：数据源和终点，表示位于系统之外的信息提供者或使用者；
数据流：表示数据和数据流向, 由一组固定成分的数据组成；
数据存储：表示需要保存的数据流向；

数据流

流向：
1. 加工之间
2. 加工与数据存储
3. 加工和外部实体
命名：
1. 具体意义的名字；
2. 现有系统已有的名字
注意：
1. 不需要激发条件；
2. 不要动词（控制流）

合法的数据流：

非法的数据流：

数据加工

编号：说明层次分解的位置（分层DFD）
命名：顶层为项目名，避免只用动词，可以用操作+对象

数据存储

一般局限在某几层，命名和数据流相似；
流向存储或从存储流出的数据流不必命名；

<<<<<<< HEAD

DFD的表示方法

只描述数据的流动；
分为多层，子图和父图表示，逐步展开数据流的细节；
先画顶层DFD，自顶向下进行；
先考虑稳定状态，忽略系统的工作条件，出错处理，随时准备重画；

1fb83ac050b63f0771177bd44e87ff97c80771c8
局部数据存储，只有出现在接口处的才有必要画出来；

字图图号为父图的加工号，顶层不编号；

<<<<<<< HEAD
一般DFD的默认原则：

一般设定深度为3-5层；
各章各数据流图加工数目为7-2 - 7+2

DFD的改进原则：

检查正确性：数据守恒，数据存储的使用，子图和父图的平衡

数据不守恒：某个加工输出的数据没有响应的数据来源，可能某个数据流被遗漏了；一个加工的输入并没有被用到；
数据存储的使用：判断是否存在只写不读，或者只读不写的数据存储
简化加工之间的联系
- 应该尽量减少加工返回输入输出数据流的数目，数据流越少，数据越独立；
- 注意分解的均匀；
适当的命名；
重新的分解：子图发现问题后应该对父图重新分解；

=======
默认原则：

父图-子图平衡：父图输入输出数据流 = 子图输入输出数据流
局部数据存储：出现在加工之间的接口时，才画出来
编号：子图图号为分解的父图中的加工号，同级子图在最后以数字序号区别，顶层不编号
分解程度合适：一般设定深度为$3-5$层，各章各数据流图加工数目为$7\pm 2$

改进原则：

检查正确性
- 数据不守恒：某个加工输出的数据没有响应的数据来源，可能某个数据流被遗漏了；一个加工的输入并没有被用到；
- 数据存储的使用：判断是否存在只写不读，或者只读不写的数据存储
- 父图-子图平衡
提高可理解性
- 简化加工之间的联系：应该尽量减少加工返回输入输出数据流的数目，数据流越少，数据越独立；
- 注意分解的均匀；
- 适当的命名；
重新分解：子图发现问题后应该对父图重新分解

面向对象的需求分析

统一建模语言UML

UML是面向对象的系统分析与设计的建模语言，统一了面向对象建模的基本概念、术语及其图形符号，为不同领域的人员提供一个交流的标准。

系统及其边界

目的：识别什么在系统内，什么在系统外，进而识别出系统的职责；
典型的系统边界：硬件设备，组织，部门
方框代表边界

参与者actor

系统之外的需要用系统或者与系统交互的东西；
表示形式：actor，lable，decoration
小人表示actor

用例use case

系统，子系统或者类和外部的参与者交互的动作序列的说明；
包括可选的动作序列，会出现异常的动作序列；
用例是系统提供给外部可感知的功能单元，描述使用的情况；
目的：定义清晰的系统行为，但不解释系统的内部结构
椭圆+动宾结构：创建索引…

如何获取use case

参与者希望系统执行的任务；
参与者在系统访问的信息；
外界信息如何提供给系统；
系统的什么事情告知参与者；
如何维护系统；

用例特点

用例从使用系统的角度描述系统；
用例描述了用户提出了可见需求，对应具体的用户目标，注意：非功能性需求就是不可见的，登陆也一般不是具体的用户目标；
用例是对系统的动态描述，属于UML的动态建模部分；
识别用例时一个常见的错误是：把用例当成是单独的步骤、操作或事务的处理。

用例图中的关系

关联：参与者和其参与的用例之间的通信途径；
泛化：一般和特殊之间的关系，其中特殊用例继承了一般用例的特性并增加了新的特性
包含：其中一个用例的行为包含另一个用例，在基础用例上插入附加的行为，并且具有明确的描述
扩展：在基础用例上插入基础用例不能说明的扩展部分

关联association

泛化generalization

子用例继承父用例的行为和含义；
子用例也可以新增或覆盖父用例的行为和含义

包含include

箭头由基本用例指向被包含用例；
被包含用例在基本用例执行时必须被执行；
被包含用例也可单独执行;
如果两个以上的用例有共同的功能，则可以将这个功能分解到另一个用例中．
一个用例的功能太多时，可以用包含关系建模两个小用例。

扩展extend

箭头由拓展用例指向基本用例；
扩展用例无法单独被执行；
一个基本用例执行时，可以执行、也可以不执行扩展用例部分；
基本用例必须声明若干扩展点，扩展用例只能在扩展点增加新的新为和含义；

用例描述

主要组成

易犯的错误

只描述系统的行为，没有描述参与者的行为；
只描述参与者行为，不描述系统的行为；
在用用例描述中设计用户界面的设计
描述冗长

用例识别的两种方法：

基于参与者：识别与系统相关的参与者，对于每个参与者，识别出他们发起或参加的执行过程
基于执行过程：

1fb83ac050b63f0771177bd44e87ff97c80771c8