软件需求（五）周勇 yzhousei.ecnu.edu.cn有错就改，当然是件好事。但我们常常却改掉正 确的，留下错误的，结果是错上加错。 匿名格言 年7月 SEI of ECNU版权所有 软件需求工程 5-2软件需求管理p需求管理所要完成的任务 p需求管理模型 p管理变更 p需求风险管理 p需求跟踪 p需求管理工具 年7月 SEI of ECNU版权所有 软件需求工程 5-3第19章 需求管理所要完成的任务 p需求管理的首要任务在于使开发人员和用户双方对于需 求都有一个明确的认识。 p需求模型实际是最终产品的抽象化表现。p用户需求的满足程度是衡量设计优劣的标准。p优秀的需求分析应当非常精确细致地对用户需求作出描 述，同时也应该最大程度地给予方案设计者充分发挥的 余地。p对开发项目进行任务划分，将整体开发任务细化为多个 子模块，从而使这些子模块能够平行开发而无需太多的 干预。p需求管理在开发周期中是自始至终存在的。需求管理必 须始终保持更新。 p需求管理同项目管理是密不可分的。 年7月 SEI of ECNU版权所有 软件需求工程 5-4需求管理的任务p明确需求并达成共识； p建立关联，根据不同需求设计相应解决办法； p进行系统优化，提出设计方案； p监控和解决可能出现的问题以及需要做出的改变； p控制不同开发任务的开展； p对最终产品做出评测； p监控可能出现的重复开发； p提出项目实施时间表； p确定最终用户界面。 年7月 SEI of ECNU版权所有 软件需求工程 5-5需求共识 p需求管理的首要任务在于使开发人员和用户双方 对于需求都有一个明确的认识。因此用来进行需 求分析的语言组织应当使所有相关人员，包括用 户，都能够理解，都能够进而对整个项目有一个 整体把握，并明确每一个人在项目中所起的作用 。 年7月 SEI of ECNU版权所有 软件需求工程 5-6里程碑与项目管理 p一项需求的满足就意味着一块里程碑的确立。p里程碑构造机制的基本方法之一就是进程管理 。p需求管理在开发周期中是自始至终存在的。需求 管理必须始终保持更新，它构成了技术管理的基 础。 p需求管理同项目管理是密不可分的 。年7月 SEI of ECNU版权所有 软件需求工程 5-7第20章 需求管理模型 p不同的需求组合起来，构成了一套完整的需求模型。p需求管理的一项重要工作就是在整个项目的不同任务 之间建立联系。p需求管理包括在工程进展过程中维持需求约定集成性 和精确性的所有活动。p需求管理的关键过程领域。p需求管理的步骤。 年7月 SEI of ECNU版权所有 软件需求工程 5-8需求管理的主要活动 p控制对需求基线的变动。p保持项目计划与需求一致。p控制单个需求和需求文档的版本情况。p管理需求和联系链之间的联系或管理单个需求和 其它项目可交付品之间的依赖关系。p跟踪基线中需求的状态。 年7月 SEI of ECNU版权所有 软件需求工程 5-9年7月 SEI of ECNU版权所有 软件需求工程 5-10能力成熟度模型CMM 年7月 SEI of ECNU版权所有 软件需求工程 5-11关键过程域与需求管理p为达到软件过程能力成熟度模型的第二级，组织 必须具有在软件开发与管理的六个关键过程域（ KPA）以展示达到目标的能力。需求管理是其中 之一，它的目标如下：n把软件需求建立一个基线供软件工程和管理使用。n软件计划，产品和活动同软件需求保持一致。 年7月 SEI of ECNU版权所有 软件需求工程 5-12CMM2级中关于需求管理的问卷 年7月 SEI of ECNU版权所有 软件需求工程 5-13需求管理步骤 p用于控制各种需求文档和单个需求版本的工具、 技术和习惯做法。p建议、处理、协商、通告新的需求和需求变更的 方法。p制订需求基线。p需求状态跟踪和报告过程。p分析需求变更带来的影响。年7月 SEI of ECNU版权所有 软件需求工程 5-14第21章 管理变更 p需求的变化是永恒的。因而，对于需求变更应该正确对待，尽量将 其负面影响降低。p需求变更可能来自解决方案提供商、客户或产品供应商等外部因素 ，也可能来源于项目组内部。p变更都是有代价的，应该评估一下变更的代价及其对项目的影响。p在需求变更发生之前尽量减少需求变更，以将需求变更带来的风险 降低到最低。切忌在项目设计之前试图消除需求变更。p有效的需求变更过程。p需求变更控制一般要经过变更申请、变更评估、决策、回复这四大 步骤。如果变更被接受，还要增加实施变更和验证两个步骤，有时 还会有取消变更的步骤。p配置管理是管理需求的一个必要方面。p基线是软件开发中的里程碑，其标志是有一个或多个软件配置项的 交付，且已经经过正式技术评审而获得认可。 年7月 SEI of ECNU版权所有 软件需求工程 5-15需求变更的原因 p因竞争、成本等因素，工期已经确定且极不合理p用户在需求期提不出需求、或用户的需求不明确p项目组对业务不熟悉、或者没有与用户密切结合 、需求分析工作不细致p项目组没有很好地实施需求管理年7月 SEI of ECNU版权所有 软件需求工程 5-16需求变更的恶性循环 年7月 SEI of ECNU版权所有 软件需求工程 5-17需求变更的因素 年7月 SEI of ECNU版权所有 软件需求工程 5-18需求变更的代价 年7月 SEI of ECNU版权所有 软件需求工程 5-19减少需求变更 年7月 SEI of ECNU版权所有 软件需求工程 5-20需求变更的过程管理 p认识到变更不可避免，为变更制订计划。p确认需求基线。p建立控制变更的唯一渠道。p使用变更控制系统来捕获变更。p分层次地管理变更。 年7月 SEI of ECNU版权所有 软件需求工程 5-21变更请求流程 年7月 SEI of ECNU版权所有 软件需求工程 5-22分层次的需求变更 年7月 SEI of ECNU版权所有 软件需求工程 5-23需求变更管理实践中的对策p优先排序，分批实现 p相互协作，充分交流p合同约束，区别对待 p选用适当的开发模型 p用户参与需求评审 年7月 SEI of ECNU版权所有 软件需求工程 5-24基于配置管理的需求管理p避免需求在未授权情况下变更，或在有潜在破坏 性的情况下不受限制地随意变更。p保护队需求文档的修正。p方便对文档以前版本的检索或重建。p支持系统以增量的方式改进基线。p避免对文档的同时更新和冲突。 年7月 SEI of ECNU版权所有 软件需求工程 5-25基线管理 p基线：已经通过正式评审和批准的某规约或产品 ，它可以作为进一步开发的基础，并且只能通过 正式的变化控制过程的改变。IEEEp基线是一个软件配置管理的概念 。p在软件工程的范围内，基线是软件开发中的里程 碑，其标志是有一个或多个软件配置项的交付， 且已经经过正式技术评审而获得认可。 p配置管理组或委员会（CCB）按照需求基线，对 整个项目的进程进行控制和把握 。年7月 SEI of ECNU版权所有 软件需求工程 5-26需求状态的变化 年7月 SEI of ECNU版权所有 软件需求工程 5-27第22章 需求风险管理 p与需求有关的风险。p用于降低风险发生的可能性或减轻风险发生给项 目带来的影响的方法。p周期性的风险跟踪能使管理人员保持对风险危害 变化的了解。 年7月 SEI of ECNU版权所有 软件需求工程 5-28与需求有关的风险 p无足够用户参与p用户需求的不断增加 p模棱两可的需求 p不必要的特性p过于精简的规格说明 p忽略了用户分类 p不准确的计划 年7月 SEI of ECNU版权所有 软件需求工程 5-29评估需求风险 （一）p需求获取阶段 n产品前景与范围 n需求开发所需时间 n需求规格说明的完整性和正确性 n对革新产品的需求，有时容易忽略市场对产品的反馈 信息 n明确非功能需求n一定要使客户认可产品需求 n关注未加说明的需求 n把已有的产品作为需求基线 n给出期望的解决办法 年7月 SEI of ECNU版权所有 软件需求工程 5-30评估需求风险 （二）p需求分析阶段n划分需求优先级 n带来技术困难的特性 n不熟悉的技术、方法、语言、工具或硬件平台 p需求规格说明n需求开发人员和客户对需求的不同理解会带来彼此间 的期望差异，这将导致最终产品无法满足客户的要求 n时间压力对待确定因素的影响 n具有二义性的术语 n需求说明中包括了设计 年7月 SEI of ECNU版权所有 软件需求工程 5-31评估需求风险 （三）p需求验证n未经验证的需求评审 n评审的有效性 p需求管理n将项目前景与范围文档作为变更的参照，可以减少项 目范围的不适当地延伸 n需求变更过程 n未实现的需求 n扩充项目范围 年7月 SEI of ECNU版权所有 软件需求工程 5-32风险管理的措施p明确你当前项目面临的一些与需求有关的风险， 不要把当前的问题当作风险，一定要是那些还未 发生的事情。将风险因素编写成文档，为每项风 险推荐至少一种可能的降低风险的方法。p召集代表开发、市场、客户和管理各方面的涉众 召开风险“集体研讨”会议。尽力找出更多与需求 有关的风险因素。估计每项风险发生的可能性及 其影响，两者