第二章过程域——需求开发

来源：互联网发布：电视台知乎编辑：程序博客网时间：2024/06/07 10:23

需求开发

成熟度3级的一个工程过程域

目的

需求开发（RD）的目的是产生并分析客户、产品、以及产品部件的需求。

介绍

本过程域描述三类需求：客户需求、产品需求、以及产品部件需求。这些需求共同陈述了相关干系人的要求，包括与不同的产品生存期阶段相关的（例如验收测试准则）和与产品特性相关的（例如安全性、可靠性、可维护性）。需求还陈述了由设计方案的选择引起的约束（例如对市售产品的集成）。

需求是设计的基础。需求的开发包括以下活动：

l 提取、分析、确认、以及沟通客户的要求、期望、以及约束，以得到客户需求。客户需求解释了什么才能满足干系人

l 收集并协调干系人的要求

l 开发产品的生存期需求

l 建立客户需求

l 建立与客户需求一致的初始的产品与产品部件需求

本过程域针对所有客户需求而不仅仅是产品级的需求，因为客户也可能提供特定的设计需求。

客户需求被进一步细化为产品与产品部件需求。除了客户需求以外，产品和产品部件需求还可以从选定的设计方案中推导出来。

需求的识别和细化贯穿产品生存期的各个阶段。对产品生存期每个阶段的设计决策、后继的纠正措施以及反馈，都要分析其对衍生的和已分配的需求的影响。

需求开发过程域包括三个特定目标。“开发客户需求”特定目标定义一组用于开发产品需求的客户需求。“开发产品需求”特定目标定义一组用于设计产品与产品部件的产品与产品部件需求。“分析与确认需求”特定目标对客户、产品和产品部件需求进行必要的分析，以定义、推导、以及理解需求。第三个特定目标的特定实践旨在辅助前两个特定目标的特定实践。属于“需求开发”过程域的过程和属于“技术解决方案”的过程可能存在相互递归影响。

分析还用于理解、定义和选择竞争的候选方案中所有级别的需求。这些分析包括：

l 分析每个产品生存期阶段的需求和需求，包括相关干系人的要求，运行环境、以及反映客户与最终用户的整体期望和满意度的安全

l 性、保密性、经济性等要素

l 开发一个运行概念

l 定义需要的功能性

功能性的定义，也被称为“功能分析”，与软件开发中的结构化分析不同，而且并不假定某种面向功能的软件设计。在面向对象的软件设计中，它与服务的定义有关。功能的定义、它们的逻辑组合、以及它们与需求的关联，被称为“功能体系结构（functional architecture）”。

多次反复进行分析，逐步进入产品体系结构中更加细化的层次，直至获得足够的细节使产品的详细设计、采办、以及测试得以进行。作为需求和运行概念（包括功能性、支持、维护、以及退役清理）的分析结果，制造或生产概念产生了更多的衍生需求，包括对以下方面的考虑：

l 多种类型的约束

l 技术上的限制

l 成本和成本驱动因素

l 时间约束和进度驱动因素

l 风险

l 隐含的但是未被客户或最终用户明确表述的考虑事项

l 由开发者特有的业务考虑、规则、以及法律引入的因素

通过随着运行概念的演进而进行的迭代，建立了一个逻辑实体（功能与子功能、对象类和子类）的层次结构。需求得到细化、推导，并被分配到这些逻辑实体。需求和逻辑实体被分配到产品、产品部件、人员、相关过程、或者服务。

相关干系人参与需求开发与分析，向他们提供了需求演进的可视性。这种活动持续地保证需求得到适当的定义。

实现目标的关键实践

SG1开发客户需求

干系人的要求、期望、约束、以及接口得到收集并被转化为客户需求。

干系人（例如客户、最终用户、供方、构建者、以及测试员）的要求是确定客户需求的基础。干系人的要求、期望、约束、接口、运行概念、以及产品概念得到分析、协调、细化、以及提炼，最终被转换为一组客户需求。

干系人的要求、期望、约束、以及接口常常得不到很好的识别，或者相互有冲突。由于干系人的要求、期望、约束和限制应该得到清晰的识别和理解，应采用一个贯穿整个项目生存期的迭代过程来实现这个目的。为了促进这种交互，常常需要由一个最终用户或者客户的代理人来表达他们的要求并帮助解决冲突。组织的客户关系或者市场部门以及来自人体工程学或支持等学科的开发组成员可以作为代理人。在创建和判定客户需求时，环境上的、法律上的以及其它方面的约束都应该考虑到。

SP1.1-1收集干系人的需求

识别和收集干系人对产品生存周期所有阶段的要求、期望、约束、以及接口。

这项基本活动接收客户提供的需求，以定义什么是需要的或者期望的。这些需求可能用技术术语来陈述，也可能不是。它们应该针对不同的产品生存周期活动及其对产品的影响。。

SP1.1-2提出要求

提出干系人对产品生存周期所有阶段的要求、期望、约束、以及接口。

提取需求不仅是对需求的收集，还包括主动地识别并未由客户明确提出的附加需求。附加需求应该针对不同的产品生存周期活动及其对产品的影响。

提出要求的技术的实例包括：

l 技术演示

l 接口控制工作组

l 技术控制工作组

l 中间产品评审

l 问卷、访谈、以及从最终用户处获取运行场景

l 运行走查和最终用户任务分析

l 原型与模型

l 头脑风暴

l 质量功能展开

l 市场调查

l Beta 测试

l 从文档、标准或规约等来源中提取

l 观察现有的产品、环境、以及工作流模式

l 用例

l 业务案例分析

l 反向工程（对于遗留产品）

子实践

1. 吸引相关干系人使用提出要求、期望、约束和外部接口的方法。

SP1.2-1开发客户需求

将干系人的要求、期望、约束和接口转换为客户需求。

对于集成化的产品与过程开发

代表产品生存周期所有阶段的相关干系人应该包括业务和技术职能人员。通过这种方式，与产品相关的所有生存周期过程方面的概念和产品概念同时得到考虑。就他们的需求对业务和技术影响进行的深思熟虑的决策产生客户需求。

将识别出来的客户需求进行文档化时，必须整理来自客户的多种输入，获取遗漏的信息，并且消除冲突。客户需求可能包括关于验证与确认的要求、期望、以及接口。

典型工作产品

1. 客户需求

2. 客户对实施验证的约束

3. 客户对实施确认的约束

子实践

1. 将干系人的要求、期望、约束、以及接口转换为文档化的客户需求。

2. 定义对验证与确认的约束。

SG2 开发产品需求

客户需求得到细化并被详细阐述，以开发产品与产品部件的需求。

结合运行概念的开发分析客户需求，以导出被称为“产品与产品部件需求”的更加详细和准确的需求集合。产品与产品部件的需求描述与每个产品生存周期阶段相关的要求。导出需求来自于客户需求基线中隐含的而不是明确陈述的约束、对问题的考虑，以及选定的体系结构、设计、和开发人员特有的业务考虑等引入的一些因素。结合后继的每个更低层的需求集合和功能结构重新检查需求，并细化最可取的产品概念。

需求被分配给产品功能和产品部件，包括对象、人员和进程。需求到功能、对象、测试、问题、或者其它实体的可追踪性得到文档化。分配需求和功能是综合技术解决方案的基础。随着内部部件的开发，附件的接口得到定义，同时接口需求得以建立。

有关如何维护双向可追踪性的更多信息请参见需求管理过程域的维护需求的双向可追踪性特定实践。

SP2.1-1 建立产品与产品部件的需求

建立并维护基于客户需求的产品与产品部件需求。

客户需求可能用客户的术语表述，而且可能是非技术的描述。产品需求是这些需求的技术术语表达，能够被用于设计决策。首次House of Quality Functional Deployment 中有这类转换的一个实例，它把客户要求映射为技术参数。例如，“实心隔音门”可能被变换为尺寸、重量、配合紧度、阻尼、以及共振频率。

产品与产品部件的需求说明了如何满足客户、业务、以及项目目的和有效性、可供应性等相关属性。

设计约束包括从设计决策而不是高层需求中导出的产品部件的规约。

对于软件工程

例如，必须与某个商用数据库部件进行交互的应用部件必须满足由选定的数据库所限定的接口需求。这类产品部件的需求通常并不能追踪到更高层的需求。

导出的需求也可能说明了业务目标范围内其它生存周期阶段（例如生产、运行以及退役）的成本和效能。

由于被批准的需求的变更而引起的需求修改由本特定实践的“维护”功能来处理，然而对需求变更的管理被涵盖在“需求管理”过程域中。

有关如何管理需求的变更的更多信息请参见需求管理过程域。

典型工作产品

1. 导出需求

2. 产品需求

3. 产品部件需求

子实践

1. 为产品与产品部件的设计而开发用技术术语描述的需求。

开发描述产品体系结构设计所需要的关键产品质量与性能的体系结

构需求。

1. 从设计决策中推导出需求。

有关如何开发能够产生附加的导出需求的解决方案的更多信息请参见技术解决方案过程域。

技术选择能够带来附加的需求。例如，选用要求诸如电磁干扰限制等附加的特定技术需求的电子器件。

3. 建立并维护需求之间的关系，以便在变更管理与需求分配过程中考虑这些关系。

有关如何维护需求的可追踪性的更多信息请参见需求管理过程域。

需求之间的关系有助于评价变更的影响。

SP2.2-1 分配产品部件需求

分配每个产品部件的需求。

参与“技术解决方案”过程域以进一步了解如何将需求分配给产品与产品部件。本特定实践为定义需求的分配提供了信息，但是必须与“技术解决方案”过程域中的特定实践相配合，以建立分配需求的解决方案。

预定的解决方案中产品部件的需求包括产品性能的分配、设计约束以及配合、造型、以及功能，以满足需求并便于生产。高层需求规定了将要由两个以上产品部件提供的性能时，必须将该性能分解到每个产品部件，作为导出需求。

典型工作产品

1. 需求分配表格

2. 暂定的需求分配

3. 设计约束

4. 导出需求

5. 导出需求之间的关系

子实践

1. 将需求分配给各功能。

2. 将需求分配给产品部件。

3. 将设计约束分配给产品部件。

4. 将需求之间的关系文档化。

关系包括依赖，在这种关系中，一个需求的变更会影响到其它需求。

SP2.3-1 识别接口需求

识别接口需求。

功能（或者对象）之间的接口得到识别。功能接口可能驱动“技术解决方案”过程域中候选解决方案的开发。

有关如何管理接口并集成产品与产品部件的更多信息请参见产品集成过程域。

在产品体系结构中识别出来的产品或产品部件之间的接口需求得到定义。它们被作为产品或者产品部件集成的一部分得到控制，并且是体系结构定义的一个必要部分。

典型工作产品

1. 接口需求

子实践

1. 识别产品外部与内部（例如功能部分或者对象之间）的接口。

随着设计的进展，技术解决方案过程将会变动产品体系结构，创建出新的产品部件之间以及部件外部对产品的新的接口。

与产品相关生存周期过程的接口也应该得到识别。

这些接口的实例包括与测试设备、运输系统、支持系统以及制造设备的接口。

2. 为识别出来的接口开发需求。

有关在设计过程中如何产生新的接口的更多信息请参见技术解决方案过程域。

接口需求用发源、终点、激励、软件的数据特性、硬件的电气和机械特性等术语来定义。

SG3 分析与确认需求

需求得到分析与确认，需要的功能的定义得到开发。

“分析与确认需求”特定目标下的特定实践支持“开发客户需求”和“开发产品需求”两个特定目标中的需求开发。本特定目标下的特定实践包括分析与确认关于用户的预期环境的需求。

分析是为了确定预期的运行环境将对满足干系人的要求、期望、约束和接口的能力产生什么影响。可行性、任务要求、成本约束、潜在的市场规模、以及采办策略等方面都必须在产品背景中得到考虑。对需要的功能性的定义也得以建立。所有规定的产品使用模式都得到考虑，而且对时间上关键的功能顺序进行了时间线分析。

分析的目的是确定能够满足干系人的要求、期望与约束的候选产品概念需求，随后将这些概念转换为需求。在这项活动的同时，将用来评价产品有效性的参数也根据客户的输入和初始的产品概念得以确定。

验证需求是为了提高结果产品在使用环境中按照预期执行的概率。

SP3.1-1 建立运行概念和场景

建立与维护运行概念和相关场景。

有关根据选定的设计开发运行概念的细节的更多信息请参见技术解决方案过程域。

场景是在产品使用中可能发生的一系列事件，用来使干系人的某些要求更加清晰。相反，产品的运行概念通常同时依赖于设计的解决方案和场景。例如，卫星通信产品的运行概念与基于陆上线路的有很大不同。由于候选解决方案在准备初始的运行概念时可能尚未确定，需要开发概念性的解决方案，以便在分析需求时使用。运行概念随着解决方案的制订而得到细化，更低层的需求也随之得到开发。

正如产品的设计决策可能变成产品部件的需求一样，运行概念可能变为产品部件的场景（需求）。

场景可能包含运行顺序，倘若那些顺序是客户需求的表现而不是运行概念。

典型工作产品

1. 运行概念

2. 产品的安装、运行、维护和支持概念

3. 退役清理概念

4. 用例

5. 时间线场景

6. 新的需求

子实践

1. 开发运行概念和场景，适当地包括功能性、性能、维护、支持以及退役清理。

识别并开发拟议中的产品预期运行的场景，其详细程度与干系人的要求、期望和约束一致。

2. 定义产品未来运行时所处的环境，包括边界和约束。

3. 评审运行概念和场景，以细化并发现需求。

运行概念和场景的开发是一个迭代的过程。应该周期性地进行评审以保证它们与需求一致。这类评审可以采用走查的形式。

4. 随着产品与产品部件的选定而开发详细的运行概念，定义产品、最终用户以及环境之间的相互作用关系，并满足运行、维护、支持以及退役清理的要求。

SP3.2-1 建立需要的功能性的定义

建立并维护需要的功能性的定义。

功能性的定义也被称为“功能分析”，是产品预期要做什么的描述。功能性的定义可以包括活动、顺序、输入、输出、或者其它关于产品未来使用方式的信息。

功能分析不同于软件开发中的结构化分析，并且不假定面向功能的软件设计。在面向对象的软件设计中，它涉及服务的定义。功能的定义、它们的逻辑组合、以及它们与需求的关系被称为功能体系结构。参见附录C 词汇表中“功能体系结构”的定义。

典型工作产品

1. 功能体系结构

2. 活动图和用例

3. 面向对象的分析，包括服务的识别

子实践

1. 分析并量化最终用于需要的功能性。

2. 分析需求以识别逻辑上或者功能上的区分（例如子功能）。

3. 将需求按照预定准则（例如类似的功能性、性能、或者结合）分组，以便于需求分析，并指出需求分析的重点。

4. 起初以及后面在产品部件的开发过程中都要考虑时间上关键的功能顺序。

5. 将客户需求分配到功能区域、对象、人员、或者支持元素，以支持解决方案的合成。

6. 将功能和性能需求分配给功能和子功能。

SP3.3-1 分析需求

分析需求以保证它们是必要而充分的。

根据运行概念和场景，分析产品分层结构中每个层次的需求以确定它们对满足更高的产品层次的目的是否是必要而充分的。这样，分析过的需求为产品分层结构中的更低层提供了更加详细而精确的需求。

随着需求的细化，必须理解它们与更高层的需求以及更高层需求所定义的功能性之间的关系。其它行动中有一项是确定将使用哪项关键需求来跟踪技术进展。例如，可以在开发过程中根据其风险来监督产品的重量或者软件的规模。

典型工作产品

1. 需求缺陷报告

2. 为解决缺陷而提出的需求变更

3. 关键的需求

4. 技术性能测度

子实践

1. 分析干系人的要求、期望、约束以及外部接口，以消除冲突并将它们组织到相关主题中。

2. 分析需求以确定它们是否满足更高层需求的目的。

3. 分析需求以确定它们是完整的、可行的、可实现的以及可验证的。

一旦设计决定了某种特定解决方案的可行性，本子实践指出哪些需求影响可行性。

4. 识别对成本、进度、功能性、风险、或者性能有重要影响的关键需求。

5. 识别将在开发工作中跟踪的技术性能测度。

有关度量的使用的更多信息请参见度量与分析过程域。

6. 分析运行概念和场景以细化客户要求、约束以及接口，并发掘新的需求。

分析可能得出更详细的运行概念和场景，同时支持新需求的导出。

SP3.4-3 分析需求以实现平衡

分析需求以平衡干系人的要求和约束。

干系人的要求和约束可能涉及成本、进度、性能、功能性、可重用部件、维修性、或者风险。

典型工作产品

1. 对与需求相关的风险的评估。

子实践

1. 使用经证实的模型、模拟、以及原型来分析干系人的要求与约束之间的平衡。

分析的结果可以用于降低产品的成本和产品开发中的风险。

2. 对需求和功能体系结构执行风险评估。

有关如何对客户与产品需求以及功能体系结构进行风险评估的更多信息请参见风险管理过程域。

3. 检查产品生存周期概念，了解需求对风险的影响。

SP3.5-1确认需求

确认结果产品将在用户环境中完成预期任务。

典型工作产品

1.需求确认的结果

子实践

1. 分析需求，以确定结果产品不能在预期的使用环境中适当运行的风险。

SP3.5-2 用全面的方法确认需求

适当地采用多种技术，确认结果产品将在用户环境中完成预期任务。

需求确认在开发工作初期进行，以收集证据来表明需求有能力引导能够导致成功的最终确认的开发。本活动应该与风险管理活动集成。成熟的组织通常用更复杂的方式来确认需求，并扩展确认的基础以包含其他干系人的要求和预期。这些组织通常进行分析、模拟、或者原型工作以保证需求将满足干系人的要求和预期。

典型工作产品

1. 分析方法与结果的记录

子实践

1. 分析需求，以确定结果产品不能在预期的使用环境中适当运行的风险。

2. 通过开发产品表述（例如原型、模拟、模型、场景、以及故事板）并从相关干系人处获得相关反馈来探究需求的充分性和完整性。

3. 随着设计在需求验证环境的上下文中的成熟，评估设计以识别确认项并揭示未声明的要求和客户需求。

目标的一般实践

GG1 完成特定目标

通过将可识别的输入工作产品转变为可识别的输出工作产品，过程支持并且能够使过程域的特定目标实现。

GP1.1 履行基本实践

履行需求开发过程的基本实践从而发展工作产品和提供达到过程域的特殊目标的服务。

仅仅适用于连续式

GG2 制度化一个已管理的过程

过程被作为一个已管理的过程制度化。

执行的保障

GP2.1 建立组织的方针

建立和维持一个用于计划和执行需求开发过程的组织性方针。

详尽的细节

这个方针建立了对收集干系人的要求，阐明产品与产品部件的需求，以及分析并确认这些需求的组织性的期望。

执行的能力

GP2.2计划过程

建立和维持一个用于执行需求开发过程的计划。

详尽的细节

通常，执行需求开发过程的计划是项目计划过程域所描述的项目计划的一部分。

GP2.3 提供资源

提供足够的资源用于执行需求开发过程，开发工作产品，以及提供过程的服务。

详尽的细节

可能需要在应用领域、提取干系人要求的方法、以及说明和分析客户、产品、以及产品部件需求的方法和工具方面的特殊技能。

提供的资源包括如下工具所示：

l 需求说明工具

l 模拟器和建模工具

l 原型工具

l 场景定义和管理工具

l 需求跟踪工具

GP2.4 分配职责

分配执行过程，开发工作产品以及提供需求开发过程服务的职责。

GP2.5 培训人员

必须培训执行和支持需求开发过程的人员。

详尽的细节

培训主题示例如下：

l 应用领域

l 需求定义与分析

l 需求提取

l 需求说明与建模

l 需求跟踪

引导（过程的）执行

GP2.6 管理配置

给需求开发过程中的指定工作产品以适宜的配置管理水平。

详尽的细节

在配置管理下存放的工作产品示例如下：

l 客户需求

l 功能体系结构

l 产品与产品部件的需求

l 接口需求

GP2.7 识别和包含相关的干系人

对照计划，识别和包含需求开发过程的相关干系人。

详尽的细节

从客户、最终用户、开发人员、生产人员、测试人员、供应商、市场人员、维护人员、最终清理人员和其它受到产品与过程的影响、或者影响产品与过程的人员中选择相关干系人。

干系人的活动示例如下：

l 评审需求是否能充分满足要求、期望、约束和接口

l 建立运行概念与场景

l 评估需求的充分性

l 建立产品与产品部件的需求

l 评估产品的成本、进度、以及风险

GP2.8 监督与控制过程

根据计划监督与控制需求开发过程，从而执行过程并进行适当的纠正活动。

详尽的细节

用于监督与控制的度量方法示例如下：

l 返工所花费的成本、进度与工作量

l 需求说明的缺陷密度

验证（过程的）执行

GP2.9 客观的评价坚持状况

对照过程的描述、规则、程序，客观评估需求开发过程的坚持状况，并处理未按此执行的相关事宜。

详尽的细节

回顾活动示例如下：

l 收集干系人的要求

l 阐明产品与产品部件的需求

l 分析并确认产品与产品部件的需求

工作产物回顾示例如下：

l 产品需求

l 产品部件需求

l 接口需求

l 功能体系结构

GP2.10 用更高等级的管理回顾状态

用更高层次的管理回顾需求开发过程中的活动、状态、和结果，并解决问题。

GG3 制度化一个已定义的过程

过程被作为一个已定义的过程制度化。

执行的能力

GP3.1 建立一个已定义的过程

建立和维持一个已定义的需求开发过程的描述。

引导（过程的）执行

GP3.2收集改进信息

收集工作产品、度量方法、度量结果以及源于计划和执行需求开发过程的改进信息，从而支持将来的使用以及组织过程和过程域的改进。

连续式/成熟度3-5级

GG4 制度化一个集成的已管理的过程

过程是作为一个集成的已管理的过程被制度化的。

GP4.1 为过程建立集成目标

为需求开发过程建立和维持集成目标从而明确质量和过程执行是基于客户需求和商业目标的。

GP4.2 稳定子过程执行

稳定一个或多个子过程的执行从而确定需求开发过程的能力以达到建立的集成质量和过程执行目标。

GG5 制度化一个已优化的过程

过程是作为一个已优化的过程被制度化的。

GP5.1 确保连续的过程改进

在完成组织的相关商业目标过程中确保连续的需求开发过程改进。

GP5.2 纠正问题的根源原因

在需求开发过程中识别和纠正缺陷和其他问题的根源原因。

仅仅适用于连续式

第二章 过程域——需求开发

需求开发

目的

介绍

相关过程域

实现目标的关键实践

目标的一般实践

执行的保障

执行的能力

引导（过程的）执行

验证（过程的）执行

第二章过程域——需求开发