【原文链接】系统架构设计师（第二版）学习笔记----需求工程
文章目录
一、需求定义
1.1 需求包含的内容
- 用户解决问题或达到目标所需条件或权能
- 系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或权能。
- 一种反映上面所述条件或权能的文档说明
1.2 软件需求的3个不同层次
- 业务需求
- 用户需求
- 功能需求
1.3 需求工程的阶段
- 需求获取
- 需求分析
- 形成需求规格
- 需求确认与验证
- 需求管理
1.4 需求管理的主要内容
- 控制对需求基线的变动
- 保持项目计划与需求一致
- 控制单个需求和需求文档的版本情况
- 管理需求和联系链，或管理单个需求和其他项目科交付产品之间的依赖关系
- 跟踪基线中的需求状态
二、需求获取
2.1 需求获取的基本步骤
- 开发高层的业务模型
- 定义项目范围和高层需求
- 识别用户角色和用户代表
- 获取具体的需求
- 确定目标系统的业务工作流
- 需求整理与总结
2.2 需求获取方法
- 用户面谈
- 需求专题讨论会
- 问卷调查
- 现场观察
- 原型化方法
- 头脑风暴法
2.3 需求讨论会参与人员
- 主持人
- 用户
- 技术人员
- 项目组人员
2.4 专题讨论会的优点
- 协助建立一支高效的团队，围绕项目成功的目标
- 所有的风险承担人都畅所欲言
- 促进风险承担人和开发团队之间达成共识
- 揭露和解决哪些妨碍项目成功的行政问题
- 能够很快地产生初步的系统定义
- 可以有效解决不同涉众主键的需求冲突
三、需求变更
3.1 需求变更管理过程
- 问题分析和变更描述
- 变更分析和成本计算
- 变更实现
3.2 需求变更策略
- 所有需求变更必须遵循变更控制过程
- 对于未获得批准的变更，不应该做设计和实现工作
- 变更应该由项目变更控制委员会决定实现哪些变更
- 项目风险承担者应该能够了解变更的内容
- 绝不能从项目配置库中删除或者修改变更请求的原始文档
- 每一个集成的需求变更必须能跟踪到一个经核准的变更请求，以保持水平可追踪性
3.3 变更控制委员会（CCB）的组成
- 产品或计划管理部门
- 项目管理部门
- 开发部门
- 测试或质量保证部门
- 市场部或客户代表
- 制作用户文档的部门
- 技术支持部门
- 帮助桌面或用户支持热线部门
- 配置管理部门
3.4 CCB操作步骤
- 指定决策
- 交流情况
- 重新协商约定
3.5 需求追踪的两种方式
- 正向跟踪
- 逆向跟踪