需求评审规范
需求管理规范
需求管理规范需求管理规范：需求采集在需求采集阶段，我们通过各种形式对用户的需求进行收集，包括用户访谈、调查问卷、数据分析、领导提供的需求、产品人员的需求等。
在收集需求时，我们需要详细记录需求的属性，并记录可追溯的反馈人员。
为了确保采集到的需求符合运营需求，我们需要遵循以下采集要求：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、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：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：需求评审流程图。