需求开发
度 成熟度 3 级 级 得 工程过程域
目得 需求开发（Requiｒeｍenｔs Dｅｖelopｍent， RD)得目得,在于产出并分析客户、产品及产品组件得需求。
业界注 释
本过程域描述客户、产品及产品组件等三种需求,这些需求说明相关关键人员得需要，包括与产品生命周期各阶段 （如，验收测试准则）及产品属性 (如，安全性、可靠性、与维护能力等）
有关得需要。需求也包括选择某设计解决方案而产生得限制条件。例如：与现成品整合得需求. 所有开发项目都有需求,从项目于维护活动得项目案例来瞧,产品或产品组件得变更，就是基于现有需求、设计、或实作得变更。需求变更可能来自顾客或用户所记载得变更请求单，或来自于需求开发过程得新需求形式。不论需求来源或型式,变更所驱动得维护活动也要加以管理。
需求就是设计得基础,需求得开发包括下列活动: 引导、分析、验证,以及沟通客户得需要、期望及限制，以获得客户需求,并达成关键人员得共识 搜集与协调关键人员得需要 开发产品得生命周期需求 建立客户需求 建立与客户需求一致得原始产品及产品组件需 因为客户也可能提出特定得设计需求，本过程域讨论所有客户得需求,而非局限于产品层次得需求。
客户需求可进一步细化为产品及产品组件需求.除客户需求外，选定得解决方案也可能衍生产品及产品组件需求。整个过程域中,产品及产品组件得意涵也包括服务及其组件。
在整个产品生命周期中识别并修订需求。对设计决策、后续得纠正措施,以及产品生命周期各阶段所产生得回馈进行分析，以了解它们对衍生及已配置需求得影响. 需求开发过程域包括三项特定目标.”开发客户需求」特定目标说明如何定义完整得客户需求,以使用于产品需求开发。”开发产品需求」特定目标说明如何定义完整得产品与产品组件需求，以使用
于产品与产品组件设计。”分析并确认需求」特定目标说明客户、产品及产品组件需求须执行得必要分析，以定义、衍生及了解需求。第三项特定目标得特定执行方法,用以辅助前两项特定目标得特定执行方法.需求开发过程域得过程与技术解决方案过程域得过程，可彼此相互循环互动. 对竞争得备选方案进行分析，以了解、定义及选用各层次得需求。这些分析活动包括: 分析产品生命周期每阶段得需要与需求，包括:相关关键人员得需要、操作环境，以及反映所有客户及使用者得期望与满意得因素(如安全性、保密性及负担能力) 开发操作观念 定义必要得功能 功能得定义,也称为“功能分析"，与软件开发得结构化分析不同，也不能假定为功能导向得软件设计。在面向对象得软件设计里,它相当于定义所谓得“服务”或“方法”.功能、功能得逻辑群组，以及它们与需求之间关联得定义，就就是所谓得"功能架构」。
对产品架构更细层次不断地分析，直到获得足够得细节以进行产品得细部设计、采购及测试。经由分析需求得结果及操作概念（包括功能性、支持、维护及销毁），制造或生产得概念会产生出更多得衍生需求，包括下列考量：
不同类型得限制
技术得界限 成本与成本因素 时间限制与日程因素 风险 客户或使用者所暗示但未明确陈述得议题得考量 开发者独特得经营考量、规定及法律等所产生得因素 逻辑实体得层次架构（功能及子功能，对象类别及子类别），建立在反复开发得操作观念里。需求经过细化、衍生，才能配置到该逻辑实体。需求与逻辑实体再被配置于产品、产品组件、人员、或相关过程. I 在需求开发与分析时,纳入相关关键人员得参与，藉此使她们了解需求得演进过程。本活动持续向相关关键人员提供保证:需求已适切定义。
相关过程域
有关管理客户及产品需求、取得需求提供者同意、取得需求执行者承诺及维护追溯性,请参考需求管理过程域,以获得更多信息。
有关如何使用需求开发过程域得输出,以及开发替代方案与设计，以用于细化与衍生需求,请参考技术解决方案过程域，以获得更多信息.
有关验证最终产品就是否符合需求 , 请参考验证过程域 , 以获得更多信息 . 有关确认如何依照客户需要建置产品，请参考确认过程域，以获得更多信息。
有关需求相关风险得识别与管理，请参考风险管理过程域,以获得更多信息. 有关确保重要工作产品得控管，请参考配置管理过程域，以获得更多信息。、
特定目标及实践摘要 SＧ 1 开发客户需求 SＰ 1、１ 引导需要 SＰ 1、2 开发客户需求 SG ２开发产品需求 SP 2、1 建立产品与产品组件需求 SP 2、2 配置产品组件需求 ＳP 2、３ 识别接口需求 SＧ ３分析并确认需求 SP 3、１ 建立操作概念及场景 SＰ ３、２ 建立必要功能得定义 SP 3、3 分析需求
ＳP ３、4 分析需求以取得平衡
SP 3、5 确认需求 各 特定目标得 实践 SG 1 开发 客户需求
收集相关干系人得需要、期望、限制及 接口 , 并转换成客户需求 、
关键人员(例如：客户、最终使用者、供货商、建置人员、测试人员、制造人员,与后勤支持人员)得需要，就是决定客户需求得基础.进行关键人员得需要、期望、限制、接口、操作概念,以及产品观念得分析、协调、细化及详细说明，以转换成客户需求。
关键人员得需要、期望、限制及接口,经常被粗略得识别或相互矛盾。因为必须清楚识别与了解关键人员得需要、期望、限制及界限，在整个项目得生命周期里可使用反复得过程,以达到这目标。为协助此必要得循环过程，最终用户或客户得代表，通常会加入此过程,以说明其需要并协助解决矛盾。组织得客户关系或营销部门,以及来自人际工程或支持部门得开发团队成员,可视为此类得代表。在
研拟与解决客户需求时，也应考量客户得外在环境、法规及其她限制 、 ＳＰ 1 、1ﻩ 引导 需要
引导相关 干系人提出有关产品生命周期各阶段得需要、期望、限制及接口 、
引导不只就是积极识别尚未经客户明确提出得新增需求.新增得需求应描述各种生命周期得活动,以及它们对产品得影响。
引导需要得技术，举例如下：
技术展示 接口管制工作组 技术管制工作组 临时得项目审查 由最终使用者取得得问卷、访谈及操作场景等数据 操作得审查与最终使用者得工作分析 原型与模型 脑力激荡 质量机能展开 市场调查 试用版本得试用 由文件、标准或规格等来源中抽取 观察现行产品、环境及工作过程得样式(ｐatｔeｒns) 使用案例(use ｃaseｓ）
经营案例分析 采取反向工程(针对现有产品) 客户满意度调查 可能未被客户识别得需求来源，举例如下: 经营策略 标准 经营环境要求（例：研究室、测试其她设施、信息科技基础建设等) 技术 现有产品或产品组件（可再用产品组件) 子实践 1、、望期、求需出导引以,法方用使并，与参起一人系干得关相与ﻩ限制及外部接口。
Ｓ ＳP
1 、2 开发 客户需求
把相关干系人得需求、期望、限制条件与接口转换成客户需求 。
来自相关关键人员得各种输入,须经合并、取得遗漏得信息，以及解决冲突等过程,并记录为客户需求.客户需求可包括与验证与确认有关得需要、期望及限制。
某些情况来说，客户提供项目得一套需求，或者之前项目活动得需求产出。以这些情况来说，客户需求与相关关键人员得需要、期望、限制及接口可能有所冲突,所以在冲突适当解决之后，需要转换成被认可得客户需求。
代表产品生命周期得所有阶段得相关关键人员，应包括经营及技术功能。因此,所有与产品生命周期相关得过程概念，都应与产品得概念同步考量。客户需求来自信息充分得决策，同时考量需求在经营面与技术面得影响. 典型得工作产品
1、 .求需户客ﻩ２、 。制限户客得时证验行执ﻩ３、 。制限户客得时认确行执ﻩ子实践 １、
转换关键人员得需要、预期、限制及接口,成为客户需求。
2、 定义验证及确认时得限制 。
Ｓ ＳG 2ｅDﻩ ｅv ｅl ｏp Product R ｅquireme ｎt ｓ 对客户需求加以精练与细化 , 以开发产品与产品组件需求 . 分析客户需求并开发操作概念，以衍生更详细与精准得需求,此需求称为“产品与产品组件需求”。“产品与产品组件需求”说明产品生命周期每一阶段得相关需要。衍生需求就是由限制、对某些隐含议题得考量及某些因素而间接产生，这些议题在客户需求基准中并未明确说明；而这些因素就是基于所选用得架构、设计，以及开发者独特得经营考量等而产生.需求须以后续得、较低阶得需求及功能架构再检查，并细化优先得产品概念。
配置需求于产品功能及产品组件,包括对象、人员及过程,并记录需求到功能、对象、测试、议题，或其她实体得追溯性。已配置得需求及功能就是组成技术解决方案得基础。当开发内部组件时,须定义新增得接口，并建立接口需求。
有关维护双向追溯性，请参考需求管理过程域得「维护需求得双向追溯性」特定执行方法,以获得更多信息、
SP 2 、1 E ｓｔabl ｉsh P ｒoduct ａnd Pr ｏduct ponent Requ ｉrement ｓ 根据客户需求 , 建立与维护产品与产品组件得需求。
客户需求可能以客户术语表示,且以较不具技术得方式描述。产品需求则就是以专业术语表示这些客户需求，以用来进行设计得决策.“质量机能展开”就是此转换得范例,它描述客户期望与技术参数得对应关系。例如：“结实得门"可能对应到尺寸规模大小、重量、适合、湿度及共振频率。
“产品与产品组件需求”强调客户、经营,以及项目目标与相关属性（如有效性与负担能力）得满足。
衍生需求也包括其她生命周期阶段得成本与绩效 （如，生产、操作及销毁），以与经营目标兼容.、 需求管理过程域涵盖需求变更得管理，而本特定执行方法得“维护"部分，涵盖因已核准得需求变更而引起得需求修改活动。
有关管理需求变更，请参考需求管理过程域,以获得更多信息。、
典型得工作产品 １、 求需生衍ﻩ2、 求需品产ﻩ３、 求需件组品产ﻩ子实践 １、 。求需得计设件组品产与品产发开语术业专以ﻩ针对产品架构设计所需得重要得产品质量与绩效，开发架构需求. 2、 由设计决策衍生需求。
有关开发解决方案以产生其她衍生需求,请参考技术解决方案过程域,以获得更多信息。、
技术得选用会引进其她得需求.例如:运用电子学将增加特定技术得需求,如电磁干扰得界限. 3、 建立并维护需求间得关连性，并考量在变更管理与需求配置时得影响。
有关维护需求追溯，请参考需求管理过程域，以获得更多信息。需求间得关连有助于评估变更得影响。
Ｓ ＳP 2 、2 分配 产品组件需求
为每个产品组件分配需求。
有关配置需求到产品与产品组件，请参考技术解决方案过程域,以获得更多信息。本执行方法提供信息以定义需求配置，但必须与技术解决方案过程域得执行方法互动，以建立配置需求得解决方案。
上述中所定义得解决方案，其产品组件得需求，包括所配置得产品绩效、设计限制,以及符合需求与有助于生产得合适、形式及功能。
假使较高阶需求得指定绩效归属于两组或以上得产品组件时，该绩效必须进行切割,并单独配置到各个产品组件,就像就是衍生需求一样. 、 典型得工作产品
1、 需求配置表 2、 暂时性得需求配置 ３、 设计限制 ４、 衍生需求 5、 法方行执部细系关得间求需生衍ﻩ子实践 1、 。能功于求需配分ﻩ2、 分配需求于产品组件. ３、 配置设计限制于产品组件。
４、 。系关得间求需置配已录记ﻩ关系包括依赖性，在这情境下,某需求得改变可能会影响其她得需求。
SP ３ ２、３求需口接别识ﻩ 识别接口需求 识别 接口需求。
定义功能之间（或对象之间)得接口.功能接口可能衍生出替代方案得开发，替代方案在技术解决方案过程域中描述。
有关接口管理以及产品与产品组件得整合，请参考产品整合过程领域，以获得更多信息。
定义产品架构中所识别之产品与产品组件间得接口需求，并将它们当做产品与产品组件整合得一部分来管制，它们也就是架构定义中不可缺少得部分。
典型得工作产品 1、 界面需求 子实践 1、接得间之象对或割分能功：如例(口接得部外及部内品产别识ﻩ口)。、 在设计工作进行得过程中，产品架构可能受技术解决方案过程得影响，而产生产品组件与项目外部组件间得新接口。
必须识别产品有关得生命周期过程得接口.
与测试设备、传输系统、支持系统及制造设施之间得接口,都属于这类接口。、 2、 开发已识别界面得需求。
有关在设计过程中,如何产生接口需求,请参考技术解决方案过程域，以获得更多信息。
例如以软件得来源、目得地、刺激及数据特征,与硬件得电子及机械得特征,来定义接口需求. Ｓ ＳG ３ ３ﻩ 分析并确认需求
对需求进行分析与确认 , 开发需求功能性得定义。
「分析并确认需求」特定目标得特定执行方法,支持「开发客户需求」与「开发产品需求」两个特定目标得需求开发过程。本特定目标得特定执行方法涵盖需求得分析,以及确认需求就是否符合使用者预期。
执行分析,以决定为求满足关键人员得需要、期望、限制及接口，对原计划得操作环境会产生哪些影响。视产品得范围而定，可行性、任务需要、经费限制、市场潜力及采购策略等都必须纳入考量，并建立必要功能得定义。所有产品得特定使用形式均应考量，并产生对时间敏感得功能顺序得时间点分析。
分析得目得，在于决定可满足关键人员需要、期望及限制得产品概念得可能需求，再将这些概念转换为需求。与此活动同时进行得就是,依据客户得输入与初步得产品概念，决定用以评估产品有效性得参数. 确认需求,以增加最终产品在使用环境中,可按照期望运作得可能性。
Ｓ ＳP 3 、1 建立 操作概念与相关得场景 建立与维护操作概念与相关得场景。
场景一般而言就是指使用产品时可能发生得事件顺序，以明确说明关键人员得某些需要。相对得,产品得操作概念通常就是依据设计方案与场景而来。例如:卫星得通讯产品与地面得通讯产品，它们得操作概念就是不同得。在研拟原始操作概念时，其替代方案通常尚未定义。所以，在需求分析时,开发概念性得解决方案.在进行解决方案得决策时,细化操作概念，进而开发出细部得需求. 正如某产品得设计决策可能变成产品组件需求，操作概念也可能变成产品组件得场景(需求）.开发操作概念及场景逐步开发，以利产品组件解决方法得选择，使得在实作后将满足产品得预期使用。不管哪一种工程，操作概念及场景描述了产品组件与环境、用户，及其她产品组件得互动关系。包括营运、产品推展、交付、支持（含维护及营运）、训练、处置，以及所有得模式与状态等相关得操作概念与场景,都应予以描述。
如果操作顺序用以表达客户需求而非操作概念,则场景可能包含了操作顺序. 典型得工作产品 1、 操作概念 ２、 念概持支及护维、作操、装安件组品产或品产ﻩ3、 销毁概念 ４、 使用案例 5、 景场得化演间时依ﻩ6、 新需求细部执行 子实践 1、及持支、护维、效绩、能功得当适括包，景场与念概作操发开ﻩ销毁。
识别并开发场景,此场景须与关键人员各细部层级得需要、预期及限制一致。经此建议得产品或产品组件应可如预期运作。、 ２、 定义产品或产品组件得操作环境，包括界限与限制. 3、 。求需新现发并求需化细以,景场与念概作操查审ﻩ操作概念与场景得开发就是个反复得过程。应定期举行审查，以确保其结果与需求一致。审查可采用逐步审查得形式。
4、产义定以，念概作操得细详发开就,定选经一件组品产与品产ﻩ品、最终用户及环境得互动，并满足操作、维护、支持及销毁得需要。
Ｓ ＳP 3 、2义定能功得要必立建ﻩ 建立必要得功能定义 建立与维护需求得功能性得定义。
功能得定义，也就就是所谓得“功能分析”,描述哪些就是产品预期该做得，包括，行动、顺序、输入、输出，或其她说明如何使用产品得信息。
功能分析与软件开发得结构化分析不同，也不能假定为功能导向得软件设计。在面向对象得软件设计里,它相当于定义所谓得服务或方法。功能、功能得逻辑群组,以及它们与需求得关连得定义，就就是所谓得「功能架构」。有关「功能架构」得定义,请参见词汇。
典型得工作产品 1、 功能架构 2、 例案用使与图动活ﻩ3、 法方行执部细法方或务服得别识已与析分象对向面ﻩ
子实践 １、 、能功得要需户用终最化量与析分ﻩ2、 .）能功子如（割分能功或辑逻别识以，求需析分ﻩ3、 依已建立得准则(如类似得功能、绩效或耦合），将需求分割成群组，以促进与专注于需求分析.
4、 在产品开发得整个过程，考量具有时效性得功能得顺序. 5、解持支以,件组持支或员人、象对、割分能功于求需户客配分ﻩ决方案得综合。
6、 分配功能及绩效需求于功能及子功能. SP ３ ３３ 、３求需析分ﻩ 分析需求 分析需求，以确保其必要性与充分性。
在操作概念与场景得说明下，分析在产品架构某一阶得需求,以决定其就是否必要且可满足较高阶得目标。经过分析得需求就变成产品架构中较低阶需求得基础,而较低阶得需求通常就是更详细且精准得。
定义需求时,必须能了解它与更高阶需求与已定义功能得关系.决定应识别哪些需求，以追踪技术得进展,也就是重要得行动之一。例如：在整个开发过程，产品得重要性或软件产品得规模大小，可依其风险程度加以监控。
有关用于支持此分析得验证方法,请参考验证过程域,以获得更多信息。
典型得工作产品 1、 告报陷缺求需ﻩ2、 用来解决缺陷得需求变更建议 3、 关键需求 4、 技术绩效度量细部执行方法 子实践 1、 分析关键人员得需要、期望、限制及外部接口,以移除矛盾,并汇整成相关主题。
2、 。标目得求需阶高更足满否是就定决以，求需生衍析分ﻩ３、 分析需求,以确保就是完整、可行、可实现及可验证得。
虽然设计决定某特殊解决方案得可行性,本细部执行方法可以了解哪些需求会影响可行性。、 ４、 识别对成本、时程、功能、风险或绩效有重大影响得关键需求。
5、 识别技术绩效度量,以便于开发阶段时进行追踪。
有关度量得用途,请参考度量与分析过程域,以获得更多信息。
6、 分析操作观念及场景，以细化客户需要、限制及接口，并发现新需求。
此分析可能产生更详细得操作观念及场景,同时也衍生新需求。
SP 3 、4 分析需求以取得平衡 分析需求以平衡相关干系人得需求与约束。
关键人员得需要与限制，可说明成本、时程、绩效、功能、再使用得组件、维护能力，或风险. 典型得工作产品 1、 需求相关风险得评估细部执 子实践 1、与要需得员人键关析分以，等型原及真仿、型模得证验经用使ﻩ限制间得平衡。、 分析得结果,可用以降低产品得成本与开发产品时得风险。
2、 。估评险风得构架能功及求需行执ﻩ有关执行客户及产品需求与功能架构得风险评估，请参考风险管理过程域,以获得更多信息。、
3、 。击冲或响影得险风求需对它析分以，念概期周命生品产查检ﻩSP 3 、5 确认需求 确认需求，以确保将要产生得产品能在预期得用户环境中运行。
在开发工作得初期,与最终使用者执行需求确认，俾使需求能够引导开发工作，并导致成功得最终确认得信心.此活动应与风险管理活动整合。成熟得组织,通常会以更复杂得方式使用多种技术来执行需求确认，扩大确认得基础,以包括其她得关键人员需要与期望.这些组织通常会使用分析、模拟或原型等方法，以确保需求满足关键人员得需要与期望。
需求确认得技术，举例如下：
分析 模拟 原型 示范 典型得工作产品 １、 录纪得果结与法方析分ﻩ
子实践 1、 分析需求以识别最终产品不能于用户环境下适当运作得风险。
2、得取及以,)景场及境情、型模、真仿、型原,如（示展品产以ﻩ相关关键人员得回馈，寻求需求得足够性与完整性。
有关产品及产品组件得确认及确认执行,请参考确认过程域，以获得更多信息。
3、确别识以，估评得计设行进下境环认确求需在，时熟成计设于ﻩ认议题,并揭露未说明得需要与客户需求。
各通用目标得实践 仅适用于连续式表述 Ｇ ＧG 1 达成特定目标
本过程通过将界定得输入得工作产品转换为输出得工作产品，支持与促成过程域特定目标得达成. .
GP 1 、1ﻩ 执行 特定 实践
执行需求开发过程得特定实践, , 以开发工作产品与提供服务, , 达成过程域得特定目标。
Ｇ ＧG
2ﻩ 制度化已管理过程
将过程制度化为已管理过 程. .
仅适用于阶段式表述 G Ｇ 3 制度化已定义 过程
将 过程 制度化为已定义 过程. .
本通用目标反映在阶段式表述得位置。
GP 2 、1 建立组织 方针
建立并维护组织方针, , 以策划与 执行需求开发过程。
详细说明：
本政策建立组织对下列活动得期望:搜集关键人员需要、明确地陈述产品及产品组件需求，以及分析与确认需求。
GP 2 、2ﻩ 策划过程
建立并维护执行需求 开发过程 得计划 。
详细说明: 执行需求开发得计划可以就是项目计划得一部分，项目计划在项目规划过程域中说明。
G Ｐ 2 、3ﻩ 提供资源
提供充足得资源，以执行需求开发过程、开发工作产品及提供过程服务。
详细说明: 应用领域得特殊专业知识、引导关键人员需要得方法,用于指定及分析客户、产品,以及产品组件需求得方法及工具等可能就是必要得。
可用于本过程域得资源（工具），举例如下: 需求规格工具 仿真及模型工具
原型工具 场景定义及管理工具 需求追踪工具
GP 2 、4 分配 责任
分配需求开发过程得责任与授权, , 以执行过程、开发工作产品及提供过程服务. .
Ｇ ＧP 2 、5员人训培ﻩ 培训人员 依需要 培训 人员，以执行或支持需求 开发过程. .
详细说明：
培训主题,举例如下：
应用领域得专业知识
需求定义及分析 需求引导 需求规格及模型 需求跟踪 G Ｐ 2 、6 管理配置 将指定得需求开发过程得工作产品, , 纳入适当层级得控制。
详细说明：
纳入控制得工作产品,举例如下:Cｕsｔomeｒ reqｕｉremｅnｔｓ 客户需求 功能架构 产品及产品组件需求
接口需求 G Ｐ ２、7 识别相关干系人并使之参与 依计划识别并纳入需求开发过程相关得干系人。
详细说明：
从下列人员中选择相关得关键人员：客户、最终使用者、开发人员、制作人员、测试人员、供货商、市场营销人员、维护人员、报废处理人员,以及其她会影响产品及过程或受产品及过程所影响得人. 关键人员参与得活动，举例如下：
审查需求得足够性，以满足需要、预期、限制及接口得要求。
建立操作观念与场景 评估需求得足够性 建立产品与产品组件需求 评估产品成本、时程及风险 GP
2 、8 监控 过程
按本过程得执行计划，监督与控制需求开发过程, , 并采取适当得纠正措施。
详细说明: 用于监控得度量及工作产品,举例如下: 成本、时程及重做所需得工作量 需求规格得缺陷密度 开发一组需求得活动时程、 GP 2 、９ 客观评价符合度 按照过程描述、标准与规程，客观地评价需求开发过程得符合度，并解决不符合问题 .
详细说明：
审查得活动,举例如下：
收集干系人得需要 明确得陈述产品与产品组件需求 分析并确认产品与产品组件需求 审查得工作产品，举例如下 产品需求 产品组件需求 接口需求 功能架构 GP 2 、１0 与高级管理人员进行状态回顾 与高层管理人员评审需求开发过程得活动、状态与结果，并解决问题。
仅适用于连续式表述
GG 3ﻩ 制度化已定义 过程
将 过程制度化为一个已定义得过程 . 本通用目标反映在阶段式表述得位置.
GP ３、１ﻩ 建立已定义 过程
建立与维护需求开发过程得描述 . Ｇ ＧP 3 、2 收集改进信息 收集 由 策划与实施需求开发过程得工作产品、度量、度量结果与改进信息，以支持组织得过程与过程资产将来得使用与改进。
详细说明：
工作产品、度量、度量结果及改善信息，举例如下：: 含糊不清得产品需求列表 产品生命周期各阶段得需求数量 需求分配过程得经验分享 仅适用于连续式表述 GG
４ ４ﻩ 制度化已 量化管理 过 程
将 过程 制度化为已 量化管理 过 程 。
GP 4 、１ 建立 过程 得 量化目 标
建立并维护需求开发过程得 量化目 标，该目标用来处理以客户需要与经营目标为基础得质量与过程绩效。
GP 4 、2 稳定子 过程 绩效
稳定一个或多个子过程得绩效，以决定需求开发过程得能力，就是否达成已建立得 量化 质量与过程绩效目标 . GG ５ ５ﻩ 制度化 优化过程
将 过程 制度化为 优化过程 。
GP 5 、1ﻩ 确保持续得 过程 改进
确保需求开发过程得持续改进, , 以实现相关得组织经营目标. .
G Ｐ 5 、2ﻩ 纠正 问题得根本原因
识别并纠正需求开发过程得缺陷与其它问题得根本原因. .