测试开发技术网站

[【原文链接】系统架构设计师（第二版）学习笔记----需求工程](http://devops-dev.com/article/676)

[TOC]

# 一、需求定义
## 1.1 需求包含的内容
* 用户解决问题或达到目标所需条件或权能
* 系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或权能。
* 一种反映上面所述条件或权能的文档说明

## 1.2 软件需求的3个不同层次
* 业务需求
* 用户需求
* 功能需求

## 1.3 需求工程的阶段
* 需求获取
* 需求分析
* 形成需求规格
* 需求确认与验证
* 需求管理

## 1.4 需求管理的主要内容
* 控制对需求基线的变动
* 保持项目计划与需求一致
* 控制单个需求和需求文档的版本情况
* 管理需求和联系链，或管理单个需求和其他项目科交付产品之间的依赖关系
* 跟踪基线中的需求状态

# 二、需求获取
## 2.1 需求获取的基本步骤
* 开发高层的业务模型
* 定义项目范围和高层需求
* 识别用户角色和用户代表
* 获取具体的需求
* 确定目标系统的业务工作流
* 需求整理与总结

## 2.2 需求获取方法
* 用户面谈
* 需求专题讨论会
* 问卷调查
* 现场观察
* 原型化方法
* 头脑风暴法

## 2.3 需求讨论会参与人员
* 主持人
* 用户
* 技术人员
* 项目组人员

## 2.4 专题讨论会的优点
* 协助建立一支高效的团队，围绕项目成功的目标
* 所有的风险承担人都畅所欲言
* 促进风险承担人和开发团队之间达成共识
* 揭露和解决哪些妨碍项目成功的行政问题
* 能够很快地产生初步的系统定义
* 可以有效解决不同涉众主键的需求冲突

# 三、需求变更
## 3.1 需求变更管理过程
* 问题分析和变更描述
* 变更分析和成本计算
* 变更实现
![](https://redrose2100.oss-cn-hangzhou.aliyuncs.com/img/c5eb20cc-57c4-11ee-b3c7-0242ac110004.png)

## 3.2 需求变更策略
* 所有需求变更必须遵循变更控制过程
* 对于未获得批准的变更，不应该做设计和实现工作
* 变更应该由项目变更控制委员会决定实现哪些变更
* 项目风险承担者应该能够了解变更的内容
* 绝不能从项目配置库中删除或者修改变更请求的原始文档
* 每一个集成的需求变更必须能跟踪到一个经核准的变更请求，以保持水平可追踪性

## 3.3 变更控制委员会（CCB）的组成
* 产品或计划管理部门
* 项目管理部门
* 开发部门
* 测试或质量保证部门
* 市场部或客户代表
* 制作用户文档的部门
* 技术支持部门
* 帮助桌面或用户支持热线部门
* 配置管理部门

## 3.4 CCB操作步骤
* 指定决策
* 交流情况
* 重新协商约定

## 3.5 需求追踪的两种方式
* 正向跟踪
* 逆向跟踪

测试开发技术网站

博客