软件过程管理 (5)

一个正式的文档，说明如何控制需求变更 建立变更审批系统

chapter__４
42
控制需求渐变的策略
1. 需求一定要与投入有显然的联系，在项目的开 始双方都要明确：需求变化，成本也要变化。 2. 需求的变化要经过出资者的认可。 3. 小的需求变更也要经过正规的需求管理过程， 否则积少成多。 4. 精确的需求和范围的定义并不会阻止需求的变 更。这是两个层面的问题。
缺乏应用领域专家Байду номын сангаас
3.6
Scale: 5 = Very Serious
1 = No Serious
chapter__４ 17
Source: Carnegie-Mellon University, Software Engineering Institute
本章要点
一、软件需求定义 二、软件需求管理过程 三、需求建模的基本方法 四、案例分析
规格说明应该是一个认识模型 规格说明应该容许不完备性并允许扩 充
chapter__４
34
3、规格文档参考
1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
引言 系统定义 应用环境 功能规格 性能需求 产品提交 实现约束 质量描述 其它 签字认证
chapter__４ 35
本章要点
一、软件需求定义 二、软件需求管理过程
作为功能需求的补充，软件需求规格说明 还应包括非功能需求，它描述了系统展现 给用户的行为和执行的操作等。它包括产 品必须遵从的标准、规范和合约；外部界 面的具体细节；性能要求；设计或实现的 约束条件及质量属性。所谓约束是指对开 发人员在软件产品设计和构造上的限制。 质量属性是通过多种角度对产品的特点进 行描述，从而反映产品功能。多角度描述 产品对用户和开发人员都极为重要。

chapter__４
32
软件需求规格说明的原则
从现实中分离功能，即描述要“做什 么”而不是“怎样实现” 要求使用面向处理的规格说明语言 （或称系统定义语言） 如果被开发软件只是一个大系统中的 一个元素，那么整个大系统也包括在 规格说明的描述之中

chapter__４ 33

规格说明应该包括系统运行环境
1. 2. 3. 4. 5.
6.
7. 8.
确定需求变更控制过程 建立变更控制委员会(SCCB) 进行需求变更影响分析 跟踪所有受需求变更影响的工作产品 建立需求基准版本和需求控制版本文档 维护需求变更的历史记录 跟踪每项需求的状态 衡量需求稳定性 chapter__４
41
需求变更管理
管理和控制需求基线的过程 需求变更控制系统
chapter__４ 14
非功能需求
许多非功能需求关心的是系统整体特性，而 不是个别的系统特性。因此非功能需求比功 能需求对系统更关键。一个功能需求没有满 足可能降低系统的能力，而一个非功能系统 需求没有满足则可能使整个系统无法使用。 n 例如：一个飞机系统不符合可靠性需求，它 将不会被批准飞行。若一个实时控制系统无 法满足其性能需求，控制功能可能根本无法 使用。 例如：银行ATM系统 非功能需求：响应时间，安全保密等
24
程、硬件环境、软件环境、现有 的运行系统等具体情况和客观的 信息，建立起良好的沟通渠道和 方式
chapter__４ 25
chapter__４
26
进行需求获取应注意的问题
1.
2. 3. 4.
识别真正的客户 正确理解客户的需求 具备较强的忍耐力和清晰的思维 说明和教育客户
chapter__４
27

chapter__４ 3
镀金（gold plating）的定义 给予用户的东西要多于他们所要求的。 事实上，额外的特性、扩展的功能、 更好的组件以及其他等等，通常都不会 为项目增加什么价值。实际上，镀金常 常会增加项目的开支，因为这需要更多 的资源、更长的开发周期，还会增加重 新设计的风险、耽误项目的交付使用。
chapter__４ 6
本章要点
一、软件需求定义 二、软件需求管理过程 三、需求建模的基本方法 四、案例分析

chapter__４
7
软件需求定义
软件需求

需求是指用户对软件的功能和性能的 要求，就是用户希望软件能做什么事 情，完成什么样的功能，达到什么性 能。
chapter__４
9
4.5 4.3 4.2 4.1
Shortage of systems engineers Shortage of software managers
缺乏了解软件特性的经理人 缺乏合格的项目经理
5
6 7 8 9
Shortage of qualified project managers Shortage of software engineers Fixed - price contract 固定价合同
chapter__４ 4
镀金案例
n
在检视项目要求的时候，你发现了 一个需要创建软件模块的要求。这 个模块允许用户在浏览应用程序的 时候，在屏幕上维持其所喜好的颜 色和字体样式。在更进一步检视的 时候，你意识到这个模块的加入虽 然很好，但是不会为整个项目增添 什么价值。
chapter__４
5
如何确定项目里是否包含有镀金的内容 要验证开发要求或者任务里是否包含 有镀金内容的一种方法是：思考一下 如果项目没有包含这个模块的话，其 影响会是什么。问问你自己：如果这 个项目没有包含这个模块，这个应用 程序的可靠性、效率是否会更低，或 者根本就不会有任何降低。
业 务 需求
软件需求的层次
用 户 需求
非功能性 需求 功 能 需求
质量特 性 约束和 假设
系 统 需求
chapter__４
软件需求规 格
10
1．业务需求（business requirement）反映了组织机 构或客户对系统、产品高层次的目标要求，它们 在项目视图与范围文档中予以说明 2．用户需求(user requirement) 文档描述了用户使 用产品必须要完成的任务，这在使用实例（use case）文档或方案脚本说明中予以说明。 3．功能需求(functional requirement)定义了开发人员 必须实现的软件功能，使得用户能完成他们的任 务，从而满足了业务需求。 在软件需求规格说明书 （SRS）中说明的功能需 求充分描述了软件系统所应具有的外部行为。软 件需求规格说明在开发、测试、质量保证、项目 管理以及相关项目功能中都起了重要的作用。对 一个大型系统来说，软件功能需求也许只是系统 需求的一个子集，因为另外一些可能属于子系统 11 （或软件部件）。 chapter__４
n
chapter__４ 15
需求管理的重要性
chapter__４
16
项目失败的原因分析
No.
1 2 3 4
Top 10 Factors
Inadequate requirements specification Changes in requirements 需求的改变 缺乏系统工程师
平均值
不充分的需求规范
修改相应的项目计划
软件基线产品修改提交单
申 请 人 项 目 名称 阶段 名称 文 件 名 称 修 改 内容 验 证 意见 SCCB
韩万江
项目管理系统
表4-3 需求变更提交单
申请 日期
2002 。 10．11
系统设计
RCR-PM-01.doc, RCR-PM-02.doc, 变更简述如下 1）修改测试流程控制：将2个角色，3个渠道流，改为3 个角色，4个渠道流，详见RCR-PM-01.doc 2）增加开发人员技能信息库管理，详见RCR-PM-02.doc 同意RCR-PM-01.doc变更。RCR-PM-02.doc的变更可以推 迟到下一个版本实施 验证日 2002 ． 验证人 杨炎泰 10．11 期 填表 47 chapter__４ 韩万江，姜岳尊，孙泉 韩万江 人

chapter__４ 37
本章要点
一、软件需求定义 二、软件需求管理过程

需求的获取 需求分析 编写需求规格 需求验证 需求变更

三、需求建模的基本方法 四、案例分析

chapter__４ 38
需求总在变化
chapter__４
39
chapter__４
40
需求变更管理
chapter__４ 43
变更控制过程
chapter__４
44
需求变更处理流程
n
n n
提出变更 变更评估 实施变更
chapter__４
45
需求方
变更申请 选择变更方式
开发方
忽略
SCCB评估 根据评估结果
项目经理自行决定
拒绝
接受本次修改
下个版本再修改
chapter__４
46
修改合同相关信息
修改相关需求
chapter__４ 12
以一个字处理程序为例来说明需求的不同 种类。 业务需求可能是：“用户能有效地纠正文档 中的拼写错误”，该产品的包装盒封面上可 能会标明这是个满足业务需求的拼写检查器。 用户需求可能是“找出文档中的拼写错误并 通过一个提供的替换项列表来供选择替换拼 错的词”。同时，该拼写检查器还有许多功 能需求，如找到并高亮度提示错词的操作； 显示提供替换词的对话框以及实现整个文档 范围的替换。
本章要点
一、软件需求定义 二、软件需求管理过程

需求的获取 需求分析 编写需求规格 需求验证 需求变更

三、需求建模的基本方法 四、案例分析

chapter__４ 28
需求分析定义

需求分析是为最终用户所看到的系统 建立一个概念模型，是对需求的抽象 描述。
chapter__４
本章要点
一、软件需求定义 二、软件需求管理过程

需求的获取 需求分析 编写需求规格 需求验证 需求变更

三、需求建模的基本方法 四、案例分析

chapter__４ 22
需求获取图示
chapter__４
23
需求获取
软 件 需 求
基线需求
用户要求
扩展需求
chapter__４

chapter__４
18
软件需求管理过程
软件需求管理的过程
需 求 确 认
需求获取 需求分析
需求验证
编写需求规格
需求变更
需求变更
chapter__４ 20
需求开发(确认)和管理基本任务
需求工程
需求开发
需求管理
需求获取
需求分析
变更管理 版本控制
需求验证
需求规格说明
chapter__４
风险分析
21
29
需求分析模型
chapter__４
30
本章要点
一、软件需求定义 二、软件需求管理过程

需求的获取 需求分析 编写需求规格 需求验证 需求变更

三、需求建模的基本方法 四、案例分析

chapter__４ 31
需求规格
需求分析工作完成的一个基本标志是形成 了一份完整的、规范的需求规格说明书 需求规格说明书的编制是为了使用户和软 件开发者双方对该软件的初始规定有一个 共同的理解，使之成为整个开发工作的基 础。

需求的获取 需求分析 编写需求规格 需求验证 需求变更

三、需求建模的基本方法 四、案例分析

chapter__４ 36
需求验证
需求是正确的吗？ 需求是一致的吗？ 需求是完全的吗？ 需求是实际可行的吗？ 需求是必要的吗？ 需求是可检验的吗？ 需求是可跟踪的吗？ 最后的签字
chapter__４ 13
功能需求

功能需求：列举出被开发软件在职能上应做什么。 这是最主要的需求，规定开发人员必须在产品中 实现的软件功能，用户利用这些功能来完成任务， 满足业务需求。 通常功能性需求是： 产品功能的规格说明； 产品必须执行的动作； 源自于产品的基本目标

例如：银行ATM系统 功能性需求：取、存、查、密码检验
承上启下
项目合同管理 生存期模型

chapter__４
0
RoadMap
合同管理 生存期 需求管理 任务分解 规模估算 项目进度
质量计划
配置计划
风险计划
团队管理
项目度量
集成项目
跟踪控制 项目结束
chapter__４ 1
软件开发项目管理
第四章 软件项目需求管理
chapter__４ 2
需求管理中的问题举例 需求的隐含错误 需求不明确、含糊 用户不断增加需求、变更需求 用户刁难 开发人员的镀金
4.1
3.9 3.8 3.8 3.6
缺乏软件工程师
Inadequate communications for system integration 系统集成阶段 , 交流与沟通不充分 团队缺乏经验
Insufficient experience as team
10
Shortage of application domain experts 3 = Serious