需求评审规范(优选.)
SOP_RM_V1.0(需求评审标准)
修订历史记录目录1目的 (3)2范围 (3)3需求评审的重要性 (3)4角色与职责 (3)5需求评审的注意点 (4)6评审的形式 (4)7评审的标准 (4)7.1组织和完整性 (4)7.2正确性 (4)7.3质量属性 (5)7.4可跟踪性 (5)7.5特殊的问题 (5)8进入和退出审查的标准 (5)9相关文件 (5)10附录 (6)10.1评审标准参考 (6)10.2检查清单 (7)1目的需求管理（RM，Requirements Management）就是在客户和软件项目之间对给定需求建立一种共同的理解，并对给定需求进行管理。
客户包括为公司外部或内部的客户。
需求管理的目的是维护需求并且确保能把对需求的更改反映到项目计划、活动和工作产品中。
2范围顾客需求的变更贯穿了软件产品开发的整个生命周期，所以本控制程序的实施应贯穿于软件项目的整个生命周期，并适用于本公司所有软件开发项目。
3需求评审的重要性软件的缺陷并不是在编程的时候才出现的，需求和设计阶段都会产生问题，如果缺陷发现的越迟，修正这个错误就要返回到以前的状态，反攻的时间就花费的很多了，如果错误还不能够被及时发现，那就可能带来更大的危害，缺陷发现的越找，修正的越早，所用的成本就月低，越迟，成本就越高。
所以我们对需求评审要认真对待了。
概括下有几点•对软件需求进行正确性的检查，能发现需求定义中的错误，从而节约成本，使后续过程的变更减少，降低风险。
•保证软件需求的可测试性，即确认客户的需求是明确的，可遇见的。
可以用测试用例反应出来•通过产品需求，可以使产品，开发，测试等部门相互沟通，达成一致•通过产品需求的评审，更好的理解产品的功能性和非功能性需求，为制订测试计划，测试范围，工作量等提供参考。
4角色与职责•业务专家或是熟悉该业务的人员（通常也叫业务方代表）•文档审查人员•架构师•需求分析师•需求评审组织人员及记录人员5需求评审的注意点•明确自己的角色和责任，熟悉评审的内容•针对问题表达自己的观点，对事不对人。
采购需求及评审标准
采购需求及评审标准第一部分：招标要求一、采购编号：BGPC-G18041二、项目名称：北京市市级行政事业单位2018-2019年度印刷定点服务政府采购项目三、招标内容：1.本次印刷定点供应和相关服务招标，共分四包，具体分包及选择中标人数量：第一包普通印刷≤80家第二包快速（数码）印刷≤80家第三包信封类印刷≤5家第四包票据证书印刷≤15家注：投标人最多投两包，否则其投标无效；投标人不能同时投第一包和第二包，否则其投标无效。
2.招标范围包括：上述印刷品的印制、运输等服务。
3.协议执行有效期：自签订框架协议之日起至2019年12月31日。
第二部分：技术文件招标文件中所有带*条款均为实质性响应条款，投标文件须完全响应，未实质响应的，按照无第三部分虚拟服务需求下列服务要求为虚拟项目，投标人按照下列虚拟项目进行报价。
评标委员会根据评审细则对报价进行价格评审。
该报价对供应商具有法律约束力。
如采购人提出的真实的采购需求与以下的虚拟项目一致，中标人在提供该服务时，价格不得高于其报价；采购人提出的其他服务要求，中标人提供服务时，其价格须参照本项目中的报价。
中标人在生产经营活动中应遵守所在地的相关《印刷业挥发性有机物排放标准》。
第一包：普通印刷名称：宣传手册；数量：5000册；规格：210 X 297（高）毫米；封面：4 P，双面四色印刷，157克国产铜版纸，封面、封底单面覆亚膜；内文：200 P（P指页码），双面四色印刷，128克国产铜版纸；装订方式：无线胶订；包装方式：每10本用牛皮纸包一包，塑料捆扎绳打井字包；甲方提供电子文件（文件可直接用于印刷），北京市范围内送至指定地点。
第二包：快速（数码）印刷名称：内部资料汇编；数量：500册；规格：210 X 297（高）毫米；封面：单面四色印刷，157克铜版纸，封面、封底单面覆哑膜；内文：40 P（P指页码），双面单色印刷，80克全木浆胶版纸；装订方式：骑马钉；包装方式：每50本用牛皮纸包一包，塑料捆扎绳打井字包；甲方提供电子文件（文件可直接用于印刷），北京市范围内送至指定地点。
项目评审要求
项目评审要求
项目评审要求通常涉及以下几个方面，这些要求是针对项目的规划、实施和完成阶段，以确保项目能够达到预期的目标和利益。
1.目的和目标：评审项目是否具有明确的目的和目标，以及
这些目的和目标是否合理和可衡量。
2.资源：评估项目所需的人力、财力和物力资源是否充足，
以及是否可以在预定的时间内获得这些资源。
3.技术可行性：评估项目的技术可行性，包括所采用的技术、
方法、工具和流程是否合适，以及是否能够满足项目的需
求。
4.组织和管理：评估项目的组织和管理能力，包括项目团队
的结构、能力和经验是否能够有效地实施和管理项目。
5.风险评估：识别和分析项目中可能出现的风险和不确定性，
并评估这些风险和不确定性对项目的影响。
6.效益和效果：评估项目的效益和效果，包括项目的收益、
成本效益比、社会效益等方面是否符合预期。
7.可持续性和长期效益：评估项目是否具有可持续性和长期
效益，包括是否能够在项目完成后继续产生效益，以及是
否有适当的维护和支持计划。
8.合法性和合规性：评估项目是否符合相关的法律、法规和
政策要求，包括知识产权、环保、安全等方面的要求。
9.社会影响：评估项目对社会的整体影响，包括对环境、经
济和社会的影响，以及是否符合社会和公众的利益。
10.沟通和协调：评估项目中的沟通和协调机制是否有效，
包括与利益相关者的沟通、信息共享和协调等方面。
在项目评审过程中，需要遵循公正、客观、透明和专业的原则，以确保评审结果的准确性和可靠性。
同时，评审过程也需要充分考虑利益相关者的意见和反馈，以确保项目的可行性和可持续性。
需求评审流程规范
需求评审流程规範评审人员：必要时参加与评审有关的培训、按评审计划阅读待评审材料、保证对待评审材料的理解、与待评审材料作者讨论，并且指出和记录问题。
文件按评审计划準备并按时提交待评审材料、必要时对材料进行解释、必要时参加评审会议，并且在确定需要改进时按时完成修改。
记录人员：评审会议中记录评审人员提出的问题及相关讨论。
专案经理：制定保证评审和改正的专案进度计划，还要确保评审準备时间、评审会议时间及错误的改正时间。
而且评审安排及结果与所有专案成员沟通，必要时参加评审会议、阅读评审报告、分析缺陷原因，并且改进专案质量。
过程规範：是否符合过程规範、是否按照计划提交、是否按时经过评审、是否準时释出（注意提交时间与释出时间的区别），以及评审的流程是否规範。
适合的评审人员：qa。
文件规範：文件成果符合企业或业界已经制定的文件模板规範。
企业，甚至行业应当制定统一的文件规範，形成一个文件约定和规则，以统一文件内容与风格。
适合的评审人员：qa。
文件语法：文件成果正确使用通用的方法与术语并符合软体工程相关的技术标準，这里所说的语法包括自然语言的语法和建模语言的语法。
适合的评审人员要求：精通软体工程、分析与设计方法、建模工具和相关标準。
文件语义：文件成果表达清晰、无歧义，可以反映系统目标。
所有质量合格的文件（包括模型）都代表它期望代表的语义，而且应该在代表这些语义时具有一致性。
文字与图表应当互相补充说明，以更加清晰。
让别人看得懂，看完后知道下一步该怎幺做。
适合的评审人员：行业业务专家、高阶程式设计师和测试工程师。
文件逻辑：主要体现需求与设计正确性、一致性，无遗漏、多余或错误。
前后左右考虑周全，不同文件之间、文件与行业标準之间、同一文件各成分之间不互相矛盾，清晰说明相关部分之间的关係，特别是要符合相关行业的业务标準规範。
适合的评审人员：行业业务专家、产品经理和测试工程师。
文件美学：文件成果能否表述得更好一些，文字、图表是否能更加均衡和完整。
需求评审标准
需求评审标准可以分为以下几个部分：一、需求完整性1. 需求内容是否完整，包括目标、功能、性能、界面、用户角色、输入输出、数据、扩展性等方面的要求。
2. 需求是否考虑了系统的边界情况，例如特殊输入、异常情况等。
3. 需求是否考虑了系统的扩展性和可维护性，是否提供了必要的文档和工具支持。
二、需求可行性1. 需求是否符合业务和技术上的可行性，是否考虑了资源限制（如时间、人力、预算等）。
2. 需求是否考虑了技术实现难度和风险，是否经过技术评审。
3. 需求是否考虑了系统的性能和安全性，是否符合法规和行业标准。
三、需求可测性1. 需求是否定义了明确的测试目标和指标，是否考虑了测试方法和工具。
2. 需求是否考虑了测试的顺序和复杂性，是否进行了测试设计。
3. 需求是否考虑了测试的边界条件和异常情况，是否提供了足够的测试数据支持。
四、需求一致性1. 需求是否符合公司或团队的需求管理规范和标准，是否经过评审和确认。
2. 需求是否与其他系统或数据接口保持一致，是否考虑了数据一致性和完整性。
3. 需求是否考虑了用户反馈和意见，是否进行了调整和修正。
五、需求优先级1. 需求是否按照重要性和紧急性进行了评估和排序，是否与项目目标相符。
2. 需求变更是否经过了评估和审批，是否影响了其他需求的优先级。
3. 需求优先级的确定是否考虑了市场需求和用户反馈，是否有明确的优先级策略支持。
六、需求描述质量1. 需求描述是否清晰易懂，是否使用了统一的术语和表达方式。
2. 需求描述是否包含了必要的上下文信息，例如用户角色、场景、时间、地点等。
3. 需求描述是否考虑了用户反馈和意见，是否有针对性地进行调整和优化。
七、需求可追溯性1. 需求文档是否建立了完善的版本控制，是否有明确的修改记录和审批流程。
2. 需求文档是否与代码、测试用例等其他项目文档保持一致，是否有明确的关联关系。
3. 需求变更是否能够及时反映在相关文档和系统中，是否有有效的追踪机制支持。
设计评审管理办法的标准与规范
设计评审管理办法的标准与规范1. 引言设计评审是产品开发过程中非常重要的环节之一，通过设计评审可以确保产品的设计符合项目需求和标准，并提高产品的质量和可靠性。
设计评审管理办法旨在规范和标准化设计评审的过程，确保评审的有效性和高效性。
本文将介绍设计评审管理办法的标准与规范，包括评审流程、评审要求和评审记录的管理。
2. 评审流程评审流程是设计评审的核心，它包括评审准备、评审会议和评审后处理三个主要阶段。
2.1 评审准备2.2 评审会议评审会议是设计评审的核心环节，评审人员根据评审准备阶段确定的评审目标和评审材料进行讨论和审核。
评审会议应当有明确的议程，并由评审主持人领导。
在评审会议中，评审人员应当充分发表意见和建议，并就设计的合理性、符合性和可行性进行讨论。
评审会议的结果可以是通过设计、修改设计或者重新设计。
2.3 评审后处理评审后处理阶段是评审的收尾工作，主要包括整理评审记录、制定改进措施和追踪评审结果。
在评审后处理阶段，评审人员应当及时整理评审记录，记录评审意见和决策结果。
同时，评审主持人应当根据评审的结果和意见制定改进措施，并跟踪评审结果的执行情况。
3. 评审要求评审要求是设计评审的基本条件，包括评审内容、评审标准和评审人员要求。
3.1 评审内容评审内容是评审的核心，它涉及到设计的各个方面。
评审内容应当包括设计目标、设计思路、设计方案、设计细节等。
评审人员应当根据评审内容，对设计的合理性、优劣性和可行性进行评判。
3.2 评审标准评审标准是评判设计的依据，它可以是相关的标准和规范，也可以是项目需求和用户需求。
评审标准应当明确、具体和可量化，并应当与评审内容相对应。
3.3 评审人员要求评审人员要求是评审的基本条件，评审人员应当具备相关的技术和专业知识，并具有一定的项目经验。
评审人员应当保持客观、公正和专业的态度，并能够充分发表意见和建议。
4. 评审记录的管理评审记录是评审的成果，它记录了评审过程和结果。
02-需求规格说明书评审
是否所有对《软件需求规格说明书》的变更都进行了评审和批准? 是否评审发现的问题已被跟踪直至解决? 是否对需求变更造成的影响都评审过? 项目计划、产品和活动和业务需求是否保持一致?
更请求）
是否所有对《需求规格说明书》的变更都 进行了评审和批准?
是否评审发现的问题已被跟踪直至解决? 是否对需求变更造成的影响都评审过?
项目计划、产品和活动和业务需求是否保 持一致?
备注
本次检查小计： 合格项数量：
一般符合项数量： 不符合项数量： 不适用项数量：
合格是否有《需求跟踪矩阵》? 是否所有的需求项都被映射到设计项? 接口需求是否准确识别并放入需求跟踪矩阵进行管理？ 是否所有的设计项可以追溯到需求项? 是否所有的设计项都可以映射到代码项? 是否所有的代码项可以追溯到设计项? 是否所有的需求项都有对应的系统测试用例? 是否所有的设计项都有对应的集成测试用例? 是否所有的系统测试用例都可以追溯到需求项? 是否所有的集成测试用例都可以追溯到设计项? 是否根据实际情况更新需求跟踪表的状态? 是否评审发现的问题已被跟踪直至解决? 基线化后,所有对《软件需求规格说明书》的变更是否进行跟踪？（审计发现的问
是否所有的代码项可以追溯到设计项?
是否所有的需求项都有对应的系统测试用
例?
是否所有的设计项都有对应的集成测试用
例?
是否所有的系统测试用例都可以追溯到需
是否所有的集成测试用例都可以追溯到设
是否根据实际情况更新需求跟踪矩阵的状
态?
是否评审发现的问题已被跟踪直至解决?
基线化后,所有对《需求规格说明书》的变 更是否进行跟踪？（审计发现的问题或变
需求规格说明书评审Checklist
项目名称： 项目编号： 项目负责人：
需求评审管理制度
需求评审管理制度一、目的需求评审是指在软件开发过程中，对需求进行全面评估和审查，确定需求的合理性、准确性和可行性，以确保产品开发符合用户需求和项目目标。
制定需求评审管理制度的目的是规范需求评审的流程和标准，提高评审质量，降低风险，保证项目的顺利进行。
二、范围本制度适用于公司内部所有软件开发项目的需求评审过程，包括但不限于新需求评审、变更需求评审以及验收前需求评审等。
三、流程1. 需求提交需求评审由需求提交人负责提交需求文档，并在系统中标注需求状态为“待评审”。
2. 需求准备项目经理根据需求文档和项目进度，确定评审时间和评审人员，并提前通知所有评审人员。
3. 评审会议评审会议由项目经理主持，评审人员根据需求文档和评审标准进行讨论和审查，提出修改意见或建议。
4. 修改与确认评审结束后，需求提交人对评审意见进行整理和修订，包括修改需求文档和系统中需求状态更新。
5. 确认与验收需求经过修改后，项目经理和需求提交人确认需求文档的最终版本，并进行验收，确保需求质量达到要求。
四、评审标准1. 合理性评审人员根据公司的业务流程和项目实际情况，判断需求是否合理，能够满足用户需求和项目目标。
2. 准确性评审人员对需求文档中的数据和信息进行核实，确保需求描述准确无误。
3. 可行性评审人员分析需求在技术和资源上的可行性，评估是否能够在规定时间内完成，满足项目的进度和成本要求。
4. 可测量性评审人员对需求文档中的量化指标和效果进行评估，确保需求能够被量化和跟踪。
五、评审记录评审会议由项目经理负责记录，记录包括评审人员名单、讨论意见、修改建议等内容，并在系统中标注需求评审的结果和进度。
六、需求变更如果评审结果需要对需求进行重大修改或变更，需求提交人和项目经理一起商讨并制定变更计划，确保变更后的需求符合项目目标和用户需求。
七、需求验收项目完成后，需求文档将作为交付物之一提交给验收人员，验收人员根据需求文档进行验收，确保项目交付符合用户需求和项目目标。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
需求评审规范
变更记录
目录
一、概要 (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）《美术需求文档》要和美术详细描述需求，明确功能。
在需求评审前制作出效果图。
f）至少提前一天将资料以邮件形式发出并通知与会人员，让与会者提前查看。
g）会议的发起至少提前半天进行通知，最好是和资料一并提前1天发送，好做好提前的协调，保证都能准时参会。
开发：
a）提前熟悉资料，查看需求是否易于理解，细节有没有说清楚，逻辑是否成立。
b）对技术可行性进行分析，能不能做，成本多大规模，有多大风险。
c）提前给产品提出开发的问题反馈，产品可以提前补充完善，保证会议的高效。
测试：
a）提前熟悉资料，查看需求是否易于理解，细节有没有说清楚，逻辑是否成立。
b）对后期的用例编写和是否需要设计评审做到心中有谱。
c）提前给产品提出问题反馈，产品可以提前补充完善，保证会议的高效。
2、材料
2.1、产品需求文档
产品需求文档要把需求的逻辑表达清楚没有歧义，对各个细节描述清晰。
各输入输出项、业务流程、计算规则、判断逻辑、以及特殊情况都要写清楚。
可以整理一份适合自己的需求文档自查清单，每次写完后从头到尾对照一遍。
2.2、产品原型文件
产品原型文件尽量做到最高的保真度，每一个点击事件，业务流程最好都可
以直接呈现出，以便开发理解。
产品原文件的元件管理要合理，要易于查询和修改。
2.3、美术图
美术效果图需要在需求评审前出图，效果图要保证为定稿，不会再做修改。
3、内部评审
产品内部评审就是在产品团队内部进行小范围评审，确保需求逻辑的一致性。
规避大部分需求不合理的地方，可以直接有效的提升需求评审的效率。
也可以在产品内部进行复查，看是否有涉及多个产品的需求点，需要协调配合的。
4、准评审条件
a）需求带有完整的效果图；
b）与会人员对于需求内容没有异议；
c）材料至少提前1天发出，复杂需求的评审需要至少提前2天发出；
d）会议至少提前1天发起；
e）所有需求提前沟通，已确认可实现；
f）主要成员前期准备妥当，无缺席；
三、会议流程
1、评审中
1.1、讲解内容：
a）明确本次需求评审会的背景及目标；
b）从功能点开始，告诉大家我们这个需求要为用户提供什么，这个需求是怎么来的，这个需求有什么价值。
然后讲原型，结合需求文档每个功能点逐一讲解。
1.2、讨论/提问规范：
a）仅需求范围，可涉及基本技术方案，但不涉及具体技术实现；
b）需求细节问题不展开；
c）如果讨论了5分钟以上仍然没有结论，产品就记下这个问题，先进行后面的内容，最后再掉回头来讨论之前有争议的问题。
如还不能解决则记下来，会后协调。
1.3、是否需要概设评审：
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：需求评审流程图
最新文件仅供参考已改成word文本。
方便更改
最新文件---------------- 仅供参考--------------------已改成-----------word文本--------------------- 方便更改。