系统架构设计师（第二版）学习笔记----需求工程

【原文链接】系统架构设计师（第二版）学习笔记----需求工程

一、需求定义

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 需求追踪的两种方式

• 正向跟踪
• 逆向跟踪