第七章需求管理练习题

1、第七章 需求管理练习题 准确性以及保持需求约定是最 1. 需求管理包括哪些活动？ 需求管理包括在项目开发过程中维护需求约定的完整性、 新约定的所有活动，如下图所示。 需求管理 需求跟踪 变更控制 Proposing changes Analyzing impact Making decisions Updating requirements documents Updating plans Measuring requirements volatility 版本控制 Defining a version identification scheme Identifying requirement

2、s document versions Identifying individual requirement versions 需求状态跟踪 Defining possible requirement statuses Recording the status of each requirement Reporting the status distribution of all requirements Defining links to other requirements Defining links to other system elements 2. 开发过程中需求有哪些状态，每个

3、状态代表什么意义？ 状态 定义 已提议 (Proposed) 该需求已被有相应权限的人提出 已批准 (Approved) 该需求已经被分析，它对项目的影响已进行了估计，并且已经 被分配到某一特定版本的基线中。 关键涉众已同意包含这一需 求，软件开发团队已承诺实现这一需求 已实现 (Implemented) 实现这一需求的代码已完成了设计、编码和单元测试。这一需 求已被跟踪到相关的设计元素和编码元素 已验证 (Verified) 已在集成产品中确认了这一需求的功能实现是正确的。 这一需 求已被跟踪到相关的测试用例。 这一需求目前可以被认为是已 完成了 已删除 (Deleted) 已批准的需求又从

4、需求基线中取消了。 要解释清楚为什么要删 除这一需求，以及是谁决定删除的 已否决 (Rejected) 需求已被提议，但并不计划在下一版本中实现它。要解释清楚 为什么要否决这一需求，以及是谁决定否决的 3. 论述 CCB的作用 变更控制委员会，有时也称为配置控制委员会(configuration control boar，d CCB)，已被证 实是软件开发领域公认的最佳实践 (McConnell 1996。) CCB 是由人组成的团体， 可以由一个小组担任， 也可以由多个不同的小组担任， 这些人 共同决定将哪些已提议的需求变更和新提议的特性在产品中付诸实现。 CCB 决定所报告的缺陷中哪些需要

5、纠正， 什么时候纠正。 CCB可以评审和批准对项目中 任何基线工作产品所做的变更。 CCB规章描述了 CCB 的目的、权力范围、成员构成、运作规程和决策的制定过程等。 1. 制定决策 决策制定过程的描述应该确定： CCB成员或主要角色的人数，这是制定决策的法定人数。 所采用的决策规则是投票、少数服从多数、协商决定或其他方法。 CCB 主席是否可以否决 CCB 的集体决策。 级别高的 CCB或其他人是否必须认可 CCB 做出的决策。 2. 交流状态 CCB做出决策之后，应该指派专人对变更数据库中的变更请求状态进行更新。 3. 重新协商原先的约定 在接受一个重大的需求变更之前， 为了适应这一变更，

6、 需要同管理部门和客户重新 协商原先的约定 (Humphrey 1997。) 协商的内容可能包括， 要求推迟产品交付时间， 要求增派人手， 或者要求推迟实现 尚未实现的优先级较低的需求等。 4. 需求跟踪的类型有哪些？ 客户需要 向前跟踪 回溯到需求 到需求 需求 向前跟踪到 向后跟踪 到需求 5. 实现需求跟踪能力带来哪些好处？ 审核 (certification) 要审核一个安全关键 (safety-critical) 的产品时，通过跟踪信息可以证明所有的需求 都已实现，虽然并不能确认实现是否正确和完整！ 变更影响分析 如果没有跟踪信息， 当添加、 删除或修改某一特定的需求时， 就很可能会

7、忽略受影响的 系统元素。 维护 可靠的跟踪信息有利于在维护过程中正确而完整地实施变更，从而提高生产率。 项目跟踪 如果在开发期间认真地记录跟踪数据， 就可以获得一个列入计划中功能的实现状态的精 确记录。 再工程 (reengineering) 定义跟踪联系链是一种方法，可以捕获到从现有系统的逆向工程中了解到的一些信息。 重用 通过跟踪信息可以确认与需求、 设计、 编码和测试相关的软件包， 就可以方便地复用产 品组件。 降低风险 把组件互连关系 (interconnection) 文档化，当对系统有深入了解的关键团队成员离开 项目组时，就可以降低由此带来的风险 (Ambler 1999) 。 测

8、试 了解哪些测试验证哪些需求，可以消除冗余测试，从而节省时间。 6. 论述需求跟踪过程 对某个特定的项目开始进行需求跟踪时，应该考虑下面这些步骤： (1) 选择要定义的联系链 。 (2) 选择要使用的跟踪矩阵的类型。 (3) 确定对产品的哪些部分维护跟踪信息。 (4) 修改开发过程和检查列表。 (5) 定义使用什么样的标记约定可以惟一地标识系统元素 (6) 确定负责提供每类联系链信息的人员，和负责协调跟踪活动并管理这些数据的人员。 (7) 为项目团队提供培训，讲述需求跟踪的概念和重要性、这一活动的目标、跟踪数据的存 储位置以及定义这些联系链所用的技术。 (8) 在开发过程中，要求每个参与者只要

9、完成工作的一小部分主体后，就提供所要求的跟踪 信息。 (9) 要定期审核跟踪信息，以确保信息最新。 7. 何为风险管理，列举实际项目中的需求风险 所谓风险就是可能给项目的成功带来某些损失或威胁的情况。 典型的需求风险包括： 误解需求。 用户的参与不恰当。 项目范围和目标不确定或随意进行变更。 对需求不断进行变更等。 结合自身实际项目经验，列举遇到的需求风险。 。 8. 风险管理包括哪些活动？结合实际项目，谈谈风险管理活动。 风险管理包括下图所示的这些活动。 识别 9. CMM 对需求管理的理解和定义是什么？ 需求管理是指在用户和将处理“分配给软件的系统需求”的软件项目组之间建立 对“分配给软件

10、的系统需求”的共同理解， 由软件工程组对“分配给软件的系统需 求”进行分析、 精化， 按照规范详细描述“分配给软件的系统需求”，形成“软件 需求规格说明”文档，并对该文档进行评审 “分配给软件的系统需求” 是指系统总体分配给软件的需求，也称软件需求 “用户”可解释为系统工程组或外部顾客等 “软件工程组” ：实施软件工程化开发的小组 软件需求既包括技术需求、又包括非技术需求 软件需求构成项目规模和工作量估算、制定项目计划和跟踪软件项目活动的基础 每当软件需求改变时， 都应调整受到影响的软件计划、 工作产品和活动， 使其与更 新后的软件需求保持一致 对已通过评审的软件需求的任何更改都应受到管理和控制 10. 论述 CMM 对需求管理的 12 个关键实践 关键实践类 关键实践数目 制定方针政策 1 确保必备条件 4 实施软件过程 3 度量和分析 1 检查实施情况 3 制定方针政策 项目遵循一个书面的、由组织制定的方针用来管理软件需求 确保必备条件 建立和明确系统需求分析和分配的人员及其职责 将软件需求写成规范化的文档 提供足够的用以管理分配需求的资源和经费 软件工程组和其它受影响组的人员接受需求管理方面的培训 实施软件过程 软件工程组识别、分析和细化软件需求，对它进行评审 将软件需求作为软件开发计划、工作产品和