如果说《用户故事地图》可以解决大部分PO以及BA在需求分析时可以“又见树木，又见森林”的话，《需求设计》其实主要是写给BA和SA的。

　　之前说到最近在看几本书，基本上都是用来解决“只见树木，不见森林”的问题的。

　　今天和大家分享第二本《需求设计》。

　　如果说《用户故事地图》可以解决大部分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的相关书籍后，发现单就工作流来说，消息是无处不在的。

　　但是无一例外，消息的产生都是基于情境的。

　　即在一种什么样的情况下会由谁发消息给谁，产生什么结果。