需求评审规范
需求管理规范
需求管理规范需求管理规范：需求采集在需求采集阶段，我们通过各种形式对用户的需求进行收集，包括用户访谈、调查问卷、数据分析、领导提供的需求、产品人员的需求等。
在收集需求时，我们需要详细记录需求的属性，并记录可追溯的反馈人员。
为了确保采集到的需求符合运营需求，我们需要遵循以下采集要求：1.需求必须符合iCage产品定义。
2.需求必须具有可实现性、拓展性、可开发性和合理性。
3.项目组成员确认需求，对人员进行限制，不能有过多相关人员加入。
4.满足用户需求和业务需求的一致性。
5.对开发周期进行安排，计算人力成本并分析工期合理性。
在采集阶段，我们需要输出需求分析文档和需求清单表，以便进行后续的需求分析。
需求管理规范：需求分析在需求分析阶段，我们对采集到的需求进行分析，确定其基本属性，以及对产品带来的商业价值、用户量的提高、实现该项目需求最多需要付出的人员、时间等系数，以确认需求的性价比。
对于一些bug或是功能的小修改，我们可以直接转为需求处理，不需要进行详细分析。
为了确保需求分析的合理性，我们需要遵循以下分析要求：1.需求分析人员必须完成相关需求分析文档。
2.分析人员要使用符合大众的惯性语言表达。
3.分析人员要了解业务及需求。
4.需求文档中不能含有模棱两可的文字，如可能、一般等。
5.需求分析工期不能超过预期时间。
6.需求分析应具备合理性。
在分析阶段，我们需要输出需求清单表和需求商业价值文档，以便进行后续的需求评审。
需求管理规范：需求评审在需求评审阶段，我们结合现状对需求进行处理，主要解决做不做、什么时候做、做什么的问题。
需求评审以会议形式展开，邀请与项目相关人员及领导参加。
通过评审，我们对多个需求进行打包，整理所需的需求点，并形成文档，提交领导复核，确认后进行开发周期。
为了确保需求评审的合理性，我们需要遵循以下评审要求：1.符合iCage产品定义。
2.需求形式化语言清晰易懂。
3.需求必须符合运营需求。
4.标示将来产品迭代可预测的需求。
文档评审规范
2．分析设计阶段分析设计阶段的测试工作是评审与测试相结合的过程，主要包括需求说明书评测、概要设计说明书评测、详细设计说明书评测以及软件编码规范评测等。
下述章节将详细论述。
（1）需求说明书评测由于软件应用系统针对的行业广泛，因此在需求分析阶段可能存在着承建单位对业主单位的业务需求理解不全面、不准确的情况，常发生承建单位认为某一个业务功能的实现非常简单，而实际上业主单位业务标准的要求却很复杂的情况。
在这种情况下，如果不通过评测进行相关的质量控制，往往造成承建单位按照自己的理解进行开发。
如果不进行评测，或者评测之后没有充分发现问题，则给系统造成重大隐患，或者造成返工与延期。
因此，在此阶段评测的工作重点是与承建单位的分析人员、设计人员一起对需求说明书进行审查，并协调业主单位完成需求说明书的评审确认。
什么样的需求说明书是良好的，需求说明书编写应该遵照怎样的框架，针对需求说明书的评测有哪些主要内容等，这些在下述章节将详细论述。
•编制良好的需求说明书8条原则。
1979年由Balzer和Goldman提出了作出良好规格说明的8条原则。
原则1：功能与实现分离，即描述要“做什么”而不是“怎样实现”。
原则2：要求使用面向处理的规格说明语言，讨论来自环境的各种刺激可能导致系统做出什么样的功能性反应，来定义一个行为模型，从而得到“做什么”的规格说明。
原则3：如果目标软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中。
描述该目标软件与系统的其他系统元素交互的方式。
原则4：规格说明必须包括系统运行的环境。
原则5：系统规格说明必须是一个认识的模型，而不是设计或实现的模型。
原则6：规格说明必须是可操作的。
规格说明必须是充分完全和形式的，以便能够利用它决定对于任意给定的测试用例，已提出的实现方案是否都能满足规格说明。
原则7：规格说明必须容许不完备性并允许扩充。
原则8：规格说明必须局部化和松散的耦合。
它所包括的信息必须局部化，这样当信息被修改时，只要修改某个单个的段落（理想情况）。
需求评审操作规范规范
需求评审流程目录5.2确定评审组长.. 23 5.3评审计划 (24)精心整理5.4评审准备 (26)5.5评审会议 (28)在团队开发中，充分的沟通精心整理是非常有必要的，沟通的方式之一就是通过文档。
不论制，而且也是一个重要而有精心整理效的沟通方式。
通过评审可以利用企业内部各种优秀成现，或者在后面越早的阶段精心整理发现，就能够及早发现潜在的风险，及时做好防范的对必采纳的建议性问题。
精心整理2. 职责评审组长：制定评审计结果，并且跟踪评审错误的精心整理改正。
评审人员：必要时参加与Array材料、必要时对材料进行解精心整理释、必要时参加评审会议，并且在确定需要改进时按记录人员：评审会议中记录评审人员提出的问题及相关讨论。
项目经理：制定保证评审和改正的项目进度计划，还要确保评审准备时间、评审会议时间及错误精心整理的改正时间。
而且评审安排及结果与所有项目成员沟果的关键，需要考虑以下因素：精心整理项目重要性：项目重要性是决定角色构成的最重提 项目复杂度：项目的复杂度也是决定角色构成的精心整理因素之一，根据温伯格的公式，项目管理的复杂度相当项目组成员的能力成分和水平：应当根据项目团队成员本身的各项技术水平，特别是精心整理分析和设计的技术水平如何，行业领域知识是否丰富各项人员需求。
需要说明的精心整理是，不具备评审能力的不应参加，可以通过旁听来提高过程规范：是否符合过程规范、是否按时经过评审、时发布（注意提交时间与发布时间的区别），以及评审精心整理的流程是否规范。
适合的评审人员：QA。
适合的评审人员：QA。
精心整理精心整理文档语法：文档成果正确使用通用的方法与术语文档语义：文档成果表达清晰、无歧义，可以反映系统目标。
所有质量合格的文怎么做。
精心整理适合的评审人员：行业业务专家、高级程序员和测试工文档逻辑：主要体现需求与设计正确性、一致性，无多余或错误。
右考虑周全，不同文档之间、文档各成分之间不互相矛精心整理盾，清晰说明相关部分之间的关系，特别是要符合相关适文档美学：否表述得更好一些，文字、图表是否能更加均衡和完整。
需求评审流程规范样本
需求评审流程规范1. 评审的作用、目的和概念在团队开发中, 充分的沟通是非常有必要的, 沟通的方式之一就是经过文档。
不论评审的效果如何, 发现多少问题都能够让相关人员了解需求与设计。
而经过相互之间的讨论, 澄清一些模糊的认识, 进一步理解文档的含义。
评审不可是软件开发活动中一个重要的质量控制机制, 而且也是一个重要而有效的沟通方式。
经过评审能够利用企业内部各种优秀成员的智慧, 为软件开发寻找最佳的解决方案。
评审的作用和目的主要是尽早发现潜在的问题, 尽早纠正缺陷, 控制纠正成本的滚雪球效应。
本阶段造成的错误如果能够及时地发现, 或者在后面越早的阶段发现, 就能够及早发现潜在的风险, 及时做好防范的对策, 做到未雨绸缪。
评审的过程不但是为了发现问题, 而且为了便于跟踪及改正, 还应当对问题进行记录。
特别是需要对问题的真实性进行确认, 剔除可能是误解、似是而非或不必采纳的建议性问题。
2. 评审角色构成因素评审人员的选择是评审效果的关键, 需要考虑以下因素:➢项目重要性: 项目重要性是决定角色构成的最重要的因素,评审角色的构成因素首先要根据项目的重要性而定。
这与需要投入的成本有关, 对于重要的项目一般会更多地投入资源, 提高评审级别。
➢项目复杂度: 项目的复杂度也是决定角色构成的因素之一, 根据温伯格的公式, 项目管理的复杂度相当于功能规模的平方数。
笔者认为还应该考虑技术复杂度、技术新鲜度和文档复杂度等因素。
➢项目组成员的能力成分和水平: 评审角色构成还应当根据项目团队成员本身的各项技术水平, 特别是分析和设计的技术水平如何, 行业领域知识是否丰富来进行搭配。
除了团队内部自己进行评审之外, 评审团队最好是一些独立于项目团队之外的成员构成。
应当注意的原则是人数要少而精, 一个人能够兼多个角色, 但要覆盖各项人员需求。
需要说明的是, 不具备评审能力的不应参加, 能够经过旁听来提高水平。
3. 基本角色职责➢评审组长: 制定评审计划、确定或制定各项评审准则、必要时组织评审人员进行培训、组织必要的资源、进行评审分工、确保正式评审准备充分、分发待评审文档、必要时召开并主持评审会议、向有关领导报告评审结果, 而且跟踪评审错误的改正。
需求评审流程规范
需求评审流程规範评审人员：必要时参加与评审有关的培训、按评审计划阅读待评审材料、保证对待评审材料的理解、与待评审材料作者讨论，并且指出和记录问题。
文件按评审计划準备并按时提交待评审材料、必要时对材料进行解释、必要时参加评审会议，并且在确定需要改进时按时完成修改。
记录人员：评审会议中记录评审人员提出的问题及相关讨论。
专案经理：制定保证评审和改正的专案进度计划，还要确保评审準备时间、评审会议时间及错误的改正时间。
而且评审安排及结果与所有专案成员沟通，必要时参加评审会议、阅读评审报告、分析缺陷原因，并且改进专案质量。
过程规範：是否符合过程规範、是否按照计划提交、是否按时经过评审、是否準时释出（注意提交时间与释出时间的区别），以及评审的流程是否规範。
适合的评审人员：qa。
文件规範：文件成果符合企业或业界已经制定的文件模板规範。
企业，甚至行业应当制定统一的文件规範，形成一个文件约定和规则，以统一文件内容与风格。
适合的评审人员：qa。
文件语法：文件成果正确使用通用的方法与术语并符合软体工程相关的技术标準，这里所说的语法包括自然语言的语法和建模语言的语法。
适合的评审人员要求：精通软体工程、分析与设计方法、建模工具和相关标準。
文件语义：文件成果表达清晰、无歧义，可以反映系统目标。
所有质量合格的文件（包括模型）都代表它期望代表的语义，而且应该在代表这些语义时具有一致性。
文字与图表应当互相补充说明，以更加清晰。
让别人看得懂，看完后知道下一步该怎幺做。
适合的评审人员：行业业务专家、高阶程式设计师和测试工程师。
文件逻辑：主要体现需求与设计正确性、一致性，无遗漏、多余或错误。
前后左右考虑周全，不同文件之间、文件与行业标準之间、同一文件各成分之间不互相矛盾，清晰说明相关部分之间的关係，特别是要符合相关行业的业务标準规範。
适合的评审人员：行业业务专家、产品经理和测试工程师。
文件美学：文件成果能否表述得更好一些，文字、图表是否能更加均衡和完整。
需求评审规范
需求评审规范变更记录目录一、概要 (4)1、规范化需求评审的目的 (4)2、明确需求评审目的 (4)3 、明确需求评审的与会人员 (4)4、每周需求评审次数 (4)二、评审准备 (5)1、人员职责 (5)2、材料 (6)3、内部评审 (7)4、准评审条件 (7)三、会议流程 (8)1、评审中 (8)2、准出标准 (9)3、评审后 (9)四、需求变更 (10)1、准更时间 (10)2、需求变更来源 (10)3、需求变更类型 (10)4、需求变更审核 (10)5、需求变更同步 (10)6、变更申明 (11)7、特殊说明 (11)五、声明 (11)一、概要1、规范化需求评审的目的1.1、提升需求质量，保障产品质量；1.2、提高评审会议效率和质量；2、明确需求评审目的2.1、让技术及测试对产品方案有详细的了解，以便后续开发更高效；2.2、让与会者清晰的知道自己在整个发开过程中处于什么位置，职责是什么，需要做什么，准备什么，提供什么帮助，对各自负责部分的实现难度及排期有一定的心理预期；2.3、需求评审只对本次需求进行讨论，不深入，不发散。
3 、明确需求评审的与会人员3.1、提前核实和通知本次需求参与的相关人员4、每周需求评审次数4.1、提前询问测试本周是否有时间进行需求评审，不要因为需求评审而导致测试计划打乱。
4.2、原则上需求评审每周最多2次。
二、评审准备1、人员职责产品：a）准备《产品需求文档》《产品原型文件》《美术需求文档》《美术效果图》。
b）编写《产品需求文档》《产品原型文件》时提前和相关的程序负责人进行沟通，将一些不确定的方案给确定下来，探讨方案实现的难易程度，确保某些需求的可行性，还可以发现可能与原有产品逻辑相冲突的地方等，提前将这些工作做好，确保需求评审会议的高效。
c）涉及运营的需要和运营提前进行沟通，确定运营需求细节并明确是否需要运营平台支持。
d）《美术需求文档》要和美术详细描述需求，明确功能。
需求评审管理制度范文
需求评审管理制度范文需求评审管理制度一、制度目的为了保障项目需求的准确性、完整性和可实施性，促进需求与项目进展的协同，规范项目中的需求评审流程和管理，提高项目的成功率，特制定本制度。
二、适用范围本制度适用于公司内所有项目的需求评审管理。
三、术语解释1. 项目：指公司内进行的特定任务或工作，为达到特定目标而策划和组织的一系列有序活动。
2. 需求：指项目或产品开发中确定的客户或用户对所需功能、性能和质量的需求描述。
3. 需求评审：指对项目需求进行全面、系统、合理的评估和验证的活动。
4. 需求评审会议：指项目团队成员和相关利益相关方参加的会议，用于讨论和确认需求。
四、需求评审流程1. 需求评审的类型根据项目规模、复杂程度和重要性，需求评审可分为小型评审、中型评审和大型评审，详细流程如下：（1）小型评审- 评审小组：由项目经理和相关技术人员组成。
- 评审时间：评审开始前3个工作日通知评审人员。
- 评审内容：评审前至少提前2个工作日将需求文档发送给评审人员进行阅读和准备。
- 评审方式：通过电话、邮件或在线沟通工具进行评审讨论。
- 评审记录：评审结束后，由项目经理记录评审结果和问题。
（2）中型评审- 评审小组：由项目经理、需求分析师、开发人员和测试人员组成。
- 评审时间：评审开始前5个工作日通知评审人员。
- 评审内容：评审前至少提前3个工作日将需求文档发送给评审人员进行阅读和准备。
- 评审方式：通过线下会议进行评审讨论。
- 评审记录：由项目经理指定专门的记录人员记录评审过程和结果。
（3）大型评审- 评审小组：由项目经理、需求分析师、开发人员、测试人员、用户代表等相关人员组成。
- 评审时间：评审开始前7个工作日通知评审人员。
- 评审内容：评审前至少提前5个工作日将需求文档发送给评审人员进行阅读和准备。
- 评审方式：通过线下会议进行评审讨论。
- 评审记录：由项目经理指定专门的记录人员记录评审过程和结果。
2. 需求评审的阶段需求评审可分为初步评审和终审两个阶段，详细流程如下：（1）初步评审- 评审目标：对需求文档的可行性、完整性和正确性进行初步评估。
订单需求评审管理规范
订单需求评审管理规范第1 页共4 页1.目的充分识别客户对产品和服务的要求和期望，对客户要求备货的合理性、可行性进行评审来证实公司满足交货的能力。
2.适用范围本文适用于公司与客户有关要求确定、评审以及客户沟通等方面的管理工作。
1.新开发客户2.量产客户需求超出规划产能部分3.职责3.1生产管理部(PMC)：3.1.1 PMC负责对接科技产品运作，针对客户订单的评审，确认准确的物料L/T时间、产品交付时间、产品是否具备量产等相关的工作；负责协调制造及相关协助部门依据规定要求进行订单确认及生产的工作。
3.1.2 组织各相关部门共同检讨新客户的需求，包含“人机料法环”等，并跟进各部门相关资源的准备工作，并及时更新相关进度，并汇报给高阶主管。
3.1.3 针对量产订单需求超出规划产能部分，及时组织相关部分开会检讨与产能相关问题，对于要满足客户需求所需的各种资源及时汇总并告知产品部运作经理，并依据资源到位状况回复交货计划。
4.控制要求4.1 与产品相关的要求：确认事宜4.1.1 PMC负责人确认好产品的bom清单，时刻与工程、研发沟通产品相关的要求，并负责组织有关部门对客户相关产品的要求进行确认。
确认内容如下：a）与产品相关的要求应在PO系统里得到体现，以及双方履行约定内容（交期）所具备的条件，具体详见《订单评审表》（附件1）。
b）识别潜在的要求，特别是那些技术复杂，不熟悉的特殊要求，并充分考虑生产难度、外购周期等情况，确保按期交付。
c) 没有形成文件的要求（如口头订单），在接受前，要求客户走OA单，可采取借用或赠送的方式得到顾客和公司领导的确认。
4.1.2 当PMC在接到客户PO备货要求后，进行收集、整理，并形成此产品有关要求的文件及生产计划等信息并通知到各相关部门。
4.2 与产品相关的要求：评审范围及总体要求4.2.1 在公司向客户做出产品交付的承诺前，PMC应组织制造等相关部门对与产品有关的要求进行评审。
需求评审标准
需求评审标准可以分为以下几个部分：一、需求完整性1. 需求内容是否完整，包括目标、功能、性能、界面、用户角色、输入输出、数据、扩展性等方面的要求。
2. 需求是否考虑了系统的边界情况，例如特殊输入、异常情况等。
3. 需求是否考虑了系统的扩展性和可维护性，是否提供了必要的文档和工具支持。
二、需求可行性1. 需求是否符合业务和技术上的可行性，是否考虑了资源限制（如时间、人力、预算等）。
2. 需求是否考虑了技术实现难度和风险，是否经过技术评审。
3. 需求是否考虑了系统的性能和安全性，是否符合法规和行业标准。
三、需求可测性1. 需求是否定义了明确的测试目标和指标，是否考虑了测试方法和工具。
2. 需求是否考虑了测试的顺序和复杂性，是否进行了测试设计。
3. 需求是否考虑了测试的边界条件和异常情况，是否提供了足够的测试数据支持。
四、需求一致性1. 需求是否符合公司或团队的需求管理规范和标准，是否经过评审和确认。
2. 需求是否与其他系统或数据接口保持一致，是否考虑了数据一致性和完整性。
3. 需求是否考虑了用户反馈和意见，是否进行了调整和修正。
五、需求优先级1. 需求是否按照重要性和紧急性进行了评估和排序，是否与项目目标相符。
2. 需求变更是否经过了评估和审批，是否影响了其他需求的优先级。
3. 需求优先级的确定是否考虑了市场需求和用户反馈，是否有明确的优先级策略支持。
六、需求描述质量1. 需求描述是否清晰易懂，是否使用了统一的术语和表达方式。
2. 需求描述是否包含了必要的上下文信息，例如用户角色、场景、时间、地点等。
3. 需求描述是否考虑了用户反馈和意见，是否有针对性地进行调整和优化。
七、需求可追溯性1. 需求文档是否建立了完善的版本控制，是否有明确的修改记录和审批流程。
2. 需求文档是否与代码、测试用例等其他项目文档保持一致，是否有明确的关联关系。
3. 需求变更是否能够及时反映在相关文档和系统中，是否有有效的追踪机制支持。
产品需求文档编写与评审的规范与流程
产品需求文档编写与评审的规范与流程产品需求文档（Product Requirements Document，简称PRD）是产品开发过程中的重要文件之一，它旨在明确产品的功能和性能要求，对产品的设计和开发起到指导作用。
为了确保PRD的质量和效果，制定一套规范的编写和评审流程尤为重要。
一、PRD编写规范1. 项目背景：简要说明产品的背景和目标，包括市场需求、竞争分析等。
突出产品的核心竞争力和市场定位。
2. 需求概述：对产品需求进行总体概述，明确产品的主要功能和特性。
可以采用列表或表格的形式列出要求，并确保语句简练明了。
3. 功能描述：详细描述产品的各项功能和特性，要求准确、清晰、完整，并附上相应的用例和流程图等辅助说明。
功能描述应该具体，每个功能点都要描述清楚其输入、输出和预期效果。
4. 性能要求：对产品的用户体验、性能指标和可扩展性等方面进行规定，并明确相应的测试方法和标准。
例如，页面加载时间不超过3秒，系统容量至少支持10000个用户同时在线等。
5. 界面设计：对产品的界面风格、交互方式和布局等进行详细的说明和设计。
可以使用界面原型或示意图形式展示，以便开发人员和设计人员理解并实现。
6. 数据需求：明确产品对数据的要求，包括数据源、数据格式、数据处理流程等。
要求数据的准确性、完整性和及时性，确保产品的功能和性能正常运作。
7. 安全性要求：对产品的安全性进行规定，包括用户权限管理、数据加密、漏洞防护等。
要求产品能够保护用户的隐私和数据安全。
8. 验收标准：制定明确的验收标准，以便在产品开发完成后进行测试和验收。
验收标准应该与需求一一对应，确保产品能够满足用户和市场的要求。
二、PRD评审流程1. 制定评审计划：在编写PRD之前，制定相应的评审计划，明确评审的时间、参与人员和评审的重点。
评审计划可以包括评审时间表、评审会议安排等。
2. 内部评审：由产品经理组织内部团队进行评审。
评审人员可以包括产品经理、开发人员、测试人员、设计人员等。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
需求评审规范
公司内部编号：（GOOD-TMMT-MMUT-UUPTY-UUYY-DTTI-
需求评审规范
变更记录
目录
一、概要
1、规范化需求评审的目的
、提升需求质量，保障产品质量；
、提高评审会议效率和质量；
2、明确需求评审目的
、让技术及测试对产品方案有详细的了解，以便后续开发更高效；
、让与会者清晰的知道自己在整个发开过程中处于什么位置，职责是什么，需要做什么，准备什么，提供什么帮助，对各自负责部分的实现难度及排期有一定的心理预期；
、需求评审只对本次需求进行讨论，不深入，不发散。
3 、明确需求评审的与会人员
、提前核实和通知本次需求参与的相关人员
4、每周需求评审次数
、提前询问测试本周是否有时间进行需求评审，不要因为需求评审而导致测试计划打乱。
、原则上需求评审每周最多2次。
二、评审准备
1、人员职责
产品：
a）准备《产品需求文档》《产品原型文件》《美术需求文档》《美术效果图》。
b）编写《产品需求文档》《产品原型文件》时提前和相关的程序负责人进行沟通，将一些不确定的方案给确定下来，探讨方案实现的难易程度，确保某些需求的可行性，还可以发现可能与原有产品逻辑相冲突的地方等，提前将这些工作做好，确保需求评审会议的高效。
c）涉及运营的需要和运营提前进行沟通，确定运营需求细节并明确是否需要运营平台支持。
d）《美术需求文档》要和美术详细描述需求，明确功能。
在需求评审前制作出效果图。
f）至少提前一天将资料以邮件形式发出并通知与会人员，让与会者提前查看。
g）会议的发起至少提前半天进行通知，最好是和资料一并提前1天发送，好做好提前的协调，保证都能准时参会。
开发：
a）提前熟悉资料，查看需求是否易于理解，细节有没有说清楚，逻辑是否成立。
b）对技术可行性进行分析，能不能做，成本多大规模，有多大风险。
c）提前给产品提出开发的问题反馈，产品可以提前补充完善，保证会议的高效。
测试：
a）提前熟悉资料，查看需求是否易于理解，细节有没有说清楚，逻辑是否成立。
b）对后期的用例编写和是否需要设计评审做到心中有谱。
c）提前给产品提出问题反馈，产品可以提前补充完善，保证会议的高效。
2、材料
、产品需求文档
产品需求文档要把需求的逻辑表达清楚没有歧义，对各个细节描述清晰。
各输入输出项、业务流程、计算规则、判断逻辑、以及特殊情况都要写清楚。
可以整理一份适合自己的需求文档自查清单，每次写完后从头到尾对照一遍。
、产品原型文件
产品原型文件尽量做到最高的保真度，每一个点击事件，业务流程最好都可以直接呈现出，以便开发理解。
产品原文件的元件管理要合理，要易于查询和修改。
、美术图
美术效果图需要在需求评审前出图，效果图要保证为定稿，不会再做修改。
3、内部评审
产品内部评审就是在产品团队内部进行小范围评审，确保需求逻辑的一致性。
规避大部分需求不合理的地方，可以直接有效的提升需求评审的效率。
也可以在产品内部进行复查，看是否有涉及多个产品的需求点，需要协调配合的。
4、准评审条件
a）需求带有完整的效果图；
b）与会人员对于需求内容没有异议；
c）材料至少提前1天发出，复杂需求的评审需要至少提前2天发出；
d）会议至少提前1天发起；
e）所有需求提前沟通，已确认可实现；
f）主要成员前期准备妥当，无缺席；
三、会议流程
1、评审中
、讲解内容：
a）明确本次需求评审会的背景及目标；
b）从功能点开始，告诉大家我们这个需求要为用户提供什么，这个需求是怎么来的，这个需求有什么价值。
然后讲原型，结合需求文档每个功能点逐一讲解。
、讨论/提问规范：
a）仅需求范围，可涉及基本技术方案，但不涉及具体技术实现；
b）需求细节问题不展开；
c）如果讨论了5分钟以上仍然没有结论，产品就记下这个问题，先进行后面的内容，最后再掉回头来讨论之前有争议的问题。
如还不能解决则记下来，会后协调。
、是否需要概设评审：
a）如果有，则要确认版本概设时间
b）如没有，则要确认版本提测时间
2、准出标准
1、需求合理，无异议；
2、无逻辑错误；
3、可遗留待确认需求细节问题，不影响整个需求正常流程；
4、技术可行性分析后是可行的；
3、评审后
1、会议纪要
会后及时整理输出会议纪要，罗列清楚问题或者争议点，已经形成结论的地方就不再赘述，待确定的问题继续找相关负责人进行讨论，直到得出最后的结论。
2、产品需求文档更新
将所有修改和变更的需求点在产品需求文档上写清楚，并同步到SVN。
SVN要保证是最新的需求文档。
3、发送会议纪要
将整理好的会议纪要和《产品需求文档》通过邮件的方式发送给所有相关人员。
四、需求变更
1、准更时间
a)逻辑类问题：提测前允许变更，提测后不允许变更；
b)细节类问题：提测前后均可变更；
2、需求变更来源
需求变更是谁提出的以及需求变更的原因是什么。
如内部人员发现了逻辑，需求上的问题，或功能上的建议以及开发、测试人员提出的需求和用户体验不符合等。
3、需求变更类型
需求有误、需求遗漏、需求不明确、需求建议；
4、需求变更审核
需求变更需要产品、开发、测试一起进行审核，共同确认是否进行需求变更。
审核包括对需求变更的影响程度，难易度，必要性，对开发周期的影响进行综合评估。
5、需求变更同步
需求变更后需要及时同步到redmine相关帖子中，并在《产品需求文档》中修改，记录下本次变更的内容。
变更以redmine为准。
6、变更申明
需求变更后，需要以邮件形式向相关人员说明需求变更来源，类型，审核结果以及变更前后的内容。
附上最新的产品需求文档地址和redmine地址
7、特殊说明
需求涉及到逻辑，不变更则完全影响版本质量及发布的，经项目组所有人员知晓并同意，允许变更，不受准更时间显示，但必须出具：需求重大变更说明书（需含变更原因、变更结果、责任划分、影响范围、总结），同时对相关文件以及版本计划进行修改并同步给所有成员。
五、声明
以上所有需求提出、变更，有redmine即同步redmine，没有的邮件发送至项目组成员，但最终都应该：以需求文档为标准；
附件1：需求评审流程图。