软件需求的方法论（2）

降低需求分析的复杂度。

为了解决项目进展缓慢的问题，尽早进入项目开发的实质阶段，在需求分析的时候，降低需求分析的复杂

度成为了关键。

如何降低需求分析的复杂度：

1，提高抽象层次

在软件开发中我们面对的一个主要问题是复杂度，降低复杂度对生产力有很大影响。在更高的抽象层次工

作降低了复杂度并使交流变得容易。

2，隔离功能实现

把业务建模和功能实现分开来。在起初阶段，只考虑业务领域实体的关系，以快速寻找系统中个实体的本

质关系。

3，运用统一建模语言（UML）

利用高级工具，方便了解其周围的高级构件的合作而同时隐藏了不必要的细节。

4，运用统一开发过程（RUP）

不要一步到位，要形成迭代开发过程。

5，业务建模

业务建模是在需求之前的。

把一个项目分成10个核心工作流程（Core Workflows）和4个阶段（Phases），并以核心工作流程为Y轴，阶段为X轴建立起一个项目视图（图一）。

调查主要业务逻辑：什么叫主要业务逻辑？包括了企业的主要业务流程、主要的业务规则、重大的算法。这些都是需要在一开始就十分明确的资料，需要在建模会议上了解清楚。当然，你不能对你的项目涉众说，"这个，接下来，大家谈一谈主要的业务逻辑吧。"下面的涉众一定摸不着头脑。你还是应该引导涉众，从涉众的话语中捕捉你需要的信息。

避免细节：建模会议主要的目标是建立高阶需求。如果把过多的时间花在讨论鸡毛蒜皮的小事，那就会浪费大家的时间。而在此时调查需求细节是没有很大的意义的。因为你对很多的事情都还不了解，需要进一步的深入。这时候的细节对你并没有太多的帮助。

需求分析： 叫不懂又不愿意学OO，RUP，business entity和UML的人搞需求是危险的。