SG 1 开发客户需求

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

干系人（例如：客户、最终用户、供方、建造方、测试方、制造方、后勤支持人员）的需要是确定客户需求的基础。干系人需要、期望、约束、接口、操作概念与产品概念得到分析、协调、提炼并细化，以转换为客户需求集合。

干系人的需要、期望、约束与接口常常识别不充分或相互冲突。由于干系人需要、期望、约束与限制应当得到清晰识别并理解，为达成这一目的，在项目的生命期中使用了迭代式的过程。为促进必要的互动，最终用户或客户的代理人经常地参与进来代表其需要，来帮助冲突的解决。组织的客关系部分或市场部分与来自人因工程学科或支持学科的开发团队成员一样，都可作为代理人。当建立并解决客户需求的集合时，环境、法律以及其他约束也应当得到考虑。

SP 1.1 挖掘需要

挖掘干系人对产品生命周期所有阶段的需要、期望、约束与接口。

挖掘活动不仅仅是对需求进行收集，而是通过主动地识别附加的、未由客户明确提供的需求。附加的需求应当解决产品生命周期的各种活动以及其对产品的影响。

挖掘需要的技术实例有：

• 技术演示

• 接口控制工作组

• 技术控制工作组

• 项目中期评审

• 从最终用户取得的问卷调查表、访谈以及（操作的、支持的与开发的）场景

• 操作的、支持的与开发的走查，以及最终用户任务的分析

• 有干系人参加的质量属性挖掘研讨会

• 原型与模型

• 头脑风暴

• 质量功能展开

• 市场调查

• Beta 测试

• 来源于诸如文档、标准或规格说明的信息提取

• 对现有产品、环境与工作流模式的观察

• 用例

• 用户故事

• 产品功能的小规模增量式“垂直片段”交付

• 业务案例分析

• （对遗留产品的）逆向工程

• 客户满意度调查

客户或许未能识别出的需求，其需求来源的实例有：

• 业务方针

• 标准

• 先前的架构设计决策与原则

• 业务环境需求（例如：实验室、测试与其它设施、信息技术基础设施等）

• 技术

• 遗留产品或产品组件（复用产品组件）

• 法规条文

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

1. 需求挖掘活动的结果

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

1. 使用方法引导相关干系人，以挖掘需要、期望、约束与外部接口。

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

将干系人的需要、期望、约束与接口转换为划分了优先级的客户需求。

随着客户需求的开发与及优先级的区分，应当合并来自于相关干系人的各种输入，获取缺失的信息并解决矛盾之处。客户需求可以包含与验证和确认相关的需要、期望和约束。

在某些情形下，客户向项目提供需求集合，或需求作为以前项目的活动输出而存在。在这些情形下，客户需求可能与相关干系人的需要、期望、约束与接口相矛盾，在矛盾得到妥善解决后，需要将其转换为经认可的客户需求集合。

代表项目的生命周期所有阶段的相关干系人应当包括业务职能与技术职能。这样，所有与产品相关的生命周期过程的概念就同产品的概念一并得到考虑。客户需求不仅得自于这些需求在技术效果方面的知情决策，而且得自于其在业务方面的知情决策。

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

1. 区分了优先级的客户需求

2. 有关执行验证的客户约束

3. 有关执行确认的客户约束

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

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

2. 建立并维护客户功能需求与质量属性需求的优先顺序。

区分了优先顺序的客户需求有助于确定项目、迭代或增量的范围。这一优先顺序可确保对客户与其他相关干系人来说那些关键的功能需求与质量属性需求得到迅速处理。

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

【RD过程域相关文章】

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

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

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

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