CMMI需求开发Word格式文档下载.docx
- 文档编号:15196242
- 上传时间:2022-10-28
- 格式:DOCX
- 页数:16
- 大小:24.80KB
CMMI需求开发Word格式文档下载.docx
《CMMI需求开发Word格式文档下载.docx》由会员分享,可在线阅读,更多相关《CMMI需求开发Word格式文档下载.docx(16页珍藏版)》请在冰豆网上搜索。
客户需求可进一步细化为产品及产品组件需求。
除客户需求外,选定的解决方案也可能衍生产品及产品组件需求。
整个过程域中,产品及产品组件的意涵也包括服务及其组件。
在整个产品生命周期中识别并修订需求。
对设计决策、后续的纠正措施,以及产品生命周期各阶段所产生的回馈进行分析,以了解它们对衍生及已配置需求的影响。
需求开发过程域包括三项特定目标。
”开发客户需求」特定目标说明如何定义完整的客户需求,以使用于产品需求开发。
”开发产品需求」特定目标说明如何定义完整的产品和产品组件需求,以使用于产品和产品组件设计。
”分析并确认需求」特定目标说明客户、产品及产品组件需求须执行的必要分析,以定义、衍生及了解需求。
第三项特定目标的特定执行方法,用以辅助前两项特定目标的特定执行方法。
需求开发过程域的过程和技术解决方案过程域的过程,可彼此相互循环互动。
对竞争的备选方案进行分析,以了解、定义及选用各层次的需求。
这些分析活动包括:
分析产品生命周期每阶段的需要和需求,包括:
相关关键人员的需要、操作环境,以及反映所有客户及使用者的期望和满意的因素(如安全性、保密性及负担能力)
开发操作观念
定义必要的功能
功能的定义,也称为“功能分析”,与软件开发的结构化分析不同,也不能假定为功能导向的软件设计。
在面向对象的软件设计里,它相当于定义所谓的“服务”或“方法”。
功能、功能的逻辑群组,以及它们和需求之间关联的定义,就是所谓的”功能架构」。
对产品架构更细层次不断地分析,直到获得足够的细节以进行产品的细部设计、采购及测试。
经由分析需求的结果及操作概念(包括功能性、支持、维护及销毁),制造或生产的概念会产生出更多的衍生需求,包括下列考量:
不同类型的限制
技术的界限
成本和成本因素
时间限制和日程因素
风险
客户或使用者所暗示但未明确陈述的议题的考量
开发者独特的经营考量、规定及法律等所产生的因素
逻辑实体的层次架构(功能及子功能,对象类别及子类别),建立在反复开发的操作观念里。
需求经过细化、衍生,才能配置到该逻辑实体。
需求和逻辑实体再被配置于产品、产品组件、人员、或相关过程。
I在需求开发和分析时,纳入相关关键人员的参与,藉此使他们了解需求的演进过程。
本活动持续向相关关键人员提供保证:
需求已适切定义。
相关过程域
有关管理客户及产品需求、取得需求提供者同意、取得需求执行者承诺及维护追溯性,请参考需求管理过程域,以获得更多信息。
有关如何使用需求开发过程域的输出,以及开发替代方案和设计,以用于细化和衍生需求,请参考技术解决方案过程域,以获得更多信息。
有关验证最终产品是否符合需求,请参考验证过程域,以获得更多信息。
有关确认如何依照客户需要建置产品,请参考确认过程域,以获得更多信息。
有关需求相关风险的识别和管理,请参考风险管理过程域,以获得更多信息。
有关确保重要工作产品的控管,请参考配置管理过程域,以获得更多信息。
.
特定目标及实践摘要
SG1开发客户需求
SP引导需要
SP开发客户需求
SG2开发产品需求
SP建立产品与产品组件需求
SP配置产品组件需求
SP识别接口需求
SG3分析并确认需求
SP建立操作概念及场景
SP建立必要功能的定义
SP分析需求
SP分析需求以取得平衡
SP确认需求
各特定目标的实践
SG1开发客户需求
收集相关干系人的需要、期望、限制及接口,并转换成客户需求.
关键人员(例如:
客户、最终使用者、供货商、建置人员、测试人员、制造人员,与后勤支持人员)的需要,是决定客户需求的基础。
进行关键人员的需要、期望、限制、接口、操作概念,以及产品观念的分析、协调、细化及详细说明,以转换成客户需求。
关键人员的需要、期望、限制及接口,经常被粗略的识别或相互矛盾。
因为必须清楚识别和了解关键人员的需要、期望、限制及界限,在整个项目的生命周期里可使用反复的过程,以达到这目标。
为协助此必要的循环过程,最终用户或客户的代表,通常会加入此过程,以说明其需要并协助解决矛盾。
组织的客户关系或营销部门,以及来自人际工程或支持部门的开发团队成员,可视为此类的代表。
在研拟和解决客户需求时,也应考量客户的外在环境、法规及其他限制
SP引导需要
引导相关干系人提出有关产品生命周期各阶段的需要、期望、限制及接口.
引导不只是积极识别尚未经客户明确提出的新增需求。
新增的需求应描述各种生命周期的活动,以及它们对产品的影响。
引导需要的技术,举例如下:
技术展示
接口管制工作组
技术管制工作组
临时的项目审查
由最终使用者取得的问卷、访谈及操作场景等数据
操作的审查和最终使用者的工作分析
原型和模型
脑力激荡
质量机能展开
市场调查
试用版本的试用
由文件、标准或规格等来源中抽取
观察现行产品、环境及工作过程的样式(patterns)
使用案例(usecases)
经营案例分析
采取反向工程(针对现有产品)
客户满意度调查
可能未被客户识别的需求来源,举例如下:
经营策略
标准
经营环境要求(例:
研究室、测试其他设施、信息科技基础建设等)
技术
现有产品或产品组件(可再用产品组件)
子实践
1.与相关的干系人一起参与,并使用方法,以引导出需求、期望、限制及外部接口。
SP开发客户需求
把相关干系人的需求、期望、限制条件和接口转换成客户需求。
来自相关关键人员的各种输入,须经合并、取得遗漏的信息,以及解决冲突等过程,并记录为客户需求。
客户需求可包括与验证和确认有关的需要、期望及限制。
某些情况来说,客户提供项目的一套需求,或者之前项目活动的需求产出。
以这些情况来说,客户需求与相关关键人员的需要、期望、限制及接口可能有所冲突,所以在冲突适当解决之后,需要转换成被认可的客户需求。
代表产品生命周期的所有阶段的相关关键人员,应包括经营及技术功能。
因此,所有与产品生命周期相关的过程概念,都应与产品的概念同步考量。
客户需求来自信息充分的决策,同时考量需求在经营面与技术面的影响。
典型的工作产品
1.客户需求。
2.执行验证时的客户限制。
3.执行确认时的客户限制。
1.转换关键人员的需要、预期、限制及接口,成为客户需求。
2.定义验证及确认时的限制。
SG2DevelopProductRequirements
对客户需求加以精练和细化,以开发产品和产品组件需求。
分析客户需求并开发操作概念,以衍生更详细和精准的需求,此需求称为“产品与产品组件需求”。
“产品与产品组件需求”说明产品生命周期每一阶段的相关需要。
衍生需求是由限制、对某些隐含议题的考量及某些因素而间接产生,这些议题在客户需求基准中并未明确说明;
而这些因素是基于所选用的架构、设计,以及开发者独特的经营考量等而产生。
需求须以后续的、较低阶的需求及功能架构再检查,并细化优先的产品概念。
配置需求于产品功能及产品组件,包括对象、人员及过程,并记录需求到功能、对象、测试、议题,或其他实体的追溯性。
已配置的需求及功能是组成技术解决方案的基础。
当开发内部组件时,须定义新增的接口,并建立接口需求。
有关维护双向追溯性,请参考需求管理过程域的「维护需求的双向追溯性」特定执行方法,以获得更多信息.
SPEstablishProductandProductComponentRequirements
根据客户需求,建立和维护产品和产品组件的需求。
客户需求可能以客户术语表示,且以较不具技术的方式描述。
产品需求则是以专业术语表示这些客户需求,以用来进行设计的决策。
“质量机能展开”是此转换的范例,它描述客户期望与技术参数的对应关系。
“结实的门”可能对应到尺寸规模大小、重量、适合、湿度及共振频率。
“产品与产品组件需求”强调客户、经营,以及项目目标和相关属性(如有效性和负担能力)的满足。
衍生需求也包括其他生命周期阶段的成本和绩效(如,生产、操作及销毁),以与经营目标兼容。
需求管理过程域涵盖需求变更的管理,而本特定执行方法的“维护”部分,涵盖因已核准的需求变更而引起的需求修改活动。
有关管理需求变更,请参考需求管理过程域,以获得更多信息。
1.衍生需求
2.产品需求
3.产品组件需求
1.以专业术语开发产品与产品组件设计的需求。
针对产品架构设计所需的重要的产品质量和绩效,开发架构需求。
2.由设计决策衍生需求。
有关开发解决方案以产生其他衍生需求,请参考技术解决方案过程域,以获得更多信息。
技术的选用会引进其他的需求。
运用电子学将增加特定技术的需求,如电磁干扰的界限。
3.建立并维护需求间的关连性,并考量在变更管理和需求配置时的影响。
有关维护需求追溯,请参考需求管理过程域,以获得更多信息。
需求间的关连有助于评估变更的影响。
SP分配产品组件需求
为每个产品组件分配需求。
有关配置需求到产品和产品组件,请参考技术解决方案过程域,以获得更多信息。
本执行方法提供信息以定义需求配置,但必须和技术解决方案过程域的执行方法互动,以建立配置需求的解决方案。
上述中所定义的解决方案,其产品组件的需求,包括所配置的产品绩效、设计限制,以及符合需求和有助于生产的合适、形式及功能。
假使较高阶需求的指定绩效归属于两组或以上的产品组件时,该绩效必须进行切割,并单独配置到各个产品组件,就像是衍生需求一样。
典型的工作产品
1.需求配置表
2.暂时性的需求配置
3.设计限制
4.衍生需求
5.衍生需求间的关系细部执行方法
1.分配需求于功能。
2.分配需求于产品组件。
3.配置设计限制于产品组件。
4.记录已配置需求间的关系。
关系包括依赖性,在这情境下,某需求的改变可能会影响其他的需求。
SP识别接口需求
识别接口需求。
定义功能之间(或对象之间)的接口。
功能接口可能衍生出替代方案的开发,替代方案在技术解决方案过程域中描述。
有关接口管理以及产品和产品组件的整合,请参考产品整合过程领域,以获得更多信息。
定义产品架构中所识别之产品与产品组件间的接口需求,并将它们当做产品与产品组件整合的一部分来管制,它们也是架构定义中不可缺少的部分。
1.界面需求
1.识别产品内部及外部的接口(例如:
功能分割或对象之间的接口)。
在设计工作进行的过程中,产品架构可能受技术解决方案过程的影响,而产生产品组件和项目外部组件间的新接口。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- CMMI 需求 开发