需求变更管理流程

需求变更管理流程
需求变更管理流程

需求变更流程规范

一、引言

由于目前公司内部对产品的需求变动都只是口头或邮件中进行通知,并没有进行内部评审和相关需求变动后的记录,导致后续出的产品某些需求增加了,某些没有进行增加。这样就会导致测试得到的信息不完整,以及后续产品的维护困难。在这里书写一份规范说明书,希望能得到一些改善。

二、目的

控制需求变化引起的开发、测试与需求不一致的情况,约束需求分析的完整性。保证每一次的需求改动都能有相关的记录。

三、角色与职责

1、市场人员

1)负责产品需求的提交以及解答项目开发过程中遇到的需求问题。

2)负责与客户的沟通确认,并及时反馈客户最新需求。

3)负责与项目经理的沟通

4)负责与客户协调沟通需求变更中需求部分存在的差异

5)负责将需求变更中的需求提供给客户签字确认

2、项目组长

1)负责协调变更的需求并对变更的需求有拒绝的权利

2)负责对变更的需求部分设计的修改

3)保证项目的开发与需求的一致性

4)确定开发进度是否需要进行变更

5)分配新需求给相关开发人员

3、测试组长

1)负责相应测试需求分析书的修改

2)负责把最新需求及时传达到测试人员

3)保证测试进度与开发进度一致性

4)负责与项目组长及时确认最新需求

4、测试人员

1)负责更改测试用例,保证用例与需求同步

2)调控测试进度,保证任务的正常完成

5、项目经理

1)参与需求修改的评审工作

2)最终确认需求是否进行修改

6、配置管理员

1)负责更新需求文档,记录需求更改记录

2)负责需求变更信息的发布与跟踪

四、需求变更处理流程图

需求变更有3种情况:

一种是客户提出来要进行修改,增加需求等,

一种是公司内部人员提交的建议,还有就是开发人员自己修改流程(修改后的效果比前面的更加好),另外需求变更可能是比较小的改动,

另外一种就是可能涉及到整个产品流程,这就是比较大的需求改动。

下面就按照上面的3种情况进行画出流程图:

1、需求变更流程(客户提出需求变更)

1)执行条件:

客户提出需求变更

图:需求变更流程(客户提出需求变更)

2)流程说明:

需求来源:客户提交相关需求变更

审核需求变更:评估如果实现该需求,需要的时间、人力成本多少;并评估对项目工期影响有多大?判断那些需求能够目前解决,那些需要留到下一版本解决。最后输出一份审核确认表反馈给客户,和客户进行商讨。参与评审的人员要包含项目经理,项目组长,测试组长,市场人员。

配置管理员:对变更需求进行记录,需求文档进行更新,并通知相关人员

项目组长:负责调整相关开发进度表,评估任务时间,分发给相关开发人员

测试组长:根据变更需求和开发进度,对测试进度进行相对应调整,并修改测试需求分析书,分发需求更新给相关测试人员。测试人员对用例进行补充,修改。

客户提交的变更需求最后必须让客户进行签字确认。

2、需求变更流程(内部提出需求变更)

1)执行条件:

对项目进度不会影响严重

与客户原始需求无偏差

图:需求变更流程(内部提出需求变更)

2)流程说明:

内部需求变更来源:公司内部人员发现逻辑,需求上的问题,或功能上的建议以及开发、测试人员提出的需求不一致内容。

需求变更类型:需求有误、需求有遗漏、需求不明确。

需求变更审核:内部提交的需求应该经过项目经理,项目组长,测试组长,市场人员共同的确认才能确认是否修改。

项目组长:评审需求变更部分的工作量,判断需求变更的内容是否对开发进度有影响,如果需求变更对开发进度有影响,项目组长可以拒绝变更;将变更内容放入下一版本进行修改,若市场人员认为必须在本版中进行修改,项目组长可以将变更的内容提交给项目经理进行处理,并决定是否在本版中进行修改。

需求信息发布:经过需求人员和项目组长的沟通、协调确定在本版中进行修改的需求变更,需求人员需要将变更内容的信息,以邮件方式通知相关人员。

配置管理员:对需求变更进行备案。

开发,测试:开发、测试人员接收到需求变更内容后首先审核设计文档和测试文档,修改变更的地方。并根据变更后的文档进行开发和测试。

五、附件

版权声明:原创作品,允许转载,转载时请务必以超链接形式标明文章原始出处、作者信息和本声明,否则将追究法律责任。

软件项目变更管理流程

变更管理流程 1概述 ....................................................................................... 错误!未定义书签。2变更流程 .. (2) 2.1摘要 (2) 2.2提交变更申请 (2) 2.3审核变更申请 (2) 2.4识别变更可行性 (2) 2.5批准变更申请 (3) 2.6实施变更申请 (3) 3变更任务 (3) 3.1变更申请人 (3) 3.2变更经理 (3) 3.3变更可研小组 (3) 3.4变更审批小组 (4) 3.5变更实施小组 (4) 4变更登记 (4) 5变更模板 (4)

1 概述 描述变更管理的目的。就项目中变更管理的总体流程提供一份概述,如: 变更管理流程是成功交付项目的基础。变更管理流程确保对在项目环境中的每个变更在实施以前都得以恰当的定义、评估和审批。 对项目的变更管理是通过对以下五个关键步骤的实施引入的。,: 提交和接收变更申请 审核和记录变更申请 确定变更申请的可行性 批准变更申请 实施和结束变更申请 2 变更流程 对将要执行的流程和程序做一个图表概述,以启动、实施项目中的变更并审核其效果。例如:Provide a diagrammatic representation of the processes and procedures to be undertaken in order to initiate, implement and review the effects of changes within the project. An example follows: 2.1 概要 下图对将要执行的变更流程和程序做了一个概述,以有效地管理与项目相关的变更。同时也明确的变更管理中的职责分工。 2.2 提交变更申请 本步骤中项目团队中的任何成员都可以提交项目变更申请,需要完成以下工作: 变更申请人识别项目中任何方面的变更需求(如范围、可交付成果、时限、组织). 变更申请人完成变更申请表(CRF),并将其呈交变更经理。变更申请表对需要进行的变更做一概述,包括: ?变更描述 ?变更原因(包括商业驱动) ?变更利益 ?变更成本 ?变更带来的影响 ?支持性文件 2.3 审核变更申请 本步骤授权变更经理对变更申请表进行审核,以决定是否需要一份充分的可行性研究报告以供变更批准小组评估变更可能带来的全部影响。做出上述决定的基本依据是: 呈交的可选择变更数目Number of change options presented 申请变更可选反性的复杂程度Complexity of the change options requested 提出的变更解决方案的衡量Scale of the change solutions proposed 变更经理将不会在变更日志中打开一份变更申请并记录是否需要一个变更可行性研究。The Change Manager will open a 慍hange Request’ in the Change Log and record whether or not a change feasibility study is required. 2.4 识别变更可行性 本步骤涉及完成一份完整的变更可行性研究,以确保对所有的变更可选项进行调查并上报,变更可行性研究包括对以下各项的定义: 变更需求 变更可选项Change options 变更成本及利益 变更风险及事项Change risks and issues 变更带来的影响

需求管理过程

需求管理过程 本文件属深圳天源迪科信息技术股份有限公司所有, 未经书面许可,不得以任何形式复印或传播。 2008-1-31发布 2008-2-18 实施

文件建立/修改记录

目录 1 简介 (4) 1.1 目的 (4) 1.2 适用范围 (4) 1.3 背景描述 (4) 1.4 术语表 (4) 1.5 参考资料 (5) 2 总体描述 (5) 2.1 概述 (5) 2.2 职责分工 (5) 2.3 结构描述 (6) 3 活动描述 (7) 3.1 需求培训 (7) 3.2 建立需求跟踪矩阵 (8) 3.3 维护需求跟踪矩阵 (9) 3.4 检查一致性 (10) 3.5 采取更正行动 (11) 3.6 需求变更管理 (12) 4 附录 (13) 4.1 附录A-相关过程 (13) 4.2 附录B-相关规范、指南 (13) 4.3 附录C-相关模板列表 (13)

1简介 1.1目的 制定需求管理过程的目的是管理产品和组件的需求,识别需求与项目计划及工作产品之间的不一致,有效地控制需求变更、以及跟踪需求的演进,指导项目组管理需求。 1.2适用范围 本过程适用于公司所有的软件项目,贯穿项目的整个生命周期。 1.3背景描述 无。 1.4术语表 ●软件需求:用户解决某一问题或者得到某一目标所需的软件功能。 ●基线:基线是经过评审和批准的配置项的集合,其作用是明确划分项目各阶段,确定各阶 段的结束点。在项目的开发过程中,最基本的基线有需求基线、开发基线、发布基线等。 ●配置控制委员会(Configuration Control Board):简称CCB,是确定配置基线,评估、批准 变更,并保证已批准变更的实施的组织。 ●需求变更:需求变更主要来自三个方面-客户、高层和开发人员。因此,无论哪一方面提 出需求变更的要求,都应当对变更请求进行评估。需求变更通常包括三项内容:新增需求、修改需求、删除需求。每一种变更都可能影响到其他需求的变化,因此在进行变更时需要利用需求跟踪记录。 ●需求跟踪:需求跟踪主要是跟踪需求及其实现之间的一致性,需求跟踪通过管理需求跟踪 记录来进行。在需求的阶段已经建立了需求跟踪记录,在后续的开发过程中,通过不断填写需求跟踪记录,将设计、开发和测试等阶段产品与需求进行一一对应。同时,在任何一个阶段发生变更时,都要检查需求跟踪记录是否需要进行变更。需求跟踪是分布在各个开发阶段之中的。 ●涉众:专指所有会受到项目结果重大影响的人。要有效地解决任何复杂的问题,就会涉及 到满足不同涉众的需要。涉众通常会对问题持有不同的观点,因而必须用所提供的解决方案来满足不同的需要。许多涉众都是系统的用户。其中许多涉众只是系统的间接用户,或者只受到系统所影响的业务结果的影响。还有许多涉众是系统的经济型买主或支持者。了解涉众的组成及其特定需要是开发有效解决方案的关键。典型的涉众有客户(或客户代表)、用户(或用户代表)、投资者、股东、生产经理、买方、项目经理、设计人员、测试

软件开发过程管理

软件开发过程管理流程

修改记录

目录 1编写背景 (4) 2编写目的 (4) 3名词解释 (4) 4适用范围 (5) 5公司各部门职责及关系 (5) 5.1项目管理委员会 (5) 5.2项目管理部与总工办 (5) 5.3公司各部门主要职责 (5) 5.3.1公司董事会 (5) 5.3.2总经理办公室 (6) 5.3.3项目管理委员会(简称:PMO) (6) 5.3.4项目管理部 (6) 5.3.5总工办 (7) 5.3.6项目经理 (7) 5.3.7测试组 (7) 5.3.8其它相关部门 (7) 6项目总体工作流程 (8) 6.1工作流程 (8) 6.2流程说明 (9) 7项目过程说明 (11) 7.1启动过程 (12) 7.1.1可行性研究阶段 (12) 7.2计划过程 (12) 7.2.1项目立项阶段 (12) 7.3执行过程 (14) 7.3.1需求分析阶段 (14) 7.3.2概要设计阶段 (15) 7.3.3代码开发阶段 (15) 7.3.4软件测试阶段 (16) 7.4监控过程 (16) 7.5收尾过程 (17) 7.5.1产品交付阶段 (17) 7.5.2产品验收阶段 (18) 8项目记录文档汇总 (18)

1文档介绍 1.1编写背景 根据公司业务特点及行业特点,公司主要以项目开发为主,那么实施全面的项目管理,将公司所有在建、新建的项目纳入项目管理的范畴之内就显得尤为重要。 因此,公司重新组建了项目管理部,在公司范围内推进项目的规范化运作,同时检验公司项目管理机制的缺陷,提出项目管理过程的改进建议和意见,更好的为公司的业务目标服务。 1.2编写目的 本文档将从项目管理的启动过程、计划过程、执行过程、监控过程、收尾过程五个过程,全面阐述项目管理的工作职能,每个过程包含那些阶段,各阶段的工作内容,相关的参与部门,参与部门的工作职责以及相应的考核指标,力求规范化管理公司的所有项目,保障公司项目保质保量按期完成。 1.3名词解释 项目基线:指项目生命周期内产生的文档,在经过公司评审通过后,该文档将作为基线文档,后续的所有变更都是基于该基线文档。 干系人:指参与项目活动或受项目活动影响的人,包括项目发起人、项目组、支持人员、客户、供应商,甚至是项目的反对者。 项目发起人:指项目的发起者,任何有创新想法的人员均可成为项目发起人。 项目组:指项目经理为具体项目而临时组建的团队,团队既可以是部门内部人员,也可以跨部门组建项目团队。 过程文档:指辅助项目经理或公司对项目过程进行管控的文档。 产品文档:指与项目开发紧密相关的文档,并作为项目的一部分交付给最终

产品需求管理流程

中国联通音乐运营中心产品需求管理流程一、目的 为提高技术部与其他部门需求沟通效率,提高需求书质量,规范化需求文档,确保中音与厂商之间建立对需求的共同理解,特制定此需求管理流程。 其中产品包括:下载、流媒体、炫铃、铃音盒、电台、下载包、俱乐部以及对以上产品的组合形式。 产品需求涉及到以下部件中多个的修改:各门户、系统后台和各省分平台及总部平台。 产品需求不包括:单独对门户、后台或接口功能的优化和修改、统计分析、问题和故障的处理等。 二、需求管理流程 需求流程管理主要包含如下三个部分: 1)需求调研:产品需求方的产品负责人主导组织进行需求调研,汇总、分析和整理需求。 2)需求评审:产品需求方召开组织需求评审会,评审团对产品需求进行评审。评审通过则启动开发,由技术部项目负责人组织厂商

制定开发计划,产品需求方确认开发计划。 3)需求变更。 三、需求调研 需求方产品负责人参照需求书模板(见附件章节),拟定需求书初稿,提交技术部,技术部根据需求情况分配需求项目负责人对口需求。 在此阶段由产品负责人主导,技术部配合,协调相关单位、部门同事进行需求调研工作,开展详细的调研,对新产品的需求进行提炼、归纳和汇总,并且按照需求模板的从各方面详细考虑完善需求文档。 在需求的描述中,要首先明确项目的边界,哪些是业务系统内部的,哪些是业务系统外部的,并应该遵循如下规则: ●相关的需求都得到了识别和描述,确保需求的完整性; ●各个需求之间不产生冲突,确保需求的一致性; ●正确描述系统需求,引用的资料有明确的出处,避免模糊词语 的使用,确保需求的正确性; ●定义必要的术语,适当结合图形,结构图等方式进行描述,确 保需求无二性; ●确保描述的需求可以通过适当的方法进行验证,确保需求的可 测性;

IBM软件产品需求管理流程

IBM 软件产品需求管理流程 1. 简介 IBM 软件产品的版本(V.R.M.F)从市场规划和客户需求开始,到研发以及后续的交付遵循IB M软件部集成产品设计(IPD)流程。IBM 软件产品需求管理流程是IPD的一个体现,也就是一个由市场/客户驱动的,跨市场部门、研发产品管理部门及研发工程部门的端到端需求管理流程。同时,此次内容我们将描述IPD和产品需求管理流程,及流程中的角色(市场、研发产品管理部门及研发工程部门),以及他们之间是如何通过协作来管理需求的。 2. 背景——IPD IPD指导如何对软件产品发布版本进行投资决策和如何协调部门间工作以实现这些决策所 定义目标,IBM软件产品需求管理基于IPD流程,要了解这个需求管理的流程,首先我们要了解IBM所有产品开发所遵循的IPD的流程,包括其决策点。 IPD流程分为六个步骤: 1.概念:即概念验证阶段,主要对需求包进行评审,以确定其是否有足够的商业价值; 2.计划:即资源投入计划阶段,主要对需求包进行评估,以确定是否有足够的资源且在 一定的时间范围内将需求包开发出来; 3.开发:即对需求包进行开发成产品阶段; 4.验证:即对产品进行验证阶段; 5.交付:即将产品交付市场阶段; 6.生命周期:即产品在市场上销售,使用,维护和退出市场的阶段。 其中包括了几个重要的决策检查点(DCP):

1.概念决策检查点:即经过概念阶段各方面进行的一系列评审,在此检查点确定(1) 我们对需求包是否有足够的理解;(2)需求包是否有足够的商业价值。如果是,继续进入计划阶段; 2.计划决策检查点:即经过计划阶段的评估,在此检查点确定(1)我们是否有足够的 资源在既定的时间范围内完成需求包的开发(2)研发部门是否能在(1)的估计上承诺进行开发。如果是,继续进入开发阶段; 3.可交付决策检查点:即经过开发和验证阶段,在此检查点确定(1)产品是否质量合 格以交付给客户(2)我们产品的相应支持和销售是否已经准备好服务客户,如果是,产品交付市场; 4.生命周期结束决策检查点:即产品在市场使用一定时期后,在此检查点确定产品是否 退出市场。 一个产品从市场需求开始,经过概念验证,时间、资源等计划的支持,然后进行开发,验证,直至发布到市场供客户使用,最后在某个特定的时候结束产品在市场上的销售,在IBM都遵循着IPD流程。在其中过程中,这个产品的概念是否被接受,是否能得到资源上的投入的承诺,是否通过最终验证可以在市场上发布,以及什么时候在市场上停售,这些关键的决策都通过相应的委员会在不同的决策点上进行决策。 3. IPD 与产品需求管理流程 以上描述了IBM IPD的基本概念,我们接下来看IBM软件产品的需求管理是如何基于IPD 的。首先,请看下图一:产品需求管理流程。

软件需求管理之需求分析

软件产品经理之需求管理 需求分析是通过需求收集获取的用户需求,选择一种业务导向的线索将零散的需求串 联起来,进行业务分析、消除矛盾,并在业务分析基础上结合系统现状进行系统分析并最 终形成方案和系统需求说明书的过程。 需求分析总体分为8个步骤,按照顺序依次为:需求识别、业务流程/统计查询/接口 分析、数据实体分析、角色及使用场景分析、系统功能分析、数据割接分析、用户体验分析、非功能需求分析。 一、需求识别 需求人员在此步骤应该分析需求类别、需求复杂度和需求价值用来确定需求实施的优 先级。 1.需求类别确认:需求类别包含流程类需求、统计分析类需求、接口类需求,一个需 求可能为某一类型需求,也可能包含多类需求。确认需求类别后应对每类需求的数量进行 初步分析(比如流程类需求包含几个流程、统计分析类需求包含几个报表、接口类需求包 含几个接口); 2.需求复杂度分析:一般需求受理工作量在1-5人天的需求复杂度低,工作量在5-15人天的需求复杂度中,工作量在15人天以上需求复杂度高。(工作量表示需求受理全过 程需求人员需要付出的工作量)。 3.价值分析:需求人员收到需求后应根据收集需求内容初步分析需求痛点/目标、需求复杂度、业务重要程度确定需求价值,需求价值分析可参考如下模型: 二、业务流程/统计查询/接口分析 针对流程类需求必须进行业务流程分析,统计查询和接口类需求可不进行详细的流程 分析。 1.业务流程分为组织级、部门级和岗位级,部门级流程关注脉络需要分析涉及哪些具 体岗位、执行活动、每个活动之间的关联关系,它是需求分析的主线条,也是流程分析的 主要产物;组织级流程关注宏观一般不会直接绘制,是对部门级流程的概括和抽象,岗位 级流程关注每个业务活动的执行步骤属需求细节范畴,在流程分析阶段不要过度进入细节。 2.需求识别阶段确认的流程均为部门级流程,需求人员在进行流程分析应遵循如下方法: 1)业务流程确认:一个流程为一个业务事件一般是外部角色发起或系统内部主动发起(比如时间事件或状态事件),发起后会触发一系列业务活动; 2)角色及业务活动确认:流程图中的每个泳道都必须对应到角色,每个角色对应多个 业务活动,需求人员在确认业务活动时一定要保证活动的粒度,一个业务活动一定是由一 个角色完成且每个业务活动都是有价值的活动(比如项目输入项目名称是一个执行步骤, 这个动作没有价值,项目经理查询项目信息就是一个业务活动),在需求描述时针对线下 活动或新增活动应该应标识区分;

需求管理规范

目录 2 1.前言......................................................................................................................... 3 2.需求管理背景......................................................................................................... 3 3.需求管理流程......................................................................................................... 4 4.指导规范................................................................................................................. 6 5.需求管理体系......................................................................................................... 6 5.1.制度 .............................................................................................................. 7(一)总则 .............................................................................................................. 7(二)机构职责 ...................................................................................................... (三)总体工作流程 ............................................................................................ 10 10(四)需求提出 .................................................................................................... 10(五)需求分析 .................................................................................................... 11(六)需求评审 .................................................................................................... 12(七)需求跟踪 .................................................................................................... 12(八)需求实现 .................................................................................................... 12(九)附则 ............................................................................................................ 13 5.2.细则 ............................................................................................................ 13 5.3.流程图 ........................................................................................................ 14 5.4.评审细则 .................................................................................................... 15 5.5.模板 ............................................................................................................ 5.6.编写指南 .................................................................................................... 16 16 6.合理性评价...........................................................................................................

项目变更管理流程

项目变更管理流程举例 1.变更提出人可以为: ●最终用户 ●开发方实施人员 ●开发方设计人员 ●本项目管理人员 2.变更的提出 由变更提出人填写《变更申请单》,并签字,提交给项目经理或项目经理指定的人员(如配置管理人员等) 3.变更的评估 1)由项目经理领导或指导具体人员负责对变更进行评估,评估参与者包括:项目经 理、项目技术总监、相关技术小组组长、相关技术人员、用户方技术人员、用户 代表 评估的方面包括: ?技术影响 ?范围影响 ?费用影响 ?时间影响 ?风险影响 ?资源影响 ?其他相关影响 2)由项目经理和用户方技术人员作出变更批准或不批准的决定,书面签字。并作相 应记录 3)项目经理负责调整变更所涉及的所有项目计划,保证计划的完整性 4)项目经理负责将相关决定通知和计划变更有关人员。对于重大变更就通知所有项

目干系人 5)对于将可能引起项目基线变更的变更申请,应由项目总监签字同意方为有效 项目变更管理流程举例 1.输入 ●客户合同 ●分包合同 ●项目计划 2.目标 保证项目质量满足合同的要求、公司的业务目标和对合同的法律要求 3.步骤 提出并审查变更申请 评估变更 评估变更涉及的范围及决定其对客户、公司业务和技术方面带来的影响 评估变更将会对项目交付物带来的变化 评估变更对项目计划和过程带来的影响 评估需要对项目计划基准和合同文本应作的修改 估算要实施该变更需要的资源和费用以及不作变更所需的费用,公司的分包商应提出一个相关的报价 提出如何处理该变更的建议 由适当的管理层审批该变更申请。审批层次应在项目计划中定义 把变更整合到项目计划中,记录变更 4.输出 项目计划 5.文档 变更申请表 变更记录表

软件项目-变更管理规程-模板

变更管理规程 变更管理规程 版本:V1.0

变更管理规程 目录 1介绍 (1) 1.1目的 (1) 1.2范围 (1) 1.3参考文档 (1) 2角色和职责 (1) 3流程图 (2) 4入口准则 (2) 5输入 (2) 6任务描述 (3) 6.1TCC010提交变更申请 (3) 6.2TCC020变更影响分析 (3) 6.3TCC030变更审批 (3) 6.4TCC040组织实施变更 (4) 6.5TCC050确认实施结果 (4) 6.6TCC060更新基线 (4) 7输出 (4) 8出口准则 (4)

变更管理规程1 介绍 1.1 目的 本文件的目的是描述项目变更管理应遵循的规程,以确保项目的变更被控制和管理起来。 1.2 范围 本文件适用于公司软件开发项目的变更活动。 1.3 参考文档 《配置管理过程》 《配置管理规范》 2 角色和职责

变更管理规程3 流程图 4 入口准则 1、软件开发过程之中的工作产品(如:需求设计文档、设计模型、代码及测试脚本等)有变更需求; 2、里程碑预计延期超过项目进度偏差的阈值;(项目进度偏差阈值根据组织级进度阈值制定,组织级 进度阈值为±20%) 5 输入 1、变更需求 2、进度计划 6 任务描述 6.1 TCC010提交变更申请 1. 变更申请人根据变更情况详细填写《变更申请表》提交给项目经理。

6.2 TCC020变更影响分析 1. 项目经理判断申请是否有效、是否存在类似申请,并指定相关人员对变更进行影响分析; 2. 项目经理根据影响分析的结果对变更申请进行初步审核,决定是否需要提交给CCB批准,并填 写《变更申请表》的审批意见: ?如果变更预计工作量导致在总工作量的2.5%以内,且变更不涉及到优先级为一级的需求变更,项目经理可直接通知实施人进行实施,在变更前应确定变更方案;这种变更一般不会导 致基线版本的变更、且对其他配置项影响不大; ?如果为影响项目进度、影响项目重要需求的变更,将此表送交CCB,进行审批。重大变更主要是正式基线的变更、该配置项变更将引起其他配置项的变更; ?如果是进度变更,一旦超过项目进度阈值,必须提交CCB审批; ?如果项目经理不能决定变更并填写《变更申请表》中相应的栏目,提交CCB进行评估; 3. 如果项目经理拒绝变更申请,则项目经理将结果反馈给变更申请人,流程结束。 6.3 TCC030变更审批 https://www.360docs.net/doc/9814649384.html,B分析变更申请,,并将审批意见填写在《变更申请表》里“CCB审批意见”栏。审批意见分 为以下三种: ?同意变更:同意此次变更申请,项目经理组织实施; ?推迟变更:变更被搁置,留作将来实施; ?拒绝变更:不同意此次变更申请,变更流程结束; 2. CCB负责人将《变更申请表》反馈给项目经理; 3. 对推迟变更和拒绝变更的申请,项目经理反馈给配置管理员和变更申请人;对同意变更的申请, 项目经理组织实施变更。 6.4 TCC040组织实施变更 1. 项目经理安排实施变更任务; 2. 项目经理通知配置管理员开放要实施变更的基线的权限,配置管理员填写《变更跟踪表》; 3. 变更实施人按照批准的《变更申请表》实施变更,变更完成后更新《需求跟踪矩阵》,并通知项 目经理;

产品需求分析与需求管理——如何搞定市场需求

产品需求分析与需求管理——如何搞定市场需求 主讲:董奎(十多年高科技企业的研发与管理实践经验,在某著名高科技企业工作期间,先后担当项目经理、系统工程师、产品经理、软件部经理) 课程对象:企业CEO/总经理、研发总监、研发经理/项目经理/技术经理/产品经理、产品规划专家等。 授课方式:讲师讲授+视频演绎+案例研讨+角色扮演+讲师点评。 【课程背景】 通过和众多国内科技企业接触,发现这些企业中普遍存在: 1、技术很牛,但最终倒闭的公司一大推;被技术人员嗤之以鼻的公司,反而活的还不错 2、研发从早忙到晚,产品开发的不少,但市场成功的产品屈指可数,开发的越多,死得越快 3、产品开发闭门造车,关注技术,不关注客户;产品开发出来才找客户、找卖点 4、了解市场的不懂技术,懂技术的不了解市场,不知道需求应该谁负责 5、需求准确把握决定产品成败,但没有人关注需求,即使偶尔想关注也不知道如何关注 6、需求的表达不够结构化,充斥着“故事会”格式的需求,直接影响了不同团队对需求理解的一致性 7、缺少完备的需求收集、汇总、分析机制,“公司神经末梢与大脑失去联系” 8、不能从自身能力提升来引导客户需求,反而天天在抱怨客户需求经常变动 9、针对需求大家“吵成一锅粥”:公司与客户吵,市场与开发吵,开发与测试吵,…… 不能满足客户需求、给客户创造价值,再牛的技术也没有价值。根据权威机构统计项目缺陷的56%来源于需求定义错误,80%的缺陷修复成本用于修复需求导致的错误,把技术变成金钱的不二选择关注、锁定、满足市场需求,创造客户价值。【课程重点】 1、如何确定目标客户,如何分析需求关系人?

2、如何从市场(客户)角度进行有效的客户需求收集? 3、围绕产品成功2个核心因素差异化+成本优势,整理产品需求 4、如何对客户需求进行整理和分析,形成产品包需求? 5、如何基于产品需求与竞争友商对比分析,确定我们的核心诉求,形成产品概念? 课程贯穿案例分享,详细讲解目标客户?客户要求?客户需求?产品包需求?产品概念确定全过程,详细讲解把技术转变为金钱的方法和工具(利润区、回溯分析、决策模型分析、KJ、$APPEALS、BSA、概念定义7个核心秘诀、破坏性创新的3石蕊实验、SweetPoint模型、基于不同产品生命周期的12个创新思路等),提升产品的竞争力,确保市场成功、财务成功。 【课程价值】 1、掌握从市场角度进行有效的客户需求收集的机制和方法,筛选高质量的客户需求; 2、掌握对客户需求进行整理、分类、分析的方法,提高各个角色对需求理解的一致性,最终形成产品包需求,明确产品的竞争优势与卖点; 3、掌握外部需求和内部需求一体化管理的机制,从而降低产品的端到端生命周期成本; 4、掌握产品核心诉求的提炼方法,确定有吸引力的产品概念; 5、掌握支撑研发需求工程各个阶段工作运作的工具和操作方法; 【培训内容】 一、案例分享 二、六个基本概念 1、什么是客户? 1)客户、用户、目标客户、潜在客户、可以送给竞争友商的毒药客户 2、什么是需求? 1)WANTS/NEEDS/DEMANDS、真假需求、客户需求、用户需求、产品需求、设计需求、需求规格、技术需求、非技术需求 2)案例:某运营上广告折射对需求五层次的理解 3、需求工作的2个基本点:

软件需求变更控制流程

需求变更控制流程 文档名称: 文档编号:___________________________ 归档日期:___________________________ 编写者: ________________ 孙_____________ 审核者:_______________________________ 批准者:_______________________________ *The information contained in this message is confidential and should not be disclosed to any third party whether or not you are the intended addressee indicated in the message. *本文件所含内容为保密信息,未经授权请勿随意复制、编改和泄露给任何第三方。 Copyright ?2009 xxx (Sha nghai) Ltd . All Rights Reserved 1.目的 指导项目部、软件部、质量部、测试部对产品的软件变更需求(简称CR进行控制和 管理,规范相应的作业流程,详细地定义了各流程环节中状态、角色和动作。 1.1明确流程中各角色的职责

1.2规范软件缺陷的变更过程 2.适用范围 所有项目的软件变更需求控制管理。 3.定义 CCB Cha ng Con trol Board 的缩写,指变更控制小组,由项目经理、产品经理、软件 开发小组长、软件部经理、测试部主管组成。 SCM Software Configuration Management 的缩写,软件配置管理员。 SQA软件质量保证 产品部门:简称PD 项目部门:简称PM 软件部门:简称SW 测试部门:简称TEST 质量部门:简称SQA 4.参考资料无 5.部门职责 5.1产品部 5.1.1制定产品战略规划,产品定位和定义。 5.1.2客户技术支持,需求分析与管理。 5.1.3提出需求变更申请到到质量部。 5.2质量部 5.2.1接收产品部提出的变更需求。 5.2.2成立项目需求变更评审(CCB小组,召集小组成员对需求变更进行评审。5.3项目部 5.3.1参与需求变更评审,确定需求变更的可行性。 5.3.2将评审通过的需求变更单以通知单的方式发到软件部和测试部。 5.4软件部 5.4.1对需求变更进行技术可行性评估,编写系统需求规格与可行性分析报告,包括技术实现方法、进度要求和风险分析结果以及建议等。 5.4.2确定需求变更信息,制定开发计划,安排代码设计,更新需求规格说明书。 5.5测试部 5.5.1参与需求变更评审工作。 5.5.2确定需求变更信息,制定测试计划,安排对新需求的功能测试。 5.6 CCB 负责对软件相关的变更需求(新需求、 bug修改、建议)进行审核,确定处理的方案。 6.作业流程

软件需求管理知识及案例

软件需求管理知识及案例 通过这篇文章,总结自己在工作实践中需求管理的方法论——普拉姆方法。总结这个方法论的特点是,用最轻量化的投入,与他人协作,并管理需求,推动需求上线。这套方 法论组合了项目管理、敏捷开发的知识,希望能对大家有所帮助。 1. 为什么要做需求管理? 1.1 我们的工作是否像救火 总是做迫在眉睫的事情,会令人丧失目标。——《普拉姆原则》 我在工作中体会到每天忙东忙西的处理需求,虽然每天都很充实,但确实极为耗费精力,时间长久就会缺乏动力。 上面讲的是个人的角度,如果一个组织或者团队面对大量的需求,在处理需求的时候,没有节奏和规划,会产生消极的影响。从小的方面看会影响团队士气,往大的方面看,会 影响组织实现既定的目标。 我的工作环境是,作为后台产品经理,处在业务运营团队和技术团队之间,要作为一 个桥梁,保障业务运营团队从我这里输出高质量的需求,也要保障具有不同知识背景团队,能过通过需求,高效沟通,快速推进需求上线。 于是,我就通过工作实践,形成了自己的管理需求方法论——普拉姆方法。 存在即有标识。——《普拉姆原则》 为了便于总结和归纳,我给这个方法论起了个名字。在需求管理中,需求的名称也是 很重要的因素,之后会提到。 1.2 需求管理是什么? 我的定义是,通过协作,管理需求内容和进程,实现成功发布。 便于理解这个概念,在这里讲一个海湾战争的故事。 在海湾战争中,美军在前期并没有派出大规模的地面部队进行战术打击。而是,派出 一批批的特种部队渗透到敌人境内,侦查清楚敌人重要的军事目标,并将精准坐标和信息,传递给后方。顷刻之间,海洋上的战舰派出飞机和战斧导弹对其进行精准轰炸,并取得战 术和战略上的胜利。 在这个例子中,特种部队是业务运营团队,飞机和战斧导弹是技术团队。产品经理通 过需求管理的方法论,用高效和轻量化的方式,去精准的做出需求,实现预期的效果。 1.3 宗旨是什么? 普拉姆方法的宗旨是积极主动,知识共享,相互尊重。 什么是宗旨?可以理解为这套方法论的价值观。这套方法论的每一个细节,都应该遵 循这个宗旨来实践,并遵循这个宗旨发展和进化。 “积极主动,知识共享,相互尊重”的宗旨,是我借鉴了美国西南航空的价值观。美 国西南航空是美国航空业受到911事件巨大打击的背景下,依然能够盈利的廉价航空。在航空业极为复杂的管理模式下,使用廉价航空的经营方式实现盈利,还是令人十分震撼的。所以,阅读了相关书籍之后,将美国西南航空的价值观的精华,吸纳为普拉姆方法的宗旨。

软件开发项目需求变更管理及应对之

软件开发工程需求变更经管及应对之道研究 变化并不是人们最害怕的,最怕的是跟不上变化的步伐。同样,在软件开发过程中需求的变更会给开发带来不确定性,但只要把需求变更作为重点、难点小心加以控制,软件开发的进度、成本和质量也就有了"安全"的基础。 需求变更经管的需求 需求变更是因为需求发生变化。根据软件工程思想,需求说明书一般要经过论证,如果在需求说明书经过论证以后,需要在原有需求基础上追加和补充新的需求或对原有需求进行修改和削减,均属于需求变更。 需求变更的出现主要是因为在工程的需求确定阶段,用户往往不能确切地定义自己需要什么。用户常常以为自己清楚,但实际上他们提出的需求只是依据当前的工作所需,而采用的新设备、新技术通常会改变他们的工作方式。或者要开发的系统对用户来说也是个未知数,他们以前没有过相关的使用经验。 随着开发工作的不断进展,系统开始展现功能的雏形,用户对系统的了解也逐步深入。于是,他们可能会想

到各种新的功能和特色,或对以前提出的要求进行改动。他们了解得越多,新的要求也就越多,需求变更因此不可避免地一次又一次出现。 这时,如果开发团队缺少明确的需求变更控制过程或采用的变更控制机制无效,抑或不按变更控制流程来经管需求变更,那么很可能造成工程进度拖延、成本不足、人力紧缺,甚至导致整个工程失败。当然,即使按照需求变更控制流程进行经管,由于受进度、成本等因素的制约,软件质量还是会受到不同程度的影响。但实施严格的软件需求经管会最大限度地控制需求变更给软件质量造成的负面影响,这也正是我们进行需求变更经管的目的所在。 六大原则 实施需求变更经管需要遵循如下原则: 1.建立需求基线。需求基线是需求变更的依据。在开发过程中,需求确定并经过评审后(用户参与评审),可以建立第一个需求基线。此后每次变更并经过评审后,都要重新确定新的需求基线。

项目变更管理流程

变更管理流程

文档控制文档分类 版本控制 批准

Method123 Array Management Methodology Version 2.0 December 2000 目录 1概述 ....................................................................................... 错误!未定义书签。2变更流程 .. (3) 2.1摘要 (3) 2.2提交变更申请 (5) 2.3审核变更申请 (5) 2.4识别变更可行性 (5) 2.5批准变更申请 (5) 2.6实施变更申请 (6) 3变更任务 (6) 3.1变更申请人 (6) 3.2变更经理 (6) 3.3变更可研小组 (6) 3.4变更审批小组 (7) 3.5变更实施小组 (7) 4变更登记 (7) 5变更模板 (7)

1 概述 描述变更管理的目的。就项目中变更管理的总体流程提供一份概述,如: 变更管理流程是成功交付项目的基础。变更管理流程确保对在项目环境中的每个变更在实施以前都得以恰当的定义、评估和审批。 对项目的变更管理是通过对以下五个关键步骤的实施引入的。,: 提交和接收变更申请 审核和记录变更申请 确定变更申请的可行性 批准变更申请 实施和结束变更申请 2 变更流程 对将要执行的流程和程序做一个图表概述,以启动、实施项目中的变更并审核其效果。例如:Provide a diagrammatic representation of the processes and procedures to be undertaken in order to initiate, implement and review the effects of changes within the project. An example follows: 2.1 概要 下图对将要执行的变更流程和程序做了一个概述,以有效地管理与项目相关的变更。同时也明确的变更管理中的职责分工。

市场需求管理

市场需求管理流程(初稿,待评审) 1、目的 市场需求管理是所有其它业务活动的基础。只有通过创新不断满足市场需求的企业才能适应市场变化而获得可持续发展。 基于市场的创新集中体现为客户需求驱动产品及解决方案的开发。具体实现方式是将核心业务划分出一个个产品及解决方案包(Offering),并根据客户需求定义产品及解决方案包需求(OR,Offering Requirements),再将包需求转化为设计需求(DR,Design Requirements),然后通过产品及解决方案的开发实现和满足客户需求。 市场需求管理提供了一个可执行的流程和相关的方法,通过多渠道多手段的需求收集,建立市场需求库来管理具有高附加值的产品及解决方案包需求,并将选定的需求反馈到市场管理流程和研发流程,为市场需求分析、市场管理、产品规划、研发投资决策和业务盈利计划提供数据支撑。 2、概念定义 包需求(OR,Offering Requirements):站在客户视角用客户化语言描述的产品及解决方案的市场需求,侧重产品及解决方案的系统外在行为,具备可验证的描述和说明。 设计需求(DR,Design Requirements):在包需求及产品概念和可选技术方案基础上,通过系统工程方法对功能、性能、质量、成本、进度等进行权衡和分析,确定产品功能、性能及技术规格可接受的参数范围,是用技术语言描述的产品及解决方案的系统内在行为,具备可测试的参数。 中长期需求:时间跨度在6个月以上的市场需求; 短期需求:时间跨度在3到6个月内的市场需求; 紧急需求:3个月以内的市场需求; 客户定制需求:单个客户或某类客户的特殊需求; DFx需求:指可靠性、可测试性、可制造性、可安装性、可维护性、可扩展性、环境适应性等方面的市场需求; 产品缺陷:产品在设计、实现及制造过程中产生的不符合项; 3、角色定义 产品管理团队(PMT):由跨功能部门(市场/营销、研发、销售、供应链、财务、质量)重量级代表组成的业务管理团队,承担市场管理、产品规划、市场需求管理; 需求管理团队(RMT):属于PMT的需求管理子团队,承担市场需求的管理和决策; 需求分析团队(RAT):是跨功能部门的小组,由系统工程师、研发、市场营销、销售、制造、采购、技服、质量等各领域专家组成,承担市场需求的分析; 需求管理员(RMO):负责RMT的事务性工作,包括需求管理对外接口、《市场需求收集表》的接收管理、需求管理IT系统的操作等; 销售项目需求管理接口人(CCM,需求承诺经理):属于销售、行销或技服团队的成员,在销售项目投标团队中承担需求管理角色; 系统设计组(SDT):承担产品及解决方案的系统设计,包括技术可选方案评估、规格定义、设计需求、总体技术方案、关键技术、测试方案等; 系统工程师(SE):作为系统设计组的Leader,是产品和解决方案的总体技术负责人,是产品研发团队的核心成员;

软件研发流程管理办法

软件研发流程管理办法 为加强对软件研发工作的管理,缩短开发周期,提高开发质量,降低开发成本,提高开发效率,特制定软件研发流程管理办法。 第一章、总则 为保证日常工作正常有序的进行,让开发中各个环节更紧凑,更可控,需要尽可能实现软件研发流程的正规化,工作过程的流程化,以便提高软件质量和开发效率,达到项目能按质按量按期交付的目标。 1、软件开发总体遵循项目管理和软件工程的基本原则。 2、项目管理涉及项目立项、项目计划和监控、配置管理。 3、软件工程涉及需求分析、系统设计、软件实现、测试、试运行、系统上线和产品维护。 第二章、阶段成果 根据软件工程的过程理论并结合公司目前的实际情况,制定以下工作流程,并规定了各个重要环节需要提交的交付物。 1、立项:市场需求合同或项目立项单。 2、需求分析:软件需求分析报告。 3、总体设计:概要设计说明书或功能模块描述。 4、详细设计:详细设计说明书,包括数据库设计、软件接口说明等。 5、软件实现:软件源代码、源代码说明或者注释。 6、产品测试:测试报告。

7、产品发布:产品说明书或使用手册。软件过程成果表: 第三章、岗位设置

根据软件开发过程,主要分为分析、开发和测试三个阶段。分析阶段完成用户需求文档的编写,系统概要设计的编写;开发阶段完成设计文档的编写,代码的编写;测试阶段完成系统的测试,测试文档及其他材料。通过逐渐的调整岗位,明确工作职责,逐步实现项目经理,需求分析工程师,软件开发工程师和测试工程师的岗位设置。 第四章、项目立项 1、需求分析工程师进行应用调查与分析,确认软件的应用需求。

2、根据项目可行情况成立项目开发小组,制定软件开发计划,确定项目经理,并由所领导和项目经理共同确定具体项目配置,知识技能要求,团队成员及团队的角色。 第五章、项目计划与监控 1、以项目为单位,项目经理负责整个项目的计划、组织和控制。 2、在整个项目过程中,项目经理定期检查项目进度和完成情况,调整人员分工和安排。 3、项目计划需要变更时,需要明确变更容并及时汇报。项目经理需要说明变更原因并及时告知所领导审核,以便根据变更容及时调整计划。 第六章、需求分析 1、对用户提出的需求进行分析汇总,梳理用户的业务流程和详细的功能定义。 2、做出简单的界面原型,与客户进行有效的沟通,编写需求详细说明书。 3、遇见需求变更时,分析需求变更容,并与项目经理一起负责对需求变更进行评估并及时告知所领导审核,以便根据变更容及时调整计划。 第七章、总体设计 1、在该阶段确定总体结构和软件开发架构,文件命名规等。可按软件需求划分子系统,也可直接定义目标系统的功能模块及各个功能模块的关系。 2、确定软件模块结构,给出每个功能模块的功能描述,并完成系统概要设计说明书。 3、完成数据库的设计,并编写数据库设计说明书。 4、完成的文档需提交公司进行归档管理。

相关文档
最新文档