软件需求与需求管理

•申请号 •变更说明 •变更类别 •影响分析 •变更请求状态 •变更请求日期
)
（2）需求变更请求实例（表三）
项目名：XYZ 变更申请号 11 日期：23 Feb 1998
变更说明 影响分析
IS-41 分析器对CDMA的支持 对CDMA的配置模块和分析器无影响 TDMA码可复用 受影响的模块是： ――CGAAPP模块，需对IS-41单独进行规范性分析 ――CDMAPP01模块 （a） TRIS41R01按TRCDMARS 41R01复制 （b） 使用纯虚拟对TRCDMAR01建立 （c） Actual Call Mode Manager 并重新定义 ――SILVER 06 GUIAPP++ 模块：在资源表中加入IS-41 5 人日 无需重大变动 将并入新的CDMA软件包
•是制定软件开发计划SDP的基础
•是制定软件需求的基础
)
（3）与分配需求相关的组： •软件评估组
•系统工程组
•系统测试组 •软件质量保证组SQA •合同管理组 •文档支持组
)
五、需求工程 1．需求工程＝需求开发＋需求管理
获取需求 分析需求
需求开发
定义需求
需求工程
验证需求 需求变更控制
需求跟踪 需求管理 需求状态跟踪 需求文档版本控制 图6 需求工程的构成
分配给硬件的需求 硬件应能使车速在规定的精确度 1.5KMH范围内
分配给软件的需求 软件应能在车速超出预期车速 0.5KMH时给硬件加/减速命令
软 件 需 求 图5 汽车限速系统ACCS的 需求分配
)
软件应能： 读入当前车速值 计算当前车速与预期车速之差 若差值0.5KMH给出加/减速命令
软件需求与需求管理
2002-4-4
)
内
容
软件发展的三个时期
软件生存期过程 软件开发 软件需求 需求工程
需求变更及其控制
CMM2级需求管理关键过程域
)
一、软件发展的三个时期
时期 年代 阶段 涉及 注重
主要使用语言
标准
模型
初期
50-60
程序设计
点
编程 技巧
ALGOL FORTRAN COBOL BASIC
2) 市场形势变化 3) 系统因素
4) 工作环境和要求变化
5) 需求开发的缺陷 ★ 需求分析、定义和评审不充分 ★ 与用户沟通不畅
)
3、需求变更对软件开发的影响 ⑴ 使变更前开发工作和成果失效 ⑵ 返工成为被迫采取的对策 ⑶ 工作量及资源投入的增加使开发成本提高 ⑷ 项目完成时间后延
)
4、需求变更失控可能导致的后果
•可行性
)
（3）定义需求 •编写软件需求规格说明（SRS）
•作用
•要求：完整、正确、可行、无歧意、可验证 •形式：图、表、文字 （4）验证需求 •联合评审
)
六、需求变更 1 、难于完全避免 对问题的 初始理解 初始需求 时间
图8 需求的变更
对问题的 新理解 变更的需求
)
2、需求变更原因分析
1) 单纯的用户因素
ห้องสมุดไป่ตู้
⑿软件验收支持
)
软件开发面临的实际问题
)
软件开发面临的实际问题
)
软件开发面临的实际问题
)
3．当前软件开发项目的特点
――规模大： LOC HP 1万几十万 激光打印驱动软件 4万110万
――复杂 满足客户需求和期望 客户满意度统计 ――开发和维护成本 缺陷后期发现 返工成本
――编码阶段――完成编码和单元测试后成为实现的需求
――测试阶段――完成确认测试后成为完成的需求
)
开发 阶段
需求
建议
设计
编码
测试
需求 状态
获 取
定 义
承 诺
设 计
实 现
完 成
图11 生存期各阶段需求 状态的演变
)
九、可追溯性管理
1 ．需求可追溯性与需求变更控制 •随着开发工作的进展需求将逐步扩展和演化 •各个开发阶段的工作产品之间存在的继承关系 •可追溯性矩阵
)
2．需求变更影响的控制 按CMM2级RM KPA的要求，由于分配需求的变更导致软 件计划、工作产品和活动的变更，都应对其作： •识别 •评价 •风险分析 •编制文档
•制定计划
•传达给受影响的小组和人员 •跟踪直至结束
)
3．变更控制的步骤 （1）提出变更请求 （2）审理变更请求，进行变更影响评估。评估内容包括： •变更所需人力投入 •变更对原计划安排的影响
需求 号
需求 描述
概要设 计文档 索引号
对应的 设计(功 能,结构, 数据库)
实现 (程序, 类,继 承类) PB405 数据采 集 CICS2 03亮点 控制器 启动
单元测 试用例
集成/系 统测试 用例
验收 测试 用例
1.1.2
利用收 集的数 据实现 亮点的 实时集 成
#12
#46
#11
5.3.2
中期
70-80
软件开发
线
结构化 模块化
PASCAL
GB8566 软件开发 规范
瀑布 原型
现代
90-
软件过程
面
过程 能力
C,C++ JAVA VB、VC
ISO/IEC 12207 软件生存期 过程 ISO9000
螺旋 CMM
表一
)
二、软件生存期过程 ISO/IEC12207 信息技术－软件生存期过程
――质量要求高
――延误交付期
)
四、软件需求
1. 系统需求分析
客户
系统工程组 最终用户
系统需求
分配
软件工程组
软件 系统需求(1)
硬件 系统需求(2)
其它成分 系统需求(n)
软件需求 图3 系统需求分配
)
2.软件需求 ⑴ 定义（IEEE-STD-610） 用户为解决某个问题、或为实现某一目标， 要求软件必须满足的条件或能力。
)
市场
用户/系统
管理者
初始需求
变更的需求
获取,分 析,定义, 验证需求 需求开发
项目 环境
需求规格说明 控制需求 变更 需求管理
图7 需求开发与需求管理 )
2．需求开发
（1）获取需求 •确定目标用户、服务对象 •明确用户代表 •用户培训
•了解实际业务和业务需求
（2）分析需求 •分清功能需求、性能需求、使用需 求…… •必要性
3 4
5 6 7 8 9 10 11
演示期 18/2
演示期 演示期 演示期 演示期 18/2 23/2 23/2
用户强迫退出 用户信息归档
关闭窗口 保存扩展数并在需要时恢复 能够在特定节点启动 删除时列出所有节点 注释（建立删除批准修改等） PENETCONFIG――支持netconfig 格式 IS-41分析器――IS-41分析器对CDMA的支持 总计
•估计变更引起的成本增加
（3）批准变更请求 （4）取得用户的认可 （5）修订项目计划 （6）实施变更
（7）验证变更
)
提出变更请求 变更影响评估 评审评估报告 批准 审批 用户认可 修订项目计划 拒绝
实施变更 修正
验证 变更结束
图10 需求变更控制流程
)
八、需求变更控制实施
1．需求变更请求
（1）内容
数据采 集与亮 度控制 器接口
#1
#47
#11
)
十、CMM 2级 RM KPA
需求管理（RM－Requirements Management）是 CMM 2级的第1个关键过程域。需求管理的目的 是要在客户和将处理客户需求的软件项目之间形 成共同的理解。
――有无冗余代码 ――检查所有性能需求是否已被测试用例测试 ――对集成测试计划和系统测试计划进行交互检查 •需求变更控制 ――需求变更后相关的工作产品受影响的部分应随之变 更 ――更新需求规格说明，同时要更新追溯矩阵 ――每增加一项需求，应在追溯矩阵中得到体现
)
表五
1 2 3
追溯矩阵实例
4 5 6 7 8
)
⑶质量功能展开（QFD－Quality Function Development）
客户需求
常规需求：客户明确提出
期望需求：并未明确提出的潜在需求，
不 言而喻的需求 • 兴奋需求：客户未想到，若实现客户 感到意外
)
⑷
分配需求的实例
系统需求 ACCS应能使汽车保持在预期 车速的2KMH范围内行驶
项目开发工作
* 产品后续开发 工作的基础 * 产品维护工作 的重要参考
项目开发组织
* 对用户的承诺 * 关系到项目开发工作的 投入、交付期和产品质量
用户
* 关系到能否如期获 得所需的产品
* 作为合同的附件，关系到双方的权益 * 是产品验收的依据
★向用户说明需求不确切或频繁变更对开发工 作的冲击 ★使用户理解过多变更最终对用户不利
⑵
软件需求的三个层次
• 业务需求 • 用户需求 • 功能需求和非功能需求
)
过程需求：交付需求，实现需求， 遵循的标准
非功能需求 性能需求：速度，容量，可靠性
外部需求：互操作性，伦理性， 机密性，安全性， 使用要求
)
业务需求
业务说明
用户需求
使用实例
约束条件
功能需求
非功能需求
软件需求规格说明
图 4 软件需求的层次
)
⑵ 与用户共同确定需求，作为合同附件， 签字生效 ⑶ 合同中含有对需求变更的条款 ⑷ 采用原型方法开发，或螺旋模型开发 ⑸ 项目计划中适当留有余地（时间进度、人力投入、 费用等） ⑹ 严格实施变更控制