刚在某客户做了3个月的需求调研，亲自体验了需求调研的过程，有一些感想，总结下来。
客户方配备了BA和SA，BA是业务专家，SA是技术专家，负责输出一个描述业务需求文档XXXS，将流程和需求都记述在该文档中，和大多数客户一样，客户的优势在于对他们的业务比较了解，但是对于如何去抽象业务，比较系统的把他们的业务需求归纳并描述下来，并不擅长，至少很多人不擅长，这就导致客户方的XXXS文档中通常是一些需求片段和样例。
我方对一个topic，分配了SA和BA，其中SA负责技术方案，而BA负责理解业务并澄清业务，topic的输出件有XXD和XXS，XXD主要记述业务流程和topic级的solution，XXS主要记述系统的功能。
XXD中的业务流程，准确的来讲，应该改名叫系统流程，是讲述业务功能操作是如果由解决方案各个内部子系统及外部系统协同完成的。这其中的actor是系统，因此，是从系统的角度来描述的。
XXXS中，模板像系统用例文档，但是里面的一个个单元是叫功能，功能与用例的差别就是，一个是从系统的角度出发，一个是从Actor（即用户）的角度出发，对每个功能，有功能描述，功能的前置条件、后置条件、功能的用户角色、业务规则，输入规格，输出规格，如果涉及到界面，就有界面原型。具体的内容，通常pre-condition是千篇一律的，如用户必须已登录什么的，后置条件通常是结果，而角色通常是一个很泛的一个总称（比如在厨房干活的分切菜的，炒菜的，统称厨子）。
对于客户方描述的不清楚或者只描述了几个片段或例子的需求，我们采用prototype的方式，先按照自己的理解做prototype，然后给客户去演示，由客户来决定是否符合他们要求。
是不是看上去很完美？
再看看几个问题：
问题一：对客户方的某个需求，我方一直不理解客户方为什么会提这么怪异的需求，觉得不可思议，而客户方一直坚持要这个功能！
问题二：客户方并不具备多么深厚的业务抽象功力，我们自己通过蒙着眼睛摸象的方式作出原型给客户方评审，客户方say ok就ok，不ok就不ok，客户方不会犯错误吗？客户方会照顾你其它客户的需求吗？我们拒绝客户方的理由通常是实现不了，或者工作量太大。我们绝大多数人没法使用客户的业务语言告诉客户，你的目的是什么，你要求怎么来做，这样做有什么样的坏处，我建议这么做，这么做能获得什么样的好处。
问题三：我们把一些业务角色使用的功能和运维人员使用的功能放置于一个界面中，从功能上来讲，我们可以自豪的告诉客户，我们实现了你要的功能。
。。。
我相信我了解到的问题绝不是全部，还有很多我不知道的问题。
对这种状况，我逐一分析了一下原因：
问题一：因为我们理解的业务概念跟客户理解的客户概念不一样，虽然我们叫的是同一个名词，但实际上并不是同一个东西，从而导致我们觉得客户提的要求匪夷所思；
问题二：我可以说，其实我们的做法是去摸清楚客户要什么，但没有去理解他为什么要；
问题三：很明显，我们实现了功能，但忽略了功能的使用者是谁；
这一切的根源是什么？我认为，这根源是我们一直从系统的角度去思考问题，思考我们的系统功能，思考我们的系统流程，对一个经验丰富的专家来讲，也许会考虑的比较全面，但绝大多数人往往是重视了功能的描述，而且描述是基于我方的语言，忽略了功能的用户，而我们没有一个万能的客户和万能的专家帮我们指出交付件的所有的问题。
即便是我们成功交付了一个系统，我们还是没有消化客户为什么要这么做的原因，对业务系统来讲，这是最核心的价值之一。
我们要怎么改？我的建议是：
1、加入对“用户需求背景”的调研，即真正的“业务调研”，在这个阶段的主角是BA，BA是业务专家，对IT技术不熟，这是他的优势，这个阶段的输出件要包括客户的业务架构，包括组织结构，人员角色，业务流程（是各业务人员如何协同来完成工作，跟系统流程有本质区别），业务模型（用户做的事情中涉及到的一些概念，这里指纯业务概念，客户能感知的，非系统概念）。经过这个阶段，我们应该能明白客户为什么会提这个那个需求，能够有效避免因为客户的片面和狭隘导致我们跟着片面和狭隘，并且我们知道了客户说的概念A是指什么，概念B是指什么，跟我们平常所说的有什么不同。
2、扭转“功能分析”的角度，由从系统的角度分析转变成由用户的角度分析。把功能变成用户基于系统所做的操作分析（系统用例），首先搞清楚是谁，然后是要基于系统做什么事情，有什么业务规则，前置条件和后置条件是什么，再次是系统通过什么样的界面或接口来支持。输出的内容看似都差不多，但因为是从用户的角度出发分析的，提供的功能自然会更贴用户的心。
3、我们要明白一个基本原则，业务架构是不依赖于IT系统存在的，IT系统是规范业务运作和提升业务效率的工具，IT系统中的软件概念是业务概念在软件系统中的投影，千万不能从技术的角度出发，视图去重定义业务概念。