需求管理
 |
需求管理(Requirements Management, REQM)的目的，在于管理专案产品及产品组件的需求，并界定这些需求与专案计划及工作产品间的差异。
简介[编辑]
“需求管理流程”管理专案所发展或收受的技术性、非技术性需求，以及组织加在专案的需求。尤其是如果组织实施“需求发展”流程领域，它的流程所产生的产品及产品组件需求，也要纳入需求管理流程的管理。在所有的流程领域中，当使用产品及产品组件这个专门名词时，也意指包含服务及其组件的意思。当组织实施需求发展、需求管理及技术解决方案等流程领域，它们相关的流程将会紧密联系并同步执行。
专案采行适当的步骤，确保议定的需求是受管理的，以支援专案规划和执行的需要。当专案从已核定的需求提供者收受需求时，应与其一起审查，以便在需求纳入专案计划前，先行解决有关议题并避免误解。一旦需求提供与接受的双方达成协议，须再取得专案成员对需求的承诺。当需求渐进发展时，专案须管理需求的变更，并界定计划、工作产品，以及需求间可能产生的差异。
需求管理也须记录需求变更及其理由，并维护原始需求与所有产品和产品组件需求之间的双向追溯性。(“双向追溯性”的定义，请参考词汇。)
所有发展专案都有需求。以专注于维护活动的专案来看，产品或产品组件的变更是基于现有需求、设计及开发的变更。如有需求变更，可能是记录在客户或使用者的变更请求上，也可能是从需求发展流程中所产生的新需求。不论来源或形式，因需求变更所引起的维护活动，应依此原则管理。
相关流程领域[编辑]
- 有关将关键人员之需要转成产品需求，以及决定如何将需求配置于产品组件，请参考需求发展流程领域，以获得更多资讯。
- 有关将需求转为技术解决方案，请参考技术解决方案流程领域，以获得更多资讯。
- 有关专案计划如何反映需求，以及专案计划如何因需求变更而修订，请参考专案规划流程领域，以获得更多资讯。
- 有关基准和如何管制需求的建构文件的变更，请参考建构管理流程领域，以获得更多资讯。
- 有关以需求为基础的专案活动和工作产品之追踪与控制，以及采取适当的矫正措施，请参考专案监控流程领域，以获得更多资讯。
- 有关与需求有关的风险界定与处理，请参考风险管理流程领域，以获得更多的资讯。
特定目标及执行方法摘要[编辑]
SG 1 管理需求
SP 1.1 了解需求
SP 1.2 取得需求承诺
SP 1.3 管理需求变更
SP 1.4 维护需求的双向追溯性
SP 1.5 界定专案工作与需求间的差异
各目标的特定执行方法[编辑]
SG1 管理需求
管理需求，并界定需求与专案计划及工作产品间之差异。
本执行方法借由进行下列活动，使专案能全程维护一组最新及已核定的需求：
· 管理所有的需求变更
· 维护需求、专案计划及工作产品间的关系
· 界定需求、专案计划及工作产品间的差异
· 采取矫正措施
有关决定需求的可行性，请参考技术解决方案流程领域，以获得更多资讯。
有关确保需求能反映客户的需要和期望，请参考需求发展流程领域，以获得更多资讯。
有关采取矫正措施，请参考专案监控流程领域，以获得更多资讯。
SP1.1 了解需求
与需求提供者一起了解需求之意义。
当专案成熟且需求已衍生后，全部的专案活动或专业领域将收受需求。要避免需求不知不觉的到来，须建立准则，以指定需求收受的适当管道和正式的来源。执行需求收受活动时，须与需求提供者一起分析需求，以确保对需求的意义能达成共识。此分析和对话的结果，才是被议定的需求。
典型的工作产品
1. 区别适当需求提供者的准则清单
2. 需求评估和接受准则
3. 依准则进行分析的结果
4. 经议定的需求
细部执行方法
1. 建立区别适当需求提供者的准则清单。
2. 建立客观的需求评估及接受准则。
缺乏评估及接受准则常常导致需求确认不够充分、昂贵的重做成本，或客户退件。
- ┌───────────────────────┐
- │需求评估及接受准则，举例如下： │
- │● 清晰而适当地表达 │
- │● 完整 │
- │● 相互的一致性 │
- │● 可个别界定 │
- │● 可适当地实作 │
- │● 可验证（可测试） │
- │● 可追溯 │
- └───────────────────────┘
3. 分析需求，以确保其符合已建立之准则的要求。
4. 与需求提供者达成需求共识，使专案成员可对需求承诺。
SP 1.2 取得对需求的承诺
取得专案成员对需求的承诺。
有关承诺的监督，请参考专案监控流程领域，以获得更多资讯。
┌─────────────────────────────────┐
│IPPD补充 │
│组成整合团队(integrated teams)时，专案成员就 │
│是整合团队和其成员。对其他整合团队的互动也 │
│是一项需求，对此需求的承诺，其重要性一如对 │
│产品及其他专案需求的承诺一般。 │
└─────────────────────────────────┘
上一个特定执行方法用于处理如何与需求提供者达成需求的了解，本特定执行方法则处理如何取得专案成员的承诺和同意，这些专案成员是负责执行需求之必要活动的人员。在专案进行期间，需求将渐进发展，尤其是在需求发展流程领域和技术解决方案流程领域之特定执行方法的说明中。在需求逐渐发展的情况下，本特定执行方法确保专案成员对当时已核可需求的承诺，以及对专案计划、活动及工作产品所造成之变更的承诺。
典型的工作产品
1. 需求影响评量(Requirements impact assessments)
2. 需求和需求变更承诺的纪录
细部执行方法
1. 评量需求对现有承诺的影响。
需求变更或新需求发生时，评估其对专案成员的影响。
2. 协商并记录承诺。
在专案成员对需求或需求改变承诺之前，对现有承诺的改变，应先协商。
SP 1.3 管理需求变更
当需求于专案执行期间渐进发展时，管理需求的变更。
有关维护和控制需求基准，并使需求及其变更资料能为专案运用，请参考建构管理流程领域，以获得更多资讯。
在专案执行期间，造成需求变更的原因甚多。当需要改变或工作进行中衍生新需求时，就可能需要变更现有的需求。如何有效率和有效果地管理这些新增需求或变更需求是很重要的。要有效分析变更所造成的影响，必须知道每一需求项目的来源，并记录变更的原因。然而，专案经理或许要追踪需求变更程度的适当度量，以决定是否要实施新的或修订现有的控制方式。
典型的工作产品
1. 需求状况表
2. 需求数据库
3. 需求决策数据库
细部执行方法
1. 记录所有的需求和需求变更，不论是专案本身产生的或外界的要求。
2. 维护需求变更纪录，以及每次变更的理由。
维护变更的历史纪录，有助于追踪需求变更的状况。
3. 从相关关键人员的观点，评估需求变更的影响。
4. 确保专案人员能取得需求和变更的资料。
SP 1.4 维护需求的双向追溯性
维护需求与工作产品间的双向追溯性。
本特定执行方法的目的，在于维护每一阶产品组件需求的双向追溯性。(“双向追溯性”的定义，请参考词汇。)当有效地管理需求，就可建立从原始需求至低阶需求的追溯性，亦可建立由低阶需求至原始需求的追溯性。如此一来，双向追溯性可协助确定已处理所有原始需求，以及所有低阶需求皆可追溯至有效的来源。需求追溯性也可以涵盖与其他实体的关系，例如：中间和最终产品、设计文件的变更、测试计划及工作项目。追溯性应包括水平及垂直关系，例如：跨界面。在进行需求变更对专案计划、活动及工作产品的影响评量时，特别需要追溯性。
典型的工作产品
1. 需求追溯表
2. 需求追踪系统
细部执行方法
1. 维护需求追溯性，确保已记录低阶(或衍生)需求的来源。
2. 维护需求追溯性，从需求到衍生需求，以及需求配置到功能、界面、物件、人员、流程及工作产品。
3. 制作需求追溯表。
SP 1.5 界定专案工作与需求间的差异
界定需求与专案计划及工作产品间的差异。
有关监控专案计划及工作产品与需求是否一致，以及视需要采取矫正措施，请参考专案监控流程领域，以获得更多资讯。
本特定执行方法用以找出需求与专案计划及工作产品间的差异，并启动修正的矫正措施。
典型的工作产品
1. 差异纪录，包括差异来源、条件及理由
2. 矫正措施(corrective actions)
细部执行方法
1. 审查专案计划、活动及工作产品，是否与需求及需求变更相符。
2. 界定差异来源及其理由。
3. 当需求基准有变动时，界定有关计划及工作产品所需的变更。
4. 启动矫正措施。