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