CMMI过程域-（RD）需求开发
上一篇 /
下一篇 2012-06-24 23:02:33
/ 个人分类：CMMI
| 序号 | 实践名称 | 描述 | 技术方法 | 备注 | 工作产品示例 | 子实践 | 相关过程域 |
| SG1 | 开发客户需求 | 收集干系人需要、期望、限制及接口，并转换成客户需求。 | | | | | |
| SP1.1 | 诱导需要 | 诱导干系人提出有关产品生命周期各阶段的需要、期望、限制及接口 | 1.技术展示
2.接口控制工作组
3.技术控制工作组
4.中间时期的项目审查
5.从最终用户获取问卷调查，访谈和情景（运作，维持和发展）
6.操作，维持和发展的演练和最终用户任务分析
7.质量属性与利益相关者启动研讨会
8.原型和模型
9.头脑风暴
10.市场调查
11.适用版本的试用
12.由文档、标准或规格等来源中抽取
13.观察现行产品、环境及工作过程的样式
14.用例
15.提供小增量“垂直截分”的产品功能
16.经营案例分析
17.采取反向工程（针对现有产品）
18.客户满意度调查 | 可能未被客户识别的需求来源：
1.经营策略
2.标准
3.经营环境
4.技术
5.现有产品或产品组件（可复用产品组件）
6.监督管理的规程
| 需求分析引导出的各项活动的结果 | 与相关干系人一起参与，并使用方法，以诱导出需求、期望、限制及外部接口。 | |
| SP1.2 | 将利益共享着的需要转化为客户需求 | 转换干系人的需求、期望、限制及接口为客户需求 | | | 1.客户需求
2.执行验证时的客户限制
3.执行确认时的客户限制 | 1.转换干系人的需要、预期、限制及接口，成为客户需求。
2.建立和维护用户功能和质量属性需求的优先级列表。划分优先级后能够帮助确立项目，迭代，或者增量模型。这种优先级策略确保了至关重要的功能和质量属性尽快得到解决。
3.定义验证及确认时的限制。 | |
| SG2 | 开发产品需求 | 调整并详细说明客户需求，以开发产品级产品组件需求。 | | 配置需求于茶品组件，包括对象、人员及过程。在迭代或者增量开发过程中，可以分配成迭代和增量的获取过程。 | | | |
| SP2.1 | 建立产品和产品组件需求 | 以客户需求为基础，建立并维护产品与产品组件的需求。 | | 质量属性测度的例子包括如下：
在一秒内相应，百分之九十九的时间系统都是可使用的，在不超过一个职员一周的工作量内实现一个变化。
需求之间的关系可以帮助评估变化的影响。 | 1.衍生需求
2.产品需求
3.产品组件需求
4.架构需求，定义约束了产品工件的关系 | 1.以专业术语开发产品与产品组件设计的需求。针对产品架构设计所需的重要的产品质量和绩效，开发架构需求。
2.由设计决策衍生需求。技术的选用会引进其它的需求。
3.开发架构需求捕获重要的质量属性，以及建立产品架构和设计需要的质量属性测度。
4.建立并维护需求间的关联性，并考虑在变更管理和需求配置时的影响。
| |
| SP2.2 | 配置产品组件需求 | 配置产品组件需求 | | 产品架构为如何将产品需求分配给产品组件提供了基准 | 1.需求配置表
2.暂时性的需求配置
3.设计限制
4.衍生需求
5.衍生需求间的关系 | 1.配置需求于功能。
2.配置需求与产品组件和架构。
3.配置设计限制于产品组件和架构。
4.配置需求于交付增量
5.记录已配置需求间的关系。 | 技术解决方案 |
| SP2.3 | 识别接口需求 | 识别接口需求，定义功能之间（或对象之间）的接口。功能接口肯能衍生出替代方案的开发，替代方案在技术解决方案过程域中描述。 | | | 1.接口需求 | 1.识别产品内部及外部的接口。
2.开发确定接口的需求。 | |
| SG3 | 分析并确认需求 | | | | | | |
| SP3.1 | 建立操作概念及场景 | 场景一般而言是指使用产品时可能发生的事件顺序，以明确说明干系人的某些需要。 | | | 1.操作概念
2.产品或产品组件安装、操作、维护及支持概念。
3.销毁概念。
4.使用案例
5.依时间演化的场景
6.新需求 | | |
| SP3.2 | 建立必要的功能定义和质量属性 | 定义需要的功能和质量属性的一种方法是用被有些人成为“功能分析”描述产品的作用，建立分析场景。功能描述可以包括行动，顺序，输入，输出等。 | | | 1.需要的功能和质量属性的定义
2.功能架构
3.活动图和用例
4.对象导向分析和已识别的服务或方法
5.架构上重要的质量属性要求。 | | |
| SP3.3 | 分析需求 | 分析需求以确保其必要性和充分性 | | | 1.需求缺陷报告
2.用来解决缺陷的需求变更建议
3.关键需求
4.技术绩效度量 | | |
| SP3.4 | 分析需求以取得平衡 | 分析需求，并在干系人的需要和时间限制间取得平衡；干系人的需要和限制可说明成本，进度，绩效，功能，再使用的组件、维护能力，或风险 | | | 1.需求相关风险的评价 | | |
| SP3.5 | 确认需求 | 确认需求以确保最终产品在使用者环境下如期的运行。 | | 1.分析
2.模拟
3.原型
4.示范
| 1.分析方法和结果的记录 | | |
收藏
举报
TAG:
