CMMI需求开发之欧阳物创编.docx
- 文档编号:26610264
- 上传时间:2023-06-20
- 格式:DOCX
- 页数:20
- 大小:23.82KB
CMMI需求开发之欧阳物创编.docx
《CMMI需求开发之欧阳物创编.docx》由会员分享,可在线阅读,更多相关《CMMI需求开发之欧阳物创编.docx(20页珍藏版)》请在冰豆网上搜索。
CMMI需求开发之欧阳物创编
需求开发
时间:
2021.02.07
命题人:
欧阳物
成熟度3级的工程过程域
目的
需求开发(RequirementsDevelopment,RD)的目的,在于产出并分析客户、产品及产品组件的需求。
业界注释
本过程域描述客户、产品及产品组件等三种需求,这些需求说明相关关键人员的需要,包括与产品生命周期各阶段(如,验收测试准则)及产品属性(如,安全性、可靠性、与维护能力等)有关的需要。
需求也包括选择某设计解决方案而产生的限制条件。
例如:
与现成品整合的需求。
所有开发项目都有需求,从项目于维护活动的项目案例来看,产品或产品组件的变更,是基于现有需求、设计、或实作的变更。
需求变更可能来自顾客或用户所记载的变更请求单,或来自于需求开发过程的新需求形式。
不论需求来源或型式,变更所驱动的维护活动也要加以管理。
需求是设计的基础,需求的开发包括下列活动:
∙引导、分析、验证,以及沟通客户的需要、期望及限制,以获得客户需求,并达成关键人员的共识
∙搜集和协调关键人员的需要
∙开发产品的生命周期需求
∙建立客户需求
∙建立与客户需求一致的原始产品及产品组件需
因为客户也可能提出特定的设计需求,本过程域讨论所有客户的需求,而非局限于产品层次的需求。
客户需求可进一步细化为产品及产品组件需求。
除客户需求外,选定的解决方案也可能衍生产品及产品组件需求。
整个过程域中,产品及产品组件的意涵也包括服务及其组件。
在整个产品生命周期中识别并修订需求。
对设计决策、后续的纠正措施,以及产品生命周期各阶段所产生的回馈进行分析,以了解它们对衍生及已配置需求的影响。
需求开发过程域包括三项特定目标。
”开发客户需求」特定目标说明如何定义完整的客户需求,以使用于产品需求开发。
”开发产品需求」特定目标说明如何定义完整的产品和产品组件需求,以使用于产品和产品组件设计。
”分析并确认需求」特定目标说明客户、产品及产品组件需求须执行的必要分析,以定义、衍生及了解需求。
第三项特定目标的特定执行方法,用以辅助前两项特定目标的特定执行方法。
需求开发过程域的过程和技术解决方案过程域的过程,可彼此相互循环互动。
对竞争的备选方案进行分析,以了解、定义及选用各层次的需求。
这些分析活动包括:
∙分析产品生命周期每阶段的需要和需求,包括:
相关关键人员的需要、操作环境,以及反映所有客户及使用者的期望和满意的因素(如安全性、保密性及负担能力)
∙开发操作观念
∙定义必要的功能
功能的定义,也称为“功能分析”,与软件开发的结构化分析不同,也不能假定为功能导向的软件设计。
在面向对象的软件设计里,它相当于定义所谓的“服务”或“方法”。
功能、功能的逻辑群组,以及它们和需求之间关联的定义,就是所谓的”功能架构」。
对产品架构更细层次不断地分析,直到获得足够的细节以进行产品的细部设计、采购及测试。
经由分析需求的结果及操作概念(包括功能性、支持、维护及销毁),制造或生产的概念会产生出更多的衍生需求,包括下列考量:
∙不同类型的限制
∙技术的界限
∙成本和成本因素
∙时间限制和日程因素
∙风险
∙客户或使用者所暗示但未明确陈述的议题的考量
∙开发者独特的经营考量、规定及法律等所产生的因素
逻辑实体的层次架构(功能及子功能,对象类别及子类别),建立在反复开发的操作观念里。
需求经过细化、衍生,才能配置到该逻辑实体。
需求和逻辑实体再被配置于产品、产品组件、人员、或相关过程。
I在需求开发和分析时,纳入相关关键人员的参与,藉此使他们了解需求的演进过程。
本活动持续向相关关键人员提供保证:
需求已适切定义。
相关过程域
有关管理客户及产品需求、取得需求提供者同意、取得需求执行者承诺及维护追溯性,请参考需求管理过程域,以获得更多信息。
有关如何使用需求开发过程域的输出,以及开发替代方案和设计,以用于细化和衍生需求,请参考技术解决方案过程域,以获得更多信息。
有关验证最终产品是否符合需求,请参考验证过程域,以获得更多信息。
有关确认如何依照客户需要建置产品,请参考确认过程域,以获得更多信息。
有关需求相关风险的识别和管理,请参考风险管理过程域,以获得更多信息。
有关确保重要工作产品的控管,请参考配置管理过程域,以获得更多信息。
.
特定目标及实践摘要
SG1开发客户需求
SP1.1引导需要
SP1.2开发客户需求
SG2开发产品需求
SP2.1建立产品与产品组件需求
SP2.2配置产品组件需求
SP2.3识别接口需求
SG3分析并确认需求
SP3.1建立操作概念及场景
SP3.2建立必要功能的定义
SP3.3分析需求
SP3.4分析需求以取得平衡
SP3.5确认需求
各特定目标的实践
SG1开发客户需求
收集相关干系人的需要、期望、限制及接口,并转换成客户需求.
关键人员(例如:
客户、最终使用者、供货商、建置人员、测试人员、制造人员,与后勤支持人员)的需要,是决定客户需求的基础。
进行关键人员的需要、期望、限制、接口、操作概念,以及产品观念的分析、协调、细化及详细说明,以转换成客户需求。
关键人员的需要、期望、限制及接口,经常被粗略的识别或相互矛盾。
因为必须清楚识别和了解关键人员的需要、期望、限制及界限,在整个项目的生命周期里可使用反复的过程,以达到这目标。
为协助此必要的循环过程,最终用户或客户的代表,通常会加入此过程,以说明其需要并协助解决矛盾。
组织的客户关系或营销部门,以及来自人际工程或支持部门的开发团队成员,可视为此类的代表。
在研拟和解决客户需求时,也应考量客户的外在环境、法规及其他限制
.
SP1.1引导需要
引导相关干系人提出有关产品生命周期各阶段的需要、期望、限制及接口.
引导不只是积极识别尚未经客户明确提出的新增需求。
新增的需求应描述各种生命周期的活动,以及它们对产品的影响。
引导需要的技术,举例如下:
技术展示
接口管制工作组
技术管制工作组
临时的项目审查
由最终使用者取得的问卷、访谈及操作场景等数据
操作的审查和最终使用者的工作分析
原型和模型
脑力激荡
质量机能展开
市场调查
试用版本的试用
由文件、标准或规格等来源中抽取
观察现行产品、环境及工作过程的样式(patterns)
使用案例(usecases)
经营案例分析
采取反向工程(针对现有产品)
客户满意度调查
可能未被客户识别的需求来源,举例如下:
经营策略
标准
经营环境要求(例:
研究室、测试其他设施、信息科技基础建设等)
技术
现有产品或产品组件(可再用产品组件)
子实践
1.与相关的干系人一起参与,并使用方法,以引导出需求、期望、限制及外部接口。
SP1.2开发客户需求
把相关干系人的需求、期望、限制条件和接口转换成客户需求。
来自相关关键人员的各种输入,须经合并、取得遗漏的信息,以及解决冲突等过程,并记录为客户需求。
客户需求可包括与验证和确认有关的需要、期望及限制。
某些情况来说,客户提供项目的一套需求,或者之前项目活动的需求产出。
以这些情况来说,客户需求与相关关键人员的需要、期望、限制及接口可能有所冲突,所以在冲突适当解决之后,需要转换成被认可的客户需求。
代表产品生命周期的所有阶段的相关关键人员,应包括经营及技术功能。
因此,所有与产品生命周期相关的过程概念,都应与产品的概念同步考量。
客户需求来自信息充分的决策,同时考量需求在经营面与技术面的影响。
典型的工作产品
1.客户需求。
2.执行验证时的客户限制。
3.执行确认时的客户限制。
子实践
1.转换关键人员的需要、预期、限制及接口,成为客户需求。
2.定义验证及确认时的限制。
SG2DevelopProductRequirements
对客户需求加以精练和细化,以开发产品和产品组件需求。
分析客户需求并开发操作概念,以衍生更详细和精准的需求,此需求称为“产品与产品组件需求”。
“产品与产品组件需求”说明产品生命周期每一阶段的相关需要。
衍生需求是由限制、对某些隐含议题的考量及某些因素而间接产生,这些议题在客户需求基准中并未明确说明;而这些因素是基于所选用的架构、设计,以及开发者独特的经营考量等而产生。
需求须以后续的、较低阶的需求及功能架构再检查,并细化优先的产品概念。
配置需求于产品功能及产品组件,包括对象、人员及过程,并记录需求到功能、对象、测试、议题,或其他实体的追溯性。
已配置的需求及功能是组成技术解决方案的基础。
当开发内部组件时,须定义新增的接口,并建立接口需求。
有关维护双向追溯性,请参考需求管理过程域的「维护需求的双向追溯性」特定执行方法,以获得更多信息.
SP2.1EstablishProductandProductComponentRequirements
根据客户需求,建立和维护产品和产品组件的需求。
客户需求可能以客户术语表示,且以较不具技术的方式描述。
产品需求则是以专业术语表示这些客户需求,以用来进行设计的决策。
“质量机能展开”是此转换的范例,它描述客户期望与技术参数的对应关系。
例如:
“结实的门”可能对应到尺寸规模大小、重量、适合、湿度及共振频率。
“产品与产品组件需求”强调客户、经营,以及项目目标和相关属性(如有效性和负担能力)的满足。
衍生需求也包括其他生命周期阶段的成本和绩效(如,生产、操作及销毁),以与经营目标兼容。
.
需求管理过程域涵盖需求变更的管理,而本特定执行方法的“维护”部分,涵盖因已核准的需求变更而引起的需求修改活动。
有关管理需求变更,请参考需求管理过程域,以获得更多信息。
.
典型的工作产品
1.衍生需求
2.产品需求
3.产品组件需求
子实践
1.以专业术语开发产品与产品组件设计的需求。
针对产品架构设计所需的重要的产品质量和绩效,开发架构需求。
2.由设计决策衍生需求。
有关开发解决方案以产生其他衍生需求,请参考技术解决方案过程域,以获得更多信息。
.
技术的选用会引进其他的需求。
例如:
运用电子学将增加特定技术的需求,如电磁干扰的界限。
3.建立并维护需求间的关连性,并考量在变更管理和需求配置时的影响。
有关维护需求追溯,请参考需求管理过程域,以获得更多信息。
需求间的关连有助于评估变更的影响。
SP2.2分配产品组件需求
为每个产品组件分配需求。
有关配置需求到产品和产品组件,请参考技术解决方案过程域,以获得更多信息。
本执行方法提供信息以定义需求配置,但必须和技术解决方案过程域的执行方法互动,以建立配置需求的解决方案。
上述中所定义的解决方案,其产品组件的需求,包括所配置的产品绩效、设计限制,以及符合需求和有助于生产的合适、形式及功能。
假使较高阶需求的指定绩效归属于两组或以上的产品组件时,该绩效必须进行切割,并单独配置到各个产品组件,就像是衍生需求一样。
.
典型的工作产品
1.需求配置表
2.暂时性的需求配置
3.设计限制
4.衍生需求
5.衍生需求间的关系细部执行方法
子实践
1.分配需求于功能。
2.分配需求于产品组件。
3.配置设计限制于产品组件。
4.记录已配置需求间的关系。
关系包括依赖性,在这情境下,某需求的改变可能会影响其他的需求。
SP2.3识别接口需求
识别接口需求。
定义功能之间(或对象之间)的接口。
功能接口可能衍生出替代方案的开发,替代方案在技术解决方案过程域中描述。
有关接口管理以及产品和产品组件的整合,请参考产品整合过程领域,以获得更多信息。
定义产品架构中所识别之产品与产品组件间的接口需求,并将它们当做产品与产品组件整合的一部分来管制,它们也是架构定义中不可缺少的部分。
典型的工作产品
1.界面需求
子实践
1.识别产品内部及外部的接口(例如:
功能分割或对象之间的接口)。
.
在设计工作进行的过程中,产品架构可能受技术解决方案过程的影响,而产生产品组件和项目外部组件间的新接口。
必须识别产品有关的生命周期过程的接口。
与测试设备、传输系统、支持系统及制造设施之间的接口,都属于这类接口。
.
2.开发已识别界面的需求。
有关在设计过程中,如何产生接口需求,请参考技术解决方案过程域,以获得更多信息。
例如以软件的来源、目的地、刺激及数据特征,和硬件的电子及机械的特征,来定义接口需求。
SG3分析并确认需求
对需求进行分析和确认,开发需求功能性的定义。
「分析并确认需求」特定目标的特定执行方法,支持「开发客户需求」和「开发产品需求」两个特定目标的需求开发过程。
本特定目标的特定执行方法涵盖需求的分析,以及确认需求是否符合使用者预期。
执行分析,以决定为求满足关键人员的需要、期望、限制及接口,对原计划的操作环境会产生哪些影响。
视产品的范围而定,可行性、任务需要、经费限制、市场潜力及采购策略等都必须纳入考量,并建立必要功能的定义。
所有产品的特定使用形式均应考量,并产生对时间敏感的功能顺序的时间点分析。
分析的目的,在于决定可满足关键人员需要、期望及限制的产品概念的可能需求,再将这些概念转换为需求。
与此活动同时进行的是,依据客户的输入和初步的产品概念,决定用以评估产品有效性的参数。
确认需求,以增加最终产品在使用环境中,可按照期望运作的可能性。
SP3.1建立操作概念和相关的场景
建立和维护操作概念和相关的场景。
场景一般而言是指使用产品时可能发生的事件顺序,以明确说明关键人员的某些需要。
相对的,产品的操作概念通常是依据设计方案和场景而来。
例如:
卫星的通讯产品与地面的通讯产品,它们的操作概念是不同的。
在研拟原始操作概念时,其替代方案通常尚未定义。
所以,在需求分析时,开发概念性的解决方案。
在进行解决方案的决策时,细化操作概念,进而开发出细部的需求。
正如某产品的设计决策可能变成产品组件需求,操作概念也可能变成产品组件的场景(需求)。
开发操作概念及场景逐步开发,以利产品组件解决方法的选择,使得在实作后将满足产品的预期使用。
不管哪一种工程,操作概念及场景描述了产品组件与环境、用户,及其他产品组件的互动关系。
包括营运、产品推展、交付、支持(含维护及营运)、训练、处置,以及所有的模式和状态等相关的操作概念与场景,都应予以描述。
如果操作顺序用以表达客户需求而非操作概念,则场景可能包含了操作顺序。
典型的工作产品
1.操作概念
2.产品或产品组件安装、操作、维护及支持概念
3.销毁概念
4.使用案例
5.依时间演化的场景
6.新需求细部执行
子实践
1.开发操作概念和场景,包括适当的功能、绩效、维护、支持及销毁。
识别并开发场景,此场景须与关键人员各细部层级的需要、预期及限制一致。
经此建议的产品或产品组件应可如预期运作。
.
2.定义产品或产品组件的操作环境,包括界限和限制。
3.审查操作概念和场景,以细化需求并发现新需求。
操作概念和场景的开发是个反复的过程。
应定期举行审查,以确保其结果与需求一致。
审查可采用逐步审查的形式。
4.产品与产品组件一经选定,就开发详细的操作概念,以定义产品、最终用户及环境的互动,并满足操作、维护、支持及销毁的需要。
SP3.2建立必要的功能定义
建立和维护需求的功能性的定义。
功能的定义,也就是所谓的“功能分析”,描述哪些是产品预期该做的,包括,行动、顺序、输入、输出,或其他说明如何使用产品的信息。
功能分析与软件开发的结构化分析不同,也不能假定为功能导向的软件设计。
在面向对象的软件设计里,它相当于定义所谓的服务或方法。
功能、功能的逻辑群组,以及它们和需求的关连的定义,就是所谓的「功能架构」。
有关「功能架构」的定义,请参见词汇。
典型的工作产品
1.功能架构
2.活动图和使用案例
3.面向对象分析和已识别的服务或方法细部执行方法
子实践
1.分析和量化最终用户需要的功能.
2.分析需求,以识别逻辑或功能分割(如子功能)。
3.依已建立的准则(如类似的功能、绩效或耦合),将需求分割成群组,以促进和专注于需求分析。
4.在产品开发的整个过程,考量具有时效性的功能的顺序。
5.分配客户需求于功能分割、对象、人员或支持组件,以支持解决方案的综合。
6.分配功能及绩效需求于功能及子功能。
SP3.3分析需求
分析需求,以确保其必要性和充分性。
在操作概念和场景的说明下,分析在产品架构某一阶的需求,以决定其是否必要且可满足较高阶的目标。
经过分析的需求就变成产品架构中较低阶需求的基础,而较低阶的需求通常是更详细且精准的。
定义需求时,必须能了解它与更高阶需求和已定义功能的关系。
决定应识别哪些需求,以追踪技术的进展,也是重要的行动之一。
例如:
在整个开发过程,产品的重要性或软件产品的规模大小,可依其风险程度加以监控。
有关用于支持此分析的验证方法,请参考验证过程域,以获得更多信息。
典型的工作产品
1.需求缺陷报告
2.用来解决缺陷的需求变更建议
3.关键需求
4.技术绩效度量细部执行方法
子实践
1.分析关键人员的需要、期望、限制及外部接口,以移除矛盾,并汇整成相关主题。
2.分析衍生需求,以决定是否满足更高阶需求的目标。
3.分析需求,以确保是完整、可行、可实现及可验证的。
虽然设计决定某特殊解决方案的可行性,本细部执行方法可以了解哪些需求会影响可行性。
.
4.识别对成本、时程、功能、风险或绩效有重大影响的关键需求。
5.识别技术绩效度量,以便于开发阶段时进行追踪。
有关度量的用途,请参考度量与分析过程域,以获得更多信息。
6.分析操作观念及场景,以细化客户需要、限制及接口,并发现新需求。
此分析可能产生更详细的操作观念及场景,同时也衍生新需求。
SP3.4分析需求以取得平衡
分析需求以平衡相关干系人的需求和约束。
关键人员的需要和限制,可说明成本、时程、绩效、功能、再使用的组件、维护能力,或风险。
典型的工作产品
1.需求相关风险的评估细部执
子实践
1.使用经验证的模型、仿真及原型等,以分析关键人员的需要和限制间的平衡。
.
分析的结果,可用以降低产品的成本与开发产品时的风险。
2.执行需求及功能架构的风险评估。
有关执行客户及产品需求和功能架构的风险评估,请参考风险管理过程域,以获得更多信息。
.
3.检查产品生命周期概念,以分析它对需求风险的影响或冲击。
SP3.5确认需求
确认需求,以确保将要产生的产品能在预期的用户环境中运行。
在开发工作的初期,与最终使用者执行需求确认,俾使需求能够引导开发工作,并导致成功的最终确认的信心。
此活动应与风险管理活动整合。
成熟的组织,通常会以更复杂的方式使用多种技术来执行需求确认,扩大确认的基础,以包括其他的关键人员需要和期望。
这些组织通常会使用分析、模拟或原型等方法,以确保需求满足关键人员的需要和期望。
需求确认的技术,举例如下:
分析
模拟
原型
示范
典型的工作产品
1.分析方法和结果的纪录
子实践
1.分析需求以识别最终产品不能于用户环境下适当运作的风险。
2.以产品展示(如,原型、仿真、模型、情境及场景),以及取得相关关键人员的回馈,寻求需求的足够性和完整性。
有关产品及产品组件的确认及确认执行,请参考确认过程域,以获得更多信息。
3.于设计成熟时,在需求确认环境下进行设计的评估,以识别确认议题,并揭露未说明的需要和客户需求。
各通用目标的实践
仅适用于连续式表述
GG1达成特定目标
本过程通过将界定的输入的工作产品转换为输出的工作产品,支持与促成过程域特定目标的达成。
GP1.1执行特定实践
执行需求开发过程的特定实践,以开发工作产品与提供服务,达成过程域的特定目标。
GG2制度化已管理过程
将过程制度化为已管理过程。
仅适用于阶段式表述
GG3制度化已定义过程
将过程制度化为已定义过程。
本通用目标反映在阶段式表述的位置。
GP2.1建立组织方针
建立并维护组织方针,以策划和执行需求开发过程。
详细说明:
本政策建立组织对下列活动的期望:
搜集关键人员需要、明确地陈述产品及产品组件需求,以及分析和确认需求。
GP2.2策划过程
建立并维护执行需求开发过程的计划。
详细说明:
执行需求开发的计划可以是项目计划的一部分,项目计划在项目规划过程域中说明。
GP2.3提供资源
提供充足的资源,以执行需求开发过程、开发工作产品及提供过程服务。
详细说明:
应用领域的特殊专业知识、引导关键人员需要的方法,用于指定及分析客户、产品,以及产品组件需求的方法及工具等可能是必要的。
可用于本过程域的资源(工具),举例如下:
需求规格工具
仿真及模型工具
原型工具
场景定义及管理工具
需求追踪工具
GP2.4分配责任
分配需求开发过程的责任与授权,以执行过程、开发工作产品及提供过程服务。
GP2.5培训人员
依需要培训人员,以执行或支持需求开发过程。
详细说明:
培训主题,举例如下:
应用领域的专业知识
需求定义及分析
需求引导
需求规格及模型
需求跟踪
GP2.6管理配置
将指定的需求开发过程的工作产品,纳入适当层级的控制。
详细说明:
纳入控制的工作产品,举例如下:
Customerrequirements
客户需求
功能架构
产品及产品组件需求
接口需求
GP2.7识别相关干系人并使之参与
依计划识别并纳入需求开发过程相关的干系人。
详细说明:
从下列人员中选择相关的关键人员:
客户、最终使用者、开发人员、制作人员、测试人员、供货商、市场营销人员、维护人员、报废处理人员,以及其他会影响产品及过程或受产品及过程所影响的人。
关键人员参与的活动,举例如下:
审查需求的足够性,以满足需要、预期、限制及接口的要求。
建立操作观念和场景
评估需求的足够性
建立产品与产品组件需求
评估产品成本、时程及风险
GP2.8监控过程
按本过程的执行计划,监督和控制需求开发过程,并采取适当的纠正措施。
详细说明:
用于监控的度量及工作产品,举例如下:
成本、时程及重做所需的工作量
需求规格的缺陷密度
开发一组需求的活动时程.
GP2.9客观评价符合度
按照过程描述、标准和规程,客观地评价需求开发过程的符合度,并解决不符合问题。
详细说明:
审查的活动,举例如下:
收集干系人的需要
明确的陈述产品与产品组件需求
分析并确认产品与产品组件需求
审查的工作产品,举例如下
产品需求
产品组件需求
接口需求
功能架构
GP2.10和高级管理人员进行状态回顾
与高层管理人员评审需求开发过程的活动、状态和结果,并解决问题。
仅适用于连续式表述
GG3制度化已定义过程
将过程制度化为一个已定义的过程。
本通用目标反映在阶段式表述的位置。
GP3.1建立已定义过程
建立和维护需求开发过程的描述。
GP3.2收集改进信息
收集由策划和实施需求开发过程的工作产品、度量、度量结果和改进信息,以支持组织的过程和过程资产将来的使用和改进。
详细说明:
工作产品、度量、度量结果及改善信息,举例如下:
:
含糊不清的产品需求列表
产品生命周期各阶段的需求数量
需求分配过程的经验分享
仅适用于连续式表述
GG4制度化已量化管理过程
将过程制度化为已量化管理过程。
GP4.1建立过程的量化目标
建立并维护需求开发过程的量化目标,该目标用来处理以客户需要与经营目标为基础的质量与过程绩效。
GP4.2稳定子过程绩效
稳定一个或多个子过程的绩效,以决定需求开发过程的能力,是否达成已建立的量化质量与过程绩效目标。
GG5制度化优化过程
将过程制度化为优化过程。
GP5.1确保持续的过程改进
确保
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- CMMI 需求 开发 欧阳 创编
![提示](https://static.bdocx.com/images/bang_tan.gif)