前几天一兄弟接到一个IT运营的系统的活，说需求分析时出了问题，越分析越乱，我问他，是需求没讲清，还是说看不明白？他说，需求虽然不是特别清晰，不过基本业务还是有的，只是在建模时，对像的关系，越分析越乱，好像变成一张没有边际的网。
然后他开始和我讲业务（具体的审批流程，入库，报修等），我听了一会就打住了他，我说你别和我讲细节，讲我也记不住，你先告诉我整体的业务流程，然后他说大概就是，设备管理---à设备申请（设备领用，设备报修，设备采购等），还有一些办公资源的管理，审批流程的定制等。
接下来，我告诉他：“他的问题的根源是为因一下子钻进业务细节去了“，有点”不识庐山真面目，只缘身在此山中“
接下来，我和他从整体的业务流程开始，先理清设备管理的业务，同时也建立了设备管理中的概念模型，然后接下来再分析设备相关的申请并建立其概念模型，在分析的同时，并着重理清了，设备申请的相关业务和设备管理中设备的业务关系，这时关系模型就慢慢的丰富起来。同样的方法，我们顺着整体业务流程下来，整个系统的对像关系模型就建好了，解决了，他原来分析时，越分析越乱，好像变成一张没有边际的网的问题。
对于需求分析，一定要在整体视图（比如：整体的业务流）下，采取先全局，后局部，各个局步再串联（串联本质就是业务关联）的方式来分析。
对于软件测试来说，测试人员要了解业务，这是必然要求，那如何了系统中的业务呢？对于需求分析中的上述方法，同样可用于测试人员做业务析。为什么这样说呢，虽然两者的输出物不一样，但他们的前提是一样的。
