需求开发

成熟度3级的工程过程域

目的

需求开发(Requirements Development, RD)的目的，在于产出并分析客户、产品及产品组件的需求。

业界注释

本过程域描述客户、产品及产品组件等三种需求，这些需求说明相关关键人员的需要，包括与产品生命周期各阶段 (如，验收测试准则)及产品属性 (如，安全性、可靠性、与维护能力等) 有关的需要。需求也包括选择某设计解决方案而产生的限制条件。例如：与现成品整合的需求。

所有开发项目都有需求，从项目于维护活动的项目案例来看，产品或产品组件的变更，是基于现有需求、设计、或实作的变更。需求变更可能来自顾客或用户所记载的变更请求单，或来自于需求开发过程的新需求形式。不论需求来源或型式，变更所驱动的维护活动也要加以管理。 需求是设计的基础，需求的开发包括下列活动：

? 引导、分析、验证，以及沟通客户的需要、期望及限制，以获得客户需求，

并达成关键人员的共识 ? 搜集和协调关键人员的需要 ? 开发产品的生命周期需求 ? 建立客户需求

? 建立与客户需求一致的原始产品及产品组件需

因为客户也可能提出特定的设计需求，本过程域讨论所有客户的需求，而非局限于产品层次的需求。

客户需求可进一步细化为产品及产品组件需求。除客户需求外，选定的解决方案也可能衍生产品及产品组件需求。整个过程域中，产品及产品组件的意涵也包括服务及其组件。

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

需求开发过程域包括三项特定目标。”开发客户需求」特定目标说明如何定义完整的客户需求，以使用于产品需求开发。”开发产品需求」特定目标说明如何定义完整的产品和产品组件需求，以使用于产品和产品组件设计。”分析并确认需求」特定目标说明客户、产品及产品组件需求须执行的必要分析，以定义、衍生及了解需求。第三项特定目标的特定执行方法，用以辅助前两项特定

目标的特定执行方法。需求开发过程域的过程和技术解决方案过程域的过程，可彼此相互循环互动。

对竞争的备选方案进行分析，以了解、定义及选用各层次的需求。这些分析活动包括：

? 分析产品生命周期每阶段的需要和需求，包括：相关关键人员的需要、操

作环境，以及反映所有客户及使用者的期望和满意的因素(如安全性、保密性及负担能力) ? 开发操作观念 ? 定义必要的功能

功能的定义，也称为“功能分析”，与软件开发的结构化分析不同，也不能假定为功能导向的软件设计。在面向对象的软件设计里，它相当于定义所谓的“服务”或“方法”。功能、功能的逻辑群组，以及它们和需求之间关联的定义，就是所谓的”功能架构」。

对产品架构更细层次不断地分析，直到获得足够的细节以进行产品的细部设计、采购及测试。经由分析需求的结果及操作概念(包括功能性、支持、维护及销毁)，制造或生产的概念会产生出更多的衍生需求，包括下列考量： ? 不同类型的限制 ? 技术的界限 ? 成本和成本因素 ? 时间限制和日程因素 ? 风险

? 客户或使用者所暗示但未明确陈述的议题的考量 ? 开发者独特的经营考量、规定及法律等所产生的因素

逻辑实体的层次架构(功能及子功能，对象类别及子类别)，建立在反复开发的操作观念里。需求经过细化、衍生，才能配置到该逻辑实体。需求和逻辑实体再被配置于产品、产品组件、人员、或相关过程。

I在需求开发和分析时，纳入相关关键人员的参与，藉此使他们了解需求的演进过程。本活动持续向相关关键人员提供保证：需求已适切定义。

相关过程域

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

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

有关验证最终产品是否符合需求，请参考验证过程域，以获得更多信息。 有关确认如何依照客户需要建置产品，请参考确认过程域，以获得更多信息。 有关需求相关风险的识别和管理，请参考风险管理过程域，以获得更多信息。 有关确保重要工作产品的控管，请参考配置管理过程域，以获得更多信息。.

特定目标及实践摘要

SG 1开发客户需求

SP 1.1 引导需要 SP 1.2 开发客户需求 SG 2开发产品需求

SP 2.1 建立产品与产品组件需求 SP 2.2 配置产品组件需求 SP 2.3 识别接口需求 SG 3分析并确认需求

SP 3.1 建立操作概念及场景 SP 3.2 建立必要功能的定义 SP 3.3 分析需求

SP 3.4 分析需求以取得平衡 SP 3.5 确认需求

各特定目标的实践

SG 1

开发客户需求

收集相关干系人的需要、期望、限制及接口，并转换成客户需求. 关键人员(例如：客户、最终使用者、供货商、建置人员、测试人员、制造人员，与后勤支持人员)的需要，是决定客户需求的基础。进行关键人员的需要、期望、限制、接口、操作概念，以及产品观念的分析、协调、细化及详细说明，以转换成客户需求。

关键人员的需要、期望、限制及接口，经常被粗略的识别或相互矛盾。因为必须清楚识别和了解关键人员的需要、期望、限制及界限，在整个项目的生命周期里可使用反复的过程，以达到这目标。为协助此必要的循环过程，最终用户或客户的代表，通常会加入此过程，以说明其需要并协助解决矛盾。组织的客户关系或营销部门，以及来自人际工程或支持部门的开发团队成员，可视为此类的代表。在研拟和解决客户需求时，也应考量客户的外在环境、法规及其他限制 .

SP 1.1

引导需要

引导相关干系人提出有关产品生命周期各阶段的需要、期望、限制及接口. 引导不只是积极识别尚未经客户明确提出的新增需求。新增的需求应描述各种生命周期的活动，以及它们对产品的影响。

引导需要的技术，举例如下： ? 技术展示 ? 接口管制工作组 ? 技术管制工作组 ? 临时的项目审查

? 由最终使用者取得的问卷、访谈及操作场景等数据 ? 操作的审查和最终使用者的工作分析 ? 原型和模型 ? 脑力激荡 ? 质量机能展开 ? 市场调查 ? 试用版本的试用

? 由文件、标准或规格等来源中抽取

? 观察现行产品、环境及工作过程的样式（patterns） ? 使用案例（use cases） ? 经营案例分析

? 采取反向工程（针对现有产品） ? 客户满意度调查

可能未被客户识别的需求来源，举例如下： ? 经营策略 ? 标准

? 经营环境要求（例：研究室、测试其他设施、信息科技基础建设等） ? 技术

? 现有产品或产品组件(可再用产品组件)

子实践

1. 与相关的干系人一起参与，并使用方法，以引导出需求、期望、限制及外

部接口。

SP 1.2

开发客户需求

把相关干系人的需求、期望、限制条件和接口转换成客户需求。

来自相关关键人员的各种输入，须经合并、取得遗漏的信息，以及解决冲突等过程，并记录为客户需求。客户需求可包括与验证和确认有关的需要、期望及限制。

某些情况来说，客户提供项目的一套需求，或者之前项目活动的需求产出。以这些情况来说，客户需求与相关关键人员的需要、期望、限制及接口可能有所冲突，所以在冲突适当解决之后，需要转换成被认可的客户需求。

代表产品生命周期的所有阶段的相关关键人员，应包括经营及技术功能。因此，所有与产品生命周期相关的过程概念，都应与产品的概念同步考量。客户需求来自信息充分的决策，同时考量需求在经营面与技术面的影响。 典型的工作产品

1. 2. 3.

客户需求。

执行验证时的客户限制。 执行确认时的客户限制。

子实践

1. 转换关键人员的需要、预期、限制及接口，成为客户需求。 2. 定义验证及确认时的限制。

SG 2

Develop Product Requirements

对客户需求加以精练和细化，以开发产品和产品组件需求。 分析客户需求并开发操作概念，以衍生更详细和精准的需求，此需求称为“产品与产品组件需求”。“产品与产品组件需求”说明产品生命周期每一阶段的相关需要。衍生需求是由限制、对某些隐含议题的考量及某些因素而间接产生，这些议题在客户需求基准中并未明确说明；而这些因素是基于所选用的架构、设计，以及开发者独特的经营考量等而产生。需求须以后续的、较低阶的需求及功能架构再检查，并细化优先的产品概念。

配置需求于产品功能及产品组件，包括对象、人员及过程，并记录需求到功能、对象、测试、议题，或其他实体的追溯性。已配置的需求及功能是组成技术解决方案的基础。当开发内部组件时，须定义新增的接口，并建立接口需求。

有关维护双向追溯性，请参考需求管理过程域的「维护需求的双向追溯性」特定执行方法，以获得更多信息.

SP 2.1

Establish Product and Product Component Requirements

根据客户需求，建立和维护产品和产品组件的需求。

客户需求可能以客户术语表示，且以较不具技术的方式描述。产品需求则是以专业术语表示这些客户需求，以用来进行设计的决策。“质量机能展开”是此转换的范例，它描述客户期望与技术参数的对应关系。例如：“结实的门”可能对应到尺寸规模大小、重量、适合、湿度及共振频率。

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

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

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

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