CMMI需求开发

成熟度3级的工程过程域目的需求开发(Requirements Development, RD)的目的，在于产出并分析客户、产品及产品组件的需求。

业界注释本过程域描述客户、产品及产品组件等三种需求，这些需求说明相关关键人员的需要，包括与产品生命周期各阶段 (如，验收测试准则)及产品属性 (如，安全性、可靠性、与维护能力等) 有关的需要。

需求也包括选择某设计解决方案而产生的限制条件。

例如：与现成品整合的需求。

所有开发项目都有需求，从项目于维护活动的项目案例来看，产品或产品组件的变更，是基于现有需求、设计、或实作的变更。

需求变更可能来自顾客或用户所记载的变更请求单，或来自于需求开发过程的新需求形式。

不论需求来源或型式，变更所驱动的维护活动也要加以管理。

需求是设计的基础，需求的开发包括下列活动：引导、分析、验证，以及沟通客户的需要、期望及限制，以获得客户需求，并达成关键人员的共识搜集和协调关键人员的需要开发产品的生命周期需求建立客户需求建立与客户需求一致的原始产品及产品组件需因为客户也可能提出特定的设计需求，本过程域讨论所有客户的需求，而非局限于产品层次的需求。

客户需求可进一步细化为产品及产品组件需求。

除客户需求外，选定的解决方案也可能衍生产品及产品组件需求。

整个过程域中，产品及产品组件的意涵也包括服务及其组件。

在整个产品生命周期中识别并修订需求。

对设计决策、后续的纠正措施，以及产品生命周期各阶段所产生的回馈进行分析，以了解它们对衍生及已配置需求的影响。

需求开发过程域包括三项特定目标。

”开发客户需求」特定目标说明如何定义完整的客户需求，以使用于产品需求开发。

”开发产品需求」特定目标说明如何定义完整的产品和产品组件需求，以使用于产品和产品组件设计。

”分析并确认需求」特定目标说明客户、产品及产品组件需求须执行的必要分析，以定义、衍生及了解需求。

第三项特定目标的特定执行方法，用以辅助前两项特定目标的特定执行方法。

需求开发过程域的过程和技术解决方案过程域的过程，可彼此相互循环互动。

对竞争的备选方案进行分析，以了解、定义及选用各层次的需求。

这些分析活动包括：分析产品生命周期每阶段的需要和需求，包括：相关关键人员的需要、操作环境，以及反映所有客户及使用者的期望和满意的因素(如安全性、保密性及负担能力)开发操作观念定义必要的功能功能的定义，也称为“功能分析”，与软件开发的结构化分析不同，也不能假定为功能导向的软件设计。

在面向对象的软件设计里，它相当于定义所谓的“服务”或“方法”。

功能、功能的逻辑群组，以及它们和需求之间关联的定义，就是所谓的”功能架构」。

对产品架构更细层次不断地分析，直到获得足够的细节以进行产品的细部设计、采购及测试。

经由分析需求的结果及操作概念(包括功能性、支持、维护及销毁)，制造或生产的概念会产生出更多的衍生需求，包括下列考量：不同类型的限制技术的界限成本和成本因素时间限制和日程因素风险客户或使用者所暗示但未明确陈述的议题的考量开发者独特的经营考量、规定及法律等所产生的因素逻辑实体的层次架构(功能及子功能，对象类别及子类别)，建立在反复开发的操作观念里。

需求经过细化、衍生，才能配置到该逻辑实体。

需求和逻辑实体再被配置于产品、产品组件、人员、或相关过程。

I在需求开发和分析时，纳入相关关键人员的参与，藉此使他们了解需求的演进过程。

本活动持续向相关关键人员提供保证：需求已适切定义。

相关过程域有关管理客户及产品需求、取得需求提供者同意、取得需求执行者承诺及维护追溯性，请参考需求管理过程域，以获得更多信息。

有关如何使用需求开发过程域的输出，以及开发替代方案和设计，以用于细化和衍生需求，请参考技术解决方案过程域，以获得更多信息。

有关验证最终产品是否符合需求，请参考验证过程域，以获得更多信息。

有关确认如何依照客户需要建置产品，请参考确认过程域，以获得更多信息。

有关需求相关风险的识别和管理，请参考风险管理过程域，以获得更多信息。

有关确保重要工作产品的控管，请参考配置管理过程域，以获得更多信息。

.特定目标及实践摘要SG 1开发客户需求SP 引导需要SP 开发客户需求SG 2开发产品需求SP 建立产品与产品组件需求SP 配置产品组件需求SP 识别接口需求SG 3分析并确认需求SP 建立操作概念及场景SP 建立必要功能的定义SP 分析需求SP 分析需求以取得平衡SP 确认需求各特定目标的实践SG 1 开发客户需求关键人员(例如：客户、最终使用者、供货商、建置人员、测试人员、制造人员，与后勤支持人员)的需要，是决定客户需求的基础。

进行关键人员的需要、期望、限制、接口、操作概念，以及产品观念的分析、协调、细化及详细说明，以转换成客户需求。

关键人员的需要、期望、限制及接口，经常被粗略的识别或相互矛盾。

因为必须清楚识别和了解关键人员的需要、期望、限制及界限，在整个项目的生命周期里可使用反复的过程，以达到这目标。

为协助此必要的循环过程，最终用户或客户的代表，通常会加入此过程，以说明其需要并协助解决矛盾。

组织的客户关系或营销部门，以及来自人际工程或支持部门的开发团队成员，可视为此类的代表。

在研拟和解决客户需求时，也应考量客户的外在环境、法规及其他限制.SP 引导需要引导相关干系人提出有关产品生命周期各阶段的需要、期望、限制及接口.引导不只是积极识别尚未经客户明确提出的新增需求。

新增的需求应描述各种生命周期的活动，以及它们对产品的影响。

引导需要的技术，举例如下：技术展示接口管制工作组技术管制工作组临时的项目审查由最终使用者取得的问卷、访谈及操作场景等数据操作的审查和最终使用者的工作分析原型和模型脑力激荡质量机能展开市场调查试用版本的试用由文件、标准或规格等来源中抽取观察现行产品、环境及工作过程的样式（patterns）使用案例（use cases）经营案例分析采取反向工程（针对现有产品）客户满意度调查可能未被客户识别的需求来源，举例如下：经营策略标准经营环境要求（例：研究室、测试其他设施、信息科技基础建设等）技术现有产品或产品组件(可再用产品组件)子实践1. 与相关的干系人一起参与，并使用方法，以引导出需求、期望、限制及外部接口。

SP 开发客户需求来自相关关键人员的各种输入，须经合并、取得遗漏的信息，以及解决冲突等过程，并记录为客户需求。

客户需求可包括与验证和确认有关的需要、期望及限制。

某些情况来说，客户提供项目的一套需求，或者之前项目活动的需求产出。

以这些情况来说，客户需求与相关关键人员的需要、期望、限制及接口可能有所冲突，所以在冲突适当解决之后，需要转换成被认可的客户需求。

代表产品生命周期的所有阶段的相关关键人员，应包括经营及技术功能。

因此，所有与产品生命周期相关的过程概念，都应与产品的概念同步考量。

客户需求来自信息充分的决策，同时考量需求在经营面与技术面的影响。

典型的工作产品1. 客户需求。

2. 执行验证时的客户限制。

3. 执行确认时的客户限制。

子实践1.转换关键人员的需要、预期、限制及接口，成为客户需求。

2. 定义验证及确认时的限制。

SG 2 Develop Product Requirements分析客户需求并开发操作概念，以衍生更详细和精准的需求，此需求称为“产品与产品组件需求”。

“产品与产品组件需求”说明产品生命周期每一阶段的相关需要。

衍生需求是由限制、对某些隐含议题的考量及某些因素而间接产生，这些议题在客户需求基准中并未明确说明；而这些因素是基于所选用的架构、设计，以及开发者独特的经营考量等而产生。

需求须以后续的、较低阶的需求及功能架构再检查，并细化优先的产品概念。

配置需求于产品功能及产品组件，包括对象、人员及过程，并记录需求到功能、对象、测试、议题，或其他实体的追溯性。

已配置的需求及功能是组成技术解决方案的基础。

当开发内部组件时，须定义新增的接口，并建立接口需求。

有关维护双向追溯性，请参考需求管理过程域的「维护需求的双向追溯性」特定执行方法，以获得更多信息.SP Establish Product and Product Component Requirements根据客户需求，建立和维护产品和产品组件的需求。

客户需求可能以客户术语表示，且以较不具技术的方式描述。

产品需求则是以专业术语表示这些客户需求，以用来进行设计的决策。

“质量机能展开”是此转换的范例，它描述客户期望与技术参数的对应关系。

例如：“结实的门”可能对应到尺寸规模大小、重量、适合、湿度及共振频率。

“产品与产品组件需求”强调客户、经营，以及项目目标和相关属性(如有效性和负担能力)的满足。

衍生需求也包括其他生命周期阶段的成本和绩效 (如，生产、操作及销毁)，以与经营目标兼容。

.需求管理过程域涵盖需求变更的管理，而本特定执行方法的“维护”部分，涵盖因已核准的需求变更而引起的需求修改活动。

有关管理需求变更，请参考需求管理过程域，以获得更多信息。

.典型的工作产品1. 衍生需求2. 产品需求3. 产品组件需求子实践1. 以专业术语开发产品与产品组件设计的需求。

针对产品架构设计所需的重要的产品质量和绩效，开发架构需求。

2. 由设计决策衍生需求。

有关开发解决方案以产生其他衍生需求，请参考技术解决方案过程域，以获得更多信息。

.技术的选用会引进其他的需求。

例如：运用电子学将增加特定技术的需求，如电磁干扰的界限。

3. 建立并维护需求间的关连性，并考量在变更管理和需求配置时的影响。

有关维护需求追溯，请参考需求管理过程域，以获得更多信息。

需求间的关连有助于评估变更的影响。

SP 分配产品组件需求为每个产品组件分配需求。

有关配置需求到产品和产品组件，请参考技术解决方案过程域，以获得更多信息。

本执行方法提供信息以定义需求配置，但必须和技术解决方案过程域的执行方法互动，以建立配置需求的解决方案。

上述中所定义的解决方案，其产品组件的需求，包括所配置的产品绩效、设计限制，以及符合需求和有助于生产的合适、形式及功能。

假使较高阶需求的指定绩效归属于两组或以上的产品组件时，该绩效必须进行切割，并单独配置到各个产品组件，就像是衍生需求一样。

.典型的工作产品1. 需求配置表2. 暂时性的需求配置3. 设计限制4. 衍生需求5. 衍生需求间的关系细部执行方法子实践1. 分配需求于功能。

2. 分配需求于产品组件。

3. 配置设计限制于产品组件。

4. 记录已配置需求间的关系。

关系包括依赖性，在这情境下，某需求的改变可能会影响其他的需求。

SP 识别接口需求定义功能之间(或对象之间)的接口。

功能接口可能衍生出替代方案的开发，替代方案在技术解决方案过程域中描述。

有关接口管理以及产品和产品组件的整合，请参考产品整合过程领域，以获得更多信息。

定义产品架构中所识别之产品与产品组件间的接口需求，并将它们当做产品与产品组件整合的一部分来管制，它们也是架构定义中不可缺少的部分。