CMMI需求管理规范
CMMI文件-(组织方针)v3.0
组织方针与目标（V3.0）更改控制页目录1组织方针与目标 (1)1.1方针 (1)1.2标准 (1)1.3商业目标 (1)2过程通用目标 (2)2.1组织过程焦点(OPF) (2)2.2组织过程定义(OPD) (4)2.3需求管理(RM) (5)2.4项目计划(PP) (7)2.5项目监控(PMC) (8)2.6采购管理(SAM) (10)2.7度量(MA) (11)2.8质量保证(PPQA) (12)2.9配置管理(CM) (13)2.10需求开发(RD) (15)2.11技术解决方案(TS) (16)2.12产品集成(PI) (18)2.13验证(VER) (19)2.14确认(VAL) (20)2.15组织培训(OT) (21)2.16集成项目管理(IPM) (23)2.17风险管理(RSKM) (24)2.18决策分析(DAR) (25)2.19组织过程性能（OPP） (27)2.20定量项目管理(QPM) (28)2.21组织革新和部署(OID) (29)2.22原因分析和解决(CAR) (31)1组织方针与目标根据公司的战略与经营管理需要，公司组织级方针与目标的内容如下：1.1方针“优质、高效、安全、规范”优质：为客户提供高品质的产品和服务；高效：以最高效率服务客户和发展企业；安全：保障企业和客户的各项资产安全；规范：建立规范的管理体系并严格执行。
1.2标准使用CMMI-DEV V1.2模型；ISO9001-2000；ISO27001。
1.3商业目标本过程改进计划旨在帮助公司在能力成熟度集成模型（CMMI）方面达成下列商业目标：1.将项目的进度偏差率控制在总工期的10%以内；2.交付时的产品质量控制在0.5个Bugs/千行代码以内；3.将项目的成本偏差率控制在10%以内；4.改善软件开发流程、提高质量、降低成本、提高效率、降低风险；5.改善软件产品及服务的品质和可靠性，提高客户满意度；6.建立出口软件开发管理规范，提高公司整体的软件开发和管控水平；7.通过CMMI 5级认证，进一步提高企业形象和市场竞争力。
CMMI配置管理规程
配置管理广东×××技术股份有限公司修订历史记录目录1目的 (4)2适用范围 (4)2.1机构 (4)2.2业务 (4)3名词术语 (4)4概述 (5)5过程定义 (5)5.1配置管理 (5)5.1.1 角色与职责 (6)5.1.2 入口准则 (6)5.1.3 输入 (6)5.1.4 过程活动 (6)5.1.5输出 (8)5.1.6 出口准则 (9)5.1.7 过程度量 (9)5.1.8 确认与验证 (9)6规程 (9)7标准与规范 (9)8裁剪指南 (9)9模板与表格 (9)10实施指导 (10)运用配置标识、版本控制、配置变更控制、配置审计，以及通过使用配置管理软件，来保证所有配置项的完整性和可跟踪性。
2适用范围2.1机构研发中心技术部门及PMO、技术拓展部。
2.2业务贯穿整个项目的配置管理活动。
3名词术语3.1 PP（Project planning）：项目策划。
3.2项目干系人（Stakeholder）：在一定程度上，对项目的实施和成果负责，或受其影响的群组或个人。
项目干系人可能包括项目团队成员、提供商、客户、最终用户等。
3.3 PMO（Project Management Office）：项目管理办公室。
3.4 CCB(Changing Control Board)：变更控制委员会。
3.5 CM(Configuration Management)：配置管理。
标识和确定系统中配置项的过程，在系统整个生命周期内控制这些项的投放和更动，记录并报告配置的状态和更动要求，验证配置项的完整性和正确性。
3.6 CMO（Configuration Management Officer）：配置管理员。
3.7 基线：基线就是项目存储库中每个工件版本在特定时期的一个快照。
在配置管理系统中，基线就是一个CI或一组CI在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态，而这个过程被称为“基线化”。
【软件工程】【CMMI】软件项目需求开发管理规程
需求小组根据客户反馈的《需求调查表》编写《用户需求说明书》。
6.1.4.2.5
《用户需求调查表》，《用户需求说明书》。
6.1.4.2.6
《用户需求调查表》，《用户需求说明书》完成。
客户化项目：公司开发出较为成熟的软件产品，可以适用于某领域的大多数客户，项目实施过程中只需要针对不同的客户进行局部开发的项目。
EPG：工程过程组，组织、执行、维护软件过程改进的所有活动。
CCB：Change Control Board变更控制委员会(项目经理、客户、高级经理、技术专家等)。
CCB的参加范围可以根据不同的情况而有所变更：当变更的影响非常小，对项目的阶段性进度和阶段内的各项活动的影响也非常小，甚至可以忽略不计时，CCB可由项目经理和客户组成；当变更的影响仍非常小，对项目的阶段性进度的影响也非常小，甚至可以忽略不计，但在阶段内的活动需要有所变动时，投入的资源相对不发生变化时，CCB可以项目经理、项目组成员和客户组成；其他的情况，CCB应由项目经理、项目内的主要成员、高级经理和客户组成。
1
“需求开发”过程帮助项目组有序地分析和产生客户需求、产品及产品构件需求。
对需求进行管理、维护需求；
识别与项目计划和工作产品之间的不一致之处；
并且确保能把对需求的更改反映到项目计划、活动和工作产品中。
确保项目经过确认的用户需求，能被有效的管理、维护、跟踪，并正确的实现，最终满足用户的需要。
2
适用于公司所有项目、产品或产品升级的需求获取。
需求开发管理规程
文件状态：
[ ]草稿
[√]正式发布
CMMI2 KPA-需求管理
需求管理目标是在客户和根据客户要求在软件项目中定义的内容之间建立一种良好的理解。
需求管理包括就软件项目与客户之间达成和维持共识。
这种共识被称作"软件的系统需求"。
"客户"可被理解为系统工程部，市场部，另一个内部机构或外部客户.该共识同时涵盖技术和非技术（如提交日期）的需求。
这种共识形成了评估、计划、实行和跟踪软件项目活动的基础，贯穿整个软件生命周期。
系统需求在软件，硬件和其他系统元素（如人力）上的分配可能是由软件工程部之外的部门执行（如系统工程部），软件工程部可不直接控制这种分配。
在项目约束下，软件工程部采取适当的步骤确保控制和存档软件方面的系统需求。
为达到这一控制，软件工程部门在最初及修改过的软件方面的系统需求被纳入软件项目之前对其进行审核以解决问题。
无论软件方面的系统需求何时变化，都要调整受影响的软件计划、工作产品和活动以保持与更新后的需求一致。
目标目标 1 控制软件方面的系统需求，建立一个基线用于软件工程和管理。
目标 2 保持软件计划、产品和活动与软件方面的系统需求一致。
行为的责任责任 1 项目依照一个书面的组织性的原则，以管理软件方面的系统需求。
在这些实践中软件方面的系统需求被称为"分配需求"（allocated requirements）.分配需求是系统需求的子集，在系统的软件部分中执行。
它是软件开发计划中的主要部分。
软件需求分析详细阐述和提炼了分配需求，结果体现为文档化的软件需求。
这一原则代表性地说明了：1．分配需求是文档化的；2．分配需求由：☐ 软件经理及其他受影响部门进行审核。
受影响部门的例子包括：☐ 系统测试软件工程（包括所有的子部门，例如软件设计）☐ 系统工程☐ 软件质量保证☐ 软件配置管理☐ 文档支持3．软件计划、工作产品和活动应随分配需求的变化而修改，以与其保持一致。
行为的能力能力1 对于每个项目而言，建立分析系统需求和将其划分到硬件、软件和其他系统元素上的责任。
CMMI-OSSP管理方针
CMMI OSSP管理方针字号：大中小1 目的(Purpose)该方针规定了公司的项目管理、开发活动和过程改进活动必须遵守的方针和策略，以降低项目风险、提高开发管理能力。
2 范围(Scope)此方针适用于本公司开发周期（累计）在3个人月以上的项目，不适用于SES（公司外派工程师）合同。
3 方针(Policy)3.1 项目管理方针( Project Management Policy )3.1.1 项目策划( Project Planning )项目策划的目的是建立并维护规定项目各项活动的计划。
包括估算、制订项目计划、计划审批和评审。
对项目策划的基本要求：1. 建立项目的WBS（工作分解结构），确定项目的范围。
2. 对工作产品、产品的规模、复杂度和结构等进行估算。
3. 必须基于估算的结果进行项目报价，报价在发给客户前必须得到评审和批准(二次开发项目)。
4. 参考公司过程资产库中的定义和以往项目的经验，为项目选用合适的生命周期模型，定义项目的开发和管理过程。
5. 对项目的工作量和成本进行估算，并制定项目的预算和进度计划。
6. 识别和管理项目风险，制定相应的风险管理计划。
7. 识别项目所需的资源、知识和技能等，并定义相应的资源计划和培训计划。
8. 识别项目的干系人，并制定相应的干系人介入计划。
9. 项目策划阶段需要考虑分包/采购计划。
10. 集成所有相关计划，制定一个项目总体计划，用于指导项目的开发和管理活动。
11. 要对计划进行评审和审批，以得到相关干系人的承诺。
12. 当计划发生变更时，必须通知相关人员，并得到认可。
3.1.2 项目综合管理( Project Integration Management )项目综合管理目的就是指实时监视项目实绩与计划之间的偏差，在出现偏差时，采取纠正措施，使项目计划得以实施。
包括项目跟踪与监控、悬案管理和项目评估。
对项目综合管理的基本要求：1. 依据项目计划，监督和管理项目的执行情况，包括进度、成本、人员计划等。
cmmi过程改进中如何有效的管理客户需求
Cmmi过程改进如何有效的管理客户需求？需求是由现场实施人员收集后反馈给研发人员来开发的，但是往往在信息传递的过程中会出现失真的情况，致使做出的产品不能达到客户的需求，请问如何保证需求在传递过程中不会出现失真的情况？【解答】睿泰咨询一部经理杨俊（新浪微博名：睿泰杨俊）关于“如何有效管理客户需求”实在是一个过于庞大的主题，本回答只试图开启一扇窗户。
关于怎么做以及如何实施是相当关键的问题，但是只有首先理解了“做什么”，我们才能确保展开正确的行动。
如果对于怎么做，包括工作与方法、流程与工具、组织结构与绩效等有进一步兴趣，建议可以提供现实的环境作为进一步深入探讨的依据。
什么是本企业客户的真实需求？对需求及其管理的一个重大的误解是我们以为企业内部的人员可能知道需求，但是需求只可能来源于外部，来源于客户，所以我们只能向一类人了解信息，即“客户及最终用户”。
当我们去真心诚意的理解客户及最终用户的需求及需要时，我们就会发现对于客户及最终用户来说的需求与我们自己定义的需求大相径庭。
比如大多数的IT 服务供应商都忽略了这样一个问题：即对接受IT 产品及服务的典型客户及最终用户来说，接受服务的过程往往也是一次（重大）改革的过程。
这样的例子层出不穷，对于每一个下决心实施ERP的企业来说，采购哪家的软件系统从来都不是重点，重点是谁能为我提供过程及管理改进；对于采购一整套自动化系统的公司来说，是否必须实施自动化是一次重大事件，并且可能直接与某个竞争战略挂钩；也许面对终端消费者的互联网企业并不那么认为，但是只要问一问已经习惯了在实体环境里购物的顾客如何彻底改变消费习惯——使之保证每一件商品都在网上购买，是多么困难的一件事情，我们就知道这必然也是一次变革的过程，是客户及最终用户重新认识自我的工作（或活动）及其背后价值的一次大胆尝试！换句话说，客户到底是在购买一个系统，还是采购了一次改革？这样的问题回答直接将颠覆我们对于客户需求的认识，并且理解许多的需求及需求变更是从何而来，又为何组织不了也预见不了。
CMMI需求管理规范
CMMI需求管理规范目录一．概述 (3)二．需求管理的基本活动 (3)1、需求提出 (3)2、需求分析及评审 (3)3、需求计划定制及跟踪 (3)4、需求变更控制 (3)5、需求制度建立及其优化 (4)6、需求成本控制 (4)三．项目实践过程示例 (4)1 、建立需求管理制度 (4)2、需求接收及其分析 (5)3、需求评审 (5)4、需求计划定制及跟踪 (5)5、需求开发及更新过程 (5)6、需求变更 (5)7、团队培训 (5)8、过程改进 (6)一．概述项目需求管理（Requirements Management, REQM）的目的，在于管理项目产品及产品组件的需求，并界定这些需求与项目计划及工作产品间的差异。
项目实行适当的步骤，确保议定的需求是受管理的，以支持项目策划和执行的需要。
需求管理也须记录需求变更及其理由，并维护原始需求与所有产品和产品组件需求的间的双向追溯性。
从实践意义上讲，需求是针对客户各类需求经双方（或多方）沟通确认后形成的一种协议，协议的范围是明确的、可控的。
在协议签订后，需求的计划有定制、进度有跟踪、结果有度量。
针对需求的变化，需要明确需求变化的原因及变更内容。
需求的紧急程度及严重程度可评估，以确定需求及其变更的优先级，从而排定切实可行的需求计划。
下面我们就如下几个方面对需求管理体系进行分析、研究：1，需求的管理的基本活动2，结合当前项目简述需求管理实践中的问题、解决方案（结合7命题）。
二．需求管理的基本活动在需求管理过程中，包含如下关键活动：1、需求提出针对客户的需求提出，开发方进入需求了解环节。
需求了解采用访谈、文档、多方会议等形式采集基础信息，在此基础上结合系统原型进行差异化分析。
2、需求分析及评审需求分析中，针对需求、系统差异进行差异记录并制定相应的矫正方案。
3、需求计划定制及跟踪需求计划的定制以用户、开发团队、计划跟踪者协商一致的结果为依据。
其过程实质是取得用户对于进度的认可、取得团队对于进度的承诺。
CMMI需求管理
⑤验证和确认：根据需求管理维护需求。
⑥供应商合同管理：根据需求管理确定能被外部满足的需求并管理可追溯的需求，这些需求来源于供应商已经完成的产品。
四、需求管理工具化
需求管理的工具包括：①需求及相关文档管理的工具;②流程审批的流转电子化;③溯源性矩阵的维护工具。其中最大的难点是需求溯源性矩阵的维护工具，对此我们作重点分析。
需求管理是基础性的管理，企业必须投入精力，认真实施，并以此作为实施CMMI的起点。在实施中要注意如下几点：
1.培训工作。从以上分析可以看出，需求管理是一项技术含量高、参与人员多、持续时间长(从项目前期到项目结束)的管理活动。因此，必须作好相关的培训，通过培训使高层管理人员了解需求管理的意义，取得他们的支持;使需求管理人员学会使用工具;使一般员工有需求管理意识，维护好溯源矩阵中与自己相关的部分，并提高识别项目工作与需求的不一致的能力。
标识项目计划和工作产品与需求的不一致性。旨在发现不一致性，并且启动纠正措施。
二、需求管理计划
在组织级建立需求管理计划模板，具体项目则是在此模板的基础上结合项目的特点和具体情况，制定项目的需求管理计划。
需求管理计划(模板)应包括如下内容：
需求管理的方针与政策;
三、需求管理流程
各企业可根据自己的组织结构制定需求管理流程，但流程必须涵盖上述5个特定实践，对于具体项目一般应用组织级的需求管理流程，项目的特殊事项可以放在需求管理计划中进行描述。
需求管理流程可以由几个子流程组成，有些子流程可以并行工作，有些子流程还与其他过程域的流程有关。
再次，两个关系密切的特定实践“维护对需求的双向可追溯性”和“标识项目计划和工作产品与需求的不一致性”，一般分散在其他相关流程中，并贯穿于整个软件生命周期中。例如，定期或以事件触发方式启动“标识项目计划和工作产品与需求的不一致性”，检查是否一致，从而进行相应处理。
CMMI 标准学习需求管理(REQM)解读
Validation (VAL)－确信
REQM
Requirements
Product and product component requirements Alternative solutions
Product components
Product
RD
TS
Requirements work products, validation reports
GP1.1 完成特定实践
执行需求管理过程的特定实践，为达成过程域的特定目 标而开发工作产品和提供服务。
把该过程制度化为已管理的过程
建立并组护一个组织级的方针用于计划和执行需 求管理过程。
该方针建立组织对以下活动的期望，收集干系人的需 求，阐述产品和产品组件的需求，以及分析和确认需 求
详细说明：
SG详解
管理需求并识别项目计划和工作产品之间的差 异
通过下面实践来保证在项目整个生命周期中有一组经核 实的最新需求：
管理所有变更需求 维护需求，项目计划，工作产品之间的关系 识别需求，项目计划，工作产品之间的差异 采取纠正措施
和需求提供者一起开发理解需求的含义 当项目成熟或者需求产生后，所有活动都要接受需求，为避免需求突然 产生，要建立准则以指导获取需求的正式渠道和适当来源。
子实践：
1. 评估对现有承诺的影响 当需求变更或新需求时，要评估对项目成员的影响 2. 协商并记录承诺 在项目成员对需求和需求变更承诺前必须对现有承诺进行 协商
在项目开发中，管理需求变更
进行有效的变更影响分析，必须知道需求的来源，并记录变 更的原因。然而项目经理或许要追踪变更程度以判断是否需 要新建或修改变更控制。 典型工作产品： 需求状态表 需求数据库 需求决策数据库
CMMI-REQM需求管理
© 1995-2004 Soft Tech Development, Inc. All rights reserved. 199513
一个字处理程序的例子
业务需求可能是：“用户能有效地纠正文档中的拼写 错误”，该产品的包装盒封面上可能会标明这是个满 足业务需求的拼写检查器。 而对应的用户需求可能是“找出文档中的拼写错误并 通过一个提供的替换项列表来供选择替换拼错的词”。 同时，该拼写检查器还有许多功能需求，如找到并 高亮度提示错词的操作；显示提供替换词的对话框 以及实现整个文档范围的替换。
用户
以某种方式使用系统，因此必须从实际使用的观点理解系 统的任何项目有关人员。
客户不一定是用户。
© 1995-2004 Soft Tech Development, Inc. All rights reserved. 199511
需求的层次
软件项目管理中的有关需求管理共性问题
目标被误解 定义很差的需求 没有充分的技能或资源 通信效率低下 缺少变更控制 缺少足够的文档
© 1995-2004 Soft Tech Development, Inc. All rights3 reserved. 1995-
© 1995-2004 Soft Tech Development, Inc. All rights7 reserved. 1995-
名言
开发软件系统最困难的部分就是准确说明 开发什么。最困难的概念性工作是编写出 详细的需求，包括所有面向用户、面向机 器和其它软件系统的接口。此工作一旦做 错，将会给系统带来极大的损害，并且以 后对它修改也极为困难。
© 1995-2004 Soft Tech Development, Inc. All rights9 reserved. 1995-
cmmi下需求管理
在CMMI的规范下建立有效的需求管理Telelogic南中国区技术经理吴星1. 介绍关于本文本文介绍了流程改进模型－CMMI, 着重描述CMMI对需求管理的要求，同时也提供了如何通过部署相关的工具使整个组织达到CMMI水平的要求。
什么是CMMI?软件工程学会（SEI），集成的能力成熟度模型（CMMI）是描述产品开发（包括系统工程和软件工程）的能力成熟度模型。
SEI把CMM描述成为包含一个或多个关键因素的有效流程，同时也描述了如何从杂乱的，不成熟的流程到规则的，成熟的具有更高质量和效率的流程。
CMMI 是对软件成熟度模型（SW-CMM），系统工程成熟度模型（SECM）和集成的产品开发成熟度模型（IPD-CMM）的最佳实践的建立和扩展。
难道流程改进不会耗费时间和金钱吗？它的回报是什么？改进产品开发流程当然需要投资。
但是，正确选择工具去支持这些流程能够加速流程实施和缩短产生回报的时间。
企业运用CMMI或CMMI之前标准所收到的投资回报是有目共睹的。
在2003年10月份的报告中，SEI发现所有使用CMMI的企业都受益匪浅，包括：z查找和修复缺陷的成本降低了15%；修复一个缺陷的平均成本降低了30% z推出新版本的时间缩短了50%；软件开发能力提高了30%z大大提高了系统的部署质量，只出现了2%的错误z提高了客户满意度，相应的得到了更好的财务回报CMMI 成熟度水平CMMI 提供了级别式的和持续式的两种表示法。
在本文中，将关注级别式表示法。
CMMI定义了五个级别（或水平）的过程成熟度（见图1）。
CMMI鼓励企业先集中精力在那些可控制的过程域上，然后逐步将这些过程演变到更复杂的级别。
本文将重点描述级别二和级别三中包含跟需求管理相关的过程域。
图1：CMMI 的五个级别过程域CMMI的过程域是一组相互关联，并且有一组可定义目标的最佳实践。
图二表示了五个成熟度级别各自的过程域。
图2：CMMI各级别的过程域本文将关注CMMI第二级别中的需求管理和第三级别中的需求开发及相关技术解决方案。
cmmi评估中的需求分析管理资料()
【最新资料,Word版，可自由编辑！】CMMI中需求分析的目的在于理解提出要求的组织对于这次CMMI评估的商业需要，CMMI评估小组领导将收集信息来帮助评估发起方对照评估目标和他们的商业目标。
通过需求分析，可使评估人员在对评估目标，约束，输出和范围形成共同理解的基础上对下一步评估作出正确的决定。
在进行需求分析之前，应确保满足以下两个进入标准：评估发起方已经决定使用SCAMPI方法；能够提供评估要求综述的人有时间接受访问。
发起者、初始要求和约束、过程相关的历史信息是需求分析的三个输入因素，评估输入是需求分析的输出因素。
确定评估目标我们知道，以满足商业需要为出发点的过程改进最为关心的三个因素是减少费用、改善质量、缩短产品面市时间。
为此，本阶段所必需的实践是：1.标明评估发起者和相关的利益分担者，并在他们之间建立经常性的交流；2.将商业目标和评估目标文档化；3.确保评估目标与商业目标的一致性；4.确定评估使用方式（内部过程改进，供应商选择，过程监视），并将其文档化。
此外，在本阶段评估小组领导和发起者之间至少有一次交流。
在某些情况下，还必须通过其他方式确保他们之间存在经常性的面谈。
确定评估约束评估约束是由评估小组领导和评估发起方或者高级管理人员讨论得出的。
它是一个不断反复的过程，以在满足评估发起者提出的要求、评估所采取方法的限制和对资源的要求之间达到平衡，最终达到评估输入参数的优化。
为此，本阶段所必需的实践是：1.建立高层费用和日程安排约束；2.确定评估包含哪些过程域和哪些组织实体；3.确定对评估结果的最小期望和最大期望，或达到某一特殊的目的；4.和评估行为的利益分享者商谈约束条件和目的，确保评估活动的可行性；5.将商谈好的约束文档化。
同样，在本阶段评估小组领导和发起者之间至少有一次交流。
在某些情况下，还必须通过其他方式确保他们之间存在经常性的面谈。
此外，在评估早期阶段标识的费用和日程安排的约束应该是针对高层而言的，是一种系统的估计，而不是详细的估计。
CMMI需求管理浅谈
CMMI需求管理浅谈目录一、摘要 (3)1）内容提要： (3)2）Abstract： (3)二、正文 (3)1.背景 (3)1.1需求管理的概念 (3)1.2需求管理在软件项目管理中的地位 (4)1.3需求管理的整体过程 (4)1.4需求管理的要点 (5)1）控制对需求基线的变动； (5)2）保持项目计划与需求一致； (5)3）控制单个需求和需求文档的版本情况； (5)4）管理单个需求和其他项目可交付品之间的依赖关系； (5)5）跟踪基线中需求的状态； (5)2.需求管理的现状 (5)3.需求管理中遇到的一些问题 (5)3.1需求正确性问题 (5)3.2需求描述不够详细 (6)3.3需求描述的完备性 (6)3.4需求的变更 (6)4.解决以上问题的一些方法 (7)4.1制定有效规范的需求管理的步骤 (7)4.2积极地协作，积极地交流、需求管理专职化 (7)4.3利用合同的约束力 (8)4.4充分掌握区分对待的原则 (8)4.5对需求文档版本的控制 (8)4.6正确认识需求变更 (9)4.7管理需求变更 (9)4.8建立需求管理模型 (9)4.9与用户充分沟通 (9)4.10利用需求管理工具 (10)5.度量需求管理的效果 (11)6.关于软件需求管理 (12)三、参考文献 (12)第2页一、摘要1）内容提要：需求管理是整个软件工程的管理的基础，也是项目成功的关键所在，本文就自己在课堂上学到的和自己的一些实际项目经验简述需求管理中主要面临的一些问题，并对部分问题提出相应的解决方法，最后给出度量需求管理的效果的方法。
2）Abstract：Requirement Management is not only the basis for the wholemanagement of a software engineering, but also the key to thesuccess of the project. This paper outlined the major issuesfacing in my own practical project experience in RequirementManagement as well as what we learnt in class, and then givesome solutions of the problems respectively. Finally，I willgive the method to measure the effect of RequirementManagement.二、正文1.背景1.1需求管理的概念要理解需求管理，首先要了解需求管理的概念，要知道什么是需求管理，需求管理的核心是什么，为什么要进行需求管理，需求管理在软件项目管理中所处的地位，下面简要地阐述。
火龙果软件-CMMI软件开发需求管理
CMMI/SPCA-11
火龙果 整理
信息内容和关系
• 信息内容表示单个数据和控制对象，构成了更大 的信息结合
– 例如：“工资”，包括姓名、基本工资、加班费、应发工资、养 老金、公积金、个调税、实发工资等 – “系统状态”的内容可由一个位串定义，每个位表示一个信息项
数据字典
• 数据字典是对所有与系统相关的数据元素的一个有组织的 列表，以及精确的、严格的定义，使得用户和系统分析员 对于输入、输出、存储成分和中间计算有共同的理解 • 数据字典包括以下信息：
– – – – – 名称－数据或控制项、数据存储或外部实体的主要名称 别名－第一项的其他名字 如何使用－使用数据和控制项的加工列表、以及如何使用 内容描述－表示内容的符号 补充信息－数据类型、预设值、限制等其他信息
名称 别名 何处使用/如何使用 描述 电话号码 无 预计设置（输入） 拨号（输出） 电话号码＝[当地分机号|外地号码] 当地分机号＝[2001|2002…|2999] 外地号码＝9 + [当地号码|长途号码] 当地号码＝ 前缀＋访问的号码 长途号码＝(1) + 区号 +当地号码 前缀 ＝ [795|799|874|877] 访问的号码＝ *任意四位串号码*
面向对象需求分析方法
OOA过程
CMMI/SPCA-20
火龙果 整理
数据建模－数据对象
• 数据对象是任何必须被软件系统理解的复合信息的表示， 复合信息是指若干不同的特征或属性的事物。 • 数据对象包括：外部实体、事务、行为、事件、角色、组 织单元、地点或结构。 • 数据对象是相互关联的。 • 数据对象只封装了数据，在数据对象中没有指向作用于数 据的操作的引用。
cmmi指导下的软件需求管理与需求开发的方法研究和应用
CMMI指导下的软件需求管理与需求开发的方法研究和应用实际应用情况1. 应用背景在软件开发过程中，需求管理与开发是关键的环节。
管理好需求可以帮助团队明确目标、合理分工、提高效率；开发好需求可以确保软件产品满足用户的期望，并提供持续的价值。
CMMI（软件能力成熟度模型）是一种广泛应用的软件过程改进框架，为组织提供了有效的指导和方法来管理软件项目和过程，其中包括软件需求管理与开发的方法。
2. 应用过程2.1 CMMI下的需求管理需求管理是确保需求得到清晰定义、有效跟踪和控制的过程。
CMMI提供了以下几个重要的步骤和方法：2.1.1 需求获取需求获取是和用户、利益相关者沟通，了解和收集需求的过程。
通过以下方法来进行需求获取： - 等待需求提供：等待用户主动提供需求，但这种方式不能很好地满足用户潜在的需求。
- 问卷调查：通过问卷调查用户，了解用户对系统的需求和期望。
- 现场观察：观察用户的工作环境，深入了解用户需求。
- 采访：直接与用户交流，深入了解用户需求和期望。
2.1.2 需求分析需求分析是将收集到的需求进行整理、分析和规划的过程。
在CMMI下，需求分析主要包括以下几个步骤： - 需求整理：将收集到的需求进行整理和分类，清晰明确需求的范围和目标。
- 需求分解：将整体需求分解为更细粒度的子需求，便于后续的开发和跟踪。
- 需求优先级确定：根据需求的重要性和紧迫性，确定不同需求的优先级，合理安排开发计划。
- 需求可行性评估：评估需求的可实施性和可行性，包括技术可行性、资源可行性等。
2.1.3 需求跟踪与变更控制需求跟踪和变更控制是在需求开发过程中，确保需求的变更得到控制和跟踪的重要环节。
CMMI提供了以下方法来实现需求跟踪和变更控制： - 需求跟踪矩阵：通过需求跟踪矩阵，可以清晰地查看需求之间的关系，以及需求与代码的对应关系。
- 变更管理：对需求的变更进行管理，包括提出变更申请、评估变更影响、批准或拒绝变更等。
cmmi项目管理流程
CMMI项目管理流程导言在当今的商业环境中，项目管理成为了一个关键的能力。
项目管理不仅仅用于组织的内部项目，也被广泛应用于企业间的合作项目。
为了提高项目管理的质量和效率，许多组织开始采用CMMI（Capability Maturity Model Integration）项目管理流程。
CMMI项目管理流程是一种基于最佳实践和标准化的方法，有助于组织在项目管理方面取得卓越的结果。
本文将对CMMI项目管理流程进行全面、详细、完整且深入的探讨。
一、CMMI项目管理流程概述CMMI项目管理流程是一个系统的框架，旨在为组织提供一种结构化的方法来管理项目。
它基于CMMI模型，该模型是由管理科学研究中心（SEI）提供的一种标准化的项目管理方法。
CMMI项目管理流程能够帮助组织在项目的所有阶段实现良好的管理和控制。
二、CMMI项目管理的基本原则CMMI项目管理流程遵循以下基本原则： 1. 组织的管理决策应该是基于实证数据和事实的。
2. 项目管理应该采用一种流程化的方法来执行。
3. 项目管理应该根据业务目标和项目目标进行调整。
4. 项目管理应该强调团队合作和沟通。
5. 项目管理应该注重风险管理和问题解决。
三、CMMI项目管理的过程CMMI项目管理流程包括以下几个关键过程：3.1 过程管理过程管理是CMMI项目管理的基础。
在这个过程中，组织为项目制定了一套标准的过程和方法，以确保项目的目标得以实现。
过程管理包括项目计划、需求管理、风险管理、质量管理和变更管理等方面。
3.1.1 项目计划在项目计划过程中，项目经理制定项目的范围、目标、可交付成果和时间表等方面的计划。
这个过程中需要明确项目的目标和关键路径，以便有效地分配资源和管理进度。
3.1.2 需求管理在需求管理过程中，项目团队与客户和利益相关方一起明确项目的需求和期望。
这个过程中需要进行需求分析、需求确认和需求变更管理，以确保项目的交付能够满足利益相关方的期望。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
CMMI需求管理规范
目录
一．概述 (3)
二．需求管理的基本活动 (3)
1、需求提出 (3)
2、需求分析及评审 (3)
3、需求计划定制及跟踪 (3)
4、需求变更控制 (3)
5、需求制度建立及其优化 (4)
6、需求成本控制 (4)
三．项目实践过程示例 (4)
1 、建立需求管理制度 (4)
2、需求接收及其分析 (5)
3、需求评审 (5)
4、需求计划定制及跟踪 (5)
5、需求开发及更新过程 (5)
6、需求变更 (5)
7、团队培训 (5)
8、过程改进 (6)
一．概述
项目需求管理（Requirements Management, REQM）的目的，在于管理项目产品及产品组件的需求，并界定这些需求与项目计划及工作产品间的差异。
项目实行适当的步骤，确保议定的需求是受管理的，以支持项目策划和执行的需要。
需求管理也须记录需求变更及其理由，并维护原始需求与所有产品和产品组件需求的间的双向追溯性。
从实践意义上讲，需求是针对客户各类需求经双方（或多方）沟通确认后形成的一种协议，协议的范围是明确的、可控的。
在协议签订后，需求的计划有定制、进度有跟踪、结果有度量。
针对需求的变化，需要明确需求变化的原因及变更内容。
需求的紧急程度及严重程度可评估，以确定需求及其变更的优先级，从而排定切实可行的需求计划。
下面我们就如下几个方面对需求管理体系进行分析、研究：
1，需求的管理的基本活动
2，结合当前项目简述需求管理实践中的问题、解决方案（结合7命题）。
二．需求管理的基本活动
在需求管理过程中，包含如下关键活动：
1、需求提出
针对客户的需求提出，开发方进入需求了解环节。
需求了解采用访谈、文档、多方会议等形式采集基础信息，在此基础上结合系统原型进行差异化分析。
2、需求分析及评审
需求分析中，针对需求、系统差异进行差异记录并制定相应的矫正方案。
3、需求计划定制及跟踪
需求计划的定制以用户、开发团队、计划跟踪者协商一致的结果为依据。
其过程实质是取得用户对于进度的认可、取得团队对于进度的承诺。
其成果物—需求跟踪表，对于后续的需求跟踪起到警示标的作用。
4、需求变更控制
用户对于系统、需求的理解是渐进的过程，因此某种意义上说需求变更存在必然性。
如何有效率和有效果地管理这些新增需求或变更需求是很重要的。
如果需求变更控制不当，不但造成新的需求变更得不到满足，而且对于需求进度的管理、对于系统稳定性的影响都将是负面的。
变更控制，需要追溯变更的缘由，记录变更的原因、内容，并做好变更比例的度量。
保证需求的可追溯性，对于需求变更管理至关重要；在进行需求变更对项目计划、活动及工作产品的影响评估时尤其需要需求追溯表这些管理工具。
5、需求制度建立及其优化
在需求管理过程中的各个环节，存在较多的争执点，这就需要制度进行明确。
形成一个系统的、规范的制度，使需求管理过程可细化度量；制度的形成需要配备对应的资源，比如需求跟踪工具、需求干系人的培训管理。
通过制度保证需求过程可监控、上层管理者可以跟踪需求的进展情况等。
6、需求成本控制
需求开发面临成本投入的现实，需求开发本身、需求管理本身，因需求开发、管理造成的物力、人力消耗都是现实的成本。
在日常系统运作中，对于需求必要性的评审，对于系统变更的控制，对于人员的培训都是提高效率降低总成本的方式。
三．项目实践过程示例
（一）需求管理过程中的问题
1、需求提交后，存在需求过于简单描述不清等问题，需求分析压力较大。
2、需求分析时，不够细化或完全按照客户的意见进行系统分析，没有考虑系统内
的关联性。
存在双方理解差异，待功能交付后，用户提出所见非所求，造成需
求、bug争论不休，需求变更及bug修复频繁，影响系统稳定并造成成本消耗。
3、需求的优先级没有划定，需求进度难以排定，造成开发压力较大且用户不满意
的局面。
4、过多的争论造成了临时事务增多，对于需求开发的支持滞后，项目整体进展缓
慢，客户满意度较低。
（二）问题的解决方案（结合7命题）
1 、建立需求管理制度
会同业务部门、系统建设部门及其上级管理者采用会议、文档确认等形式就需求的提交、需求优先级划分、需求规范进行。
涉及到领导命题（需要高层领导的
发起、参与和支持）、投资命题（需要计划，配备专职人员以及管理时间和资金投
入）及团队命题（需要全体人员的协作和努力）。
1）需要向领导层阐述需求管理制度形成、按新流程推进后，可以在项目资金整体投入方面得到控制，因为需求本身质量和开发质量都得以提升，日常争论降低，分析、开发效率都得到提高。
2）该制度的形成需要配备相应的工具，对于需求的计划跟踪、需求评审、需求质量控制进行有效监控。
需要加强人员培训，熟悉相应的工具；需要增加若干审批环节，增加管理资金投入。
3）新制度形成会造成各环节流程变动，对于过往习惯造成影响，这就需要整个团队的适应。
需要各部门群策群力，才能将制度落到实处。
2、需求接收及其分析
需求文档提供及分析文档形成也涉及到了文档命题（需要文档（解释和沟通）支持过程活动可视化，使得复杂的智力密集的支持过程活动得到有效地控制）。
在开发前期形成双方认可的文档是减少功能交付后争议的有效办法。
3、需求评审
在需求文档和需求分析文档形成后，可会同专家小组，对于需求提交、分析的质量进行监控，在评审过程中就双方理解的差异进行消除，并对后续需求提交、分析的质量提出指导意见。
评审后，形成评审文档备案。
4、需求计划定制及跟踪
在需求经过多方确认后，可根据现有开发团队的人力结合需求的优先级确定需求开发计划，并将计划登记入需求跟踪表，需求过程进行统一跟踪，各部门均可获取当前需求的进展状态。
如果对于计划有调整需求的，需要有明确的审批机制，评估调整计划对于项目整体进度的影响，经过相关干系人协调一致后，予以调整。
5、需求开发及更新过程
需求开发阶段，需要在设计文档、测试文档提供方面进行加强，提高需求开发的整体质量。
需求提交纳入配置管理库，由专人进行版本的更新，在更新时检查对应文档的提供情况。
6、需求变更
变更需要在新流程中明确登记原因、追溯变更设计的功能点，并对变更进行审核。
变更得到严格控制，并定期对各部门变更进行统计，提高需求提交的计划性和需求本身的质量。
7、团队培训
成熟度命题（需要不断地组织学习以持续地改进全组织的软件支持过程能力。
一方面团队需要学习新流程推行中需要遵循的规范，另一方面团队也需要接触新流程配套使用的工具。
同时需要不断提升自身业务、技术水平以适应新流程。
效果命题：需要明确地努力和定期地强化其效果。
通过不断增加团队的适应水平，使新流程的效果得以显现，不断的效果显现本身就是对团队的激励，使得新流程的认可度不断提升。
8、过程改进
过程命题：需要仔细地进行过程设计来减轻甚至消除软件支持过程认知障碍并提高群体认知活动的效力和效率。
新流程的形成必然存在一定的瑕疵，因此在流
程推进过程中需要不断总结，消除新流程推进过程中的问题。
使各部门消除推
进新流程的顾虑，体现新流程的价值。
（三）形成的流程
经过多方讨论，我们形成了需求管理理流程
（四）改进小结
在执行新的管理制度后，得到领导层的支持，并有序推进。
各业务部门在实践过程中发现新的流程带来了需求开发质量的提高和团队需求进度承诺的有效，也普遍接受了新的管理流程。
开发在推行新流程后，减少了临时事务，客户满意度提高，团队士气得以提升，也普遍接受了新的流程。
领导层在经过数月后发现需求提交和开发质量大幅度提升、需求进度可控，对项目团队和各部门的工作都给予了较高评价！
.。