那个美妙的咔哒声：需求文档的概念的分析过程

作为开发者，拿到一个需求文档，怎么看？

一个字一个字的看：）

其实开发者都是看了差不多，就开始写代码的。写不下去的，回头看文档，再来找问题，提需求的bug。当然这样反馈周期其实就是太长了。

我这里有一个案例，就是之前两个人对一段代码疑问，一个人说和这个10行就可以搞定，不需要那么多，现在60行，一个反对，说我这个60行是因为和需求直接对应的，这样需求改了，我就直接对应的跟着改就好。我觉得两个人都有道理，但是依然觉得代码逻辑复杂，于是我看了需求，发现需求是错的，仅仅是逻辑自洽的角度判定就是错的。把需求从新整理完，再来看，代码10行确实够了。

这就说明，开发者看了需求，不等于真正理解了，如何算是理解?

我认为理解的过程就是分析的过程，分析的过程就是拆解重组的过程。意思就是说，需求哪一个文档过来表面是文档，后面是需求的思维模型，只要需求有一定的规模和复杂度，你要弄明白，怎么办，就是分治。就得把它的一个个拆解，变成零件，需要用自己的模型把它重新组装。

组装的过程就是分析的过程，这个过程，你可能发现两个零件重装时发出了咔哒的声音，这是对你的奖励，好像告诉你，是的，你理解对了，也可能怎么也契合不了，然后，你会发出一个疑问，需求应对你的疑问，可能是我的本意是你得换个方向，或者其实你误会了，它两个不是要转配一起的。当然也有可能需求说，我这个得放考虑的不对，是一个bug，我重新弄。当几次反馈下来后，你每一个零件都可以发出咔哒声，那么你就知道，我理解透彻了。否则，就不太明白，就还得反复。这时候，你怎么重装呢，总不至于自己把需求从新抄一遍？我的做法就是换模型，一个需求都是图表文字，我就是用类模型。其实类模型有些专业，可以叫做概念模型，每一个概念都是一个零件，装配时就是两个概念的关系，关系包括使用，泛化，组合等，还有映射关系，就是几对几的关系。我看完文档，我会开始绘制概念图，我把文字才分为概念，在用关系把它重组。这个过程就是一个发现和建立的过程。引入术语，概念图就是UML类图，关系就是use ,inherited 等，映射技术1：N，1：1，N：1，N:N。这个分析过程，就是OOA（面向对象分析）

当我和同事讨论此问题，说到此处是，我突然发现原来OOA在这里啊。我之前一直都是OOD，OOA是我一直用，却没有想到自己在用的。或者说，我知道在分析，却不知道它这么有用。

还有一个案例。是一个销售系统，需求人员做了一个UI图，就是我们常常看到的这些图。我觉得用户看到的，基本都有了，是一个合适的需求文档。但是我总觉得其中出现的一些概念，叫做跟单、跟进、动态，，可能是一回事，我就把它的概念图画出来，然后反复比对这些概念的场景。每一个出现的概念，都可能对弈一个类，所以不能不认真考察，反复确认这些概念出现的场景后，我们最后确认，它们是一个东西。分析完后，他认为确实概念图拿来做分析是有用的。

当然还有一个问题，就是拿着这个图，和有开发背景的人谈当然没有问题，但是和没有开发背景的需求谈，怕就难了。这里就有一个根本问题，是为了自己弄懂，还是为了别人弄懂，如果是为了自己弄懂，那么uml是自己的分析工具，而和需求沟通只是辅助，并且也不会涉及太细节的代码层面的东西，甚至是方法和属性的概念，而就是概念，概念关系，概念构成，那么uml类图立刻就换身为概念图，这个并不需要什么开发背景。

理解和分享这样的抽象的思维过程，请有趣的。