1、到那步再解决：很多自己考虑的问题实际当中不一定会遇到或很少，提前考虑会导致系统过分臃肿，一旦系统臃肿了，实现中遇到的困难就越多。
例子：处于租赁流程中的资产可以用于发起调拨流程吗？流程与资产状态的关系类似原子操作与事务的关系。
2、设计系统的理念和技术实现系统的思路是两回事，有时候需求方临时提出的改动可能技术上可以实现，但是会破坏理念的完整性，并降低系统的通用性，需要慎重取舍。
例子：资产租赁可以租给子公司，子公司需要发起周检流程，但是子公司不在系统部门管理中，可以技术上添加虚拟列表，但是概念上部门和子公司就混乱了。
3、系统实现之前，需求方不能提出一些具体的意见，但是系统上线以后，需求方提出的改动必然有很多。
例子：系统实现之前，甲方只能提出一些需求，上线以后，看着系统演示，甲方持续提出新的要求。
4、甲方的每个人只有局限的视角，不会从总体的视角考虑系统的运行，提出的需求常常矛盾，作为系统设计人员需要通盘考虑所有需求，发现矛盾并及时拒绝。
例子：资产租赁可以租给子公司，子公司需要发起周检流程，但是子公司不在系统部门管理中。
5、系统不能解决人的问题，当系统设计可以解决90%的问题时，还有10%的问题可以留待系统的操作人员去发挥才智。
例子：