说到这里，我们可以知道，基于情境进行需求设计，主要是将任务、用户组、数据表、任务之间的消息这4个元素进行相互验证，以保证需求的完整性，减少遗漏。

　　如果我们在需求分析和设计的初期就这么去做，能够识别出相当多之前遗漏的部分。

　　如果有机会大家可以尝试一下。

　　矛盾的需求

　　有两种情况可能会有需求矛盾的状况。

　　同一个用户，他在描述一个流程的时候，使用规则A，比如快递敲门的时候，要在关闭水龙头之后，才能去开门。

　　而当他在描述另外一个流程的时候，可能时隔数月，使用规则B，比如女朋友敲门的时候，要先去开门，再去关闭水龙头。

　　如果你简单的设计为先关水龙头再开门，或者先开门再关水龙头，都不妥当。

　　此时你需要做的应该是分析这两种情境，找出矛盾点和解决方案选项。

　　不同的用户，他们在描述同一个流程的时候，有矛盾。

　　这个可以理解，因为每个人的角色不同，看待一件事情的角度也就不一样，很可能会有矛盾的规则出现。

　　此时，你必然需要找出产生这样问题的原因，并且根据项目或者产品的目标进行引导，以达成一致。

　　OK，问题来了。

　　我们怎么发现需求是矛盾呢?

　　如果需求是一份清单，或者是一个长长的Backlog，必然很难发现。

　　而如果使用情境设计中的四个元素是很容易分析出来的。

　　我们在识别出任务后，对用户组以及任务间的消息分析可以很快得出，因为参与的用户组不同，而导致了任务间的消息触发机制不同。

　　这其实也相应的可以识别出备选的解决方案。

　　全局性

　　而我们在提到“只见树木，不见森林”的时候，不得不提到需求的全局性的问题。

　　在工程设计中，有个部门叫做“总体部”，主要职责是统筹各个专业设计部门对于需求的分析、设计和实现、测试。

　　他们会接收到来自于客户的情景化的需求，进行分析和总体设计后，将需求拆分成为各个设计指标，下发给各个专业设计部门。

　　比如，结构设计部门，你这边强度要求是多少多少。

　　动力设计部门，你这边要求要支持多少多少。

　　很显然，总体在分析这些需求的时候，会从全局上看，因为有些指标是相互牵制的。比如，你强度要是很大，那么可能自重会很重，对动力的要求也会高。

　　借鉴这样的想法，在使用情境设计的时候，也需要考虑这样的全局性。

　　在进行需求分析及设计的时候，一定要时不时的退后一步，看一下四层的关系，全局的目标。以保证不会偏离航线。

　　《需求设计》这本书，我会推荐给偏向后台设计的BA阅读，特别是抱怨和程序猿沟通不能的BA进行阅读。

　　我也不止一次的被程序猿提醒：“你这样的方案和客户对接，当然没问题。但是我们在设计的过程中需要考虑更多的细节。”