业务部门所需要的数据看作一个实体，部门间的数据关系就是实体之间的关系。比如：经营
部门所需要的用户资料、用户话费，实际上就是用户这一实体与账单这一实体间的关系 。
Play CASE 提供了构件（不过我觉得是部件更为合适一些），来表示对应的数据，并提供
了三种构件的表示关系即组装关系、分类关系与相连关系。这三类关系基本上反映出了现实
世界中的业务数据之间的关系。例如现实世界中的用户资料与用户话费，在

Play CASE 中，

可将用户构件与账单构件用相连关系表示。这种方法，实际上是借鉴了

OOA 面向对象的分

析方法中的类、聚集、继承、封装等概念，能较好地反映出现实中的业务；同时，这一步的工
作也为总体设计中数据库的概念模式设计奠定了很好的基础。
    经历了上述四个步骤以后，利用 Play CASE 工具自动生成了软件需求规格说明书、初步的
DFD 图和业务流程图，为下一步的总体设计打好了基础。
    使用 Play CASE 工具，使需求分析既能继承传统的结构化分析方法，又能吸收面向对象
设计方法的优点。比如能把业务流程转变成为运行过程，业务组织转变成了软件的结构等都
体现了这一点。而在运行过程中，对复杂过程的细分以及追踪则反映了传统方法中的自上到
下分解的分析思想，这对于解决复杂系统的分析是很有帮助的。
    通过使用，我觉得这个工具还是很不错的。因为它实际将以下四个方面的问题结合起来了：
软件、业务、开发人员和用户。对于用户而言，

Play CASE 用图形化的方式显示出业务流程，

使用户了解业务在软件中的运行过程，提供了将来验收软件时的依据。对于开发人员来说，
使开发人员能更清楚地了解业务流程，不会再发生

“因为不理解用户的需求而出现的闭门造

车情况，从而导致开发出来的产品不符合用户需要

”的现象。因此，Play CASE 所自动提供

的需求说明书能够很好地沟通用户与开发人员之间的理解，使他们都能对需求有共同的理
解。
    使用 Play CASE 工具后，使我们的需求分析取得了很好的效果，不但能自动地提供许多
结果，如需求说明书等；还使需求的质量有了很大的提高，受到领导的赞扬（领导不是学
计算机的，但对公司的业务十分熟悉）；在后继的设计与维护工作中，我们感到工作似乎
轻松了很多。
    当然，该软件工具也有不足之处，一个突出问题是灵活性不够，一县公司的部门或者组
织机构发生变化时，整个设计都要重新来过。因此，在改进的过程中，我们在第一步过程预
留了好多个虚拟的部门，以备将来进一步的扩充或者变动。