做需求分析的工作将近一年了，第一次看到“正确的需求”这样的词语时会有点困惑，需求本不是什么标准答案，难道还有正确和错误之分？
《掌握需求过程》说需求就是产品支持其拥有着的业务所必须完成的事，或让拥有者接受并感兴趣所必须具备的品质。软件是一种解决方案，要提供有价值的解决方案首先要理解要解决的问题，也就是真正的问题。我想，正确的需求可以理解为为了解决真正的问题业务所必须完成的事。
而为了发现正确、完整的需求，需要某种有序的过程，《掌握需求过程》就描述了这样一个过程，也就是如何得到正确的需求。大概过程如下：
项目启动 项目的启动会通常会先确定业务问题的范围，同时确定的还有利益相关者。
网罗需求 启动结束后，业务分析师开始学习“这部分业务是做什么的”，也就是了解真正的问题，获取真正的需求。
业务建模 了解了业务，分析师可以有效利用快速的草图，对调研的工作进行建模。
场景讨论 用场景描述业务过程，达成一致意见。场景是需求的基础。
编写需求 为了避免需求被系统开发误解，分析师必须以一种无二义的、可测试的方式写下需求，同时确保提出需求的利益相关者理解并同意写下的需求，然后再传递给开发者。
这个过程当中我认为难度最大的就是网罗需求了，因为需要在这个阶段发现真正的问题。
书中介绍了许多网罗需求的技巧，最常用的应该还是业务用例研讨会和访谈。研讨会通常讨论的对象就是场景，也就是通过结构化的方式叙述业务用例的故事。使用场景，以一系列的步骤，描述业务用例完成的工作，对于利益相关者而言会非常易于理解。而访谈最难的便是如何提问。书中介绍了一种非常有效的方式，或者说是视角——Brown Cow模型。
作者通过这张图告诉我们如何发现真正的需求：我们通常会从左下象限开始，了解目前的业务是怎么运作的；去除当前情况中一些技术化石和过时的组织机构流程，我们也就可以看到纯粹的、没有杂质的业务问题了，也就是左上象限；继而转向右上角，这个象限的价值是准确展示了拥有者想要做什么，这里我们可以跟利益相关者讨论然后达成共识。加上实现的手段、技术，使得他们的想法能够实现，也就是最右下象限了。
这样一个过程中，看上去按部就班执行就可以了，但要注意的是，横线之上才是业务的真正本质，而我们通常很难发现，而且在跟利益相关者探讨的过程当中，很容易就“跑偏”了。
第一个“障眼”的是Future-How。比如我们在访谈时，客户说，“我想要一个报表来显示我每年都在哪些项目上做了哪些任务”，这个时候客户已经在描述他期望的未来是什么样的工作模式。但这并不是真正的问题。
怎样才能识别对方说的到底是不是业务问题，书中给出了一种方法，看这样的“需求”当中有没有包含技术。比如“报表”，其实就是一种技术，所以客户已经在描述一种解决方案了，但我们只有了解和理解了真正的业务问题，才能定义针对性的解决方案，到时候报表也许还可以是一种解决方案，但不一定是最好的。
如何才能发现真正的业务问题呢，这个时候不妨多问一句，“请问您需要了解每年在多少项目上做了多少任务是什么目的呢，这对您有什么帮助吗”。客户想要这样一个统计结果，也许是方便自我总结经验教训，为第二年做准备；也许是总觉得工作安排不过来，不知道时间去哪儿了；这个时候我们的解决方案也许就不是报表那么简单了。
简单来说，需求不应预先确定实现方式，不论某种技术是多么具有吸引力。如果我们在一开始就认为客户表达的正是他的需求，最后的结局很可能就是“我知道这是我提出的，但这不是我想要的”。也就是说你并没有解决客户真正的业务问题，因为真正的问题从未阐明，所以从没有正确的理解。
第二个“障眼”的是Now-How。泳道图是我们常用的业务建模的工具，来对当前的业务开展模式进行描述。但泳道图其实很容易误导读者，让他们认为泳道代表的处理节点边界应该在将来的实现中保留。而寻找业务本质的重要一步，就是查看端到端的过程，忽略当前工作在部门间的划分，这些划分的方式其实是基于当时的技术或者业务结构的，所以当前的实现通常掩盖了真正的业务本质。所以，不妨试试把泳道从模型中去除，业务分析师和利益相关者就更容易看到一些活动，这些活动也不需要和以前执行的位置或顺序相同，而是一种纯粹的端到端的业务。简单来说，放眼整个泳池，我们才能更容易发现业务的本质。
这本书其实是有很多干货的，一步接一步、一个模板接一个模板、一个例子接一个例子地展示了Volere方法，这是业务分析的前辈们在多年帮助客户改进需求的过程中积累而得的产物，对于业务分析师们非常受用。Get了这些方法和技能，相信我们离正确的需求就不远了。
