软件需求与需求管理

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