001 需求研发流程

需求研发流程

1具体流程图：

1.接收或提出需求

2.需求调研

3.需求分析确认

4.需求计划确认

5.审核入库：将需求录入Jira系统，启动需求研发流程

需求对应jira问题类型的task

优化对应jira问题类型的improvement

关键点特色对应jira问题类型的new feature

6.输出物：《需求跟踪矩阵》

2.2架构设计组操作指南：

架构设计组成员：李维伟、丁慧明、曾志刚、高晓东、刘纲、陈耀才、林志伟、沈孝龙

1.需求确认：与需求开发组确认需求

2.需求实现分析，输出需求规格书

3.发起需求评审并参与评审

4.提供需求实现大概思路，完成总体方案设计，输出概要设计

5.发起总体方案评审和概要方案评审

6.输出物：《需求规格书》、《需求分析计划》、《概要设计方案》

2.3开发组操作指南：

非税端小组成员：林志伟、陈志福、刘柱、黄俊华、赖显鑫

单位端小组成员：刘春龙、郑仲超、侯凯伟、黎炜

数据交换代理小组成员：黄宗基、张建华

非税收入网小组成员：高晓东

1.具体实现分析：与架构设计组确认需求

2.完成具体方案设计，输出详细设计

3.代码研发

4.输出物：《研发计划》、《详细设计方案》

2.4测试组操作指南：

1.测试要点与测试用例设计：与架构设计组确认需求

2.系统测试

3.输出物：《测试计划》、《测试要点》、《测试用例》、《测试报告》

3状态定义

需求提出/分析：由客户现场或者需求开发者提出需求，通过需求组分析接收后审核录入Jira系统审核入库：整个需求研发流程的初始状态，open；

并做出相应的版本规划之后，转入设计

设计中：designing

开发中：developing

测试中：testing

测试未通过：reopened

测试已验证：resolved；对应解决状态：fixed，won’t fix，duplicate，incomplete，cannot reproduce

关闭：closed

合入下一版本：对应最初做的版本规划，对该版本封版打标备份等

版本提供：版本提供给现场测试，实施上线

废弃：中间过程中，双方确定可以取消。（现场、产品线）

挂起：当需求单暂时不需要处理，例如需求推迟处理；需求要局方确认但长时间没有确认结果时可以更改为挂起状态，当从挂起状态返回正常状态时，表示重新进入需求流程

软件需求分析的详细流程

第一阶段：总体把握，了解概况接手一个项目，不要着急去了解需求，这一阶段是和具体用户方的领导层、业务层人员的访谈式沟通，主要目的是从宏观上把握用户的具体需求方向和趋势，了解现有的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体情况、客观的信息。建立起良好的沟通渠道和方式。针对具体的职能部门，最好能指定本次项目的接口人。该阶段的主要工作方法：客户访谈输出成果：业务流程报告/调查报告（对客户方的组织业务概况和企业现状的一些总结）第二阶段：详细了解业务，梳理业务流程通过第一阶段的调研，了解客户业务概况的前提下，经过充分的业务调研准备，开始进入正式的业务调研工作。这一阶段要对所有业务流程、业务单据、报表等进行详细的分析。整理出业务架构，尽可能多的与相关基层人员进行诱导式的访谈，与用户一起探讨业务流程设计的合理性、准确性、便易性、习惯性。对主要的业务流程要有原型DEMO让客户操作，发现问题，提出改进的意见和建议。该阶段的主要工作方法：访谈、业务分析、原型设计演示输出成果：调研分析报告、原型反馈报告、业务流程报告第三阶段：需求细化和确认这一阶段是在上述两个阶段成果的基础上，进行具体的流程细化、数据项的确认阶段，这个阶段承建方必须提供原型系统和明确的业务流程报告、数据项表，并能清晰地向用户描述系统的业务流设计目标。用户方可以通过审查业务流程报告、数据项表以及操作承建方提供的DEMO系统，来提出反馈意见，并对已经可接受的报告、文档签字确认。实现手段：拜访（回顾、确认），提交业务流程报告、数据项表；原型演示系统输出成果：需求分析报告、数据项、业务流程报告、原型系统反馈意见（后三者可以统一归入需求分析报告中，提交用户方、监理方进行确认和存档）

需求分析方法论

需求分析方法论原则上，需求分析阶段IT中心应尊重需求方的项目管理和项目分析能力；在具体的任务开展上，以不干扰需求方的自主权为主，除非在项目过程中发现需求方的项目管理以及项目分析能力存在很大的差距和不足。为了保证项目的成功，IT中心必须加强项目管理和项目分析工作，在具体的操作上可以坚持吸收、同化、贯彻的方法和手段。其中，需求分析是一个项目的开端，也是项目建设的基石。在以往的信息化建设失败的案例中，80％是由于需求分析的不明确而造成的。因此一个项目成功的关键因素之一，就是对需求分析的把握程度。而项目的整体风险往往表现在需求分析不明确、业务流程不合理，用户不习惯或不愿意去用应用管理软件。作为IT中心，必须提醒需求方重视需求分析的重要性，采用必要的手段和方法来进行需求调研，同时IT 中心也应深入具体的需求调研中去。只有这样才能切切实实地把握用户的需求和方向，才能在将来的功能界定、实施上有发言权。一、如何进行需求分析需求分析不象侦探推理那样需从蛛丝马迹着手，而是应该先了解宏观的问题，再了解细节的问题。一个应用软件系统（记为S）的涉及面可能很广，可以按不同的问题域（记为D）分类，每个问题域对应于一个软件子系统。 S={D1，D2，D3，…Dn} 问题域Di由若干个问题（记为P）组成，每个问题对应于子系统中的一个软构件。 Di={P1，P2，P3，…Pm} 问题Pj有若干个行为（或功能，记为F），每个行为对应于软构件中的实现接口。 Pj={F1，F2，F3，…Fk} 需求说明书应该对于那些只想了解宏观需求的领导，和需要了解细节的技术人员都合适。在写需求说明书时应该注意两个问题： 1、最好为每个需求注释“为什么”，这样可让双方（IT中心、需求方）了解需求的本质，以便选用最合适的技术来实现此需求。 2、需求说明不可有二义性，更不能前后相矛盾。如果有二义性或前后相矛盾，则要重新分析此需求。二、重点监控需求分析由于项目的特殊性和行业覆盖的广阔性，以及需求分析的高风险性，软件需求分析的重要性是不言而喻的，同时需求分析又的的确确难做。其原因基本是由于以下情况造成的。 1、用户说不清楚需求有些用户对需求只有朦胧的感觉，当然说不清楚具体的需求。例如总部各部门及各地的很多店铺在进行应用系统以及网络建设时，需求方的办公人员大多缺乏IT系统建设方面的专家和知识。此时，用户就会要求IT中心系统分析人员替他们设想需求。项目的需求存在一定的主观性，为项目未来建设埋下了潜在的风险。 2、需求自身经常变动根据以往的历史经验，随着用户对信息化建设的认识和自己业务水平的提高，他们会在不同的阶段和时期对项目的需求提出新的要求和需求变更。事实上，历史上没有一个软件的需求改动少于三次的！所以必须接受“需求会变动”这个事实，在进行需求分析时要懂得防患于未然，尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求，以便在系统选型及实施时，将软件的核心建筑在稳定的需求上，同时留出变更空间。IT中心在需求分析的功能界定上担任一个中间、公平、公正的角色，所以也必须积极参与到需求分析的准备中来，以便协助需求方来界定“做什么”、“不做什么”的系统功能界限。 3、IT中心分析人员或用户理解有误系统分析人员不可能都是全才，更不可能是行业方面的专家。用户表达的需求，不同的分析人员可能

研发项目流程管理

怎样架构企业研发管理体系所有成功的公司,特别就是高新技术企业,几乎都拥有较为完善的项目研发管理体系。良好的研发管理体系,对企业的高速运转与持续获取竞争力起着强大的支撑作用。然而,目前我国研发管理的现状就是:大多数的企业对研发创新还没有确立相应的概念,研发管理过于粗旷、简单,工具落后,缺乏完整的管理体系。因此,中国企业在研发方面面临着非常具体的管理挑战:如何建立研发创新体制、如何提高研发管理水平,如何架构研发管理体系必将就是企业最先考虑的问题。 1研发管理核心思想新产品开发就是一项投资决策。研发管理强调对新产品开发进行有效的投资组合分析,并在开发过程中设置关键的检查点,通过阶段性评审来决定项目就是继续、暂停、中止还就是改变方向; 基于市场的开发。研发管理强调产品创新一定就是基于市场需求与竞争分析的创新; 跨部门、跨系统的协同。采用跨部门的产品开发团队(PDT:ProdutDevelopmentTeam),通过有效的沟通、协调以及决策,达到尽快将产品推向市场的目的; 异步开发模式,也称并行工程。就就是通过严密的计划,准确的接口设计,把原来许多后续活动提前进行,从而缩短产品上市时间; 采用公用构建模块(CBB:CommonBuildingBlock)提高产品开发效率; 结构化的流程。产品开发项目的相对不确定性,要求开发流程在非结构化与结构化之间找到平衡。 2研发管理框架研发管理框架就是IPD(IntegratedProductDevelopment,简称IPD)的精髓,它代表业界最佳实践的诸多要素。具体包括异步开发与共用基础模块、跨部门团队、项目与管道管理、结构化流程、客户需求分析、优化投资组合与衡量标准共七个方面,其框架如下图所示。 2、1市场管理市场管理从客户、投资、市场等产品生存的外在客观环境因素来影响产品的特性与生命。 2、1、1客户需求分析

研发流程问题整理

林小池测试： 1、开发项目计划变更通知不到位，导致测试人员从其他项目剥离后无任务安排；——项目变更通知不到位 2、测试组处于被动告知，个别项目需求测试内容是与开发多次交流后得知，需求与开发内容脱节；——项目需求开发过程设计发生变更甚至推翻原有方案研发： 1、能够直观获取了解前后版本修改内容的对比，便于更快确认修改的内容；产品： 1、需求既定的情况下，并且经过内部开发技术评审，在时间允许的情况下的开发内部变更都必须互相知晓，保证开发过程中产品需求与用户真实需求的落实的一致性。 2、评审会议是内部明确需求的会议，不是产品的独角戏，所有与会者必须高度的熟悉需求及方案，评审通过后，原则上不允许变更； 3、希望研发内部也能尽量有详细开发文档的留存； 4、研发在熟知需求，开发完成之后要求自测，测试组能有一定的决策，并能对开发提测内容有初步用户体验，对不符合使用习惯或业务逻辑有偏差、样式有区别原型的功能需求提出整改建议。 5、在有产品人员出具的需求文档中，应该以需求文档为业务文档为用户需求，并以之为蓝本，进行开发，研发进行不对该需求中的方案及逻辑、规则进行随意变更；陈莹莹 1、小池展示的原型文档相对完整，且有益于项目交接，但此文档单次输出时间较长，是否能适用于我们现有的开发流程？对开发和测试的工作是否有很大的推进作用？ 2、如何解决项目开发时间紧的情况下保证开发流程的完整性？ 3、如果解决开发与测试在需求评审过程中的主动性？陈家辉 1、对已有系统业务细节无法很好的掌握，一个是历史的需求文档缺失或者记录的不够详细，第二个是代码那边的提交记录，好像代码迁移之后就没了，一些不明确的改动不知道是因为哪个需求改动的

需求分析主要流程

1.1主要流程需求分析阶段的主要活动围绕需求开发进行，包括制定及修改需求开发计划、开展需求调查以及分析、需求验证、需求规则说明制作、需求确认几个步骤。1.1.1制定及修改需求开发计划包括建立需求团队的组织并授权、对需求分析阶段的WBS进行分解、协商并制定调查分析以及评审计划、评估工作量等等方面的内容，其目的是保证各项活动有序、可控的进行。 1.1.2需求调查以及分析的过程主要活动通过沟通、收集项目中的各级关系人的需求，形成需求调查报告。需求调查通过现场参观、开调查会、业务专家培训、询问沟通、设计调查表并调查、收集查阅记录等方式获取客户、用户各级组织对（软件）系统需求，分析并识别客户以及用户的需要、期望、业务要求，归纳整理后形成需求调查报告。1.1.3需求验证环节主要通过原型（Prototype）、POC（ProofofConcept）、用例（UseCase）或简单的功能列表的方式同客户、用户沟通逐步将业务需求、用户需求等转化为软件系统需求。（1）原型（Prototype）模拟最终软件的屏幕显示，这样用户可以看到最终软件将是什么样，有些原型可以模拟实际的操作，对关键的输入输出数据也可以一定程度的模拟。对于用户体验为主的系统往往可以起到很好的效果。（2）POC（ProofOfConcept）原意是“为观点提供证据”。对于关键的技术或者业务模型，论证需求、设计的可实施性,评估和确认概念设计方案，POC的评价可能引起需求和设计的调整。一般来说，进行POC的条件：1.论证业务中涉及到的模型或者算法的可行性。2.论证技术模型实现的可行性、成本等。（3）用例（UseCase）：对（软件）系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。每个用例提供了一个或多个场景，该场

需求管理过程

需求管理过程XXXX有限公司

前言按照国家军用标准《GJB 5000A-2008 军用软件研制能力成熟度模型》和公司《5000体系软件方针》的要求，为了确保软件项目需求管理过程的适宜性、充分性和有效性，寻求持续改进的机会，特制订本程序。本程序文件主要编写人：本程序文件批准人：本程序文件批准日期：

更改历史页

目录 1 范围 (1) 2 引用文件 (1) 3 术语和定义 (1) 4 角色和职责 (1) 5 过程域描述 (2) 6 主要活动 (2) 6.1 确认软件研制要求 (2) 6.2 需求跟踪 (4) 6.3 需求更改控制 (6) 7 通用要求 (7) 7.1 制定方针 (7) 7.2 策划此过程 (7) 7.3 提供资源 (7) 7.4 指派职责 (8) 7.5 培训人员 (8) 7.6 管理配置 (8) 7.7 标识并吸纳利益相关方 (8) 7.8 监督并控制此过程 (8) 7.9 客观评价遵循性 (8) 7.10 与更高层一起评审状态 (8) 8 相关过程文件 (8) 9 指导性文件 (8) 10 模板 (9) 11 检查表 (9) 12 标准对照表 (9)

1范围本过程文件依据《5000体系软件方针》，规定了我公司军用软件研制过程中需求定义、需求变更控制以及需求跟踪等活动的相关要求。本过程文件适用于我公司军用软件项目的需求管理过程，其它软件项目可参照执行。 2引用文件 GB/T11457-2006 软件工程术语 GJB 5000A-2008 军用软件研制能力成熟度模型 5000体系软件方针 3术语和定义本标准采用 GB/T11457-2006和 GJB 5000A-2008附录 A术语。 4角色和职责角色和职责见表 1。表1 角色和职责

需求管理过程

需求管理过程本文件属深圳天源迪科信息技术股份有限公司所有，未经书面许可，不得以任何形式复印或传播。 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.如何平衡市场竞争的压力和客户多变的需求，快速将产品推向市场； 2.如何建立一个真正的“以客户为中心、以市场为导向”的研发组织体系，快速响应市场需求； 3.产品开发的过程中研发如何与市场、财务、生产、采购等相关职能部门协同工作； 4.研发资源管理中的“会哭的孩子有奶吃”、一个人做多个项目资源冲突、公司优先级高的项目在每个部门却无法保证资源优先、开始了很多项目却总是不能上市、立项评审会上为何总是问题不断 5.如何在保证产品质量的同时又要降低产品的研发费用和设计成本； 6.如何在产品开发的过程中积累技术和管理的经验，从制度上保证公司的成功；课程在总结大量中国企业从“作坊式”的研发模式向“产业化”研发模式转变的过程中的成功经验和失败教训的基础上，提出一个有竞争力的科学的研发管理体系，同时分享业界企业在研发管理变革过程中应该注意的风险，确保企业的研发管理变革能够真正落地实施。培训收益 ★. 了解如何正确地制定新产品研发战略； ★. 学习选择正确的新产品项目的技术和方法； ★. 探讨新产品研发项目的资本运作和风险投资方式； ★. 学习如何建立新产品研发项目管理体系； ★. 掌握建立和应用正确的新产品开发的流程； ★. 学习新产品研发的风险控制和管理的要旨； ★. 学会评价和改善新产品开发项目绩效的途径； ★. 新产品研发的项目模板与工具介绍； ★. 分享讲师上百场研发管理培训的专业经验，通过现场互动帮助学员理清适合自己企业的研发管理思路；★. 掌握业界最佳的研发管理模式与实践，并总结如何与公司的规模相适应来建立研发管理体系； ★. 掌握研发管理的决策体系、组织体系、流程体系、项目管理体系等关键构成要素； ★. 掌握科学的新产品开发流程和研发项目管理操作方法； ★. 分享中国企业推行研发管理体系建设、优化、变革过程中的经验和教训； ★. 分享讲师团队数十个研发管理咨询项目的案例资料（模板、表格、样例……），帮助学员制定Action Plan，使得学员参训后回到自己的公司能够很好实施研发管理体系的优化。课程大纲一、研发管理业界最佳模式及案例分析 1. “微笑曲线”的含义 2. 做正确的事情（市场管理体系）

需求开发和管理流程范例

需求开发和管理流程范例目录 1.目的 (3) 2.适用范围 (3) 3.名词和缩略语 (3) 4.角色和职责 (3) 5.过程综述 (5) 5.1. 流程图 (5) 5.2. 过程说明 (5) 6.过程活动 (6) 6.1. 活动一：获取用户需求 (6) 6.2. 活动二：建立系统需求 (7) 6.3. 活动三.需求分析与建模 (9) 6.4. 活动四.形成需求规格说明 (10) 6.5. 活动五.需求验证 (11) 6.6. 活动六：需求变更 (12) 6.7. 活动七：需求跟踪 (12) 7.过程度量与改进 (15) 8.过程裁剪指南 (15) 9.相关文件 (15)

10.质量记录 (16) 11.附录 (17) 11.1. 附录1：需求优先级说明 (17) 11.2. 附录2：需求状态说明 (17)

1.目的本程序文件定义了本组织的需求与管理的过程，目的是实现有计划地收集、分析顾客的需求，并保证所有共利益者在项目进展过程中始终保持对需求一致的理解和承诺。 2.适用范围本过程适用于公司所有合同项目和自主研发项目。 3.名词和缩略语 4.角色和职责

5.1.流程图 5.2.过程说明需求开发与管理过程包括首先获取用户需求，然后对用户需求进行分类和整理，形成系统需求。通过对系统需求进行分析和建模，形成需求规格说明书，并将分析后的需求以模型或原型方法与用户进行确认，以此建立设计开发基础。最后采用原型、测试验证、评审等方式验证需求。同时，在开发活动中有序的管理需求变更，并通过需求跟踪确保需求的可追溯性和一致性。

6.1.活动一：获取用户需求通过与用户交流、对现有系统的了解以及对项目任务的分析，开发、捕获和修订用户的需要。 6.1.1.进入准则经过市场扫描活动、售前支持、客户反馈等活动，产品经理经过基本分析，确定要进行某产品的开发和较大升级； 6.1.2.输入市场分析报告、售前和售后服务相关记录 6.1.3.任务任务1：产品市场扫描。市场服务部会同产品经理针对特定产品进行市场扫描工作，主要包括与该产品相关的其他产品的名称、主要功能、市场情况；产品的领域，相关标准情况；产品主要涉及的技术领域和技术发展概况。产品经理根据市场扫描的结果确认是否需要进行产品开发和升级。任务2：需求调研。产品经理根据《需求调研规程》组织相关人员实施需求调研活动，形成相关调研记录和《需求特性列表》。评审小组对调研结果实施结构化审查。任务3：产品路线图设计。产品经理根据产品的需求特性列表和市场情况初步确定产品功能特性的优先级，优先级划分参见附录1，并且将优先级的划分与高级经理进行沟通，得到初步的确定后，对需求特性列表按照优先级进行分类整理，形成《产品路线图》。对于项目而言，此任务可以演化成考虑项目分阶段实施的需求划分。 6.1.4.输出《需求特性列表》、《产品路线图》 6.1.5.退出准则《需求特性列表》通过审核，与高级经理沟通后初步明确项目经理

研发项目管理流程

项目管理流程编制：宋登琼审核：批准：日期：2012年10月

目录 1.目的 (4) 2.适用范围 (4) 3.项目分类 (4) 3.1.技术研发型 (4) 3.2.产品研发型 (4) 3.3.项目研发型 (4) 4.职责 (4) 4.1.立项建议人 (4) 4.2.高层管理者 (5) 4.3.技术总监 (5) 4.4.项目经理 (5) 4.5.项目组成员 (5) 4.6.客户 (5) 4.7.销售与售前 (6) 4.8.CM工程师（配置管理工程师） (6) 4.9.QA工程师（质量管理工程师） (6) 4.10.EPG (6) 4.11.技术支持人员 (6) 5.具体内容 (7) 5.1.项目立项流程 (7) 5.1.1.流程图 (7) 5.1.2.工作流程 (7) 5.2.项目策划流程 (9) 5.2.1.流程图 (9) 5.2.2.工作流程 (9) 5.3.项目监控流程 (11) 5.3.1.流程图 (11) 5.3.2.工作流程 (11) 5.4.项目结项流程 (13) 5.4.1.流程图 (13) 5.4.2.工作流程 (13) 5.4.3.项目的异常暂停或终止 (14) 5.5.过程模板 (15) 6.参考文件 (15) 7.说明 (15)

1.目的本流程定义了公司研发项目的立项、策划、监控、结项和风险管理的全标准化过程和活动，达到为项目和人员在项目实施和操作过程中提供规范化指导的作用。 2.适用范围本规定适用于研发中心所有立项实施的项目。 3.项目分类 3.1.技术研发型指以实现技术为目标，形成产品的时机还不成熟的项目； 3.2.产品研发型指以形成产品为目标，实现自定义的应用的项目； 3.3.项目研发型指按照市场的输入定制的常规项目； 4.职责 4.1.立项建议人 ?负责制定产品概念阶段进度计划； ?协调相关人员开展立项调研，参与编制《产品可行性分析报告》； ?负责编写《项目立项建议书》，提出立项建议，申请立项评审。

研发部需求开发流程管理

管理目标 1、所有关系人清晰明确地了解项目的需求和期望，努力做到满足项目所有关系人的不同需求；项目关系人包括：项目团队成员和项目团队外(内部/外部客户，内部/外部合作伙伴，经销商/客户等)。 2、项目管理三要素平衡（时间/成本/质量），即开发项目按需按时按质的完成。 3、目标：功能满足需求，设计支持变化，开发快速迭代，成果持续交付。执行概述 1、建立有效的工作流程保证项目的顺利进行，初期使用传统RUP过程，引入部分敏捷方法，团队磨合完成后逐步实现敏捷开发全流程管理。 2、明确项目目标，制定具有可行性的项目计划，有效明确的分解项目需求。 3、跟踪设计/开发/测试/回归/发布全流程，推动项目按预定计划执行。 4、解决项目过程中出现的问题和冲突，一般集

中在需求不明/工作量或时长/开发难度/跨部门协调等几个方面。 5、调动开发团队的积极性，创造力，推动团队成员在项目过程中的学习成长。 6、风险识别、风险控制以及风险的预案。项目管理 1、需求阶段对项目进行技术可行性分析、技术评估、成本评估以及风险评估。与需求提出方的代表进行需求讨论，明确项目的目标、价值。确定项目范围、功能及优先级。组建项目团队，特别要搞清楚项目的关键人。项目启动会议，相关的关系人都必须参加。 2、设计阶段根据确认后的软件需求规格说明书，制定项目进度计划，工作任务分解(WBS)；资源申请，项目涉及到的开发资源、测试资源、设计资源(包括人员和软硬件资源)；数据库设计；系统

设计；文档(包括系统用例、Demo、测试用例等)；评审会议。设计阶段结果交付一般为系统用例/系统原型/系统设计文档(概要设计和详细设计)/数据库设计文档等。该阶段交付成果需要进行评审。 3、执行阶段(开发和测试) 准备开发环境、测试环境。跟踪，推动项目按计划进行。项目成员以日报/项目负责人以周报的形式通报各关系人当前项目的进展情况。按里程碑对阶段成果进行评估，以确保该阶段完成的质量。代码审核，包括CS审核、SQL审核、WEB 审核等。对需求变更进行控制管理。测试阶段BUG响应及改进、收集反馈意见。对项目风险进行管理。 4、发布阶段包括制定项目发布计划，用户培训，发布上

需求开发流程管理规定

需求开发流程管理规定 1. 目的通过需求开发流程的规定，规范公司软件项目的需求开发和管理活动，提高需求质量，降低开发成本，改进系统质量。通过对各业务部门提交的需求进行评审，确保需求的正确性和合理性，获得需求的承诺；控制需求的变更，并确保各应用软件系统工作成果与需求的一致性。 2. 范围适用于公司各软件开发项目及已经通过《用户需求确认书》的项目，如未通过《用户需求确认书》技术中心暂时无法参与需求立项，评审，分析等流程。附件一：《用户需求确认书》 3. 释义

4.流程图段图i :需求开发流程图

5. 主要活动需求定义的目的是需求提出人通过收集、调查与分析，获取用户业务需求并定义需求。需求定义的主要活动包括：需求收集、需求分析&定义。需求管理的目的是在需求方与程序组之间建立对需求的共同认识和理解，维护需求与程序开发成果的一致性，并控制需求的变更。需求管理的主要活动包括：需求评审确认、需求变更、需求跟踪控制。 5.1需求定义由于在实际情况下，大部分原始需求都未完整地讲述其业务需求，需求获取的质量，对后续的需求分析和需求定义工作将会产生重大影响。在完成需求收集所得到的记录与资料的分析与整理后，信息中心应对需求进行分类、排优先级等。 5.1.1标识需求与命名规则为了便于需求文档的统一管理，更好的识别每个项目的需求，需要明确需求文档的命名规则，具体格式为: ［需求年月］-［项目类别］-［用途类别］如，201310-TMS项目-运单打印需求; 5.1.2需求分类 : 5.1.3需求优先级需求分析员应确定每个需求的优先级，需求的优先级判定标准如下:

需求分析流程需求产品

需求分析一.流程 ->1.需求分析（战略层，发现有效需求，排期）- ->2.功能设计（范围层，用哪些功能来实现这个需求） ->3.交互设计（结构层，将功能带入到产品里，将抽象的功能具象成按钮）->4.视觉设计（表现层） ->5.开发测试（走查） ->6.上线运营（循环）二.需求通俗来说即谁在什么情况下想干什么。这里就涉及到了“目标用户”“使用场景”“用户目标”。目标用户：是在人群细分的基础上得出的，需要考虑细分时的潜在用户量（市场份额）和用户质量（市场价值）。比如说做外卖市场，目标用户想当然的可能就是有定外卖需求的人，这当然没错，只是把用户群体定得太局限，也太浅显了。 020本质上是懒人经济，用户最大的特点就是懒和信息不对称。从潜在用户量的角度想，没有定外卖的习惯但是对新的菜品有强烈好奇心的吃货，是否也是我们的用户呢？从用户质量的角度想，主打高校市场是为了培养未来的主流消费用户的习惯，那主打白领市场就可能是想快速抢占用户并得到流量变现。使用场景：是需要根据具体场景特点来分析如何满足需求。比如分析观看视频的用户在移动场景下的特点是移动频繁、注意力不易集中、流量有限等，那对应的视频类产品设计原则就会考虑让交互易单手操作、视频精简而亮点集中（如万万没想到等10分钟左右的搞笑视频）

用户目标：即我们日常讨论的用户的需求。然而表层的目标和底层的需求还是有差别的，目标是不同用户在自己的认知范围内对自己的需求做出的一种反馈，由于大众认知偏差大，所以需求相似但目标相异，这就要求我们在众多的用户反馈中去剖析提取真实的需求。比如对于打折商品，用户的目标可能是需要查看商品折前折后价方便对比，但可知用户的需求是想知道商品的打折力度，其性价比的上升程度，从而确定购买决策，所以对此我们应该直接提供“省了多少，已有多少人下单、多少人好评”等这种辅助用户进行购买决策的信息。三.产品是指满足人们某种需求并能被使用和消费的东西，包括有形的物品和无形的服务。这里就涉及到了“使用人群”“主要功能”“产品特色”。使用人群：指经过需求分析和性价比考量后确定服务的对象，也就是说制造者会分析这个产品会被哪些人需要、这些人有没有盈利价值、产品做起来难不难。使用人群也涉及到了一个概念：用户自画像（即用户信息标签化，以后再详细讨论这点）主要功能：也就是用户使用产品的根本原因，解决用户的核心需求。产品特色：核心需求容易抓，用户为何选你不选他？这便是同行竞争的核心点，也是运营推销的切入点。优秀的产品：首先要能解决需求，这是产品的根本价值所在。其次是要有良好体验，这是产品出类拔萃的前提。最后还要有用户粘性，这是商业价值的源头。

需求开发与管理过程

密级：普通标识:S_RD_XQKFYGLGC 版本号：2.0 分册：第1册/共1册需求开发与管理过程湖南创博龙智信息科技股份有限公司湖南创博龙智信息科技股份有限公司对本文件资料享受著作权及其它专属权利，未经书面许可不得将该等文件资料（其全部或任何部分）披露予任何第三方，或进行修改后使用。

文件更改摘要：

目录 1.目的/方针 (3) 2.范围 (3) 3.术语 (3) 4.角色与职责 (3) 5.入口准则 (3) 6.输入 (3) 7.流程图 (4) 8.主要活动 (4) 8.1.需求获取 (4) 8.1.1.明确所需获取信息的来源与渠道（Where） (5) 8.1.2.获取需求（How） (5) 8.1.3.需求获取资料的保管 (7) 8.1.4.编写用户需求规格说明书 (7) 8.2.需求分析 (7) 8.2.1.结构化分析方法 (7) 8.2.2.基于用例的分析方法 (8) 8.3.需求定义 (9) 8.3.1.定义需求的优先级 (9) 8.3.2.编写《需求分析说明书》 (10) 8.4.需求确认 (10) 8.4.1.需求评审 (10) 8.4.2.需求承诺 (11) 8.4.3.建立需求基线 (11) 8.5.需求变更 (11) 8.5.1.需求变更申请................................................................. 错误！未定义书签。 8.5.2.需求变更的实施 (12) 8.6.需求跟踪 (12) 8.6.1.建立需求跟踪矩阵 (12) 8.6.2.需求跟踪矩阵的维护与使用 (12) 9.输出 (12) 10.出口准则 (13) 11.资源 (13) 12.引用文档 (13)

项目需求分析和调研实践过程(精)

某集团船代项目需求分析和调研实践过程此文档主要在于项目管理设置项目相关文档，有兴趣人员可以参考一下，对于项目管理和未来有此方向者有一定的参考价值。流程再造方法论 -流程影射，系统评估，定义考核，再造建议前言本文档主要根据某集团船代项目需求分析和调研实践过程整理而得，描述从项目启动，调研到设计过程的大致过程叙述，重点在于咨询过程中涉及的需求分析和调研方法论，其他相关项目前期规划和调研可参考此方法论。如有不妥之处敬请指正，也希望能不断完善，谢谢！正文：软件需求的定义：根据IEEE软件工程标准词汇（1997年）中定义的需求为：用户解决问题或达到目标所需的条件和能力；系统或系统部件要求满足合同，标准，规范或其他正式规定文档所需具有的条件和能力；一种反映上述条件和能力的文档说明。本项目简介因某某集团船代业务发展需要，加上目前的系统存在很大问题，也不能涵盖目前的所有业务需求，需进行调研和需求分析是否需要上一套新的

船代系统，新系统需要整合目前的业务结构和业务流程，同时满足业务的需求和未来发展。适合读者此文档适合信息系统项目咨询规划和分析的相关项目人员作为项目前期方法论参考之用。目录 1.项目启动 2.项目调研 3.项目规划与考核指标 4.撰写SOR 项目启动 1.与成员企业与相关部门沟通召开项目总启动会议，介绍项目组相关人员以及此项目的主要目的和要求，企业简单本项目涉及的业务流程和相关业务部门和目前主要组织结构。例如船代项目我们在这一个环节我们了解到了整个船代所涉及的主要业务可以分为：集装箱进出口业务散杂货进出口业务箱管

订舱根据业务的分工部门的分工也不同。以后的调研思路我们也可以按照这样两种业务流程主线去咨询调研相应的部门与人员。 2.安排项目相关人员根据业务主线（集装箱进出口，散杂货进出口）整理调研思路，要求企业根据提供的业务主线流程，和部门结合分工安排，组织各部门主要相关人员积极配合项目未来的调研。 3.出初期调研时间和相关人员安排表根据前期的准备工作，出具具体调研时间和人员安排表，时间项目组掌控制（需要和业务部门协调），人员安排需要业务部门提供详细人员名单资料。以便项目成员和企业相关部门人员提前做好调研准备（安排相关人员和准备一些相关资料）。根据时间人员安排表，做好前期调研准备。注：在调研具体调研前，我们因该知道所有物流在运作过程中碰到的四个主要问题为：出错率时效成本结算在具体的调研过程中，我们始终要以此作为主导的思路问问题，才能找出目前的问题所在。也就是未来规划后的系统的价值所在。

公司研发项目流程

公司研发项目流程为使公司运营更有效率，节约时间和成本，特指定此流程。一，研发项目的制定公司年研发总费用预算相对固定，在保证销售后产品的技术支持基础上，选择更有利的项目进行。项目的发起：1，销售和市场人员在市场发现好的机会，考虑对公司的发展帮助和公司技术的可行性，提出申请；按照市场需求，要求销售部门每月提出一份报告，供公司选择。 2，公司客户提出产品和技术需求，公司参考公司能力和客户要求后审查项目可行性。二，研发项目的立项审批 1，按照市场需要和客户要求，由市场销售部门提出立项申请，交由公司总经理和法人二级审批，通过后交技术和研发部论证。 2，技术和研发部，从技术角度评价项目可行性，要求15天提出意见。 3，技术和研发部门意见如果可行，则需在2个月内作出项目大致预算及所需时间估算。同时财务部门参考研发费用余额提出意见。 4，由销售，财务，研发，技术部门负责人及公司总经理，法人和相关股东讨论后，综合考虑市场，技术和财力等条件，作出项目进行与否的决定。这个流程在7天内完成。三，项目论证由技术和研发部门负责，对前期预算下的方案进行详细论证，一般在2个月内完成，并提交总经理最终确定立项与否。四，项目进行 1，项目确立后，技术和研发部门需要按照实际列出大致预算及进程计划，财务部门需要配合统筹好资金； 2，按照项目要求，市场采购需要作好后勤配合，销售部门随时查找更新市场情报。五，项目完成 1，项目末期，公司内部由市场人员，技术人员和管理人员共同对产品进行验收，并提出各自意见； 2，技术和研发部门根据多方意见进行必要的整改后，提交公司进行正式验收； 3，成果由市场和销售人员有针对性的推荐给潜在用户，或由合作客户试用，并听取市场各方面意见，并进行改进或定型； 4，研发成果以档案形式由公司保存，同时看必要性，由公司进行专利申请。

培训需求管理

学习导航通过学习本课程，你将能够： ●熟悉培训需求的定义和分类； ●掌握静态、动态需求的操作方法； ●学会量化培训需求； ●了解培训需求确认的重要性。培训需求管理一、培训需求的定义及分类 1.培训需求的定义凡事都有开端，需求就是培训的开端。所谓培训需求，就是现在的水平线离岗位要求线水平之间的差距。一般而言，培训需求应该从三个层面进行考虑：第一，组织层面，包括公司文化和经营策略、业务重点、组织架构。第二，岗位层面，包括岗位职责和胜任能力。第三，个人层面，包括绩效评估和人员发展。 2. 常用培训需求方法及优缺点分析三个层面的需求理论分析虽然很有道理，但进行实际操作时，并不简单。目前，市面上有两种通用的做法，即传统的调查问卷和现代的基于胜任力模型的需求调查。传统调查问卷现在，绝大部分企业都是采取这一方法来处理问题。在实施过程中，首先由培训部门设计调查问卷，然后发到各个职能部门当中，让员工填写问卷，培训部门收集、整理并对这些问卷进行数据分析，最后制定未来的培训计划，这是基本的工作流程，如图1所示。图1 传统需求调查工作流程优点。传统调查问卷的优点是参与度很高，各个职能部门主管都能人手一份，每个人都能参与进来。但是这也仅仅是其唯一的优点。缺点。传统调查问卷的缺点如下：第一，易走形式。企业在进行需求调查时，实际情况往往是，这些调查常在部门年终最忙的时候进行，员工在抽时间填写这些没有实际用处的问卷时充满抱怨，效果可想而知；或

者填写问卷的员工会填对自己最有好处的课程，比如MBA、EMBA等昂贵的课程，在占便宜心理的驱使下，也会让调查问卷流于形式。第二，填写者有负担。有的员工在填写问卷时，由于对课程不了解，对工作职责与哪些课程相匹配也不清楚，不知道如何填写一些问题，因而感到有负担。在这种情形下，问卷就属于被动的任务，为了交差只能硬着头皮填完。第三，填写者对课程等不了解，凭兴趣。也有些员工因为对课程不了解，最多凭兴趣选择答案，没有结合自己切身的需求，也是问卷调查的一个弊端。第四，工作量大。填写问卷的工作量很大，公司有上千上万人，如果都填写，针对性和实用性就不是很大。第五，填写结果用处不大。员工提交上来的问卷，很多答案由于没办法使用，这让员工的积极性受到打击，下次再进行类似的调查工作员工往往更容易敷衍了事。现代需求调查现代需求调查是基于胜任能力模型的需求调查。操作流程为：从职能部门开始，确定岗位的能力要求，建立每个岗位的能力模型，然后根据能力模型评估人员的能力差距，接着培训负责人收集分析这些人员的能力差距，然后选择相应的课程。其操作流程如图2所示。图2 现代需求调查操作流程图优点。现代需求调查的优点除了参与度高之外，还有一个优点就是精确度高。如果严格按照上面流程操作，能够很精确地知道员工需要哪些培训。缺点。现代需求调查的缺点主要体现在以下方面：第一，要求部门主管很专业。建立能力模型是一项操作起来专业性非常强的工作，因此此要求各个部门主管需很专业。有些公司请外部的咨询师来做，这样不仅牵涉到费用问题，还有模型的可行性、适用性和操作性问题。第二，较难建立各岗位的胜任力模型。在我国企业里面，各部门的主管都无法达到建立能力模型的要求，很多公司即使在企业内部建立了能力模型，也很难起到应有的效果。第三，各岗位的职责说明书需要很全、很专业。做各个岗位的职责说明书比建立能力模型相对要容易，但是要把岗位说明书做到专业和全面，就还需要各部门花费很大力气去做。第四，要求评估人的评估技巧要很高。对于如何根据岗位的情况对现有员工能力进行评估，每个人看问题的角度不一样，评估出来的结果可能也就不相同。所以，不同评估人员得出的结论会不同，如果误差很大，就说明其评估技巧需要提高。第五，人数越多，工作量越大。在需求调查中，面对公司上下万千名员工，而具备评估水平的人只有少数几个，是无法对全公司的人进行准确评估的，这将是一项无法完成的任务。

软件需求分析方法

软件需求分析（Software Reguirement Analysis）是研究用户需求得到的东西，完全理解用户对软件需求的完整功能，确认用户软件功能需求，建立可确认的、可验证的一个基本依据。软件需求分析是一个项目的开端，也是项目实施最重要的关键点。据有关地机构分析结果表明，我们设计的软件产品存在不完整性、不正确性等问题80％以上是需求分析错误所导致的，而且由于需求分析错误造成根本性的功能问题尤为突出。因此，一个项目的成功软件需求分析是关键的一步。一、软件需求分析理论如果我们用数学方法来描述软件需求分析，可以将一个应用软件定义为S，可能应用软件涉及功能性问题非常广，我们用抽象化理论分析，可以划分为各个功能域，可以用D1、D2、… Dn表示，那么，我们可以用一个表达式描述为 S={D1，D2，D3，…Dn} 但是，功能域Di依然存在着有若干个问题P1、P2、P3、… Pm组成，并且每个功能对应于子系统中的一个软构件，我们可以表示为 Di={P1，P2，P3，…Pm} 同样，功能Pj有若干个行为F1、F2、F3、… Fk，每个行为对应于软构件中的实现方法Pj={F1，F2，F3，…Fk} 一个软件包含了所有功能的集合，同时包含了实现所有功能的所有方法和算法描述。需求分析是依据于用户需求，经过需求问题识别，进行分析、消化与综合，制订规格说明，评审，分为四个阶段，形成用户需求与设计同步，设计满足用户需求目标。需求分析方法始终贯穿着吸收、同化、贯彻方法和手段，用商业化行为解决需求与实现中存在的矛盾，解决用户需求与商业化产品融通，解决规范与个性化追求。二、软件需求分析目标软件需求分析的主要实现目标： 1）对实现软件的功能做全面的描述，帮助用户判断实现功能的正确性、一致性和完整性，促使用户在软件设计启动之前周密地、全面地思考软件需求； 2）了解和描述软件实现所需的全部信息，为软件设计、确认和验证提供一个基准； 3）为软件管理人员进行软件成本计价和编制软件开发计划书提供依据；

cmmi软件开发流程图

软件开发流程软件项目生命周期模型

需求分析需求分析流程图过程描述 1、由部门经理组建临时项目组，并指定PM、开发人员、测试人员、QA，人数根据项目规模确定。

2、PM制定需求阶段日程表，该表须通过研发经理审核。 3、PM指示配置管理员建立配置库。 4、由PM与测试负责人提出裁剪申请，QA指导临时项目组人员对项目进行裁剪，形成项目裁剪表。 5、EPG和部门经理对裁剪结果进行审批，审批通过项目裁剪表正式生效。 6、PM与测试负责人确定项目管理机制，内容包括组织结构、沟通、跟踪、报告、风险管理、问题管理、QA、CM等。 7、项目组人员与客户进行沟通，编写需求清单列表。 8、PM组织临时项目组成员确定系统架构，编写架构设计书和需求规格书。架构设计过程中的重要的技术方案选择、开发/采购/复用分析等内容要明确体现在架构设计书中。 ?对技术方案选择(例如，系统结构、开发平台、数据库等的选择)，要事先建立评价准则(例如，满足系统需求的能力(例如，功能、性能、可靠性等)、技术的发展前景、供应商资质与实力等)及相对优先级，采用讨论表决的方法选择并确定最终的技术方案。 ?关于自行开发和采购复用的分析，如果公司有基本满足系统需要的可复用组件(包括其分析、设计、代码、测试用例等)，一般应进行复用；本公司没有能力开发或没有必要开发的非核心技术部分，如果采购成本在项目可接受范围内，可考虑采购；否则，由项目组自行开发。架构设计的总体候选方案选择和供应商选择要使用正式的方法做决策。 9、PM召集临时项目组、测试负责人等技术骨干评审架构设计书和需求规格书。 10、PM组织临时项目组与客户沟通、说明需求，必要时编制系统原型向客户展示，直到临时项目组、客户就需求的真实含义达成共识、客户书面确认需求规格书为止。 11、临时项目组确定项目目标的范围，明确系统边界，建立系统的模块分解结构。 12、PM与测试负责人遵循《项目估算流程》组织人员进行项目估算。 13、PM、测试负责人与临时项目组确定项目关键参数。 ?工作量、工期、日程、人数 ?成本/预算（由于本公司的项目的绝大部分成本是人力成本，对估计成本的管理等同于估计工作量的管理，对实际成本的管理等同于实际工作量的管理，对预算的管理等同于计划工作量的管理。） ?质量目标 14、PM、测试负责人与部门经理协调人员及资源、计划知识技能、协调相关干系人的参与。 15、项目组基于公司环境标准，结合项目实际情况建立适合的工作环境。 16、PM、测试负责人编制项目计划书。 17、PM、测试负责人编制项目日程表。 18、临时项目组、研发部、QA评审项目计划书，评审通过后正式生效。 19、PM指示配置管理员建立配置基线。 20、PM编制阶段总结报告（项目总结报告中的度量分析页面），召开阶段会议。