需求、分析和需求-分析

需求分析，说到软件工程则不得不谈这个阶段，任何项目的开始除去立项的可行性分析、技术论证外，需求分析就算是第一步了。那么怎样才算是需求分析呢？

从词语的本意来看，需求和分析是两个词语分别表达了两个意思。但是将两个词语合起来却又表达了另一个意思。这里就产生了歧义，是先做需求再做分析呢？还是需求的过程中进行分析呢？此外又有个问题，需求是做些什么呢？分析又是做些什么呢？

不妨，我们把先做需求后做分析产生一个新词组：需求、分析；我们把需求的过程中进行分析也产生一个新词组：需求-分析

看起来两个词语仅仅是一个符号的差别，但是呢，这却表明了两种做需求分析的方式。

需求、分析

很显然把需求分析分为了两个阶段，即是先做需求，后做分析。先做需求应该做些什么？关注点在于需求调研上，Step-1要做的是：

1.和客户谈需求

2.谈业务流程

3.谈表单

4.谈操作方式

5.谈客户的习惯

结果Step-2将得到

1.流程图（通常，这时候的流程图可以使用Viso中的职能图来描绘）

2.对流程图的描述

3.将客户的表单和调研的结果产生所谓的业务对象（请注意，这时候的业务对象并没有Table的概念，也没有抽象的概念，而仅仅是客户想要在某些时候得到的业务相关信息的对象）

4.对业务对象进行描述

这两个步骤做完后，就算是需求结束了，此时就可以进行分析的入手了。分析的时候可以做这样的事情：

1.用例图

2.用例说明

3.用户接口（用户输入哪些具体对象，得到哪些具体对象）

4.界面原形（简单的界面显示样例）

其中最主要的是用例图和用例说明，因为这将是设计阶段的基础。而界面原形则可以不做，但一旦做了将是很容易和用户进行交流的一个好手段。

这个做法的好处是业务流程谈完后得到的结果，将可以通过用例来检查其正确性，流程和用例分开将能从两个不同的关注点来关注整体。缺点是当项目很大时将导致重复劳动力的产生，因为用例和流程随便怎么说都不是互相独立的，用例中本身就有基本流和可选流的概念。

需求-分析

这个做法是需求谈完后直接进行分析，因此它只有一个阶段，就是需求-分析阶段，做的事情是这样的。

Step1：

1.和客户谈需求

2.谈业务流程

3.谈表单

4.谈操作方式

5.谈客户的习惯

Step2：

1.用例图

2.用例说明

3.用户接口（用户输入哪些具体对象，得到哪些具体对象）

4.界面原形（简单的界面显示样例）

5.业务对象

这样的做法省略了流程图，把业务对象也拉到了分析的时候。并且将业务流程完全使用用例来表现。这个做法要注意的是用例分析的完整性，也即将用例的 包，用例从大到小一一说明，而且各个用例之间的关系extend、include等等都要描述清晰，可以让有经验的设计者一眼就看出分析者的思想。再有就 是用例的基本流和可选流都要清晰无二。

这个做法的好处是避免了重复劳动，缺点是没有整体业务的描述和对客户的要求将比较高，因为需要客户也最好能看得懂用例。

 

需求、分析和需求-分析前者可以认为是一个瀑布模型的实现，后者则可以认为是一个小迭代的实现，二者都可以被选择使用，当然各有优劣，我将会在今后的文章中给出更多说明，本篇就到此为止吧。