需求评审流程规范.doc

需求评审流程目录1.目的12.职责13.评审角色构成因素14.文档评审的层次25.文档评审流程35.1评审流程概览35.2确定评审组长35.3评审计划35.4评审准备45.5评审会议45.6评审记录45.7评审结论45.8跟踪与总结45.9材料归档51.目的在团队开发中，充分的沟通是非常有必要的，沟通的方式之一就是通过文档。不论评审的效果如何，发现多少问题都可以让相关人员了解需求与设计。而通过相互之间的讨论，澄清一些模糊的认识，进一步理解文档的含义。评审不但是软件开发活动中一个重要的质量控制机制，而且也是一个重要而有效的沟通方式。通过评审可以利用企业内部各种优秀成员的智慧，为软件开发寻找最佳的解决方案。评审的作用和目的主要是尽早发现潜在的问题，尽早纠正缺陷，控制纠正成本的滚雪球效应。本阶段造成的错误如果能够及时地发现，或者在后面越早的阶段发现，就能够及早发现潜在的风险，及时做好防范的对策，做到未雨绸缪。评审的过程不仅是为了发现问题，而且为了便于跟踪及改正，还应当对问题进行记录。特别是需要对问题的真实性进行确认，剔除可能是误解、似是而非或不必采纳的建议性问题。2.职责 评审组长：制定评审计划、确定或制定各项评审准则、必要时组织评审人员进行培训、组织必要的资源、进行评审分工、确保正式评审准备充分、分发待评审文档、必要时召开并主持评审会议、向有关领导报告评审结果，并且跟踪评审错误的改正。 评审人员：必要时参加与评审有关的培训、按评审计划阅读待评审材料、保证对待评审材料的理解、与待评审材料作者讨论，并且指出和记录问题。 文档作者：按评审计划准备并按时提交待评审材料、必要时对材料进行解释、必要时参加评审会议，并且在确定需要改进时按时完成修改。 记录人员：评审会议中记录评审人员提出的问题及相关讨论。 项目经理：制定保证评审和改正的项目进度计划，还要确保评审准备时间、评审会议时间及错误的改正时间。而且评审安排及结果与所有项目成员沟通，必要时参加评审会议、阅读评审报告、分析缺陷原因，并且改进项目质量。3.评审角色构成因素评审人员的选择是评审效果的关键，需要考虑以下因素： 项目重要性：项目重要性是决定角色构成的最重要的因素，评审角色的构成因素首先要根据项目的重要性而定。这与需要投入的成本有关，对于重要的项目一般会更多地投入资源，提高评审级别。 项目复杂度：项目的复杂度也是决定角色构成的因素之一，根据温伯格的公式，项目管理的复杂度相当于功能规模的平方数。笔者认为还应该考虑技术复杂度、技术新鲜度和文档复杂度等因素。 项目组成员的能力成分和水平：评审角色构成还应当根据项目团队成员本身的各项技术水平，特别是分析和设计的技术水平如何，行业领域知识是否丰富来进行搭配。除了团队内部自己进行评审之外，评审团队最好是一些独立于项目团队之外的成员构成。应当注意的原则是人数要少而精，一个人可以兼多个角色，但要覆盖各项人员需求。需要说明的是，不具备评审能力的不应参加，可以通过旁听来提高水平。4.文档评审的层次 过程规范：是否符合过程规范、是否按照计划提交、是否按时经过评审、是否准时发布（注意提交时间与发布时间的区别），以及评审的流程是否规范。适合的评审人员：QA。 文档规范：文档成果符合企业或业界已经制定的文档模板规范。企业，甚至行业应当制定统一的文档规范，形成一个文档约定和规则，以统一文档内容与风格。适合的评审人员：QA。 文档语法：文档成果正确使用通用的方法与术语并符合软件工程相关的技术标准，这里所说的语法包括自然语言的语法和建模语言的语法。适合的评审人员要求：精通软件工程、分析与设计方法、建模工具和相关标准。 文档语义：文档成果表达清晰、无歧义，可以反映系统目标。所有质量合格的文档（包括模型）都代表它期望代表的语义，而且应该在代表这些语义时具有一致性。文字与图表应当互相补充说明，以更加清晰。让别人看得懂，看完后知道下一步该怎么做。适合的评审人员：行业业务专家、高级程序员和测试工程师。 文档逻辑：主要体现需求与设计正确性、一致性，无遗漏、多余或错误。前后左右考虑周全，不同文档之间、文档与行业标准之间、同一文档各成分之间不互相矛盾，清晰说明相关部分之间的关系，特别是要符合相关行业的业务标准规范。适合的评审人员：行业业务专家、产品经理和测试工程师。 文档美学：文档成果能否表述得更好一些，文字、图表是否能更加均衡和完整。需要追求平衡的美，每个组成部分应该大小适中，可解读并可变更。平衡有多个方面，如排版次序更加合理、文字、图形更加精炼并更易理解等。适合的评审人员：系统分析与设计专家，以及建模工具专家。 结果优化：通过检查判断文档成果（如项目计划、需求规格及设计方案）是否还有改进的空间，以便更加方便地进行项目管理、降低成本、加快进度、提高质量并减少风险，尽可能达到最佳方案。任何一项设计都可以有许多不同的方案，通过“方案优化”选定一种最好的方案。适合的评审人员：系统分析与设计专家、项目经理和产品经理。5.文档评审流程5.1评审流程概览确定评审组长。制定并发布评审计划。准备评审。举行评审会议。改正、跟踪和回归评审。分析、总结和报告。归档。5.2确定评审组长由品质保证人员与项目经理、部门经理论协商，确定项目的评审级别及评审人员角色构成要求，初步确定评审组长人选。品质保证人员与评审组长沟通，最终确定评审组长。评审组长充分了解项目相关情况，为制定评审计划做好准备。5.3评审计划评审组长制定评审计划（根据项目计划和质量计划）。评审组长确定评审对象和评审时间。评审组长确定评审级别和策略（形式的组合）。评审组长确定评审流程裁减和提交物。评审组长确定入口条件并通过准则。评审组长确定回归评审准则。评审组长制定评审检查表（CheckList）。评审组长确定评审角色构成。评审组长根据评审角色构成确定评审人员并成立评审小组。相关人员（评审人员和项目团队双方）确认评审计划。评审组长发布评审计划。5.4评审准备正式评审前准备：文档作者向相关人员发布文档。评审人员阅读了解文档，争取发现大部分问题。文档作者解决大部分发现的问题。评审组长确定会议地点、环境、设备和所有材料。评审组长确定人员职责和会议议程。评审组长确定评审开始条件成熟。评审组长通知相关人员到会。5.5评审会议主持人（评审组长）宣布会议议程、人员职责和会场纪律。文档作者介绍工作成果，对评审人员的疑问进行必要的解释。评审人员对不解之处提出疑问，指出问题或缺陷并说明根据。文档作者与评审人员讨论缺陷的真实性，分清缺陷性问题和建议性问题，讨论确定是否需要按照评审人员的要求进行改进。一般不涉及为节省时间改进方案或错误的纠正方案。5.6评审记录正式评审应当记录有共识的问题或缺陷，也要记录有争议待解决的问题。使评审工作文档化，便于跟踪最终解决。总体记录：包括项目名称、系统名称版本号、日期时间、主文档名称、附文档名称、文档版本号、作者、评审类型（首次、回归、部分和阶段）、评审人员和评审结论。缺陷记录：包括缺陷编号、提出者、章节页码、缺陷描述、缺陷类型（严重、一般和建议）和承诺改正时间。验证记录：全部打勾的CheckList，说明CheckList所列的工作都已经做完，所列的内容都已经评审完，确保工作的完整性。5.7评审结论评审结论包括如下内容。 是否需要修改？这是就成果的整体而言，结论可以是无需、少量、较大或是一个量化的数字。 项目组确定是否接受修改要求？这是针对具体的一条意见或建议。有些问题可能是误会，消除了就不是问题；有些建议性的问题，项目组考虑进度可不接受修改要求。如不接受修改要求，项目组给出不修改的理由。如何处理？是否需要进行回归评审？总体结论：合格或不合格。确定的修改责任人和跟踪责任人。确定的回归评审时间。是否都认同评审结论？如果需要做得更正式一些，可以要求相关人员签字表示同意评审结论，签字5.8跟踪与总结评审中发现的问题的后续跟踪是改正错误并消除缺陷的有效措施，应当有专门的责任人进行后续跟踪确认错误都已改正，根据结论必要时回归评审。评审组长分析评审数据并总结经验。评审组长发布评审记录与数据分析报告。管理人员应当防止评审数据被不恰当地使用，如果使用评审数据来对个人进行绩效评价，将会给以后的评审工作造成障碍，使评审各方不能放开进行评审。评审组长进行工作总结，工作总结很有必要，有利于对项目或过程的改进。评审组长提交各类评审报告，有关领导批准发布通过的文档。5.9材料归档评审材料归档是项目配置管理工作的一部分。新建项目，记载配置管理工具中为此项目建立一个目录，并建立下列子目录。待评阅态：文件放入此目录后会自动通过邮件通知需要评阅的人员，全体评阅人员评阅完毕，也会自动通过邮件把意见通知文档作者并实现到期自动提醒功能。待评审态：文件放入此目录后会自动通过邮件通知需要评审的人员，全体评阅人员评审完毕，也会自动通过邮件把批准或拒绝的意见通知文档作者并实现到期自动提醒功能。受控态：评审批准后自动转入受控态并发布自动邮件。签出态：为了修改而版本升级，当文件签出时放入签出态。修改后的文档可能签入到待评阅态、待评审态或直接到受控态，但文档版本已经升级。产品态：项目结束后受控态的文档自动归到产品态。