SG 3 分析并确认需求

需求得到分析与确认。

“分析并确认需求”特定目标中的特定实践，既支持“开发客户需求”特定目标中的需求开发，也支持“开发产品需求”特定目标中的需求开发。与本特定目标相关联的特定实践涵盖需求的分析与确认，并与最终用户的预期环境相关。

分析得到执行，以确定预期的操作环境将会对满足干系人的需要、期望、约束与接口的能力产生什么影响。取决于产品所处的环境，诸如可行性、使命需要、成本约束、潜在的市场规模与采购策略等因素，都应当加以考虑。基于使命与业务驱动因素，在架构方面具有重要性的质量属性得到了识别。必需的功能与质量属性定义也得到了建立。所有规定的产品使用方式得到了考虑。

分析的目的是为了确定那些满足干系人需要、期望与约束的产品概念的候选需求，然后将这些概念转换为需求。与此同时，基于客户的输入与初步的产品概念，用于评价产品有效性的参数得到了确定。需求得到确认，以增加最终产品的表现在使用环境中合乎预期设想的可能性。

SP 3.1 建立操作概念与场景

建立并维护操作概念与相关场景。

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

CMMI模型中，RD过程域的工作产品实例：

1. 操作概念

2. 产品或产品组件的开发、安装、操作、维护与支持概念

3. 废弃概念

4. 用例

5. 时间线场景

6. 新需求

CMMI模型中，RD过程域的子实践：

1. 适当地开发包括操作、安装、开发、维护、支持与废弃的操作概念与场景。

识别并开发场景，其详细程度与干系人的需要、期望与约束相一致，所提议的产品或产品组件在此场景下进行预期的操作。扩充场景，扩充时考虑场景中描述的功能（或其它逻辑实体）的质量属性因素。

2. 定义产品或产品组件将要操作的环境，包括边界与约束。

3. 评审操作概念与场景，以提炼并发现需求。

操作概念与场景的开发是迭代式的过程。应当定期进行评审以确保它们与需求一致。评审可以用走查的形式进行。

4. 随着对产品与产品组件进行选择，开发详细的操作概念，该操作概念定义了产品、最终用户与环境的交互，且满足操作、维护、支持与废弃的需要。

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

建立并维护必需的功能与质量属性的定义。

一种定义必需的功能与质量属性的方法是使用某些称为“功能分析”的方法，去分析场景以描述产品打算要做什么。这一功能描述可以包括行动、顺序、输入、输出或其它沟通产品使用方式的信息。得出的功能、功能的逻辑分组以及其与需求的关联关系的描述被称为功能架构。（见术语表中“功能分析”与“功能架构”的定义。）

近年来这些方法已经通过架构描述语言、方法与工具的引入等不断演进发展，以更充分地处理并描述质量属性的特征，在已定义的功能将如何在产品中进行实现方面，这样的演进发展使得对约束更丰富的（例如：多维度）规格说明成为可能，并便于对需求与技术解决方案进行进一步的分析。某些质量属性将显现出在架构方面的重要性，进而驱动产品架构的开发。这些质量属性所涉及的通常是横向交叉的影响，而可能无法分配至解决方案中更低层次的元素。对质量属性及其基于使命或业务需要的重要性的清晰理解，是设计过程的必不可少的输入。

CMMI模型中，RD过程域的工作产品实例：

1. 必需的功能与质量属性定义

2. 功能架构

3. 活动图与用例

4. 识别了服务或方法的面向对象分析

5. 具有架构重要性的质量属性需求

CMMI模型中，RD过程域的子实践：

1. 确定关键使命与业务驱动因素。

2. 识别可取的功能与质量属性。

如同上一特定实践所描述的那样，通过与相关干系人一起进行各种场景的分析，可以对功能与质量属性进行识别与定义。

3. 基于关键使命与业务驱动因素，确定具有架构重要性的质量属性。

4. 分析最终用户所要求的功能，并确定其数量。

这样的分析可涉及考虑时间关键性功能的时序。

5. 分析需求以识别逻辑或功能划分（例如：子功能）。

6. 依据已建立的准则（例如：相似的功能、相似的质量属性需求、耦合等），将需求分组，以利于需求的分析与专注。

7. 将客户需求分配至功能划分、对象、人员或支持元素，以支持解决方案的整合。

8. 将需求分配至功能与子功能（或其它逻辑实体）。

SP 3.3 分析需求

分析需求以确保其必要性与充分性。

以操作概念与场景为出发点，分析产品在某个层次的需求，以确定它们在满足产品上一层次的目标方面是否必要与充分。分析后的需求进而为产品下一层次的更详细、更精确的需求建立了基础。定义了需求之后，就应当能够理解需求与上一级需求、需求与上一级必需的功能与质量属性定义之间的关系。用于跟踪进度的关键需求也可以进行确定。例如，在开发期间，产品的重量或软件产品的规模可以依据其风险或其对客户的关键程度进行监督。

参阅“验证”过程域，以进一步了解如何建立验证规程与准则。

CMMI模型中，RD过程域的工作产品实例：

1. 需求缺陷报告

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

3. 关键需求

4. 技术性能度量项

CMMI模型中，RD过程域的子实践：

1. 分析干系人需要、期望、约束与外部接口，以将其按照相关的主题组织在一起，并排除冲突。

2. 分析需求以确定其是否满足上一层次需求的目标。

3. 分析需求以确保其是完整的、可行的、可实现的并且是可验证的。

虽然确定某个特定解决方案可行性的是设计，但是本子实践可用于理解哪些需求影响了可行性。

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

5. 识别将在开发期间进行跟踪的技术性能度量项。

参阅“度量与分析”过程域，以进一步了解如何开发并保持用于支持管理信息需要的度量能力。

6. 分析操作概念与场景，以提炼客户需要、约束与接口，并发现新需求。

这一分析可能得出更详细的操作概念与场景，并支持新需求的派生。

SP 3.4 分析需求以达到平衡

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

干系人的需要与约束能处理诸如成本、进度、产品性能或项目绩效、功能、优先顺序、可复用组件、可维护性或风险等事项。

CMMI模型中，RD过程域的工作产品实例：

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

CMMI模型中，RD过程域的子实践：

1. 使用已证明的模型、模拟与原型对如何平衡干系人的需要与约束进行分析。

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

2. 对需求及必需的功能与质量属性定义进行风险评估。

参阅“风险管理”过程域，以进一步了解如何识别并分析风险。

3. 检验产品生命周期概念以评价需求对风险的影响。

4. 评估具有架构重要性的质量属性需求给产品与产品开发成本及风险带来的影响。

当需求给成本与风险的带来的影响似乎超出了预计收益时，应当咨询相关干系人，以确定需要进行哪些变更。举例来说，非常严格的响应时间需求或高可用性需求可能被证明实现起来成本高昂。一旦理解了这样的影响（例如对成本），或许可以放宽这一需求。

SP 3.5 确认需求

确认需求，以确保所做出的产品在最终用户的环境中能如预期执行。

在开发活动的早期就要与最终用户共同进行需求的确认，以获得信心，使得需求能够指导开发，并实现最后的成功确认。这一活动应当与风险管理活动集成在一起。成熟的组织进行需求确认时，通常以更复杂的方式，使用多种技术，并且扩大确认的基础，去包含干系人的其它需要与期望。

用于需求确认的技术的实例有：

• 分析

• 模拟

• 原型

• 演示

CMMI模型中，RD过程域的工作产品实例：

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

CMMI模型中，RD过程域的子实践：

1. 分析需求以确定所获得产品将不能在其预期的使用环境中正确运行的风险。

2. 开发产品表示法（例如：原型、模拟、模型、场景、故事板等），获得相关干系人对此的反馈，以此方式探索需求的充分性与完整性。

参阅“确认”过程域，以进一步了解如何进行确认的准备，并对产品或产品组件进行确认。

3. 随着设计的成熟，在需求确认环境的背景下对其进行评估，以识别确认的问题，并揭示未陈述的需要与客户需求。

【RD过程域相关文章】

CMMI过程域详解-需求开发（RD）之概述

CMMI过程域详解-需求开发（RD）之SG 1

CMMI过程域详解-需求开发（RD）之SG 2

CMMI过程域详解-需求开发（RD）之SG 3