上周说到最近在看几本书，基本上都是用来解决“只见树木，不见森林”的问题的。
今天和大家分享第二本《需求设计》。
如果说《用户故事地图》可以解决大部分PO以及BA在需求分析时可以“又见树木，又见森林”的话，《需求设计》其实主要是写给BA和SA的。
如果运用得当的话，我们可以使用用户故事地图来进行需求的收集和整理，用需求设计提到的情境驱动设计来进行构思和设计。
之前我曾经接触过一些设计师，非软件的。
大家知道汽车或者飞机是怎么设计出来的吗？
一般来说，客户方会给出需求，比如我要求车子要能运送1吨以内的货物，满载时车子的速度可以达到80码，油气混合动力，其他满足国家标准……
接下来会由总体设计师对其需求进行分析，也就是进行指标的分解。
比如，要能运送1吨以内的货物，可能会对车体设计、动力设计等都有相应的需求。
而整个设计部门会按照功能进行划分，会有车体结构设计部门，动力设计部门，电子设备设计部门。
一条客户需求可能会涉及到多个设计部门，同样的多个需求可能会对同一个设计部门的一个指标有影响。
比如，结构设计部门发现如果要载重1吨的货物，必须要有一定的强度支撑，这会增加车身重量。
但是，增加的车身重量就会影响到车速。
纷繁复杂，理不清。
曾几何时，各个设计部门也是各自为政，只关心自己的指标，不考虑对其他设计的影响。
最终在物理机外场联试联调的时候就会出现各种各样的问题，造成非常大的损失。
嗯，你可以想象一下，一架飞机在进入风洞实验的时候，才发现问题。。。。
这个损失后面大概有几个零？
我是数不清楚的……
这都是因为“只见树木，不见森林”导致的。
而随着技术的发展和观念的更新，在工程设计过程中，会采取总体牵头先进行需求的分析和设计，再由各个设计部门去进行设计。
并且因为计算机技术的发展，越来越多的测试和调试不是实物的，不是物理机的调试了，而是采用大量的仿真、模拟手段进行测试。
保证在早期将大量的问题消除，避免不可挽回的数不清的零的损失。
《需求设计》提出的我们的软件设计可以借鉴工程设计的部分。
作者提出了六框设计模型。
而与我们今天想要解决问题关系比较密切的是第一层，情境设计。
回忆一下前文，汽车的需求时怎么提出的呢？
用户提需求的时候大部分是情境化的。
在这种情况下，我们是怎么处理的。
在那种情况下，我们有怎样的流程。
对了，我们还有一些特殊的情况。
对于如此多的纷繁复杂的信息，在进行需求的分析的时候难免会迷失方向。
我们需要避免几个常见的问题，需求的遗失以及需求的冲突。
需求的遗失
需求的遗失，往往因为我们在进行需求收集的时候，自我假设了一番：
- 用户一定会将所有的需求非常明确的告诉我。
- 用户说的东西是一致的不存在矛盾的。
- 我能够联系到所有的干系人，并且获得信息。
- 最终我设计的方案会由客户方进行评审，并且对于其中的问题，他们都能明确的指出。
呵呵哒……
我相信做过年把的BA不会如此单纯了，因为这些假设而产生的坑和锅多的数都数不清了。
曾经在UAT的时候，用户说，不对啊，我们还有这样的场景……你们这样交付，我们没办法签字的。
你会很委屈，因为你觉得客户之前调研的时候根本没有提过这样的需求。
而整个团队可能都会责怪你，责怪你没有“认真”的收集并和客户做确认。
这是收集和确认的问题吗？
很多情况下，并不是。
需求的遗漏，有可能是你没有做需求验证导致的。
前两天我在BABOK中分享了关于Requirement Validation的相关内容。
其实需求验证也是提前对需求进行测试的工作，保证需求的完整性。
那具体怎么进行需求验证呢？
《需求设计》的作者提出了一个方法，就是情境设计。
通过对任务、用户组、数据表以及任务间消息的设计，来减少需求验证。
任务
首先，可以通过情境分析出涉及到的任务，最好是能拆分到原子任务。
对于BA来说，你可以将任务理解为活动。
但是对于SA来说，任务可能或者说，应该是比活动更细的元素。
比如，在地上挖洞，这是BA眼中的任务。
而SA会将其拆分成领队者命令团队开始挖洞，以及挖洞结束两个任务。
请BA细细品味一下这两者的不同。
这也是BA和SA在思维上不同的地方。
用户组
对于用户组，我们需要进行界定。
这个比较简单，我们在绘制泳道图或者用例图的时候，本就会涉及到用户组的识别。
而其实我们之前在识别任务的时候就可以识别出相关的用户组了。
并且将哪些用户归在一组，很大程度上与任务相关。
一般情况下，我们会把执行同类型的任务，甚至是相同任务的用户归在一个用户组里面。
数据表
我不知道有多少BA在设计的过程中会考虑数据表的问题。
但是SA或者DBA肯定会考虑这个问题。
作为BA需要清楚的是，你这个任务中使用到的对象属性，可能会在其他什么任务中使用到。
是否有数据之间的传递等等。
业务设计数据库不是你的职责，但是你有责任清晰的表明数据的关系。
任务之间的消息
在BA理解，任务之间的关系无非是一个用户在执行一个触发了什么机关，导致了另外的一个任务的变化。
而对于SA来说，范围要广的多。
在我粗略的阅读了Activitii的相关书籍后，发现单就工作流来说，消息是无处不在的。
但是无一例外，消息的产生都是基于情境的。
即在一种什么样的情况下会由谁发消息给谁，产生什么结果。
说到这里，我们可以知道，基于情境进行需求设计，主要是将任务、用户组、数据表、任务之间的消息这4个元素进行相互验证，以保证需求的完整性，减少遗漏。
如果我们在需求分析和设计的初期就这么去做，能够识别出相当多之前遗漏的部分。
如果有机会大家可以尝试一下。
矛盾的需求
有两种情况可能会有需求矛盾的状况。
同一个用户，他在描述一个流程的时候，使用规则A，比如快递敲门的时候，要在关闭水龙头之后，才能去开门。
而当他在描述另外一个流程的时候，可能时隔数月，使用规则B，比如女朋友敲门的时候，要先去开门，再去关闭水龙头。
如果你简单的设计为先关水龙头再开门，或者先开门再关水龙头，都不妥当。
此时你需要做的应该是分析这两种情境，找出矛盾点和解决方案选项。
不同的用户，他们在描述同一个流程的时候，有矛盾。
这个可以理解，因为每个人的角色不同，看待一件事情的角度也就不一样，很可能会有矛盾的规则出现。
此时，你必然需要找出产生这样问题的原因，并且根据项目或者产品的目标进行引导，以达成一致。
OK，问题来了。
我们怎么发现需求是矛盾呢？
如果需求是一份清单，或者是一个长长的Backlog，必然很难发现。
而如果使用情境设计中的四个元素是很容易分析出来的。
我们在识别出任务后，对用户组以及任务间的消息分析可以很快得出，因为参与的用户组不同，而导致了任务间的消息触发机制不同。
这其实也相应的可以识别出备选的解决方案。
全局性
而我们在提到“只见树木，不见森林”的时候，不得不提到需求的全局性的问题。
在工程设计中，有个部门叫做“总体部”，主要职责是统筹各个专业设计部门对于需求的分析、设计和实现、测试。
他们会接收到来自于客户的情景化的需求，进行分析和总体设计后，将需求拆分成为各个设计指标，下发给各个专业设计部门。
比如，结构设计部门，你这边强度要求是多少多少。
动力设计部门，你这边要求要支持多少多少。
很显然，总体在分析这些需求的时候，会从全局上看，因为有些指标是相互牵制的。比如，你强度要是很大，那么可能自重会很重，对动力的要求也会高。
借鉴这样的想法，在使用情境设计的时候，也需要考虑这样的全局性。
在进行需求分析及设计的时候，一定要时不时的退后一步，看一下四层的关系，全局的目标。以保证不会偏离航线。
《需求设计》这本书，我会推荐给偏向后台设计的BA阅读。
特别是抱怨和程序猿沟通不能的BA进行阅读。
我也不止一次的被程序猿提醒：“你这样的方案和客户对接，当然没问题。但是我们在设计的过程中需要考虑更多的细节。”
我们如果可以在需求分析和设计的前期，通过情境设计的方式，对需求进行验证，进而保证解决方案的整体效果，是解决“只见树木，不见森林”的方法之一。
小婧是一名行走在实践路上的资深业务分析师（BA），如果想与我同行，就请关注我呗！
