软件项目需求评审流程图

软件开发流程软件项目生命周期模型需求分析需求分析流程图过程描述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、测试负责人与临时项目组确定项目关键参数。

软件项目评审工作流程和交付物规范V3.O一、范围本流程规定了软件产品开发过程中的评审工作流程和交付物输出，适用于所有软件产品开发过程评审工作。

三、评审内容评审否同意正式发布。

各类别决策和技术评审点评审内容四、裁剪合并原则a）DCP决策评审通常可与TR技术评审合并，但需要保证决策评审的参与范围和把关重点；b）TR1和TR6评审，原则上不能裁剪,确因项目特殊需要裁剪时，应报BG负责人审批确认；c）评审点、开发活动和交付件的裁剪合并工作，需要视产品复杂程度、紧急程度而定，可通过正式评审的形式予以确认；d）产品开发评审点设置应在TRl阶段予以明确，产品开发计划和交付件列表最终应在TR2阶段予以确定，均应通过正式评审确认；e）评审级别的设置可参考4.2执行，结合产品开发特点可考虑适当调整，但应经过TRl评审确认。

五、详细要求5.1制定评审计划产品总监根据市场需求调研、产品发展规划等安排，在组织完成产品组合SP（战略规划，通常规划未来2-3年工作）和产品线BP（业务计划，通常规划下一年度工作）的基础上,确定charter项目任务书的开发或完善计划，并将Charter-DCP评审计划纳入到BP中执行。

在Charter-DCP评审通过的基础上,产品总监根据工作情况任命产品经理并启动产品立项工作;产品经理制定产品立项方案，拉通相关方成立PDT团队，制定产品开发计划，并在产品开发计划中明确主要的里程碑节点的技术和决策评审计划。

5.2准备评审文件产品经理、项目经理、技术人员、测试人员按职责分工准备评审报告，评审报告应按照有关报告模板进行编制，并经上级Leader审阅确认,报告中涉及其它部门相关工作内容的，应于报告准备过程中做好沟通确认。

产品发布评审之前，产品经理应确保立项约定的所有过程文档已经完成整理，并基于SVN和PLM完成归档，PMO人员负责对文档归档情况进行检查确认。

5.3内部评审出评审申请之前需首先进行部门内部评审，拉通部门领导与内部相关人员意见；5.4预评审召开BG评审会议时，召开内部评审完成后，正式开启会议评审前，需召开预评审活动；项目级评审可按需进行预评审活动。

同级评审1 概述同级评审是进行软件产品验证的活动，其目的是为了及早和高效地从软件工作产品中识别并消除缺陷。

同级评审过程域是包括了两个主要流程： ● 评审 ● 走查2 评审2.1 目的● 尽可能早的发现并确定软件过程产品中的缺陷。

● 尽可能早的发现软件过程产品中应该改进和提高的部分，并及早实现。

● 项目成员通过评审，可以更好的理解软件产品，预防错误的发生。

2.2 角色流程图输出2.3 启动准则● 到达在软件项目计划中拟定的同级评审计划的时间。

● 工作产品已完成并已向项目经理/评审负责人提交工作产品。

2.4 输入●待评审的软件工作产品，可以包括以下工作产品：运行软件和支持软件。

可交付的和不交付的软件工作产品、软件（例如源代码）非软件工作产品（例如过程文档）。

与该同级评审相关的一些材料，如相关需求或设计。

2.5 主要步骤[Step1] 准备评审●作者向项目经理或项目经理指派的评审负责人提交工作产品及相关资料后，项目经理/评审负责人检查工作产品是否初步符合评审的要求，检查要求参见评审检查单。

如果不符合评审要求，立即向作者退回工作产品，要求作者对工作产品进行修改，项目经理同作者制定修改计划和下次评审时间。

评审过程结束。

●评审负责人确定评审的具体的时间、地点、设备、评审员、会议记录员等。

评审前一天（即提前24 小时）将会议通知、工作产品包（待评审的工作产品、评审检查单、工作产品缺陷及问题记录单、以及相关的工作产品）分发给指定的评审员。

●对于需要在评审中运行和演示的软件和支持软件等，作者要搭建好相应的运行环境及使用工具（如投影仪等）。

[Step2] 检查工作产品●检查工作产品。

评审员理解工作产品，利用评审检查单识别出工作产品中的缺陷或问题，并将缺陷或问题记录到《工作产品缺陷及问题记录单》中。

●监控工作产品检查进度。

项目经理/评审负责人应跟踪评审员检查工作产品的情况，以确定工作产品是否已检查完成还是需要更多的时间，或是需要重新安排一次评审会议。

一个完整的软件开发流程一、开发流程图二、过程产物及要求本表主要列出开发阶段需要输出的过程产物，包括产物名称、成果描述、负责人及备注，即谁、在什么时间、应该提供什么内容、提供内容的基本方向和形式是什么。

三、过程说明(一)项目启动1、产品经理和项目干系人确定项目方向，产品型项目的干系人包括公司领导、产品总监、技术总监等，项目的话则包括客户方领导、主要执行人等。

2、公司领导确认项目组团队组成，包括产品经理、研发项目经理、研发工程师、测试团队等。

3、明确项目管理制度，每个阶段的成果产物需要进行相应的评审，评审有相应的《会议纪要》;从项目启动起，研发项目经理每周提供《项目研发周报》;测试阶段，测试工程师每周提供《项目测试周报》。

4、产品经理进行需求调研，输出《需求调研》文档。

需求调研的方式主要有背景资料调查和访谈。

5、产品经理完成《业务梳理》。

首先，明确每个项目的目标;其次，梳理项目涉及的角色;再来，每个角色要进行的事项;最后，再梳理整个系统分哪些端口，要有哪些业务模块，每个模块再包含哪些功能。

(二)需求阶段1、进入可视化产物的输出阶段，产品经理提供最简单也最接近成品的《产品原型》，线框图形式即可。

在这个过程中还可能产生的包括业务流程图和页面跳转流程图。

业务流程图侧重在不同节点不同角色所进行的操作，页面跳转流程图主要指不同界面间的跳转关系。

项目管理者联盟2、产品经理面向整个团队，进行需求的讲解。

3、研发项目经理根据需求及项目要求，明确《项目里程碑》。

根据项目里程表，完成《产品开发计划》，明确详细阶段的时间点，最后根据开发计划，进行《项目任务分解》，完成项目的分工。

4、研发工程师按照各自的分工，进入概要需求阶段。

《概要需求》旨在让研发工程师初步理解业务，评估技术可行性。

(三)设计阶段1、UI设计师根据产品的原型，输出《界面效果图》，并提供界面的标注，最后根据主要的界面，提供一套《UI设计规范》。

UI设计规范主要是明确常用界面形式尺寸等，方便研发快速开发。

软件部项目设计评审管理制度2000年10月北京金达融信计算机系统有限公司前言某一设计开发工作项目的设计评审是在一个研制过程阶段末了，对照设计输入，按照规定的设计标准、规范对设计输出进行审核。

不通过设计评审的一般不能转入下一阶段。

设计评审不能取代产品研制的技术责任制，技术负责人应充分重视评审意见及建议，如限于条件不予采纳也应陈述理由及存档。

1范围本标准适用于公司软件部开发设计过程的设计评审管理。

2设计评审流程图3职责进入下一研制阶段3.1软件部经理负责:a)组织设计评审;b)确定设计评审组长和成员。

3.2设计评审组组长负责：a)制订设计评审计划;b)组织设计评审小组、明确小组人员分工；c)主持评审会议；d)拟出评审结论；e)签署设计评审报告。

f)对设计评审过程和结论进行监控。

3.4 设计评审组依据分工制订评审审核单，负责该方面的评审并作出评审意见。

3.5 项目经理负责对评审意见进行处理。

4.管理内容4.1 设计评审申请和准备：由项目组长填写《设计评审申请报告》，经软件部经理确认，并确定评审组组长和成员后，软件部经理组织评审会议，并于评审会五个工作日前通知相关人员并提交相关评审资料。

必要时还须通知公司总工办、技术部选择参加。

4.2设计评审内容设计评审内容主要涉及：（各设计评审内容详见《设计评审审核要点》）a)设计输出的产品功能、性能、进度成本等是否符合设计输入的需求。

b)设计是否符合现有的设计标准、规范、准则。

c)所明确的质量（包括功能、性能、进度、成本等）薄弱环节是否恰当，建议的解决途径是否可行。

d)为验证或确认所需的测试试验计划、程序、方法及资源是否合理。

4.3 设计评审进行：评审由评审组组长主持，本设计开发项目的主管设计工程师作提供评审文件的重点介绍，评审组根据设计评审审核单提出讨论（主要是存在问题及有分岐意见的问题），进行审核及评价并提出改进意见，最终讨论通过评审结论。

评审结论根据研究所各阶段设计评审故障判断标准由评审组成员讨论得出结论，要求三分之二以上成员同意，方可通过。

软件文档的评审和签署规范一、目的在软件开发的每个阶段，对该阶段所形成的文档进行评审，尽早发现问题，并及时采取措施予以解决，确保文档的内容准确，为软件产品的质量提供保障。

文档的签署是为了体现文档的合法性、有效性、法规性。

二、规定1．文档评审的重点是需求说明和设计说明的评审，见附录一。

2．需求评审需要进一步确认用户要求什么，及用户从开发者一方了解某些限制和约束。

用户代表必须参与此项评审活动，以得到双方认可的需求文档。

3．设计评审主要进行概要设计评审和详细设计评审。

概要设计评审主要详细评审每个系统组成部分的基本设计方法和测试计划；详细设计评审主要评审程序和程序单元测试计划。

4．所有评审会议必须形成会议记录（备忘录）和评审报告。

5．涉及到文档的更改按文档的更改要求执行。

6．评审的内容还可以包括：编排方式、技术准确度、完整性、对读者的适合性、表达上的正确性、格式的规范性等。

7．评审一般采用评审会的方式进行。

8．软件文档都应进行签署，签署的一般顺序为编制→审核→会签→标准化→批准的顺序进行。

其中会签仅在必要时进行。

9．签署不允许代签，且修改单的签署与被修改的文档签署要一致。

10．编制、审核、会签、标准化、批准等人员见附录二。

三、程序评审1．由主管领导、用户代表（必要时）、开发小组成员、项目管理人员、标准化人员等组成评审小组，必要时邀请外单位专家参加。

2．开会前，由主管领导确定评审的具体内容，并将材料发给评审小组成员。

3．评审小组成员准备。

4．主管领导主持会议，根据评审条目由评审小组成员评议、评审。

5．评审小组得出评审结论，形成评审报告，评审小组成员应在评审报告上签字。

签署（无）四、相关记录评审报告会议纪要（记录）五、相关文档（无）附录一各评审点评审内容附录二软件文档签署者一览表编制：审核：批准：附录一各评审点评审内容26 开发进度月报主管设计师主任设计师项目管理部门标准化主管师总设计师27 * 项目开发总结报告主管设计师主任设计师标准化主管师总设计师28 用户使用报告用户单位用户单位负责人29 产品标准主管设计师主任设计师标准化主管师总设计师30 媒体内容分布图设计师主管设计师标准化主管师主任设计师31 成套软件明细表设计师主管设计师标准化主管师主任设计师32 成套运用文件清单设计师主管设计师标准化主管师主任设计师33 经济分析报告财务人员总设计师财务部门负责人34 标准化审查报告标准化主管师标准化室主任35 性能测试报告测试组组长36 资料审查报告评审组组长37 鉴定会纪要鉴定会主任38 软件验收报告验收委员会主任39 * 软件问题报告维护人员总设计师40 * 软件维护报告主管设计师主任设计师标准化主管师总设计师41 软件维护通报主管设计师主任设计师标准化主管师总设计师。

评审过程XXXX公司--------------------------------------------------------------------- XXXX公司对本文件资料享受著作权及其它专属权利，未经书面许可，不得将该等文件资料（其全部或任何部分）披露予任何第三方，或进行修改后使用。

文件更改摘要：目录1.目的 (3)2.角色与职责 (3)3.入口准则 (3)4.输入 (3)5.主要步骤 (3)5.1 技术评审 (4)5.2 个人复查 (6)5.3 审批 (7)5.4 管理类评审 (8)6.评审通过准则 (10)7.输出 (10)8.出口准则 (10)9.引用文档 (10)10.使用模板 (10)1.目的通过本文件规范评审活动，确保公司的评审活动过程规范、评审问题得到跟踪与解决，提高评审的效率、保证评审质量。

2.角色与职责3.入口准则●产生评审需求4.输入●被评审资料5.主要步骤本文件适用于公司所有的评审活动。

根据评审的内容特点，评审活动可分为技术评审、管理类评审、个人复查、审批；适用范围如下：公司组织的相关评审活动，如：可行性分析评审、项目计划评审、用户需求规格说明书评审、软件需求规格书评审、概要设计评审、详细设计评审、代码走查、测试用例评审、里程碑评审等。

图1: 评审方式示意图5.1 技术评审技术评审需召开正式的会议，且对会议的准备工作有严格的要求，要求在评审时使用评审检查单，由规定的角色参与评审，并输出明确的评审报告。

其主要步骤要求如下：●输入：被评审资料●输出：评审资料、《评审检查单》、《评审报告》、《评审问题跟踪表》●流程图：图1 技术评审流程示意图5.2 个人复查个人复查是指由被评审人完成产品后，由指定的单个检查人对其工作产品进行独立检查并提供检查意见的方式。

个人复查的步骤如下：✧被评审人形成工作产品并完成自查后，将工作产品提供给指定的复查人；✧复查人检查工作产品，若发现问题，可采取以下方式反馈问题：a)与被评审人直接沟通问题，并达成共识；b)对于文档，可以在文档中采用修订状态方式直接做出修改；c)对于代码，复查人应根据《代码走查表》进行检查，发现问题后复查人将《代码走查表》发给被评审人；✧被评审人根据复查人的意见修改工作产品，并再次提供给复查人确认直到通过。

项目评审制度及流程1、目的：主要是尽早发现潜在的问题，尽早纠正缺陷，控制项目整体进程。

2、范围：适用于研发中心项目评审工作。

3、职责：3.1 项目组长协助评审人员进行项目评审工作，并提交评审计划。

3.2 评审人员针对项目进行系统评审并撰写评审报告。

3.3 评审人员应对评审完成发现的问题进行后续跟踪处理。

4、程序：4.1 评审角色构成因素评审人员的选择是评审效果的关键，需要考虑以下因素：项目重要性：项目重要性是决定角色构成的最重要的因素，先要根据项目的重要性而定。

这与需要投入的成本有关，对于重要的项目一般会更多地投入资源，提高评审级别。

项目复杂度：项目的复杂度也是决定角色构成的因素之一，根据温伯格的公式，项目管理的复杂度相当于功能规模的平方数。

笔者认为还应该考虑技术复杂度、技术新鲜度和文档复杂度等因素。

项目组成员的能力成分和水平。

项目组成员的能力成分和水平：评审角色构成还应当根据项目团队成员本身的各项技术水平，特别是分析和设计的技术水平如何，行业领域知识是否丰富来进行搭配。

除了团队内部自己进行评审之外，评审团队最好是一些独立于项目团队之外的成员构成。

应当注意的原则是人数要少而精，一个人可以兼多个角色，但要覆盖各项人员需求。

需要说明的是，不具备评审能力的不应参加，可以通过旁听来提高水平。

4.2 基本角色职责评审组长：制定评审计划、确定或制定各项评审准则、必要时组织评审人员进行培训、组织必要的资源、进行评审分工、确保正式评审准备充分、分发待评审文档、必要时召开并主持评审会议、向有关领导报告评审结果，并且跟踪评审错误的改正。

评审人员：必要时参加与评审有关的培训、按评审计划阅读待评审材料、保证对待评审材料的理解、与待评审材料作者讨论，并且指出和记录问题。

文档作者：按评审计划准备并按时提交待评审材料、必要时对材料进行解释、必要时参加评审会议，并且在确定需要改进时按时完成修改。

记录人员：评审会议中记录评审人员提出的问题及相关讨论。