需求管理过程文件

确保把对需求的更改反映到项目计划、活动和工作产品中。确保项目经过确认的用户需求，能被有效的管理、维护、跟踪，并正确的实2范围从“需求开发”的“需求确认”结束开始，直到项目结束为止；有些项目可能3术语定义EPG：工程过程组，组织、执行、维护软件过程改进的所有活动。CCB：ChangeControlBoard变更控制委员会(项目经理、客户、高级经理、CCB的各项活动的影响也非常小，甚至可以忽略不计时，CCB可由项目经理和客户组成；当变更的影响仍非常小，对项目的阶段性进度的影响也由项目经理、项目内的主要成员、高级经理和客户组成。技术管理委员会：对有关技术问题进行评审、审查的组织，一般执行同行评审一般包括需求开发的全部工作产品(需求文档、评审记录及参考文档)。是项目计4职责审求求5裁剪指南根据项目实际情况，包括需求明确程度、项目规模、工期、变更情况、项目经理可对本过程进行裁剪。6过程需求小组(一般包括项目经理、系统分析员)依据经过“需求开发”而形成的6.1.1概要图6.1.2启动条件6.1.3输入“项目已定义的软件过程”6.1.4活动6.1.4.1学习和理解“需求开发”阶段的产生的需求文档档”，《用户需求说明书》一般织、提炼、概括后的用户提出的需求；《系统需求规格说明书》是经过转讲解人一般为项目经理、后续阶段活动的项目组成员(例如：系统设计阶段的系统设计员，开发阶段的编码人员，测试阶段的测试人员，实施过程的实施人员和验收人员等)。在这一过程中一定要成需求小组，当系统分析员完成需求开发、系统分析组时，项目经理必须有能力对需求进行维护，项目经理必须在系统化产生的影响进行讲解。6.1.4.2获得对需求的承诺者达成共识，确保项目的各个阶段的参与者能够对当前的“需求”做出承诺。每个项目参与者都在理解了需求的基础之上，做出重新“需求开发”阶段之后的所有项目相关人续阶段的各个参与者对“需求”的确认和承求承诺”的《用户需求说明书》、《系统需求6.1.4.3建立需求跟踪矩阵“项目已定义的软件过程”来建立《需求跟踪矩阵》。确定跟踪的时间、频率、间出各个需求项目，并按“需求文档”中定义好计划，参与项目计划的评审。需求管理安排的时间一般是里程碑或周这样的阶段性6.1.5输出6.1.6关闭标准需求的状态、工作产品与需求之间的不一致等6.2.1概要图6.2.2启动条件跟踪时刻6.2.3输入6.2.4活动6.2.4.1接收当前阶段工作产品，维护矩阵中，按《需求跟踪矩阵》中计划好的时作产品。后续阶段过程的执行人或参与者(例如设计阶统设计员)应将当前阶段的工作产品为需求小组讲解，直到需求小组理解为需求变更”的结果，修改更”影响到了“项目计划”和“进度安排”时，《需求跟踪矩阵》中的时间安排也应相应发生变化。变化后的《需求跟踪6.2.4.2发现不一致检查。作产品是否都能满足“需求”中的某个或6.2.4.3分析不一致、制定解决方案大不一致发生时，有必要召集技术管理委员会来分析“需求不一致”，制定和求：经过技术管理委员会与客户的讨论协商确定通过修改需求来解决不段性工作产品：需求小组召集项目当前阶段的相关人员，确定一个修改。致给予认同，当后续阶段产生的不一致是因为这个不一致引起的6.2.4.4执行纠正活动别出由于对需求基线的变更而导致的必须对项目计划、活动和工作除不一解决方案来消除不一致，并将消决，或技术管理委员会认可不一致，则关闭不一致，否则重新解决不一致，或重6.2.4.5需求管理的记录动的过程，结果，需求的不一致以及原因、解决方法等分别记录在《个人周报》或相关的文档中，提交给项目经理。项目经理对这些内容6.2.5输出6.2.6关闭标准的需求变更请求，与相关人员一起分析请求，给出解6.3.1概要图6.3.2启动条件6.3.3输入6.3.4活动6.3.4.1收集需求变更请求需求小组收集项目相关方(主要是客户)的需求变更请求(客户提出需求变更的可能的方式：电话、传真、邮件、会议纪要等，并且这些记录的文件或其他的方式被客户给予确认)，填写《需求变更申请》；变更的提出人应在《需求变更申请》6.3.4.2分析变更申请同变更的提出人一起分析变更申请，确定影响、拟定解决方案。同时需求小组应有拟定解决方案时与项目组其他成员一同来完成，这样可以保证解决立即解决：暂停项目的当前正常的进行，修改需求、修改计划、修改设计、修6.3.4.3评审变更请求及解决方案CCB围。作的进展及阶段的进他功能模块的影响、系统非功能性指标(稳定性)的影响、对系统质量的影响、对风险的影响。案，刚退回到分析变更申请的过程。直到通过为案及评6.3.4.4获得对变更的承诺关方获得相应的承诺。承诺方式可以双方认可6.3.4.5执行需求变更活动求被变更了，其可能影响的项目过程也会一起发生变化。受“需求变需求小组依据确认的解决方案，召集项目组成需求变更影响到《项目计划》，则重