软件工程需求分析案例.docx

软件工程需求分析案例.docx

《软件工程需求分析案例.docx》由会员分享，可在线阅读，更多相关《软件工程需求分析案例.docx（22页珍藏版）》请在冰豆网上搜索。

软件工程需求分析案例

11.假设你在一所职业高中工作，负责该校信息系统的建设与维护。

财务科长请你研究用学校拥有的微型计算机生成工资明细表和各种财务报表的可能性。

请详细描述你用结构化分析方法分析上述问题的过程。

答：

通常，结构化分析过程包括问题定义、可行性研究和需求分析3个阶段。

下面分别叙述这3个阶段的分析过程。

（1）问题定义

从何处着手解决财务科长提出的问呢？

立即开始考虑实现工资支付系统的详细方案并动手编写程序，对技术人员无疑是很有吸引力的。

但是，在这样的早期阶段就考虑具体的技术问题，却很可能会是我们迷失前进的方向。

会计部门（用户）并没有要求在学校自己的计算机上实现工资支付系统，仅仅要求研究这样的可能性。

后者是和前者很不相同的问题，它实际上是问，这样做预期将获得的经济效益能超过开发这个系统的成本吗？

换句话说，这样做值得吗？

优秀的系统分析员还应该进一步考虑，用户面临的问题究竟是什么。

财务科长为什么想研究在自己的计算机上实现工资支付系统的可能性呢？

询问财务科长后得知，该校一直由会计人工计算工资并编制财务报表，随着学校规模扩大工作量也越来越大。

目前每个月都需要两名会计紧张工作半个月才能完成，不仅效率低而且成本高。

今后学校规模将进一步扩大，人工计算的成本还会进一步提高。

因此，目标是寻找一种比较便宜的生成工资明细表和各种财务报表的办法，并不一定必须在学校自己的计算机上实现工资支付系统。

财务科长提出的要求，实际上并没有描述应该解决的问题，而是在建议一种解决问题的方案。

这种解决方案可能是一个好办法，分析员当然应该认真研究它，但是也还应该考虑其他可能的解决方案，以便选出最好的方案。

良好的问题定义应该明确地描述实际问题，而不是隐含的描述解决问题的方案。

分析员应该考虑的另一个关键问题，是预期的项目规模。

为了改进工资支付系统最多可以花多少钱？

虽然没人明确提出来，但是肯定会有某个限度。

应该考虑下述3个基本数字：

目前计算工资所花费的成本，新系统的开发成本和运行费用。

新系统的运行费用必须低于目前的成本，而且节省的费用应该能使学校在一个合理的期限内收回开发新系统时的投资。

目前，每个月有两名会计用半个月时间计算工资和编制报表，一名会计每个月的工资和岗位津贴共约2000元，因此，每年为此项工作花费的人工费约2.4万元。

显然，任何新系统的运行费用也不可能减少到小于零，因此，新系统每年最多可能获得的经济效益是2.4万元。

为了每年能节省2.4万元，投资多少钱是可以接受的呢？

绝大多数单位都希望在3年内收回投资，因此，7.2万元可能是投资额的一个合理的上限值。

虽然这是一个很粗略的数字，但是它确实能使用户对项目规模有一些了解。

为了请客户（会计科和学校校长）检验分析员对需要解决的问题和项目规模的认识是否正确，以便在双方达成共识的基础上开发出确实能满足用户实际需要的新系统，典型地，分析员用一份简短的书面备忘录表达他对问题的认识，这份文档称为“关于系统规模和目标的报告书”（见表2.1）。

表2.1关于工资支付系统规模和目标的报告书

项目名称：

工资支付。

问题：

目前计算工资和编制报表的费用太高。

项目目标：

研究开发费用较低的新工资支付系统的可能性。

项目规模：

开发成本应该不超过7.2万元（±50%）。

初步设想：

用学校自己的计算机系统生成工资明细表和财务报表。

可行性研究：

为了更全面地研究工资支付项目的可能性，建议进行大约历时两周的可行性研究。

这个研究的成本不超过4000元。

校长和财务科经过研究同意了上述报告书，可以对工资支付项目进行更仔细的研究了。

（2）可行性研究

可行性研究是抽象和简化了的系统分析和设计的全过程，它的目标是用最小代价尽快确定问题是否能够解决，以避免盲目投资带来的巨大浪费。

本项目的可行性研究过程由下述步聚组成。

1澄清系统规模和目标

为了确保从一个正确的出发点着手进行可行性研究，首先通过访问财务科长和校长进一步验证上一阶段写出的“关于工资支付系统规模和目标的报告书”的正确性。

通过访问分析员对人工计算工资存在的弊端有了更具体的认识，并且了解到工资总数应该记入分类日记帐，显然，新工资支付系统不能忽略与分类帐系统的联系。

研究现有的系统

了解任何应用领域的最快速有效的方法，可能都是研究现有的系统。

通过访问具体处理工资事务的两名会计，可以知道处理工资事务的大致过程。

开始时把工资支付系统先看作一个黑盒子，图2.11所示的系统流程图描绘了处理工资事务的大致过程。

图2.11处理工资事务的大致过程

处理工资事务的大致过程是，每月月末教师把他们当月实际授课时数登记在课时表上，由各系汇总后交给财务科，职工把他们当月完成承包任务的情况登记在任务表上，汇总后交给财务科。

两名会计根据这些原始数据计算每名教职工的工资，编制工资表、工资明细表和财务报表。

然后，把记有每名教工工资总额的工资表报送银行，由银行把钱打到每名教工的工资存折上，同时把工资明细表发给每名教职工。

接下来应该搞清楚图2.12中黑盒子（工资支付系统）的内容。

通过反复询问财务人员，可以知道现有的人工系统计算工资和编制报表的流程如下：

接到课时表和任务表之后，首先审核这些数据，然后把审核后的数据按教职工编号排序并抄到专用的表格上，该表格预先印有教职工编号、姓名、职务、职称、基本工资、生活补贴、书报费、交通费、洗理费等数据。

接下来根据当月课时数或完成承包任务情况，计算课时费或岗位津贴。

算出每个人的工资总额之后，再计算应该扣除的个人所得税，应交纳的住房公积金和保险费，最后算出每个人当月的实发工资数。

把算出的上述各项数据登记到前述的专用表格上，就得到了工资明细表。

然后对数据进行汇总，编制出各种财务报表，而工资表不过是简化的工资明细表，它只包含工资明细表中的教职工编号、姓名和实发工资这3项内容。

图2.12所示的系统流程图描绘了现有的人工工资支付系统的工资流程。

必须请有关人员仔细审查图2.12所示的系统流程图，有错误就应该及时纠正，有遗漏就应该及时补充。

③导出高层逻辑模型

系统流程图很好的描绘了具体的系统，但是，在这样的图中把“做什么”和“怎样做”这两类不同范畴的知识混在一起了。

我们的目标不是一成不变地复制现有的人工系统，而是开发一个能完成同样功能的新系统，因此，应该着重描绘系统的逻辑功能。

图2.12现有的工资支付系统

删除图2.12中表示的有关具体实现方法的信息，把它抽象成图2.13。

在这张数据流程图中用“事务数据”代表课时表和任务表中包含的数据，用“加工事务数据”笼统地代表计算课时费、岗位津贴、工资总额、个人所得税、住房公积金、保险费、实发工资等一系列功能。

这张数据流图描绘的是系统高层逻辑模型，在可行性研究阶段还不需要考虑完成“加工事务数据”功能的具体算法，因此，没必要把它分解成一系列更具体的数据处理功能。

在图2.13中的处理框“更新分类账”虽然不属于本系统应完成的功能，但是，工资支付系统至少必须和“更新分类账”所在的系统通信，因此，搞清楚它门之间的接口要点是很重要的。

在数据流图上直接注明关键的定时假设很有必要。

在以后的系统设计过程中这些假设将起重要作用。

清楚地注明这些假设也可以增加及时发现和纠正误解的可能性。

④进一步确定系统规模和目标

现在，分析员再次访问会计和财务科长，讨论的焦点集中在图2.13所示的数据流图，它代表了到现在为止分析员所要开发的系统认识。

通过仔细分析和讨论数据流图，能够及时发现并纠正分析员对系统的误解，补充被他忽视了的内容。

分析员现在对工资支付系统的认识已经比问题定义阶段深入多了，根据现在的认识，可以更准确地确定系统规模和目标。

如果系统规模有较大变化，则应及时报告给客户，以便做出新的决策。

可行性研究的上述4个步聚可以看作是一个循环。

分析员定义问题，分析这个问题，导出试探性的逻辑模型，在此基础上再次定义问题······重复这个循环直至得出准确的逻辑模型为止，然后分析员开始考虑实现这个系统的方案。

图2.13工资支付系统的数据流图

⑤导出供选择的解法

现在分析员对用户的问题已经有了比较深入的理解，但是，问题有行得通的解决方法吗？

回答这个问题的唯一方法是，导出一些供选择的解决方法，并且分析这些解决的可行性。

导出共选择的解法的一个常用的简单方法是从数据流图出发，设想几个划分自动化边界的模式，并且为每种模式设想一个系统。

在分析供选择的解法时，首先考虑的是技术上的可行性。

显然，从技术角度看不可能实现的方案是没有意义的。

但是，技术可行性只是必须考虑的一个方面，还必须能同时通过其他检验，一种方案才是可行的。

接下来考虑操作可行性。

例如，在对学生开放的公共计算机房内运行工资支付程序显然是不合适的。

这样做不仅不安全而且会暴露教职工的个人隐私。

因此，必须为工资支付系统单独购置一台计算机及必要的外部设备，并且挡在一间专用房间里。

最后，必须考虑经济可行性问题，即“效益大于成本吗？

”因此，分析员必须对已经通过技术可行性和操作可行性检验的解决方案再进行成本/效益分析。

为了给客户提供在一定范围内进行选择的余地，分析员应该至少提供3种类型的供选择的方案：

低成本系统，中等成本系统和高成本系统。

如果把每月发一次工资改为每两个月发一次工资，则人工计算工资的成本大约可减少一半，即每年可节省1.2万元。

除了已经进行的可行性研究的费用外，不再需要新的投资，这是一个诱人的低成本方案。

当然，也必须充分认识上述低成本方案的缺点：

违反常规；教职工反对；不能解决根本问题，随着学校规模扩大，人工处理工资事务费用也将成比例的增加。

作为中等成本的解决方案，建议基本上复制现有系统的功能：

课时表和任务表交到处理工资事务的专用机房。

操作员把这些数据通过终端送入计算机，数据收集程序接收并校核这些事务数据，把它们存储在磁盘上。

然后运行工资支付程序，这个程序从磁盘中读取事务数据，计算工资，打印出工资表，工资明细表和财务报表。

图2.14所示的系统流程图描绘了上述系统。

图2.14中等成本方案的系统流程图

上述中等成本方案看起来比较现实，因此对它进行了完整的成本/效益分析，分析结果列在表2.2中。

从分析结果可以看出，中等成本的解决方案是比较合理的，经济上是可行的。

表2.2中等成本方案的成本/效益分析

开发成本

人力（4人月，8000元/人月）

购买硬件

总计

3.2万元

1.0万元

4.2万元

新系统的运行费

人力和物流子（250元/月）

维护

总计

0.3万元/年

0.1万元/年

0.4万元/年

现有系统的运行费用

2.4万元/年

每年节省的费用

2.0万元

年

节省

现在值（以5%计算）

累计现在值

1

2

3

20000元

20000元

20000元

19047.62元

18181.82元

17241.38元

19047.62元

37229.44元

54470.82元

投资回收期

纯收入

2.28年

12470.82元

最后，考虑一种成本更高的方案：

建立一个中央数据库，为开发完整的管理信息系统做好准备，并且把工资支付系统作为系统的第一个子系统。

这样做开发成本大约将增加到12万元，然而从工资支付这项应用中获得的经济效益并不变。

因此，如果仅考虑这一项应用，投资是不划算的，但是，将来其他应用系统（例如，教学管理，物资管理，人力资源管理）能以较底成本实现，而且这些子系统能集成为一个完整的系统。

如果校长对这个方案感兴趣，可以针对它完成更详尽的可行性研究（大约需要用1万元）。

⑥推荐最佳方案

底成本方案虽诱人，但是很难付诸实现；高成本的系统从长远看是合理的，但是它所需要的投资超出了预算。

从已经确定的系统规模和目标来看，显然中等成本的方案是最好的。

⑦草拟开发计划

应该为推荐的最佳方案草拟一份开发计划。

把系统生命周期划分成阶段，有助于制定出相对合理的计划。

当然，在这样的早期开发阶段，制定出的开发计划是比较粗略的，表2.3的计划。

表2.3实现中等成本的工资支付系统的粗略计划

阶段

需要用的时间（月）

可行性研究

0．5

需求分析

1．0

概要设计

0．5

详细设计

1．0

实现

2．0

总计

5．0

⑧写出文档提交审查

分析员归纳整理本阶段的工作成果写成正式文档（其中成本/效益分析的内容，根据表2.3的实现计划适当修正），提交由校长和财务料全体人员参加的会议审查。

（3）需求分析

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

“系统必须做什么？

”

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

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

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

怎样完成这个任务呢？

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

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

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

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

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

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

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

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

1沿数据流图回潮

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

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

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

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

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

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

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

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

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

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

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

教职工编号

教职工姓名

基本工资

职务

职称

生活补贴

书报费

交通费

洗理费

课时费

岗位津帖

工资总额

个人所得税

住房公积金

保险费

室发工资

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

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

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

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

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

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

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

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

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

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

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

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

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

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

“

写出文档初稿

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

IPO表

系统：

工资支付作者：

王晓明

编号：

被调用：

注释：

教师岗位津贴为0，

职工课时费为0

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

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

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

定义逻辑系统

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

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

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

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

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

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

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

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

有没有遗漏？

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

审核数据的算法是什么？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

教职工编号

教职工姓名

本年度累计工资总额

本年度累计实发总额

本年度累计授课总额

上年度月平均工资

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

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

④细化数据流图

经过上述工作分析员对工资支付系统已经有了

更深入、更具体的认识，原有的数据流图已经不能充分表达他对系统的认识，应该进一步地细化数据流图。

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

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

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

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

·取数据取出事务数据，人事数据和年度数据。

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

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

·更新年度数据把每月工资总额，实发工资及授课时数累加到相应的年度数据

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

中，并在年终计算本年度的月平均工资。

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

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

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

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

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

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

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

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

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

⑤书写正式文档

数据流图细化之后，组成系统的各