Martin Fowler给了一篇很好的文章http://martinfowler.com/bliki/RollerSkateImplementation.html从中能学到很多东西。
以往的系统建设仅仅是获取用户的需求，并将需求实现成系统，这一点有错么？表面看起来没错！从传统意义上讲也没错！但是请看下面一段小故事：
某天，外面下着大雨，你坐在办公室里，突然你的同事焦急的过来说“有伞么？借我用用！”，你会说“我没带伞”然后继续做自己的事情。第二天你得知你的同事因为没有伞而错过了一个很重要的聚会，而当同事得知你昨天开车来，并且车就在楼下的时候，他非常懊恼的说“早知道叫你开车送我去好了”。
类似这样的小事件在日常生活里层出不穷，看起来没什么不妥，但是在需求者的或者BA的眼里，有着很重大的问题——这里的“你”，就是一个接受需求的人，当你在得知需求是“有伞么”的时候如果认为需求真的就是一把伞那你就错了，因为几乎百分之百可能性你的客户（这里的“同事”）不知道如何准确全面地阐述需求，而把一个全面的需求以一种最极端迫切得到的形式表达出来，以至于让需求人员把这种极端迫切的形式误以为是需求的全部。
其实从上面的例子看出，表面需求为：伞，而潜在的核心意图为：我要到聚会现象去。这时候如过你提供一个雨衣或者开车送他去，虽然没有满足其需求，但是他都会欣然接受，因为核心意图得到满足了。当然日常生活中，没有送他去没什么大不了，我们不需要想这么多，但是系统建设中有可能就是一个影响全局的大事件。
区分好的BA还是普通的需求人员的标准之一，就是看他们是仅仅实现一个表面意图，还是从表面意图看到软件的核心价值。
更有时候，你发现客户提出一个很难实现的东西，你试图去寻找缘由，最终发现“原来他就是这个目的。。”，最反向终转换一种更容易实现的形式来实现其意图，节省时间节省成本。
在现代软件开发过程中，经常会出现两种非常有意思的现象:
一、你实现了全部用户想要的功能，但是用户非常不满意。原因就在于你只顾着实现功能本身而忘记了功能为客户所带来的潜在价值，导致功能在不断实现过程中发生了商业价值的偏差。
二、你没实现用户想要的功能，但是用户非常满意。原因就不用多说了。
从MartinFowler的文章可以看到，尽可能快得交付给客户一部分核心价值对于客户来说是很大的福音，敏捷项目一个主旨就是把风险分摊到每次迭代里，当然，用户期望也可以分摊，你最终请他吃一顿大餐或许远远不如每天让他尝点甜头。
