CMMI—需求开发_cmmi需求管理

一、目的

需求开发（Requirements Development， RD）的目的在于挖掘、分析并建立客户需求、产品需求与产品组件需求。

二、简介

本过程域描述 3 类需求：客户需求、产品需求与产品组件需求。综合起来，这些需求涉及相关干系人的需要，包括与不同的产品生命周期阶段（例如：验收测试准则）和产品属性（例如：响应性、安全性、可靠性、可维护性等）相关的需要。需求还涉及源于设计解决方案（例如：商用现货产品的集成、特定架构模式的使用等）的选择所带来的约束。
所有的开发项目都有需求。需求是设计的基础。需求的开发包括下列活动：
• 客户需要、期望与约束的挖掘、分析、确认与沟通，以获得区分了优先级的客户需求，形成对什么样的需求将能使干系人得到满足的理解
• 干系人需要的收集与协调
• 产品的生命周期需求的开发
• 客户功能性需求与质量属性需求的建立
• 与客户需求一致的产品及产品组件初始需求的建立
本过程域涉及所有的客户需求而不仅仅是产品级需求，原因在于客户也可能提供具体的设计需求。
客户需求要进一步提炼为产品需求与产品组件需求。除客户需求之外，产品需求与产品组件需求产生自选定的设计解决方案。过程域内凡是用到术语“产品”与“产品组件”的地方，其预期的含义还包含服务、服务系统与其组件。
需求的识别与提炼贯穿于产品生命周期的所有阶段。在产品生命周期的每个阶段，都需要分析设计决策、后续纠正措施与反馈等对衍生需求与已分配需求造成的影响。
“需求开发”过程域包含 3 个特定目标。“开发客户需求”特定目标所应对的是定义用于开发产品需求的客户需求集合。“开发产品需求”特定目标所应对的是定义用于设计产品与产品组件的产品需求或产品组件需求。
“分析并确认需求”特定目标所应对的是分析客户需求、产品需求与产品组件需求，以对需求进行定义、衍生并理解。第三个特定目标中的特定实践意图在于辅助前两个特定目标中的特定实践。与“需求开发”过程域相关联的过程以及与“技术解决方案”过程域相关联的过程可以递归地相互作用。
分析工作用于理解、定义并从相互冲突的备选方案中选择所有级别的需求。
这些分析包含下列活动：
• 对产品生命周期的每一阶段的需要及需求的分析，包含相关干系人的需要、操作环境以及反映客户与最终用户的总体期望与满意度的因素，诸如安全性、安保性以及可承担性
• 操作概念开发
 • 必需的功能与质量属性的定义
必需的功能与质量属性的定义描述了产品要做什么。（见术语表中“必需的功能与质量属性的定义”。）该定义可以包含产品的描述、产品的分解与产品的功能划分（或面向对象的分析所称的“服务”或“方法”）。另外，该定义详细说明了产品必需的功能将如何实现的设计依据或约束条件。质量属性应对的是诸如产品可用性、可维护性、易修改性、及时性、吞吐量以及响应性、可靠性、安全性与可缩放性。一些质量属性将显现出在架构方面的重要性，并因此驱动产品架构的开发。这样的分析在产品架构不断细化的层次递进开展，直到具备足够的细节，使得产品的详细设计、采购和测试能够进行。 对需求与操作概念（包括功能、支持、维护与废弃）进行分析后，制造或生产的概念将因此产生更多的衍生需求，所考虑的因素有：
• 不同类型的约束
• 技术限制
• 成本及成本驱动因素
• 时间约束及进度驱动因素
• 风险
• 对客户或最终用户隐含的但未明确说明的问题的考虑
• 由开发者独特的业务考虑、规章与法律等方面所引入的因素随着操作概念的反复演进，逻辑实体的层次结构（例如：功能与子功能、对象类与子类；过程；其它架构实体）得以建立。需求得以提炼、派生并分配到这些逻辑实体。需求与逻辑实体被分配到产品、产品组件、人员或相关联的过程中。在迭代或增量式开发的情况下，需求也将被分配到迭代或增量中。
相关干系人参与到需求开发与分析之中，可以使需求的演化对他们具有可视性。该活动使相关干系人不断确信需求得到妥当地定义。
对于产品线，工程过程（包括需求开发）可在组织中至少两个层级进行应用。在组织级或产品线级，进行“通用性和差异性分析”来帮助挖掘、分析并建立由产品线内各项目使用的核心资产。而在项目级，作为项目工程活动的一部分，项目则根据产品线生产计划使用这些核心资产。
在敏捷环境中，客户需要与想法是以迭代的方式进行挖掘、细化说明、分析并确认的。需求的文档化是以诸如用户故事、场景、用例、 产品工作清单以及迭代的结果（在软件中指可运行的代码）等形式进行的。在一次指定迭代中要处理哪些需求是由风险评估驱动的，并由与产品工作清单中的遗留事项相关联的优先顺序驱动。需求（以及其它产物）的哪些细节需要文档化是由（团队成员之间、团队之间以及后续迭代之间）的协调需要驱动的，并由丢失哪些已有知识的风险来驱动。当客户在团队中时，仍可能需要区分客户文档与产品文档，以便于对多种解决方案进行探索。随着解决方案的显现，对衍生需求的职责被分配给适当的团队。（见第一部分中的“使用敏捷方法时对CMMI 的解读” 。）

本章所涉及的内容：

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 挖掘需要

挖掘干系人对产品生命周期所有阶段的需要、期望、约束与接口。
挖掘活动不仅仅是对需求进行收集，而是通过主动地识别附加的、未由客户明确提供的需求。附加的需求应当解决产品生命周期的各种活动以及其对产品的影响。

挖掘需要的技术实例有：
• 技术演示
• 接口控制工作组
• 技术控制工作组
• 项目中期评审
• 从最终用户取得的问卷调查表、访谈以及（操作的、支持的与开发的）场景
• 操作的、支持的与开发的走查，以及最终用户任务的分析
• 有干系人参加的质量属性挖掘研讨会
• 原型与模型
• 头脑风暴
• 质量功能展开
• 市场调查
• Beta 测试
• 来源于诸如文档、标准或规格说明的信息提取
• 对现有产品、环境与工作流模式的观察
• 用例
• 用户故事
• 产品功能的小规模增量式“垂直片段”交付
• 业务案例分析
• （对遗留产品的） 逆向工程
• 客户满意度调查
客户或许未能识别出的需求，其需求来源的实例有：
• 业务方针
• 标准
• 先前的架构设计决策与原则
• 业务环境需求（例如：实验室、测试与其它设施、信息技术基础设施等）
• 技术
• 遗留产品或产品组件（复用产品组件）
• 法规条文
工作产品实例
1. 需求挖掘活动的结果
子实践
1. 使用方法引导相关干系人，以挖掘需要、期望、约束与外部接口。

SP 1.2 将干系人的需要转换为客户需求

将干系人的需要、期望、约束与接口转换为划分了优先级的客户需求。
随着客户需求的开发与及优先级的区分， 应当合并来自于相关干系人的各种输入，获取缺失的信息并解决矛盾之处。客户需求可以包含与验证和确认相关的需要、期望和约束。
在某些情形下，客户向项目提供需求集合，或需求作为以前项目的活动输出而存在。在这些情形下，客户需求可能与相关干系人的需要、期望、约束与接口相矛盾，在矛盾得到妥善解决后，需要将其转换为经认可的客户需求集合。
代表项目的生命周期所有阶段的相关干系人应当包括业务职能与技术职能。这样，所有与产品相关的生命周期过程的概念就同产品的概念一并得到考虑。客户需求不仅得自于这些需求在技术效果方面的知情决策，而且得自于其在业务方面的知情决策。
工作产品实例
1. 区分了优先级的客户需求
2. 有关执行验证的客户约束
3. 有关执行确认的客户约束
子实践
1. 将干系人需要、期望、约束及接口转换为文档化的客户需求。
2. 建立并维护客户功能需求与质量属性需求的优先顺序。
区分了优先顺序的客户需求有助于确定项目、迭代或增量的范围。这一优先顺序可确保对客户与其他相关干系人来说那些关键的功能需求与质量属性需求得到迅速处理。
3. 定义验证与确认的约束。

SG 2 开发产品需求

客户需求得到提炼与细化，以开发产品与产品组件需求。
结合操作概念的开发，客户需求得到分析，以衍生出更详细且精确的需求集合，称为“产品与产品组件需求”。产品与产品组件需求解决与产品生命周期各阶段相关联的需要。衍生需求产生自约束；对隐含在客户需求基线中而未明确说明的问题的考虑；由选定的架构、产品生命周期与设计引
入的因素；以及开发方独特的业务考虑。伴随每一后续的、低一级的需求集合与架构，需求得到再次检验，并且首选的产品概念得到提炼。
需求得以分配至产品功能与产品组件，包括对象、人员与过程。在迭代式或增量式开发的情况下，需求也会根据客户的优先顺序、技术问题与项目目标分配至那些迭代或增量。需求到功能、对象、测试、问题或其它实体的可追溯性得到文档化。已分配的需求及功能（或其它逻辑实体）是合成
技术解决方案的基础；然而，随着架构得到定义或显现，架构成为指导将需求分配至解决方案的最终基础。随着内部组件得到开发，附加的接口得到了提炼，并且接口需求得到了建立。

SP 2.1 建立产品与产品组件需求

依据客户需求，建立并维护产品与产品组件需求。
客户功能需求与质量属性需求可以用客户的术语表达，并且可以是非技术性描述。产品需求则是以技术术语表达的这些需求，并能用于设计决策。
这一转换的实例可以在“质量功能展开屋（ House of Quality FunctionDeployment）”的第一步中找到，这一步骤将客户希望映射为技术参数。
例如，“实心音效门”可以映射为尺寸、重量、安装匹配、减震与共振频率。
产品与产品组件需求处理的是客户的满意度、业务、以及项目目标与关联属性，如有效性与可承担性。
衍生需求同时处理其它生命周期阶段（例如：生产、运行、废弃等）与业务目标一致的需要。
由已得到批准的需求变更引起需求的修改由本特定实践的“维护”部分覆盖；而需求变更的管理则由“需求管理”过程域覆盖。
参阅“需求管理”过程域以进一步了解如何管理需求。
工作产品实例
1. 衍生需求
2. 产品需求
3. 产品组件需求
4. 说明或约束了产品组件之间关系的架构需求
子实践
1. 使用技术术语开发需求，这些技术术语对产品与产品组件的设计来说是必要的。
2. 对需求进行由设计决策引起的衍生推断。
参阅“技术解决方案”过程域以进一步了解如何选择产品组件解决方案并进行设计的开发。
技术的选择带来附加的需求。例如，电子器件的使用需要额外的技术上的特定需求，例如电磁干扰限制。
诸如架构模式的选择那样的架构决策为产品组件引入额外的衍生需求。
例如，分层模式将约束某些产品组件之间的依赖关系。
3. 开发架构需求，这些架构需求捕获了关键的质量属性与为建立产品架构与设计而必要的质量属性度量项。
质量属性度量项的实例有：
• 响应时间小于 1 秒
• 系统的可用时间达到 99%
• 实现一项变更的工作量不超过 1 个人周
4. 建立并维护需求间的关系，以便在变更管理与需求分配时进行考虑。

SP 2.2 分配产品组件需求

为各产品组件分配需求。
参阅“技术解决方案”过程域以进一步了解如何选择产品组件的解决方案。将产品需求分配到产品组件中，产品架构是其基础。对于已定义的解决方案，其产品组件的需求包括产品性能的分配、设计约束、以及为满足需求并便于生产的安装匹配、外形与功能。由上一级需求所规定的某项质量属
性可以由多于一个的产品组件所承担，在此情况下，该质量属性有时能作为衍生需求被单独分解到每一产品组件中去，然而有时这一共享的需求却应当直接分配至架构。例如，共享需求至架构的分配将描述性能需求（例如：响应时间）如何在各组件进行划分，以便以端对端的方式解决需求的
实现。这一共享需求的概念可以扩展到其它在架构方面具有重要性的质量属性（例如：安全性、可靠性等）。
工作产品实例
1. 需求分配单
2. 临时的需求分配
3. 设计约束
4. 衍生需求
5. 衍生需求之间的关系
子实践
1. 将需求分配至功能。
2. 将需求分配至产品组件与架构。
3. 将设计约束分配至产品组件及架构。
4. 将需求分配至交付增量。
5. 将已分配需求之间的关系文档化。 
这样的关系包括某一需求内的变更可能影响其它需求的依赖关系。

SP 2.3 识别接口需求

识别接口需求。
功能之间（或者是对象或其它逻辑实体之间）的接口进行了识别。接口可以驱动在“技术解决方案”过程域中描述的备选解决方案的开发。
参阅“产品集成”过程域以进一步了解如何确保接口的兼容性。
在产品架构中识别的产品之间或产品组件之间的接口需求进行了定义。它们作为产品集成与产品组件集成的一部分受到控制，并且是架构定义的必不可少的一部分。
工作产品实例
1. 接口需求
子实践
1. 识别产品的外部接口以及产品的内部接口（例如：功能划分之间或对象之间）。
随着设计的进展，技术解决方案过程会改变产品架构，从而创建产品组件与产品外部组件之间的新接口。
与产品相关的生命周期过程的接口也应当进行识别。
这些接口的实例有测试设备的接口、传输系统的接口、支持系统的接口与制造设施的接口。
2. 开发已识别接口的需求。

SG 3 分析并确认需求

需求得到分析与确认。
“分析并确认需求”特定目标中的特定实践既支持“开发客户需求”特定目标中的需求开发，也支持“开发产品需求”特定目标中的需求开发。与本特定目标相关联的特定实践涵盖需求的分析与确认，并与最终用户的预期环境相关。
分析得到执行，以确定预期的操作环境将会对满足干系人的需要、期望、约束与接口的能力产生什么影响。取决于产品所处的环境，诸如可行性、使命需要、成本约束、潜在的市场规模与采购策略等因素，都应当加以考虑。基于使命与业务驱动因素，在架构方面具有重要性的质量属性得到了
识别。必需的功能与质量属性定义也得到了建立。所有规定的产品使用方式得到了考虑。
分析的目的是为了确定那些满足干系人需要、期望与约束的产品概念的候选需求，然后将这些概念转换为需求。与此同时，基于客户的输入与初步的产品概念，用于评价产品有效性的参数得到了确定。
需求得到确认，以增加最终产品的表现在使用环境中合乎预期设想的可能性。

SP 3.1 建立操作概念与场景

建立并维护操作概念与相关场景。
典型情况下，场景是可能发生在产品的开发、使用或支持时的事件序列，用于明确干系人在某些功能或质量属性方面的需要。与此相对，产品的操作概念通常既依赖于设计解决方案，也依赖于场景。例如，基于卫星的通信产品的操作概念与基于陆上通信线的通信产品的操作概念就有非常大
的不同。由于在准备初步的操作概念时备选解决方案往往还没有得到定义，这时通过开发概念性的解决方案供分析需求时使用。在制定解决方案决策时操作概念被进一步提炼，并且更低层次的详细需求得到了开发。
正如产品的设计决策能成为产品组件的需求，操作概念也能成为产品组件的场景（需求）。对操作概念与场景进行演化以便于产品组件解决方案的选择，当实现这样的解决方案后，它将能够满足产品的预期用途，或便于其开发与维持。不管是怎样的工程学科，操作概念与场景都记录了产品组
件与环境、最终用户和其它产品组件之间的交互。这些交互的文档记录应体现操作、产品开发、部署、交付、支持（包括维护与维持）、培训与废弃在内的所有模式和状态。
可以开发场景以应对操作、维持、开发或其它事件序列。

工作产品实例
1. 操作概念
2. 产品或产品组件的开发、安装、操作、维护与支持概念
3. 废弃概念
4. 用例
5. 时间线场景
6. 新需求
子实践
1. 适当地开发包括操作、安装、开发、维护、支持与废弃的操作概念与场景。
识别并开发场景，其详细程度与干系人的需要、期望与约束相一致，所提议的产品或产品组件在此场景下进行预期的操作。
扩充场景，扩充时考虑场景中描述的功能（或其它逻辑实体）的质量属性因素。
2. 定义产品或产品组件将要操作的环境，包括边界与约束。
3. 评审操作概念与场景，以提炼并发现需求。
操作概念与场景的开发是迭代式的过程。应当定期进行评审以确保它们与需求一致。评审可以用走查的形式进行。
4. 随着对产品与产品组件进行选择，开发详细的操作概念，该操作概念定义了产品、最终用户与环境的交互，且满足操作、维护、支持与废弃的需要。

SP 3.2 建立必需的功能与质量属性的定义

建立并维护必需的功能与质量属性的定义。
一种定义必需的功能与质量属性的方法是使用某些称为“功能分析”的方法，去分析场景以描述产品打算要做什么。这一功能描述可以包括行动、顺序、输入、输出或其它沟通产品使用方式的信息。得出的功能、功能的逻辑分组以及其与需求的关联关系的描述被称为功能架构。（见术语表中“功能分析”与“功能架构”的定义。）
近年来这些方法已经通过架构描述语言、方法与工具的引入等不断演进发展，以更充分地处理并描述质量属性的特征，在已定义的功能将如何在产品中进行实现方面，这样的演进发展使得对约束更丰富的（例如：多维度）规格说明成为可能，并便于对需求与技术解决方案进行进一步的分析。某些质量属性将显现出在架构方面的重要性，进而驱动产品架构的开发。这些质量属性所涉及的通常是横向交叉的影响，而可能无法分配至解决方案中更低层次的元素。对质量属性及其基于使命或业务需要的重要性的清晰理解，是设计过程的必不可少的输入。
工作产品实例
1. 必需的功能与质量属性定义
2. 功能架构
3. 活动图与用例
4. 识别了服务或方法的面向对象分析
5. 具有架构重要性的质量属性需求
子实践
1. 确定关键使命与业务驱动因素。
2. 识别可取的功能与质量属性。
如同上一特定实践所描述的那样，通过与相关干系人一起进行各种场景的分析，可以对功能与质量属性进行识别与定义。
3. 基于关键使命与业务驱动因素，确定具有架构重要性的质量属性。
4. 分析最终用户所要求的功能，并确定其数量。
这样的分析可涉及考虑时间关键性功能的时序。
5. 分析需求以识别逻辑或功能划分（例如：子功能）。
6. 依据已建立的准则（例如：相似的功能、相似的质量属性需求、耦合等），将需求分组，以利于需求的分析与专注。
7. 将客户需求分配至功能划分、对象、人员或支持元素，以支持解决方案的整合。
8. 将需求分配至功能与子功能（或其它逻辑实体）。

SP 3.3 分析需求

分析需求以确保其必要性与充分性。
以操作概念与场景为出发点，分析产品在某个层次的需求，以确定它们在满足产品上一层次的目标方面是否必要与充分。分析后的需求进而为产品下一层次的更详细、更精确的需求建立了基础。
定义了需求之后，就应当能够理解需求与上一级需求、需求与上一级必需的功能与质量属性定义之间的关系。用于跟踪进度的关键需求也可以进行确定。例如，在开发期间，产品的重量或软件产品的规模可以依据其风险或其对客户的关键程度进行监督。
参阅“验证”过程域以进一步了解如何建立验证规程与准则。
工作产品实例
1. 需求缺陷报告
2. 为解决缺陷而提议的需求变更
3. 关键需求
4. 技术性能度量项
子实践
1. 分析干系人需要、期望、约束与外部接口，以将其按照相关的主题组织在一起，并排除冲突。
2. 分析需求以确定其是否满足上一层次需求的目标。
3. 分析需求以确保其是完整的、可行的、可实现的并且是可验证的。
虽然确定某个特定解决方案可行性的是设计，但是本子实践可用于理解哪些需求影响了可行性。
4. 识别对成本、进度、性能或风险有重大影响的关键需求。
5. 识别将在开发期间进行跟踪的技术性能度量项。
参阅“度量与分析”过程域以进一步了解如何开发并保持用于支持管理
信息需要的度量能力。
6. 分析操作概念与场景，以提炼客户需要、约束与接口，并发现新需求。
这一分析可能得出更详细的操作概念与场景，并支持新需求的派生。

SP 3.4 分析需求以达到平衡

分析需求以平衡干系人的需要与约束。
干系人的需要与约束能处理诸如成本、进度、产品性能或项目绩效、功能、优先顺序、可复用组件、可维护性或风险等事项。
工作产品实例
1. 与需求相关的风险评估
子实践
1. 使用已证明的模型、模拟与原型对如何平衡干系人的需要与约束进行分析。
分析的结果可用于降低产品的成本与产品开发的风险。
2. 对需求及必需的功能与质量属性定义进行风险评估。
参阅“风险管理”过程域以进一步了解如何识别并分析风险。
3. 检验产品生命周期概念以评价需求对风险的影响。
4. 评估具有架构重要性的质量属性需求给产品与产品开发成本及风险带来的影响。
当需求给成本与风险的带来的影响似乎超出了预计收益时，应当咨询相关干系人，以确定需要进行哪些变更。
举例来说，非常严格的响应时间需求或高可用性需求可能被证明实现起来成本高昂。一旦理解了这样的影响（例如对成本），或许可以放宽这一需求。

SP 3.5 确认需求

确认需求，以确保所做出的产品在最终用户的环境中能如预期执行。
在开发活动的早期就要与最终用户共同进行需求的确认，以获得信心，使得需求能够指导开发，并实现最后的成功确认。这一活动应当与风险管理活动集成在一起。成熟的组织进行需求确认时，通常以更复杂的方式，使用多种技术，并且扩大确认的基础，去包含干系人的其它需要与期望。
用于需求确认的技术的实例有：
• 分析
• 模拟
• 原型
• 演示
工作产品实例
1. 分析方法与结果的文档记录

子实践
1. 分析需求以确定所获得产品将不能在其预期的使用环境中正确运行的风险。
2. 开发产品表示法（例如：原型、模拟、模型、场景、故事板等），获得相关干系人对此的反馈，以此方式探索需求的充分性与完整性。
参阅“确认”过程域以进一步了解如何进行确认的准备，并对产品或产品组件进行确认。
3. 随着设计的成熟，在需求确认环境的背景下对其进行评估，以识别确认的问题，并揭示未陈述的需要与客户需求。