工资支付系统需求分析.doc

工资支付系统需求分析.doc

《工资支付系统需求分析.doc》由会员分享，可在线阅读，更多相关《工资支付系统需求分析.doc（6页珍藏版）》请在冰点文库上搜索。

需求分析

需求分析的目的是确切地回答下述问题：

“系统必须做什么？

”

需求分析在可行性研究的基础上进行，前一阶段产生的文档，特别是数据流图（见图2.13），是需求分析的出发点。

在需求分析过程中分析员将设计出更精确的数据流图，并将写出数据字典及一系列简明的算法描述，它们都是软件需求规格说明书的重要组成部分。

需求分析的主要任务是更详尽地定义系统应该完成的每一个逻辑功能。

怎样完成这个任务呢？

任何数据处理系统的基本功能，都是把输人数据转变成需要的输出信息。

数据决定了处理和算法，看来数据应该是分析工作的出发点。

必须经过计算才能得到的数据元素引出了必要的算法，算法反过来又引出了更多的数据元素。

对数据的描述记录在数据字典中，对算法的描述记录在一组初步的IPO表中（目前描述的是说明数据处理功能的原理性算法）。

对系统有了更深人的认识之后，可以进一步细化数据流图。

在细化数据流图的过程中，又会进一步加深对系统的认识。

这样一步一步地分析，将更详尽更准确地定义出所需要的逻辑系统。

下面叙述工资支付系统的需求分析过程。

①沿数据流图回溯

为了把数据流和数据存储定义到元素级，一般说来，从数据流图的输出端着手分析是有意义的。

这是因为，系统最基本的功能是产生需要的输出数据，在输出端出现的数据元素决定了系统的基本构成。

从图2.13的数据终点“教师”和“职工”开始分析，流入他们的数据流是“工资明细表”。

工资明细表由哪些数据元素组成呢？

从该职业高中目前使用的工资明细表上可以看出它包含许多数据元素，表2.4列出了这些数据元素。

这些数据元素是从什么地方来的呢？

既然它们是工资支付系统的输出，它们或者是从外面输人进系统的，或者是由系统经过计算产生出来的。

沿数据流图从输出端往输人端回溯，分析员应该可以确定每个数据元素的来源。

如果分析员不能确定某个数据元素的来源，那么，工资问题的专家应该知道，因此需要再次调查访问。

这样有条不紊地分析下去，分析员将逐渐定义出系统的详细功能。

表2.4工资明细表上包含的数据元素

教职工编号

教职工姓名

基本工资

职务

职称

生活补贴

书报费

交通费

洗理费

课时费

岗位津贴

工资总额

个人所得税

住房公积金

保险费

实发工资

例如，表2.4中的数据元素“工资总额”是怎样得出来的呢？

从图2.13可以看出，包含数据元素“工资总额”的工资明细表，是从处理4（“分发工资明细表”）输出到数据终点的，但是这个处理的功能是分发已经打印好的工资明细表，并不能生成新的数据元素。

沿着数据流图回溯（即逆着数据流箭头方向前进），接下来遇到数据存储D3（“工资明细表”）。

数据存储只不过是保存数据的介质，它不具有变换数据的功能，因此也不会生成工资总额这项数据元素。

再回溯则来到处理3（“加工事务数据”），显然，工资总额是由这个处理框计算出来的，因此应该确定相应的算法，以便更准确地定义这个处理框的功能。

根据常识，工资总额等于各项收人（基本工资、生活补贴、书报费、交通费、洗理费、课时费或岗位津贴）之和。

虽然不同教职工的基本工资、生活补贴、书报费、交通费和洗理费的数额可能并不相同，但是对同一个人来说，在一段时间内这些数值是稳定不变的，不需要在每次计算工资总额时都从外面输人这些数据。

事实上，在输人的事务数据中并不包含这些数据元素，因此，它们必定保存在某个数据存储中。

目前，还不知道这些数据保存在何处，分析员在笔记本中记下“必须搞清楚基本工资、生活补贴、书报费、交通费和洗理费等数据元素存储在何处。

”此外，为了计算工资总额必须先计算课时费或岗位津贴，因此，分析员在笔记本中记下“必须弄清课时费和岗位津贴的计算方法。

”然后，着手分析另一个重要的数据元素“实发工资”。

显然，从工资总额中扣除个人所得税、住房公积金和保险费之后，余下的就是实发工资。

沿数据流图回溯可知，个人所得税、住房公积金和保险费的数值都由处理3（“加工事务数据”）计算得出。

但是，目前还不知道怎样计算这些数值，分析员在笔记本中记下“必须搞清楚个人所得税、住房公积金和保险费的计算方法。

”

②写出文档初稿

分析员在分析过程中不断加深对目标系统的认识，应该把获得的信息用一种容易修改、容易更新的形式记录下来。

通常，一个系统会涉及许多人，他们彼此理解是至关重要的。

文档是主要的通信工具，因此，文档必须是一致的和容易理解的。

结构化分析方法要求，在需求分析阶段完成的正式文档（软件需求规格说明书）中必须至少包含三个重要成分：

数据流图，数据字典，以及一组黑盒形式的算法描述。

数据字典是描述数据的信息的集合。

在分析阶段数据字典能帮助分析员组织有关数据的信息，并且是和用户交流信息的有力工具，此外，它还能起备忘录的作用。

在设计阶段可以根据它确定记录、文件或数据库的格式。

在实现阶段，程序员可以根据数据字典确定数据描述。

在系统投人运行以后，数据字典可以清楚地告诉维护人员，具体的数据元素在系统中是怎样使用的，当必须修改程序时，这样的信息是极其宝贵的。

在手边没有数据字典软件包可用时，可以用卡片形式人工建立数据字典。

例如，为工资支付系统中几个数据元素填写的数据字典卡片如图2.15所示。

名字：

工资总额

别名：

总工资

描述：

扣除个税、公积金和保险费之前一个教职工的月工资

格式：

数，最大值=9999.99

位置：

工资明细表

名字：

个人所得税

别名：

个税，所得税

描述：

政府本月征收的个人收人所得税

格式：

数，最大值=9999.99

位置：

工资明细表

图2.11工资支付系统的数据字典卡片

分析员还应该以黑盒形式记录算法。

所谓黑盒子就是不考虑一个功能的具体实现方法，只把它看作给予输人之后就能够产生一定输出的黑盒子。

这正是在早期开发阶段分析员对算法应持有的正确观点，目的是用原理性算法准确地定义功能，算法的细节可以等到以后的开发阶段再确定。

通常使用IPO表记录对算法的初步描述。

以后可以进一步精化它，而且在详细设计阶段可以把它作为HIPO图的一部分。

图2.16是描述计算工资总额的初步算法的IPO表。

IPO表

系统：

工资支付作者：

王晓明

模块：

工资总额算法日期：

2003.2.28

编号：

注释：

教师岗位津贴为零；

职工课时费为零

被调用：

调用：

输入：

基本工资、课时费、岗位津贴、生活补贴、书报费、交通费、洗理费

输出：

工资总额

处理：

工资总额=基本工资+课时费+岗位津贴+生活补贴+书报费+交通费+洗理费

局部元素：

图2.16描述工资总额初步算法的IPO表。

目前写出的文档还仅仅是初稿，写出文档初稿的目的，一方面是记录已经知道的信息，另一方面是供用户审查。

随着需求分析工作的深人，这些文档还将进一步修改完善。

③定义逻辑系统

通过前一步的工作，已经划分出许多必须在工资支付系统中流动的数据元素，并且把它们记录在初步的数据字典中，此外，还把某些算法以黑盒形式记录在IPO表中。

上述这些工作成果正确吗？

某些数据元素（例如，基本工资、生活补贴、书报费、交通费、洗理费）是从哪里来的呢？

分析员必须设法得到这些问题的答案。

关于工资支付系统的详细信息只能来源于直接工作在这个系统上的人。

因此，再次访问财务科长和具体处理工资事务的两位会计。

数据流图（见图2.13）是使讨论时焦点集中的极好工具，从数据流图的数据源点开始，沿着数据流循序讨论。

事务数据从教职工流进收集数据这个处理中，以前已经在数据字典中描述了组成事务数据的元素（图2.16中未列出这张卡片），这个描述正确吗？

有没有遗漏？

“收集数据”的功能是什么？

审核数据的算法是什么？

……对于分析员来说，数据流图、数据字典和算法描述可以作为校核时的清单或备忘录。

必须审核已经知道的信息，还必须补充目前尚不知道的信息，填补文档中的空白。

例如，考虑工资总额的算法。

假设分析员和会计正在讨论数据流图中“加工事务数据”这个处理。

在前一步骤中已经用IPO表（见图2.16）描述了计算工资总额的算法，并且知道基本工资、生活补贴、书报费、交通费和洗理费等数据应该存储起来，那么，它们到底存储在哪个数据存储中呢？

会计说，这些数据属于人事数据。

但是，在图2.13所示的数据流图中并没有一个数据存储保存人事数据，显然应该修改数据流图，补充进这个数据存储。

这样一步一步地分析数据流找出未知的数据元素，未知的数据元素引出访问时的问题，而问题的答案又引人一个以前不知道的系统成分——人事数据存储。

上述新发现又引出下一个问题：

人事数据存储是从哪里进人系统的呢？

经询问得知，这些数据的来源是人事科，而且需要增加一个新的处理—更新人事数据。

接下来讨论计算课时费和岗位津贴的方法。

会计告诉分析员，课时费等于教师当月的授课时数乘上每课时的课时费，再乘上职称系数和授课班数系数；岗位津贴由职工的职务和完成当月任务的情况决定。

通过讨论还进一步了解到，应在每年年末计算超额课时费，也就是说，如果一位教师一年的授课时数超过学校规定的定额，则超出部分每课时的课时费按正常值的1.2倍计算。

显然，为了计算超额课时费需要保存每位教师当年完成的授课时数，也就是说，需要一个数据存储来存放“年度数据”。

接下来讨论“加工事务数据”这个处理需要的其他算法。

例如，在讨论住房公积金的算法时了解到，根据国务院2002年3月24日修订的《住房公积金管理条例》的规定，“职工住房公积金的月缴存额为职工本人上一年度月平均工资乘以职工住房公积金缴存比例”，“职工和单位住房公积金的缴存比例均不得低于职工上一年度月平均工资的5％”。

因此，需要存储每名教职工上一年度的月平均工资，显然，这个数据元素也应该存储在“年度数据”中。

表2.5是年度数据包含的数据元素。

相应地，应该增加一个处理（“更新年度数据”）在每年年末更新年度数据。

最后，把新发现的数据源点、数据处理和数据存储补充到数据流图中，得到新数据流图（见图2.17）。

④细化数据流图

经过上述工作分析员对工资支付系统已经有了更深入、更具体的认识，原有的数据流图已经不能充分表达他对系统的认识，应该进一步地细化数据流图。

通常，使用下述的功能分解方法来细化数据流图：

选取数据流图上功能过分复杂的处理，把它分解成若干个子功能，这些较低层次的子功能成为新数据流图上的处理，它们有自己的数据存储和数据流。

图2.17补充后的工资支付系统数据流图

例如，图2.17中“加工事务数据”这个处理的功能太复杂了，用一个处理框不能清晰地描绘它的功能，应该把它进一步分解细化。

根据分析员现在对加工事务数据功能的了解，把这个处理分解成下述5个逻辑功能：

．取数据取出事务数据、人事数据和年度数据。

·计算正常工资计算不包含超额课时费的工资。

·计算超额课时费年终计算超额课时费，算得的钱数加到12月份的工资总额中。

·更新年度数据把每月工资总额、实发工资及授课时数累加到相应的年度数据中，并在年终计算本年度的月平均工资。

·印表格印出工资表、工资明细表和各种财务报表。

表2.5年度数据包含的数据元素

教职工编号

教职工姓名

本年度累计工资总额

本年度累计实发工资

本年度累计授课时数

上年度月平均工资

上述5个子功能及它们之间的关系，可以用一张数据流分图来描绘（见图2.18）。

把分解“加工事务数据”处理框的结果加到原来的数据流图中，得到一张更详细的新数据流图（见图2.19）。

图2.18对“加工事务数据”的细化

新数据流图对工资支付系统的逻辑功能描绘得比以前更深入、更具体了。

分析本系统其他处理功能后得知，对于这个具体系统来说，已经没有必要再分解其他功能了。

一般说来，如果进一步分解将促使你考虑为了完成该功能需要写出的代码，就不应该再分解了。

在需求分析阶段分析员应该只在逻辑功能层工作，代码已经属于物理层了。

图2.19工资支付系统完整的数据流图

书写正式文档

数据流图细化之后，组成系统的各个元素之间的逻辑关系更清楚了。

以细化后的数据流图为基础，可以对系统需求做更进一步地分析。

随着分析过程的进展，通过询问与回答的反复循环，将把目标系统定义得越来越准确。

最终，分析员对系统需求有了令人满意的认识，应该把这些认识用正式文档“软件需求规格说明书”准确地记录下来。

细化到适当层次的数据流图、数据字典和黑盒形式的算法描述，是构成软件需求规格说明书的重要成分。

⑥技术审查和管理复审

由从外单位聘请来的一位有经验的系统分析员担任技术审查小组的组长，并由具体处理工资事务的两名会计及本系统的分析员作为小组礴员。

图2.19所示的数据流图是审查的重点；用数据字典和IPO表辅助对数据流图的理解，由作为小组组员的一名会计朗读软件需求规格说明书，大家仔细审查这份文档。

审查的目的是发现错误或遗漏，而不是对前一阶段的工作进行批评或争论。

本系统的分析员负责改正审查小组发现的问题。

除了技术审查之外，在转入概要设计之前还必须进行管理方面的复审。

由财务科长和学校校长对本项目的经费支出情况和开发进度，从管理角度进行审查。