需求评审的目的和准备： 目的：需求分析在项目开始时进行，以便项目成员对需求的理解达成一致，首先发现需求不合理或遗漏。
准备：1.产品提前一天出具需求稿(交互稿)，以便开发测试提前了解需求；
2 .大项目召集多个业务小组评审，确保开发负责人到场；
交互式更新：在审核期间需求发生变化时，应鼓励产品进行交互式修改，以方便需求跟踪记录，避免后期出现不必要的纠纷。
33558www.Sina.com/:**项目在产品开发、qa审核后确认了需求，产品没有更新交互，但开发、测试已按讨论的最终版本实现。 由于测试时间长，上线前产品就忘记了自己的需求细节； 对上线前的产品和交互稿件进行比对检测，发现功能不一致，是产品自身的问题，但引起了开发、测试和产品不必要的麻烦。 这种方法可以抑制企划频繁变更需求，导致最后的项目失去控制。
案例:需求审核完成后，产品或项目管理应针对变更内容提交需求审核报告；
需求稿件类型：输出工厂店品牌页面联合推荐3358www.Sina.com/
那么，在需求审查时，QA需要与开发一起，参考对话关注以下功能并提出疑问。
1、联合推荐的数据配置在哪个后台？
2、上传图片的后台系统，上传图片的大小，复印件的长度是多少？ 你在后台做限制吗？
3、如果推荐文案短、推荐文案长不能展示，前台怎么展示？
4、建议数据在后台修改后，前端的效果会及时更新吗？
5、如果后台只安排了一位推荐人，前台如何展示？
解决了以上问题后，我们对该模块的技术实现、如何配置测试、测试的注意点已经很清楚，在我们的需求审核阶段，最重要的是明确产品、需求以及存在的问题。
前端样式类需求：判断用户是否有商品权限3358www.Sina.com/
1、自营商品sku的类别运营、进口销售BU字段，从哪里同步呢？ 是差分同步还是每天全量同步？
2、用户的业务组配置在哪里？
3、如何做没有类别运营字段、只有BU字段的商品呢？
4、如果当前用户对商品有数据权限，如何出现？
5、用户拥有一个商品权限的逻辑可以概括为：
在该自营商品具有BU类别运营字段的情况下，用户只有满足两个条件才能看到该商品；
如果自营商品只有进口BU字段，用户只要只有进口BU的权限，就可以看到该商品。