就坏事了。争吵不仅对评审工作没有好处，而且会无意中伤害同事们的感情。同时也解决不了问题。所以，在评审会的过程中，我们要尽可能的是在阐述事实与证据，而并不是从你心底要如何地说服别人。
人们在很多时候分不清楚自己究竟是“坚持真理”还是“固执己见”。毫不妥协或者轻易妥协都不是好办法。我们应当养成良好的习惯：不要一棍子打死异己的观点，尝试着让自己站在他人的立场思考问题，这样你会找到比较满意的答案。试著从不同的角度去看同样的问题。
{项目名称}评审报告_需求
基本信息
工作产品.版本号
名称，标识符，版本，作者，时间
工作产品标识号
评审方式
第几次评审
工作产品存放路径
评审地点
评审时间
参与人员
评审人员名字
工作单位或部门
职务职称
签字
问题记录及处理意见
问题编号
位置
问题描述
问题类型
严重程度
Problem A
Problem B
评审结论
评审结论
[ ] 工作产品合格，“无需修改”或者“需要轻微修改但不必再审核”。
[√] 工作产品基本合格，需要作少量的修改，之后通评审组长检查即可。
[ ] 工作产品不合格，需要作比较大的修改，之后必须重新对其评审。
签字
需求承诺（Requirement Consent）
什么是需求承诺，是指开发方和客户方的责任人对通过了同行评审的需求阶段的工作产品，作出承诺，同时该承诺具有商业合同的同等效果。 需求承诺如下：
需求承诺
XXX项目需求文档_《XXX需求说明书》，版本号：X.X.X,是建立在XXX与XXX双方共同对需求理解的基础之上，同意后续的开发工作根据该工作产品开展。如果需求发生变化，双方将共同遵循项目定义的“变更控制规程”执行。需求的变更将导致双方重新协商成本、资源和进度等。
甲方签字
乙方签字
不少人会草率地对待需求承诺：不就是在一张纸的最后一行文字下面签字吗，反正已经评审过了，我就签吧。但他将来变更需求时可能会表示不瞒：“不错，我是签字了，但是我并没有阅读文档。是你们要我在文档上签字的，我是相信你们才这么做的。”为了避免发生此类纠纷，人们在作出承诺之前务必要认真阅读文档，一定要明白签字意味着什么。
需求跟踪(Requirement Track)
为什么要进行需求跟踪？在整个开发过程中，进行需求跟踪的目的是为了建立和维护从用户需求开始到测试之间的一致性与完整性。确保所有的实现是以用户需求为基础。对于需求实现是否全部的覆盖。同时确保所有的输出与用户需求的符合性。
需求跟踪有两种方式，正向跟踪与逆向跟踪：
正向跟踪：以用户需求为切入点，检查《用户需求说明书》或《需求规格说明书》中的每个需求是否都能在后继工作产品中找到对应点。
逆向跟踪：检查设计文档、代码、测试用例等工作产品是否都能在《需求规格说明书》中找到出处。
正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式，都要建立与维护《需求跟踪矩阵》。需求跟踪矩阵保存了需求与后续开发过程输出的对应关系。矩阵单元之间可能存在“一对一”、“一对多”或“多对多”的关系。
见下表：简单的需求跟踪矩阵示例。
需求代号
需求规格说明书V1.0
设计文档V1.2
代码1.0
测试用例
测试记录
R001
标题或标识符
标题或标识符
代码文件名称
测试用例标识或名称
R002
…
…
…
…
…
…
…
…
…
简单的需求跟踪矩阵示例1
使用需求跟踪矩阵的优点是很容易发现需求与后续工作产品之间的不一致，有助于开发人员及时纠正偏差，避免干冤枉活。
很多人有这样的误解：如果依照“需求开发－系统设计－编码－测试”这样的顺序开发产品，由于每一步的输出就是下一步的输入，所以不必担心设
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
