需求评审是大家日常开发工作中，一个重要且频繁的工作。如果是评审一个自己非常熟悉的模块的需求，那会非常的轻松，因为你足够了解。但是，假如你是去评审一个自己完全不了解的需求时，需要关注哪些点，才能保证你掌握足够的信息。
一、评审需求
需求评审是大家日常开发工作中，一个重要且频繁的工作。如果是评审一个自己非常熟悉的模块的需求，那会非常的轻松，因为你足够了解。但是，假如你是去评审一个自己完全不了解的需求时，需要关注哪些点，才能保证你掌握足够的信息。
1. 确定需求跟 APP 哪个版本上线
确定了跟版的版本号后，就能确定自己的需求最终要集成到哪个集成分支，然后就可以从对应的集成分支创建自己的功能分支。
假如评审完需求发现，需要的集成分支还没有创建，只能暂时从上一个版本的集成分支创建功能分支的话，那么一定要在笔记里备注一下，以免集成到了错误分支。
2. 确定各方人员是否到齐
一般来说，评审需求时，各端人员一定都要出席，人员齐整的话，遇到一些有疑问的点，才能及时的确定清楚，否者会后还需要单独找时间沟通，影响效率。
3. 确定是否涉及 UI 新增和改动
一般来说，公司的 UI 资源都是比较紧张的，所以本次需求如果涉及 UI 的改动的话，一定要确定 UI 图产出时间，以免项目延期。
同时，还需要确认是否涉及UI的动效，因为有动效和没有动效的开发时间和成本是有很大差别的，开发动效一般需要多投入一些精力去开发和自测。
当然了，非常复杂的动效，可以通过一些框架来加载，比如Lottie。
4. 是否会涉及线上流程的改动
一些需求会涉及到对线上流程的改动，比如混合开发项目中，FE 和 Native 存在交互，需要确认开发新需求是否会对这个交互有影响。
如果有影响，就需要你多了解一下老的交互流程是什么，测试 case 有哪些，具体改动点是哪里，改动以后对老流程有怎样的影响。
5. 是否需要做版本控制
一般新的业务需求，不用考虑版本控制问题。但是，如果是修改线上业务，一定要考虑版本控制：是 FE 去做，还是 Server 端去做？
6. 确定需求的所有入口，每个入口请求参数是否一致
记得有一次开发直播的需求，原本以为，直播只有一个入口，后来，等要提测的时候才发现，总共有 3 个入口 。
而且每一个入口涉及到不同的业务场景，因此，从不同的入口进来，请求接口的参数是不一样的。
并且直播还涉及到与 H5 通信，而且不同入口，协议也不一样。
所以，为了避免这种情况发生，一定要在评审的时候多关注这一点。
以上就是我们需求评审的时候会比较关注的几个点。
当然了，不一定很全面，但是大家记住一点就行了，需求评审的时候一定要多问几个为什么。
并且建议大家把需求评审时候的一些重要信息记录到笔记里。
因为，在开发期间，你很容易受到其他事情的干扰，比如开会，或者中途让你修复一个bug，如果不记录下来，可能后面自己都忘记了。
最后，总结一下吧：
1.需求评审时，多问几个为什么；
2.随时记录下重要信息。
延伸阅读：
二、评审类型有哪些
按评审目的分类，可以分为管理评审和技术评审。管理评审是对项目计划、进度、资源、成本相关工作产品的评审，重点关注项目状态，根据评审结果决定下一步的工作安排。例如进展评审、里程碑评审就属于管理评审。技术评审是对项目工程技术类工作产品的评审，评估技术成熟度，检查是否满足规定的需求和标准，尽早发现问题和缺陷。同行评审属于技术评审。
按评审的组织范围分类，可以分为内部评审和外部评审，其中内部评审又包括公司级评审、部门级评审以及项目级评审。
按评审的组织方式分类，可以分为会议评审和审查。审查是指由评审人员独立对工作产品进行检查，记录问题并反馈审查结论。
