指南:需求管理计划
主题
需求管理计划包含其它计划可能或多或少涵盖的信息。
正如 白皮书:将需求管理应用于用例中所述,需求管理对于确保项目成功是很重要的。项目失败时最常提到的原因包括:
需求错误也可能是最常见类别的错误,而改正的花费也最高。
与涉众保持恰当的关系会有助于解决这些问题。涉众是定义需求和了解需求优先级的关键输入源。但是,多数涉众对所需特性的成本和安排影响缺乏了解,因此开发组织必须控制涉众的期望值。
建立涉众关系包括定义:
- 涉众的职责:可以向站点上的职员咨询吗?要预先安排时间吗?
- 涉众对项目工件的了解:可以了解所有工件吗?仅在已安排的里程碑上了解吗?
描述可跟踪性项并定义如何对它们进行命名、标记和编号。请参阅概念:需求类型和概念:可跟踪性。
除了确定可跟踪性链接外,还应指定链接的基数。一些常见的约束是:
- 每个已核准的产品特性必须链接到一个或多个补充需求和/或一个或多个用例。
- 每个补充需求和每个用例部分都必须链接到一个或多个测试用例。
白皮书 使用用例管理需求的可跟踪性策略中提供更详细的可跟踪性讨论。
以下是您可能想要从中选择的中确定的需求类型组织的一些示例属性。
涉众需要
源:发出需求的涉众。(这也可作为“涉众”可跟踪性项的可跟踪性来实现。)
贡献:表示针对总体业务机会提出的问题或该项目所解决的问题。百分比(0 至 100%)。所有贡献的总和不应大于 100%。下面是 排列图的示例,它显示了几个涉众需要各自的贡献。

特性、补充需求和用例
状态:表示“官方渠道”是否已复审和接受了需求。示例值为“已提议”、“已拒绝”和“已核准”。
这可以是约定状态或由能做出绑定决策的工作组设置的状态。
利益:从涉众立场来考虑的重要性。
- 关键(或主要)。这些关系到系统的主要任务、其基本功能和为之开发系统的那些功能。如果缺少这些功能,系统则无法完成其主要任务。这些功能推动体系结构设计,并将成为最常用的用例。
- 重要(或次要)。这些关系到系统功能的支持,如统计数据编译、报告生成、监督和功能测试。如果缺少这些功能,系统仍可(暂时)完成其基本任务,但服务质量会有所下降。在建模时,这些用例的重要性将低于关键用例。
- 有用(最好有)。这些“适宜的”特性并不关系到系统的主要任务,但有助于系统的使用或市场定位。
工时:实现需求所需的估计工作天数。
例如,这可以分为低、中、高等几类。如,低 = < 1 天,中 = 1-20 天,高 = > 20 天。
在定义“工时”时,应明确指出估计值中所包括的各项开销(管理工时、测试工时、需求工时等等)。
大小:估计的非注释性源代码行(SLOC),不包括任何测试代码。
为了更好的计算成本估计值,您可能希望区分新的 SLOC 和重用的 SLOC。
风险:实施需求时将遇到重大的不良事件(如偏离进度安排、成本超支或取消安排)的可能性百分比。
例如,这可以分为低、中、高等几类。如,低 = < 10%,中 = 10-50%,高 = > 50%。
风险的另一个选项是单独跟踪技术风险 - 由于缺乏领域经验和/或必需技术而在实施需求时遇到严重困难的可能性百分比。总体风险可以计算为基于其它属性(包括规模、工时、稳定性、技术风险、体系结构影响和组织复杂度)的加权和。
组织复杂度:对制定需求的组织的控制的分类。
- 内部:某个站点上的内部开发
- 地理:在地理位置上分散的小组
- 外部:公司内的外部组织。
- 供应商:转包或购买在外部开发的软件。
体系结构影响:表示该需求将如何影响软件体系结构。
- 无:不影响现有体系结构。
- 扩展:需要扩展现有的体系结构。
- 修改:必须变更现有的体系结构,以适应需求。
稳定性:该需求发生变更或开发小组对需求的理解发生变更的可能性。(> 50% = 高,10..50% = 中,< 10% = 低)
目标发行版:满足需求的预期产品发行版。(R1、R1.1、R2 ...)
危险级别/紧急程度:影响健康、福利或造成经济后果的程度,
通常是由于软件未能按要求执行引起的。
- 可忽略:不会导致严重的人员伤害或设备损害。
- 不重要:可以得到控制,不会造成人员伤害或重大的系统损害。
- 重要:可能会造成人员伤害或重大的系统损害,或为了挽救人员或系统而需要立即采取更正措施。
- 灾难:可能会导致严重伤害或死亡,或是系统完全瘫痪。
危险还可以确定为单独的需求类型并链接到相关的用例。您可能还想跟踪危险概率,更正性措施和/或预防措施。
说明:在某些情况下,需求形成了正式合同,这时变更需求的措词可能很难且花费很大。在开发组织更好地理解需求后,可能有必要附加说明文本,而不是简单地变更需求的正式措词。
用例
除以上内容外,跟踪以下用例属性也是有用的:
详细程度百分比:详细描述用例的程度:
- 10%:提供基本描述。
- 50%:记录主要流程。
- 80%:完成事项,但不进行复审。充分指定所有前置条件和后置条件。
- 100%:已复审并已核准。
测试用例
状态:在测试开发期间跟踪进度。
- 无活动:在开发该测试用例期间未完成任何工作。
- 手动:已创建手动脚本并确认能够验证相关的需求。
- 自动:已创建自动脚本并确认能够验证相关的需求。
一般属性
具有一般适用性的其它一些需求属性是:
属性用于跟踪与可跟踪性项相关的信息,通常用于状态和报告目的。每个组织都可能需要针对自身组织的特定跟踪信息。指定属性之前,应考虑:
- 谁将提供该信息?
- 谁将使用该信息,且该信息为什么有用?
- 跟踪该信息的花费与效益相比值得吗?
为了允许对需求划分优先级以进行范围管理和针对迭代分配需求,要跟踪的基本属性是风险、利益、工时、稳定性和体系结构影响。起先应对“特性”跟踪这些属性,然后对所有用例和补充需求进行跟踪。
考虑派生信息
除直接使用需求属性外,您可能还希望通过其它需求类型的可跟踪性从这些需求属性中派生出信息。一些典型的派生模式是:
- 向下派生 - 根据上面的可跟踪性,假设产品特性具有属性“目标发行版”。用户可以推断,由该产品特性跟踪的每个用例部分在指定目标发行版中(或在该发行版之前)必须也是可用的。
- 向上派生 - 根据上面的可跟踪性,假设用例部分具有属性“估计工时”。通过将产品特性跟踪的用例部分的估计工时相加,可估计产品特性的成本。使用该方法时必须小心,因为可能有多个产品特性映射到同一个用例部分。
因此,为了向需求类型分配需求属性,应考虑:
- 我们希望由该属性生成什么派生信息/报告?
- 应在可跟踪性层次结构的哪一级别跟踪此属性?
属性依赖关系
某些属性可能仅适用于某一级别的开发。例如,一旦在设计中完整地表示出用例,用例的估计工时属性就可由设计元素的工时估计值替换。
以下是与需求相关的报告和评估示例。通过为项目选择所需/预期的一组报告和评估,就可以得出需求管理计划的必要属性。
报告/评估描述 |
用于 |
用例的开发优先级(按风险、利益、工时、稳定性和体系结构影响排序的用例列表)。 |
这可以是单独排序的列表,或是按这些属性的加权组合排序的单个列表。用于活动:对用例划分优先级。 |
每个状态类别中的特性百分比。 |
在定义项目基线期间跟踪进度。 |
- 按目标发行版分类 |
- 跟踪每个发行版的进度 |
- 按工时加权 |
- 提供更精确的进度评估。 |
按风险排序的特性 |
- 确定风险特性。用于规模管理和向迭代指定特性。 |
- 按目标发行版分类,具有为每个目标发行版汇总的开发风险 |
- 用于评估风险特性是安排在项目早期还是后期。 |
按稳定性排序的用例部分 |
- 用于决定需要使哪些用例部分保持稳定。 |
- 按影响体系结构加权或排序 |
- 用于将在体系结构方面重要的用例和/或高工时用例优先安排为首先进行稳定。 |
具有未定义属性的需求 |
第一次提议需求时,可能不会立即指定所有属性(如通过使用缺省的“未定义”值)。检查点:软件需求规范使用此报告检查此类未定义属性。 |
具有不完整可跟踪性链接的可跟踪性项 |
不正确或不完整可跟踪性链接的报告用于检查点:软件需求规范。 |
变更是不可避免的,并应进行计划。进行变更是因为:
- 要解决的问题存在变更。这可能是由于新的法规、经济压力、技术变更等等。
- 涉众改变了想法或改变了对希望系统执行的工作的认知。这可能归咎于各种原因,包括负责人的变更、更深入地理解问题等。
- 定义原始需求时,未能包括所有涉众或未能询问所有适当的问题。
管理变更需求的策略包括:
- 为需求建立基线
- 建立控制变更的单一通道
- 维护变更历史记录
为需求建立基线
精化阶段结束时,系统分析人员应为所有已知需求建立基线。通常的执行步骤如下:确保需求工件上存在版本控制,并确定一组工件及其形成基线的版本。
基线的目的不是用于冻结需求。而是使得能够确定、传达、估计和控制新需求和修改过的需求。
建立控制变更的单一通道
涉众的变更需要不能假设为正式变更预算和进度安排。通常情况下,必须先启动协商或预算协调流程,然后才能核准变更。通常变更必须相互平衡。
每个变更通过单一通道即变更控制委员会(CCB)的核准是至关重要的,可确定变更对系统的影响并进行正式的核准。提议变更的机制为提交变更请求,该请求由 CCB 复审。
维护变更历史记录
维护各个需求的变更审计跟踪是很有用的。该变更历史记录可使您查看该需求之前的所有变更以及属性值的变更和变更的基本原因。对于评估需求的实际稳定性和确定变更控制流程可能不起作用的情况(例如,确定未正确复审和核准的需求变更),这可能是很有用的。
|