需求变更评审太重要了，因为需求直接决定着范围的边界，决定着我们工作量的大小，所以变更需求更需要我们来好好控制。
举个栗子吧，客户说通过退货订单类型，我看不出这是返回来维修的还是返工的，因为退货订单类型都是同一个，而我就要在创建退货订单时区分开来。这个时候如果我能识别出是返回来维修的，那我就不需要准备物料，反之则需要准备。
客户的真实需求是尽可能早的对退货订单可能使用到的物料做规划。这很明显是一个合理的需求，我们需要从下面几个维度对它进行评审：
1.是不是一定要在创建退货订单时区分？放在后续流程可不可以？
2.仅仅是对两种类型的订单进行区分吗？会不会涉及其他信息？
3.如果要实现客户的需求，我们应该通过哪些方式解决？
4.这些解决方法带给我们的代价是什么，对整个系统或业务流程有什么影响？并且要告知需求提出者。
做系统实施，一定有很多种方案和途径，但并不是客户提什么需求就要满足什么，需要在蓝图阶段对需求或需求变更进行评审，最终让系统更贴切我们的业务，更好的为企业来服务。
欢迎指正！
