需求评审的关注点

评审的目标是在写代码前发现所有的问题。不要吝惜花时间在前期的沟通上，这能减少中后期的意外，不耽误最终的发布时间。我们可从这些思路出发来发现问题。

文笔

• 错别字，特别是界面上的文案。例如，登陆->登录
• 歧义，需要补充解释或换一种表述
• 表达不清，模糊
• 没有统一术语，多处地方用不同词语来表示同一概念
• 是否杂乱无章，不便于阅读和查找信息

逻辑

• 需求的目标都没想清楚，为了有新版本而做需求
• 流程的出入口和分支：是否明确，是否过多（连用户都会昏头转向）
• 条件与规则说明：是否有矛盾，是否仍有不确定的情况，是否疏漏了其它条件以及多个条件组合的情况
• 缺少异常状态的考虑
• 缺少说明数据的来源、类型、精度、取值范围、默认值、显示格式、计算处理方式
• 没考虑其它功能或需求的关联影响
• 用户体验
• UI相关，不同状态可能不一样：文案、大小、颜色、阴影、字体、对齐方式、前后层次、动画、图片、声音、视频等

实现

• 软硬件限制、人员能力不足等条件下无法实现
• 难度较大，耗时
• 遗留的坑会导致出严重bug的概率大，风险高
• 性能不佳，会造成用户体验差
• 是否有比产品经理想到的更好的方案
• 能否复用已有的逻辑或使用业界更通用的有开源实现的做法
• 后续的迭代考虑，是否在设计上预留可扩展性
• 不重要的部分（例如后台系统）可以由开发自行决定界面和交互