软件需求管理部分完整版

1、1 需求开发面临的特殊难题 需求开发：是针对一个新软件或系统开发项 目的情况，这种项目有时也称为零起点项目 (green-field project)。 大多数组织的主要精力集中于维护现存的遗 留系统，或者为已有的商业产品构建新的版 本；其他组织也很少是从零开始构建一个新 系统，而是对商用现货产品进行集成、定制 和扩充，以满足自己的需要。 开始捕获信息 缺少精确的需求文档，那么维护人员就必须进行 逆向工程，通过代码来理解系统，将此看作是软 件考古学(software archaeology)。 构建一个包含当前系统部分的需求表示可达到以 下3个有用的目标： 消除知识鸿沟，使将来的维护人员能更好

2、地理解所做 的变更。 收集当前系统的一些信息当前系统在以前缺乏良 好的书面文档。 提供一个指标，表明当前的系统测试集对系统功能的 覆盖率。 定义质量需求 软件的质量属性和性能目标是选择解决方案时 所要考虑的用户需求的另一个方面。 我们至少要研究下面几个属性： 性能 易使用性 灵活性 互操作性 完整性 尽早地而且要经常地设定优先级 客户和开发人员协同工作，共同选定功 能实现的顺序，这样增量开发才会取得 成功。 开发团队的目标是，将可用的功能和对 质量的改进有规律地交到用户手中，因 此，开发人员必须了解每次增量开发计 划实现哪些功能。 5 设定需求优先级 每一个受资源限制的软件项目都必须对要求 的

3、产品功能定义相对优先级。 设定优先级有助于项目经理解决冲突、安排 阶段性交付，并且做出必要的取舍。 讨论设定需求优先级的重要性，提出一个简 单的优先级划分方案，并介绍更严格的基于 价值、成本和风险的优先级分析方案。 需求和进度安排 注意： 不要迫于压力而许下自己 明知道不可能做到的诺言， 这是避免最后两败俱伤的 秘诀。 需求管理 8 需求管理的原则和实践 需求管理包括在项目开发过程中维护需求约定 的完整性、准确性以及保持需求约定是最新约 定的所有活动，如图所示。 软件需求管理软件需求管理 需求管理所要完成的任务 需求管理模型 管理变更 需求风险管理 需求跟踪 需求管理工具 需求管理所要完成的任

4、务 需求管理的首要任务在于使开发人员和用户双方对 于需求都有一个明确的认识。 需求模型实际是最终产品的抽象化表现。 用户需求的满足程度是衡量设计优劣的标准。 优秀的需求分析应当非常精确细致地对用户需求作 出描述，同时也应该最大程度地给予方案设计者充 分发挥的余地。 对开发项目进行任务划分，将整体开发任务细化为 多个子模块，从而使这些子模块能够平行开发而无 需太多的干预。 需求管理在开发周期中是自始至终存在的。需求管 理必须始终保持更新。 需求管理同项目管理是密不可分的。 需求管理的任务 明确需求并达成共识； 建立关联，根据不同需求设计相应解决办法； 进行系统优化，提出设计方案； 监控和解决可能

5、出现的问题以及需要做出的改变； 控制不同开发任务的开展； 对最终产品做出评测； 监控可能出现的重复开发； 提出项目实施时间表； 确定最终用户界面。 里程碑与项目管理 一项需求的满足就意味着一块里程碑的确立。 里程碑构造机制的基本方法之一就是进程管 理 。 需求管理在开发周期中是自始至终存在的。 需求管理必须始终保持更新，它构成了技术 管理的基础。 需求管理同项目管理是密不可分的 。 需求管理模型 不同的需求组合起来，构成了一套完整的需求 模型。 需求管理的一项重要工作就是在整个项目的不 同任务之间建立联系。 需求管理包括在工程进展过程中维持需求约定 集成性和精确性的所有活动。 需求管理的关键过

6、程领域。 需求管理的步骤。 需求管理的主要活动 控制对需求基线的变动。 保持项目计划与需求一致。 控制单个需求和需求文档的版本情况。 管理需求和联系链之间的联系或管理单个需 求和其它项目可交付品之间的依赖关系。 跟踪基线中需求的状态。 需求开发与需求管理的分界 中程在线信息产业培训网中程在线信息产业培训网 需求基线管理 为何需要：频繁的需求变更会破坏开发的节 奏，使整个项目开发的进度陷入混乱和失控 的状态，而且会变成一个“救火队”式的工 作，整天都在处理突发事件. 主要思想：将所有现在的、将来的需求进行 优先级评估，然后分解成为不同的组，每次 迭代都选择其中优先级最高的部分进行开发， 然后在迭

7、代完成之前，开发工作不响应变更， 这些划入的需求项就是需求基线的组 成部分 需求基线管理-操作思路 我们应该在分析的基础上，将需求整合成为 用例或功能项，然后对其进行优先级、依赖 性进行综合性评估 优先级判断：业务人员确定业务决定，技术 人员确定技术决策；“满意度/不满意度”模 型 依赖性是指对于某些功能，在实现上有必须 的依赖关系，即当某些功能没有实现时，另 外的功能无法开始，这就需要对其 进行调整 需求变更管理 需求变更是一定存在的，而需求变更管理并 不是指逃避它，更不是说要避免它，它实际 上是希望控制变更 在基线内的需求不响应变更，为开发人员提 供一个安静的工作时间状态 专门的需求变更管

8、理来对所有的需求变更进 行响应，了解需求变更的关键意图、新产生 的工作量，从而良好地进行重新计划，以便 能够有效地解决其对整个开发带来的麻烦 对待软件项目管理的组织必须确保做到以 下几点： 在提交提议的需求变更之前要对其进行仔细的 评估。 请合适的人员就需求变更做出周全合理的业务 决策。 将已批准的变更传达给受此影响的所有人员。 项目以一致的方式将需求变更包含进来。 采用一致的变更控制方法，就可以避免相 关问题，避免开发工作的返工和浪费时间 等情况的发生。 变更控制委员会 变更控制委员会，有时也称为配置控制委员会 (configuration control board，CCB)，已被证实是软

9、 件开发领域公认的最佳实践(McConnell 1996)。 CCB是由人组成的团体，可以由一个小组担任，也可 以由多个不同的小组担任，这些人共同决定将哪些已 提议的需求变更和新提议的特性在产品中付诸实现。 CCB也决定所报告的缺陷中哪些需要纠正，什么时候 纠正。 CCB可以评审和批准对项目中任何基线工作产品所做 的变更，项目需求文档只是其中的一个样例。 CCB的组成 CCB的成员应该能代表需要参与制定决策的所 有小组，当然这些决策制定只能是在CCB的权 力范围之内。 可考虑从下面这些部门中选择CCB代表： 项目或程序管理部门 产品管理或需求分析部门 开发部门 测试或质量保证部门 市场或客户代

10、表 编写用户文档的部门 技术支持或帮助部门 配置管理部门 CCB规章 CCB规章描述了CCB的目的、权力范围、成 员构成、运作规程和决策的制定过程等 (Sorensen 1999)。 CCB的权力范围规定了哪些决策由CCB决定， 哪些决策则必须上报给高一级CCB或者由管 理层来决定。 1. 制定决策 决策制定过程的描述应该确定： CCB成员或主要角色的人数，这是制定决策的法定人 数。 所采用的决策规则是投票、少数服从多数、协商决定 或其他方法。 CCB规章 CCB主席是否可以否决CCB的集体决策。 级别高的CCB或其他人是否必须认可CCB做出的决 策。 2. 交流状态 CCB做出决策之后，应该

11、指派专人对变更数据库中 的变更请求状态进行更新。 3. 重新协商原先的约定 在接受一个重大的需求变更之前，为了适应这一变更， 需要同管理部门和客户重新协商原先的约定 (Humphrey 1997)。 协商的内容可能包括，要求推迟产品交付时间，要求 增派人手，或者要求推迟实现尚未实现的优先级较低 的需求等。 变更需要付出代价：影响分析 对软件实施大的功能增强，则需要进行影响分析 (impact analysis)。但是，即使是小的变更请求，也 可能潜伏着难以预料的复杂性。 影响分析是需求管理的一个关键方面(Arnold和 Bohner 1996)。 通过对影响进行分析，可以准确地理解提议的变更

12、所涉及到的问题，有助于项目团队就批准哪些提议 做出周全合理的业务决策。 影响分析:通过对所提议的变更进行检查，确定可能 必须创建、修改或废弃哪些部分，并估计与实现这 些变更相关的工作量。 影响分析的过程 影响分析有3个方面： 1.理解进行变更可能涉及的问 题。变更常常会产生大量的连 锁反应，产品包括的功能太多 会降低其性能，甚至会到令人 难以接受的地步。 2.确定如果团队将提议的变更 包括到产品中，可能必须对哪 些文件、模型和文档进行修改。 3.确定实现变更所需执行的任 务，并估计完成这些任务所需 的工作量。 注意: 跳过影响分析并不能改变 任务的规模，只会使规 模令人感到惊奇，而软 件方面令

13、人惊奇却很少 是好消息。 影响分析报告模板 图是一个推荐 的报告模板， 表示对每个需 求变更造成的 潜在影响的分 析结果。如果 采用标准模板， CCB成员就可 以轻松地找到 他们所需的信 息，作出合理 的决策。 变更请求ID号：_ 标题：_ 描述：_ _ 分析人员： _ 日期： _ 优先级评估： 相对收益：_(19) 相对损失：_(19) 相对费用：_(19) 相对风险：_(19) 计算出的最终优先级：_(相对于其他待处理的需求) 估计的总工作量：_劳动小时数 估计损失的工作量：_劳动小时数(用于废弃的工作) 估计对进度的影响：_天 额外的成本影响：_美元 质量影响：_ 受影响的其他需求：_

14、受影响的其他任务：_ 集成问题：_ 生存期费用问题：_ 检查可能要变更的其他组件：_ 需求的变化是永恒的。因而，对于需求变更应该 正确对待，尽量将其负面影响降低。 需求变更可能来自解决方案提供商、客户或产品 供应商等外部因素，也可能来源于项目组内部。 变更都是有代价的，应该评估一下变更的代价及 其对项目的影响。 在需求变更发生之前尽量减少需求变更，以将需 求变更带来的风险降低到最低。切忌在项目设计 之前试图消除需求变更。 需求变更的原因 因竞争、成本等因素，工期已经确定且极不 合理. 用户在需求期提不出需求、或用户的需求不 明确. 项目组对业务不熟悉、或者没有与用户密切 结合、需求分析工作不细

15、致. 项目组没有很好地实施需求管理. 需求变更的恶性循环 时间紧迫压缩需求过程产品不满足需求 变更需求维护工作量增加项目资源恶化 需求过程的恶性循环 需求变更的因素 需求变更的代价 减少需求变更 需求变更的过程管理 认识到变更不可避免，为变更制订计划。 确认需求基线。 建立控制变更的唯一渠道。 使用变更控制系统来捕获变更。 分层次地管理变更。 基于配置管理的需求管理基于配置管理的需求管理 避免需求在未授权情况下变更，或在有潜在 破坏性的情况下不受限制地随意变更。 保护队需求文档的修正。 方便对文档以前版本的检索或重建。 支持系统以增量的方式改进基线。 避免对文档的同时更新和冲突。 基线管理 需

16、求基线(requirement baseline)是团队成员已经承诺将在某 一特定产品版本中实现的功能性和非功能性需求的一组集合。 基线：已经通过正式评审和批准的某规约或产品，它可以作 为进一步开发的基础，并且只能通过正式的变化控制过程的 改变。IEEE 基线是一个软件配置管理的概念 。 在软件工程的范围内，基线是软件开发中的里程碑，其标志 是有一个或多个软件配置项的交付，且已经经过正式技术评 审而获得认可。 配置管理组或委员会（CCB）按照需求基线，对整个项目的 进程进行控制和把握 。 需求状态的变化 开 始 被建议被批准被实现被交付 被验证 被丢弃被拒绝 评审 通过 评审未 通过 设计完成

17、 编码完成 单元测试 取消取消 集成测试 完成 用户测 试接收 需求管理过程 注意 如果项目中无人负责执行需求 管理活动，那么就不要指望 需求管理能够运作。 需求版本控制 版本控制是管理需求规格说明和其他项目文档必不可少 的一个方面。 需求文档的每一个版本都必须惟一地标识出来。 为了尽量减少混乱、冲突和误传，应该指派一个人专门 负责更新需求，并确保只要需求有所变更就相应地改变 其版本标识号。 最简单的版本控制机制是，根据标准约定，对每一个软 件需求规格说明版本进行手工标识。 还有一种更复杂的技术，可以把需求文档存储在版本控 制工具中。 版本控制最有用的方法是将需求存储在商业需求管理工 具的数据

18、库中 。 需 求 属 性 应该考虑为每个需求指定如下一些属性： 需求创建的日期。 需求的当前版本号。 创建需求的作者。 负责确保该需求得到满足的人员。 需求的拥有者或一组涉众列表。 需求状态。 需求的最初来源。 创建需求的理由。 需求涉及的子系统。 需求涉及的产品版本号。 使用的验证方法或验收测试的标准。 需求实现的优先级。 需求的稳定性。 注意 如果选择的需求属性太多，那 么开发团队会望而生畏，结果 是他们绝不可能提供所有需求 的全部属性值，也无法有效地 使用这些属性信息。 跟踪需求状态 表列出了若干可能的需求状态。有些跟踪人员还添加了 另外两个状态： “已设计(Designed)”和“已交

19、付 (Delivered)。 状状 态态 定定 义义 已提议已提议(Proposed)(Proposed) 该需求已被有相应权限的人提出该需求已被有相应权限的人提出 已批准已批准(Approved)(Approved) 该需求已经被分析，它对项目的影响已进行了估计，并且已经被分配到某一特定版本该需求已经被分析，它对项目的影响已进行了估计，并且已经被分配到某一特定版本 的基线中。关键涉众已同意包含这一需求，软件开发团队已承诺实现这一需求的基线中。关键涉众已同意包含这一需求，软件开发团队已承诺实现这一需求 已实现已实现(Implemented)(Implemented) 实现这一需求的代码已完成了

20、设计、编码和单元测试。这一需求已被跟踪到相关的设实现这一需求的代码已完成了设计、编码和单元测试。这一需求已被跟踪到相关的设 计元素和编码元素计元素和编码元素 已验证已验证(Verified)(Verified) 已在集成产品中确认了这一需求的功能实现是正确的。这一需求已被跟踪到相关的测已在集成产品中确认了这一需求的功能实现是正确的。这一需求已被跟踪到相关的测 试用例。这一需求目前可以被认为是已完成了试用例。这一需求目前可以被认为是已完成了 已删除已删除(Deleted)(Deleted) 已批准的需求又从需求基线中取消了。要解释清楚为什么要删除这一需求，以及是谁已批准的需求又从需求基线中取消了

21、。要解释清楚为什么要删除这一需求，以及是谁 决定删除的决定删除的 已否决已否决(Rejected)(Rejected) 需求已被提议，但并不计划在下一版本中实现它。要解释清楚为什么要否决这一需求，需求已被提议，但并不计划在下一版本中实现它。要解释清楚为什么要否决这一需求， 以及是谁决定否决的以及是谁决定否决的 评估需求管理的工作量 如果跟踪在需求管理上投入了多少工作量，我们 就可以评估工作量是太少，还是正合适，或者是 太多，并且可以对当前过程和未来的计划做出相 应的调整。 将下面这些活动中所投入的工作量加起来，就可 以算出需求管理的工作量： 提交需求变更和提议新的需求。 评估已提议的变更，包括

22、进行影响分析。 变更控制委员会的活动。 更新需求文档或数据库。 向受影响的小组或个人传达需求变更。 跟踪并报告需求状态。 收集需求的跟踪信息。 需求风险管理 44 所谓风险就是可能给项目的成功带来某些损失或 威胁的情况。 由于需求在软件项目中具有十分重要的地位，所 以精明的项目管理者应尽早确定与需求相关的风 险并积极主动地控制它们。 典型的需求风险包括： 误解需求。 用户的参与不恰当。 项目范围和目标不确定或随意进行变更。 对需求不断进行变更等。 软件风险管理基本原理 对外部实体的依赖就是一种常见的风险来源。 项目管理一直面临各种风险的挑战：评估不准确、管理 人员拒绝开发人员的准确评估、对项目

23、状态不了解以及 进行了人员调整等原因所引起的风险。 技术风险威胁着高度复杂或很前沿的开发项目。 知识的缺乏是风险的另一种来源，另外还有参与者对所 用的技术或项目应用领域经验不足。经常变更的或强制 执行的一些政府规定可能会使最好的项目规划彻底作废。 风险管理的要素 风险管理(risk management)就是使用某些工具和 步骤把项目风险限制在一个可接受的范围内。 风险管理提供了一种标准的方法，可以指出风险 因素并将其编写成文档，评估这些风险的潜在威 胁，并提出减少这些风险因素的战略。 风险管理包括图所示 的这些活动。 风险评估(risk assessment)是一个 对项目进行检查以确 定潜

24、在风险领域的过 程。 风险避免 (riskavoidance)是处 理风险的一种方法， 也就是尽量不要做冒 险的事。 风 险 管 理 评 估 避 免 控 制 识 别 分 析 优 先 级 管 理 计 划 解 决 方 案 监 控 编写项目风险文档 图展示 了一个 模板， 用于对 单个风 险编写 文档。 风险条目跟踪模板 I D号： 确定日期： 撤消日期： 描述： 可能性： 影响： 危害值： 降低风险计划： 负责人： 截止日期： 制定风险管理计划 对于小型项目，可以把控制风险的计 划包括在软件项目管理计划内。 但对一个大型项目，则应该编写一个 单独的风险管理计划，详细说明打算 采用哪些方法来识别、评

25、估、编档和 跟踪风险。这一计划还应该包括风险 管理活动的角色和职责。 要建立起周期性进行风险监控的措施。 注意： 不要想当然地以为， 在识别出了风险并采 取了降低风险的相应 活动之后，风险就会 处于您的控制之下。 接下来还要实行风险 管理活动。 与需求有关的风险 无足够用户参与 用户需求的不断增加 模棱两可的需求 不必要的特性 过于精简的规格说明 忽略了用户分类 不准确的计划 风险管理是我们的好帮手 即使不能控制项目可能遇到的所有风险， 风险管理也能帮助我们看清形势，做出 合理的决策。 风险管理的措施 明确你当前项目面临的一些与需求有关的风 险，不要把当前的问题当作风险，一定要是 那些还未发生的事情。将风险因素编写成文 档，为每项风险推荐至少一种可能的降低风 险的方法。 风险管理的措施 召集代表开发、市场、客户和管理各方面的 涉众召开风险“集体研讨”会议。 需求跟踪 需求跟踪提供了一个表明与合同或说明一致 的方法。更进一步，需求跟踪可以改善产品 质量，降低维护成本，而且很容易实现重用。 需求跟踪链使你能跟踪一个需求使用期限的 全过程。 通用的跟踪模型显示了我们要在软件开发的 不同层面全面地跟踪需求。 需求跟踪的定义需求跟踪的定义IEEE，1994 开发过程的两个或多个产品之间能够建立关