需求工程
需求工程
1 阶段划分
软件需求是指用户对系统在功能、行为、性能、设计约束等方面的期望
- 需求获取
- 需求分析
- 形成需求规格【SRS 规格说明书】
- 需求确认与验证 【形成需求基线（评审过的SRS）】
- 需求管理：对需求基线进行管理
- 变更控制
- 版本控制
- 需求跟踪
- 需求状态跟踪
2 需求获取
2.1 需求层级
- 业务需求：整体、全局的需求，偏向于目标性的东西。
- 用户需求：用户视角 和实际用户沟通，了解用户的需求。
- 功能需求：系统需求，系统要实现的功能、达到哪些性能指标、有哪些设计约束（比如指定技术栈，运行环境）
2.2 获取方法
| 方法 | 特点 |
|---|---|
| 用户面谈 | 1对1-3，有代表性的用户，了解主观想法，交互好。成本高，要有领域知识支撑。 |
| 联合需求计划（JRP） | 高度组织的群体会议，各方参与，了解想法，消除分歧，交互好，成本高。 |
| 问卷调查 | 用户多，无法一一访谈，成本低。 |
| 现场观察 | 针对较为复杂的流程和操作。 |
| 原型化方法 | 通过简易系统方式解决早期需求不确定问题。 |
| 头脑风暴法 | 一群人围绕新业务，发散思维，不断产生新的观点。 |
3 需求分析
3.1 结构化需求分析
数据字典：模型里表述不清的地方，用数据字典解释（比如 实体定义）
3类模型
3.1.1 功能模型
一般用数据流图DFD完成
- 数据流
- 加工
- 数据存储
- 外部实体
3.1.2 数据模型
E-R图
- 实体
- 联系
3.1.3 行为模型
状态转换图
- 状态（初态、终态）
- 事件
3.2 面向对象需求分析（UML）
统一建模语言UML：平台无关性、语言无关性
3.2.1 事物
- 结构事物：静态的部分，包括类，接口、协作、用例、构件和节点
- 行为事物：代表时间和空间上的动作。消息、动作次序、连接
- 分组事物：看成是个盒子，如：包，构件
- 注释事物：UML模型的解释部分。描述、说明等
3.2.2 关系
3.2.3 图
静态图（结构图）：
- 类图：一组类、接口、协作和它们之间的关系
- 对象图：一组对象和它们之间的关系
- 构件图：一个封装的类和它的结构
- 部署图：软硬件之间的映射
- 制品图：系统物理结构
- 包图：由模型本身分解而成的组织单元，以及它们之间的依赖古纳西
- 组合结构图
动态图（行为图）：
- 用例图：系统与外部参与者的交互
- 顺序图：强调按时间顺序
- 通信图：协作图
- 定时图：强调实际时间
- 交互概览图
- 活动图：类似程序流程图，并行行为
- 状态图：：状态转换变迁
4 需求定义
即形成需求规格说明书
4.1 严格定义法
适用于清晰的需求，偏向瀑布模型的思想
- 所有需求都能被预先定义好（预测形，如：瀑布模型）
- 开发和用户之间能够准确而清晰的交流
- 采用图形/文字可以充分体现最终系统
4.2 原型法
适用于不清晰的需求，偏原型开发模型的思想
- 并非所有需求都能在开发前被准确说明
- 项目参加者之间存在交流上的困难
- 需要实际、可供用户参与的系统模型
- 反复是完全需要和值得提倡的，需求一旦确定，就应遵从严格的方法
5 需求确认与验证
需求基线：经过评审的需求规格说明书
SRS通过需求验证后得到需求基线
要求客户参与，签字确认
6 需求跟踪
需求开发跟踪不易，在项目当中获取全面的需求也不容易
正向跟踪：用户原始需求 -> 软件需求 -> 下游工作产品
二维表（原始需求、需求用例）
反向追踪：下游工作产品 -> 软件需求 -> 用户原始需求
7 需求变更管理
项目形成需求基线后，不能随意改动。要先分析再决定要不要做
识别出问题
问题分析和变更描述
变更分析和成本计算
变更实现