2.2 系统需求分析

按照我国财政和教育部门的有关规定，教育经费支出按用途主要划分为事业性经费支出和基建支出。事业性经费支出主要包括人员工资、职工福利费、奖贷助学金、公务费、业务费、设备购置费，等等。由于事业性经费支出可变因素较多、各种开支之间的比例关系难以确定，因而是经费测算的重点所在。

实际测算时，学校先拟定一个总的预算支出，将总预算支出按照一定比例分割，确定测算模型，制定测算的各相关系数，进行模拟测算。一旦测算结果有较大偏差，调整系数重新测算，直到寻找到较为合理的经费支出结构。

那么如何描述系统需求呢？传统的需求表述方式采用“软件需求规约（Software Requirement Specification）”表述方式，也就是大家熟悉的功能分解方式。在这种表述方式中，通过功能模块的分解达到描述整个系统功能的目的。这种方式实际上已经包含了开发人员的部分设计，对于开发人员还是有实用价值的。但是这种方式存在两个问题：功能模块的细化程度难以把握。对于用户来说，这种表述方式不够直观，难以准确表述用户的原始需求。因此，在UML规范中提出了一种标准化的需求表述方法——用例（Use Case），可以较好地解决传统需求表述方式中存在的重要缺陷：无法表现功能模块之间的关联关系，也难以清晰地说明功能模块是如何通过相互关联以完成整个软件系统的目标的。

用例方法的核心思想是站在用户的角度看问题。对于软件系统的最终用户来说，他们更关心系统能够提供哪些服务？他们又将如何使用系统？系统是如何设计的？内部结构又怎样？等等，往往并不是很关心。用例方法主要由参与者（Actor）、用例（Use Case）、通信（Communication）三大元素组成。参与者指存在于系统外部并与该系统发生交互的人或其他系统，主要包括使用者和使用环境。用例表示系统所能提供的服务内容，也就是系统是如何被参与者使用。通信表示参与者和用例之间的对应关系，即参与者使用了系统中的哪些用例，或者说系统所提供的用例被哪些参与者使用。关于这方面的相关知识，请读者参阅UML方面的书籍。

根据调查分析情况，系统用例图如图2-1所示。

图2-1 系统用例图

从用例图可以看到，用户的原始需求主要是调整模型参数、确定分配基数，测算经费并以Excel报表方式查看测算结果。在调整模型参数时，需要从教学数据库服务器获得基础数据。教务处、财务处、学校领导、教学单位具有不同的处理权限。这里需要说明的是，调整模型参数只能在本地数据库进行。另外，测算经费是整个系统的核心功能。