CMMI过程域详解-需求开发（RD）之SG2 开发产品需求

SG 2 开发产品需求

客户需求得到提炼与细化，以开发产品与产品组件需求。

结合操作概念的开发，客户需求得到分析，以衍生出更详细且精确的需求集合，称为“产品与产品组件需求”。产品与产品组件需求解决与产品生命周期各阶段相关联的需要。衍生需求产生自约束；对隐含在客户需求基线中而未明确说明的问题的考虑；由选定的架构、产品生命周期与设计引入的因素；以及开发方独特的业务考虑。伴随每一后续的、低一级的需求集合与架构，需求得到再次检验，并且首选的产品概念得到提炼。

需求得以分配至产品功能与产品组件，包括对象、人员与过程。在迭代式或增量式开发的情况下，需求也会根据客户的优先顺序、技术问题与项目目标分配至那些迭代或增量。需求到功能、对象、测试、问题或其它实体的可追溯性得到文档化。已分配的需求及功能（或其它逻辑实体）是合成技术解决方案的基础；然而，随着架构得到定义或显现，架构成为指导将需求分配至解决方案的最终基础。随着内部组件得到开发，附加的接口得到了提炼，并且接口需求得到了建立。

参阅“需求管理”过程域，以进一步了解如何维护需求的双向可追溯性。

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

依据客户需求，建立并维护产品与产品组件需求。

客户功能需求与质量属性需求可以用客户的术语表达，并且可以是非技术性描述。产品需求则是以技术术语表达的这些需求，并能用于设计决策。这一转换的实例可以在“质量功能展开屋（House of Quality Function Deployment）”的第一步中找到，这一步骤将客户希望映射为技术参数。例如，“实心音效门”可以映射为尺寸、重量、安装匹配、减震与共振频率。产品与产品组件需求处理的是客户的满意度、业务、以及项目目标与关联属性，如有效性与可承担性。衍生需求同时处理其它生命周期阶段（例如：生产、运行、废弃等）与业务目标一致的需要。由已得到批准的需求变更引起需求的修改由本特定实践的“维护”部分覆盖；而需求变更的管理则由“需求管理”过程域覆盖。

参阅“需求管理”过程域，以进一步了解如何管理需求。

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

1. 衍生需求

2. 产品需求

3. 产品组件需求

4. 说明或约束了产品组件之间关系的架构需求

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

1. 使用技术术语开发需求，这些技术术语对产品与产品组件的设计来说是必要的。

2. 对需求进行由设计决策引起的衍生推断。

参阅“技术解决方案”过程域，以进一步了解如何选择产品组件解决方案并进行设计的开发。

技术的选择带来附加的需求。例如，电子器件的使用需要额外的技术上的特定需求，例如电磁干扰限制。诸如架构模式的选择那样的架构决策为产品组件引入额外的衍生需求。例如，分层模式将约束某些产品组件之间的依赖关系。

3. 开发架构需求，这些架构需求捕获了关键的质量属性与为建立产品架构与设计而必要的质量属性度量项。

质量属性度量项的实例有：

• 响应时间小于1 秒

• 系统的可用时间达到99%

• 实现一项变更的工作量不超过1 个人周

4. 建立并维护需求间的关系，以便在变更管理与需求分配时进行考虑。

参阅“需求管理”过程域，以进一步了解如何维护需求的双向可追溯性。

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

SP 2.2 分配产品组件需求

为各产品组件分配需求。

参阅“技术解决方案”过程域，以进一步了解如何选择产品组件的解决方案。

将产品需求分配到产品组件中，产品架构是其基础。对于已定义的解决方案，其产品组件的需求包括产品性能的分配、设计约束、以及为满足需求并便于生产的安装匹配、外形与功能。由上一级需求所规定的某项质量属性可以由多于一个的产品组件所承担，在此情况下，该质量属性有时能作为衍生需求被单独分解到每一产品组件中去，然而有时这一共享的需求却应当直接分配至架构。例如，共享需求至架构的分配将描述性能需求（例如：响应时间）如何在各组件进行划分，以便以端对端的方式解决需求的实现。这一共享需求的概念可以扩展到其它在架构方面具有重要性的质量属性（例如：安全性、可靠性等）。