对于需求而言，最宏观的概念是六字诀：
Who->Where->Which->How->End->Effect；谁（Who）在什么地方（Where），对那个对象（Which）做了什么（How），做完了（End），影响是什么（Effect）；
在How上面要做的文章是最多的，How其实本质就是场景，操作，数据（对象）。
刷墙
只要是被操作的数据就需要考虑是否需要添加状态，比如IMS审批从NPIOT系统中抽调的数据就需要考虑是否需要加状态，防止审批期间物料被移动；不加状态，就代表着，操作本身不具有数据"加锁"性或者"刷墙性"（狗撒尿性，数据刷一层油标记），比如简单的查询看结果；但是一旦被刷墙了，就要考虑是否需要再刷回去。
覆盖刷墙
需求的任何操作都要考虑一个"数据冲突问题"（是否破坏了人家安静的生活），现有的操作是否会导致信息冲突，比如数据导入，如果导入图纸，重复了怎么处理，怎么来判定处理；IMS审批的数据也是这个歌道理，你要考虑到如果别的数据动用了你操作的数据是否可以？两个方向考虑问题：你的动作是否导致了别的数据的冲突（导入）；你的动作"维护的"数据是否导致了别的数据冲突（IMS审批）；
冲突问题的本质就是刷墙，本来数据已经被人刷墙了，结果你又刷了一遍，如果你的优先级就是高或者就是要覆盖性的刷墙，没问题；但是如果没有权限去覆盖或者不确定，你就要考虑是否是要用户来判断，或者新添加一个字段（墙，用来刷）来标识；
亲戚关系
每创建一条数据的时候，都要捋清一个问题，他和"近亲"数据的关系（比如WAS单预留项和需求的关系，WAS单预留项和WAS单的关系）； 八竿子打不到的亲戚就不要管了，我们只管"近亲"的。
外一篇 When：场景集市
When的概念有两个，一个是出发需求的时间点，另外一个就是场景（外景）；考虑需求"支撑"一定要把支撑的场景想全了，比如发放控制，需要跟踪需求的预留量，支撑场景一是精确预留，每一个需求，会精确到一条UP记录；但是还有场景二，费精确预留，所以客户有一个需求，一定会有一个场景集市来做做支持，一定要把场景集市都考虑清楚了；比如Peter之前就有一种思想：把所有的物料类型都过一遍，以确定所有的场景，我们设计的需求流程图都走得通，很多时候可能就是某一类物料（关联的内容和约束不一样）就走不通了，这个时候需要考虑一下。