软件需求管理部分完整版
合集下载
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
需求管理的首要任务在于使开发人员和用户双方对 于需求都有一个明确的认识。 需求模型实际是最终产品的抽象化表现。 用户需求的满足程度是衡量设计优劣的标准。 优秀的需求分析应当非常精确细致地对用户需求作 出描述，同时也应该最大程度地给予方案设计者充 分发挥的余地。 对开发项目进行任务划分，将整体开发任务细化为 多个子模块，从而使这些子模块能够平行开发而无 需太多的干预。 需求管理在开发周期中是自始至终存在的。需求管 理必须始终保持更新。 需求管理同项目管理是密不可分的。
需求开发面临的特殊难题
需求开发：是针对一个新软件或系统开发项 目的情况，这种项目有时也称为零起点项目 (green-field project)。 大多数组织的主要精力集中于维护现存的遗 留系统，或者为已有的商业产品构建新的版 本；其他组织也很少是从零开始构建一个新 系统，而是对商用现货产品进行集成、定制 和扩充，以满足自己的需要。
注意: 跳过影响分析并不能改变 任务的规模，只会使规 模令人感到惊奇，而软 件方面令人惊奇却很少 是好消息。
影响分析报告模板
变更请求ID号：___________________________________ 标题：___________________________________________ 描述：___________________________________________ _________________________________________________ 分析人员： ______________________________________ 日期： __________________________________________ 优先级评估： 相对收益：_________(1~9) 相对损失：_________(1~9) 相对费用：_________(1~9) 相对风险：_________(1~9) 计算出的最终优先级：_________(相对于其他待处理的需求) 估计的总工作量：_________劳动小时数 估计损失的工作量：_________劳动小时数(用于废弃的工作) 估计对进度的影响：_________天 额外的成本影响：____________美元 质量影响：_______________________________________________ 受影响的其他需求：_______________________________________ 受影响的其他任务：_______________________________________ 集成问题：_______________________________________________ 生存期费用问题：_________________________________________ 检查可能要变更的其他组件：_______________________________
定义质量需求
软件的质量属性和性能目标是选择解决方案时 所要考虑的用户需求的另一个方面。 我们至少要研究下面几个属性： • 性能 • 易使用性 • 灵活性 • 互操作性 • 完整性
尽早地而且要经常地设定优先级
客户和开发人员协同工作，共同选定功 能实现的顺序，这样增量开发才会取得 成功。 开发团队的目标是，将可用的功能和对 质量的改进有规律地交到用户手中，因 此，开发人员必须了解每次增量开发计 划实现哪些功能。
需求变更管理
需求变更是一定存在的，而需求变更管理并 不是指逃避它，更不是说要避免它，它实际 上是希望控制变更 在基线内的需求不响应变更，为开发人员提 供一个安静的工作时间状态 专门的需求变更管理来对所有的需求变更进 行响应，了解需求变更的关键意图、新产生 的工作量，从而良好地进行重新计划，以便 能够有效地解决其对整个开发带来的麻烦
CCB规章
CCB主席是否可以否决CCB的集体决策。 级别高的CCB或其他人是否必须认可CCB做出的决 策。
• 2. 交流状态
CCB做出决策之后，应该指派专人对变更数据库中 的变更请求状态进行更新。
• 3. 重新协商原先的约定
在接受一个重大的需求变更之前，为了适应这一变更， 需要同管理部门和客户重新协商原先的约定 (Humphrey 1997)。 协商的内容可能包括，要求推迟产品交付时间，要求 增派人手，或者要求推迟实现尚未实现的优先级较低 的需求等。
注意： 不要迫于压力而许下自己 明知道不可能做到的诺言， 这是避免最后两败俱伤的 秘诀。
需求管理
需求管理的原则和实践
需求管理包括在项目开发过程中维护需求约定 的完整性、准确性以及保持需求约定是最新约 定的所有活动，如图所示。
8
需求管理
变更控制
建议变更 分析影响 做出决策 交流 合并 测量需求的稳定性
变更控制委员会
变更控制委员会，有时也称为配置控制委员会 (configuration control board，CCB)，已被证实是软 件开发领域公认的最佳实践(McConnell 1996)。 CCB是由人组成的团体，可以由一个小组担任，也可 以由多个不同的小组担任，这些人共同决定将哪些已 提议的需求变更和新提议的特性在产品中付诸实现。 CCB也决定所报告的缺陷中哪些需要纠正，什么时候 纠正。 CCB可以评审和批准对项目中任何基线工作产品所做 的变更，项目需求文档只是其中的一个样例。
图是一个推荐 的报告模板， 表示对每个需 求变更造成的 潜在影响的分 析结果。如果 采用标准模板， CCB成员就可 以轻松地找到 他们所需的信 息，作出合理 的决策。
需求的变化是永恒的。因而，对于需求变更应该 正确对待，尽量将其负面影响降低。 需求变更可能来自解决方案提供商、客户或产品 供应商等外部因素，也可能来源于项目组内部。 变更都是有代价的，应该评估一下变更的代价及 其对项目的影响。 在需求变更发生之前尽量减少需求变更，以将需 求变更带来的风险降低到最低。切忌在项目设计 之前试图消除需求变更。
设定需求优先级
每一个受资源限制的软件项目都必须对要求 的产品功能定义相对优先级。 设定优先级有助于项目经理解决冲突、安排 阶段性交付，并且做出必要的取舍。 讨论设定需求优先级的重要性，提出一个简 单的优先级划分方案，并介绍更严格的基于 价值、成本和风险的优先级分析方案。
5
需求和进度安排
1
开始捕获信息
缺少精确的需求文档，那么维护人员就必须进行 逆向工程，通过代码来理解系统，将此看作是软 件考古学(software archaeology)。 构建一个包含当前系统部分的需求表示可达到以 下3个有用的目标：
• 消除知识鸿沟，使将来的维护人员能更好地理解所做 的变更。 • 收集当前系统的一些信息——当前系统在以前缺乏良 好的书面文档。 • 提供一个指标，表明当前的系统测试集对系统功能的 覆盖率。
必须创建、修改或废弃哪些部分，并估计与实现这 些变更相关的工作量。
影响分析的过程
影响分析有3个方面：
• 1.理解进行变更可能涉及的问 题。变更常常会产生大量的连 锁反应，产品包括的功能太多 会降低其性能，甚至会到令人 难以接受的地步。 • 2.确定如果团队将提议的变更 包括到产品中，可能必须对哪 些文件、模型和文档进行修改。 • 3.确定实现变更所需执行的任 务，并估计完成这些任务所需 的工作量。
需求管理的主要活动
控制对需求基线的变动。 保持项目计划与需求一致。 控制单个需求和需求文档的版本情况。 管理需求和联系链之间的联系或管理单个需 求和其它项目可交付品之间的依赖关系。 跟踪基线中需求的状态。
需求开发与需求管理的分界
中程在线信息产业培训网
需求基线管理
为何需要：频繁的需求变更会破坏开发的节 奏，使整个项目开发的进度陷入混乱和失控 的状态，而且会变成一个“救火队”式的工 作，整天都在处理突发事件. 主要思想：将所有现在的、将来的需求进行 优先级评估，然后分解成为不同的组，每次 迭代都选择其中优先级最高的部分进行开发， 然后在迭代完成之前，开发工作不响应变更， 这些划入的需求项就是需求基线的组 成部分
需求管理的任务
明确需求并达成共识； 建立关联，根据不同需求设计相应解决办法； 进行系统优化，提出设计方案； 监控和解决可能出现的问题以及需要做出的改变； 控制不同开发任务的开展； 对最终产品做出评测； 监控可能出现的重复开发； 提出项目实施时间表； 确定最终用户界面。
变更需要付出代价：影响分析
对软件实施大的功能增强，则需要进行影响分析 (impact analysis)。但是，即使是小的变更请求，也 可能潜伏着难以预料的复杂性。 影响分析是需求管理的一个关键方面(Arnold和 Bohner 1996)。 通过对影响进行分析，可以准确地理解提议的变更 所涉及到的问题，有助于项目团队就批准哪些提议 做出周全合理的业务决策。 影响分析:通过对所提议的变更进行检查，确定可能
版本控制
需求跟踪
需求状态跟踪
确定需求文档版本 确定单个需求文档 版本
定义对其它需求的 连接链 定义对其它系统元 素的连接链
定义需求状态 跟踪需求每一个状 态
软件需求管理
需求管理所要完成的任务 需求管理模型 管理变更 需求风险管理 需求跟踪 需求管理工具
需求管理所要完成的任务
需求基线管理--操作思路
我们应该在分析的基础上，将需求整合成为 用例或功能项，然后对其进行优先级、依赖 性进行综合性评估 优先级判断：业务人员确定业务决定，技术 人员确定技术决策；“满意度/不满意度”模 型 依赖性是指对于某些功能，在实现上有必须 的依赖关系，即当某些功能没有实现时，另 外的功能无法开始，这就需要对其 进行调整
CCB规章
CCB规章描述了CCB的目的、权力范围、成 员构成、运作规程和决策的制定过程等 (Sorensen 1999)。 CCB的权力范围规定了哪些决策由CCB决定， 哪些决策则必须上报给高一级CCB或者由管 理层来决定。
• 1. 制定决策
决策制定过程的描述应该确定： CCB成员或主要角色的人数，这是制定决策的法定人 数。 所采用的决策规则是投票、少数服从多数、协商决定 或其他方法。
对待Baidu Nhomakorabea件项目管理的组织必须确保做到以 下几点：
• 在提交提议的需求变更之前要对其进行仔细的 评估。 • 请合适的人员就需求变更做出周全合理的业务 决策。 • 将已批准的变更传达给受此影响的所有人员。 • 项目以一致的方式将需求变更包含进来。
采用一致的变更控制方法，就可以避免相 关问题，避免开发工作的返工和浪费时间 等情况的发生。
里程碑与项目管理
一项需求的满足就意味着一块里程碑的确立。 里程碑构造机制的基本方法之一就是进程管 理。 需求管理在开发周期中是自始至终存在的。 需求管理必须始终保持更新，它构成了技术 管理的基础。 需求管理同项目管理是密不可分的 。
需求管理模型
不同的需求组合起来，构成了一套完整的需求 模型。 需求管理的一项重要工作就是在整个项目的不 同任务之间建立联系。 需求管理包括在工程进展过程中维持需求约定 集成性和精确性的所有活动。 需求管理的关键过程领域。 需求管理的步骤。
CCB的组成
CCB的成员应该能代表需要参与制定决策的所 有小组，当然这些决策制定只能是在CCB的权 力范围之内。 可考虑从下面这些部门中选择CCB代表：
• • • • 项目或程序管理部门 产品管理或需求分析部门 开发部门 测试或质量保证部门 • • • • 市场或客户代表 编写用户文档的部门 技术支持或帮助部门 配置管理部门
需求变更的原因
因竞争、成本等因素，工期已经确定且极不 合理. 用户在需求期提不出需求、或用户的需求不 明确. 项目组对业务不熟悉、或者没有与用户密切 结合、需求分析工作不细致. 项目组没有很好地实施需求管理.
需求开发面临的特殊难题
需求开发：是针对一个新软件或系统开发项 目的情况，这种项目有时也称为零起点项目 (green-field project)。 大多数组织的主要精力集中于维护现存的遗 留系统，或者为已有的商业产品构建新的版 本；其他组织也很少是从零开始构建一个新 系统，而是对商用现货产品进行集成、定制 和扩充，以满足自己的需要。
注意: 跳过影响分析并不能改变 任务的规模，只会使规 模令人感到惊奇，而软 件方面令人惊奇却很少 是好消息。
影响分析报告模板
变更请求ID号：___________________________________ 标题：___________________________________________ 描述：___________________________________________ _________________________________________________ 分析人员： ______________________________________ 日期： __________________________________________ 优先级评估： 相对收益：_________(1~9) 相对损失：_________(1~9) 相对费用：_________(1~9) 相对风险：_________(1~9) 计算出的最终优先级：_________(相对于其他待处理的需求) 估计的总工作量：_________劳动小时数 估计损失的工作量：_________劳动小时数(用于废弃的工作) 估计对进度的影响：_________天 额外的成本影响：____________美元 质量影响：_______________________________________________ 受影响的其他需求：_______________________________________ 受影响的其他任务：_______________________________________ 集成问题：_______________________________________________ 生存期费用问题：_________________________________________ 检查可能要变更的其他组件：_______________________________
定义质量需求
软件的质量属性和性能目标是选择解决方案时 所要考虑的用户需求的另一个方面。 我们至少要研究下面几个属性： • 性能 • 易使用性 • 灵活性 • 互操作性 • 完整性
尽早地而且要经常地设定优先级
客户和开发人员协同工作，共同选定功 能实现的顺序，这样增量开发才会取得 成功。 开发团队的目标是，将可用的功能和对 质量的改进有规律地交到用户手中，因 此，开发人员必须了解每次增量开发计 划实现哪些功能。
需求变更管理
需求变更是一定存在的，而需求变更管理并 不是指逃避它，更不是说要避免它，它实际 上是希望控制变更 在基线内的需求不响应变更，为开发人员提 供一个安静的工作时间状态 专门的需求变更管理来对所有的需求变更进 行响应，了解需求变更的关键意图、新产生 的工作量，从而良好地进行重新计划，以便 能够有效地解决其对整个开发带来的麻烦
CCB规章
CCB主席是否可以否决CCB的集体决策。 级别高的CCB或其他人是否必须认可CCB做出的决 策。
• 2. 交流状态
CCB做出决策之后，应该指派专人对变更数据库中 的变更请求状态进行更新。
• 3. 重新协商原先的约定
在接受一个重大的需求变更之前，为了适应这一变更， 需要同管理部门和客户重新协商原先的约定 (Humphrey 1997)。 协商的内容可能包括，要求推迟产品交付时间，要求 增派人手，或者要求推迟实现尚未实现的优先级较低 的需求等。
注意： 不要迫于压力而许下自己 明知道不可能做到的诺言， 这是避免最后两败俱伤的 秘诀。
需求管理
需求管理的原则和实践
需求管理包括在项目开发过程中维护需求约定 的完整性、准确性以及保持需求约定是最新约 定的所有活动，如图所示。
8
需求管理
变更控制
建议变更 分析影响 做出决策 交流 合并 测量需求的稳定性
变更控制委员会
变更控制委员会，有时也称为配置控制委员会 (configuration control board，CCB)，已被证实是软 件开发领域公认的最佳实践(McConnell 1996)。 CCB是由人组成的团体，可以由一个小组担任，也可 以由多个不同的小组担任，这些人共同决定将哪些已 提议的需求变更和新提议的特性在产品中付诸实现。 CCB也决定所报告的缺陷中哪些需要纠正，什么时候 纠正。 CCB可以评审和批准对项目中任何基线工作产品所做 的变更，项目需求文档只是其中的一个样例。
图是一个推荐 的报告模板， 表示对每个需 求变更造成的 潜在影响的分 析结果。如果 采用标准模板， CCB成员就可 以轻松地找到 他们所需的信 息，作出合理 的决策。
需求的变化是永恒的。因而，对于需求变更应该 正确对待，尽量将其负面影响降低。 需求变更可能来自解决方案提供商、客户或产品 供应商等外部因素，也可能来源于项目组内部。 变更都是有代价的，应该评估一下变更的代价及 其对项目的影响。 在需求变更发生之前尽量减少需求变更，以将需 求变更带来的风险降低到最低。切忌在项目设计 之前试图消除需求变更。
设定需求优先级
每一个受资源限制的软件项目都必须对要求 的产品功能定义相对优先级。 设定优先级有助于项目经理解决冲突、安排 阶段性交付，并且做出必要的取舍。 讨论设定需求优先级的重要性，提出一个简 单的优先级划分方案，并介绍更严格的基于 价值、成本和风险的优先级分析方案。
5
需求和进度安排
1
开始捕获信息
缺少精确的需求文档，那么维护人员就必须进行 逆向工程，通过代码来理解系统，将此看作是软 件考古学(software archaeology)。 构建一个包含当前系统部分的需求表示可达到以 下3个有用的目标：
• 消除知识鸿沟，使将来的维护人员能更好地理解所做 的变更。 • 收集当前系统的一些信息——当前系统在以前缺乏良 好的书面文档。 • 提供一个指标，表明当前的系统测试集对系统功能的 覆盖率。
必须创建、修改或废弃哪些部分，并估计与实现这 些变更相关的工作量。
影响分析的过程
影响分析有3个方面：
• 1.理解进行变更可能涉及的问 题。变更常常会产生大量的连 锁反应，产品包括的功能太多 会降低其性能，甚至会到令人 难以接受的地步。 • 2.确定如果团队将提议的变更 包括到产品中，可能必须对哪 些文件、模型和文档进行修改。 • 3.确定实现变更所需执行的任 务，并估计完成这些任务所需 的工作量。
需求管理的主要活动
控制对需求基线的变动。 保持项目计划与需求一致。 控制单个需求和需求文档的版本情况。 管理需求和联系链之间的联系或管理单个需 求和其它项目可交付品之间的依赖关系。 跟踪基线中需求的状态。
需求开发与需求管理的分界
中程在线信息产业培训网
需求基线管理
为何需要：频繁的需求变更会破坏开发的节 奏，使整个项目开发的进度陷入混乱和失控 的状态，而且会变成一个“救火队”式的工 作，整天都在处理突发事件. 主要思想：将所有现在的、将来的需求进行 优先级评估，然后分解成为不同的组，每次 迭代都选择其中优先级最高的部分进行开发， 然后在迭代完成之前，开发工作不响应变更， 这些划入的需求项就是需求基线的组 成部分
需求管理的任务
明确需求并达成共识； 建立关联，根据不同需求设计相应解决办法； 进行系统优化，提出设计方案； 监控和解决可能出现的问题以及需要做出的改变； 控制不同开发任务的开展； 对最终产品做出评测； 监控可能出现的重复开发； 提出项目实施时间表； 确定最终用户界面。
变更需要付出代价：影响分析
对软件实施大的功能增强，则需要进行影响分析 (impact analysis)。但是，即使是小的变更请求，也 可能潜伏着难以预料的复杂性。 影响分析是需求管理的一个关键方面(Arnold和 Bohner 1996)。 通过对影响进行分析，可以准确地理解提议的变更 所涉及到的问题，有助于项目团队就批准哪些提议 做出周全合理的业务决策。 影响分析:通过对所提议的变更进行检查，确定可能
版本控制
需求跟踪
需求状态跟踪
确定需求文档版本 确定单个需求文档 版本
定义对其它需求的 连接链 定义对其它系统元 素的连接链
定义需求状态 跟踪需求每一个状 态
软件需求管理
需求管理所要完成的任务 需求管理模型 管理变更 需求风险管理 需求跟踪 需求管理工具
需求管理所要完成的任务
需求基线管理--操作思路
我们应该在分析的基础上，将需求整合成为 用例或功能项，然后对其进行优先级、依赖 性进行综合性评估 优先级判断：业务人员确定业务决定，技术 人员确定技术决策；“满意度/不满意度”模 型 依赖性是指对于某些功能，在实现上有必须 的依赖关系，即当某些功能没有实现时，另 外的功能无法开始，这就需要对其 进行调整
CCB规章
CCB规章描述了CCB的目的、权力范围、成 员构成、运作规程和决策的制定过程等 (Sorensen 1999)。 CCB的权力范围规定了哪些决策由CCB决定， 哪些决策则必须上报给高一级CCB或者由管 理层来决定。
• 1. 制定决策
决策制定过程的描述应该确定： CCB成员或主要角色的人数，这是制定决策的法定人 数。 所采用的决策规则是投票、少数服从多数、协商决定 或其他方法。
对待Baidu Nhomakorabea件项目管理的组织必须确保做到以 下几点：
• 在提交提议的需求变更之前要对其进行仔细的 评估。 • 请合适的人员就需求变更做出周全合理的业务 决策。 • 将已批准的变更传达给受此影响的所有人员。 • 项目以一致的方式将需求变更包含进来。
采用一致的变更控制方法，就可以避免相 关问题，避免开发工作的返工和浪费时间 等情况的发生。
里程碑与项目管理
一项需求的满足就意味着一块里程碑的确立。 里程碑构造机制的基本方法之一就是进程管 理。 需求管理在开发周期中是自始至终存在的。 需求管理必须始终保持更新，它构成了技术 管理的基础。 需求管理同项目管理是密不可分的 。
需求管理模型
不同的需求组合起来，构成了一套完整的需求 模型。 需求管理的一项重要工作就是在整个项目的不 同任务之间建立联系。 需求管理包括在工程进展过程中维持需求约定 集成性和精确性的所有活动。 需求管理的关键过程领域。 需求管理的步骤。
CCB的组成
CCB的成员应该能代表需要参与制定决策的所 有小组，当然这些决策制定只能是在CCB的权 力范围之内。 可考虑从下面这些部门中选择CCB代表：
• • • • 项目或程序管理部门 产品管理或需求分析部门 开发部门 测试或质量保证部门 • • • • 市场或客户代表 编写用户文档的部门 技术支持或帮助部门 配置管理部门
需求变更的原因
因竞争、成本等因素，工期已经确定且极不 合理. 用户在需求期提不出需求、或用户的需求不 明确. 项目组对业务不熟悉、或者没有与用户密切 结合、需求分析工作不细致. 项目组没有很好地实施需求管理.