第3章 需求分析案例
- 格式：doc
- 大小：204.50 KB
- 文档页数：4
第三章需求分析
需求分析的基本任务是对目标系统提出完整、准确、清晰、具体的要求。
在这个阶段，分析员应在高层功能级数据流图的基础上开发更精确的数据流图，同时还要建立数据字典。
这些文档是需求分析结束的标准。
在可行性研究阶段中许多实际的被忽略了的系统元素，本阶段应该严格定义。
1、沿数据流回溯，完善数据流图
在可行性分析阶段建立的功能及数据流图中，一些数据存储及变换的具体含义尚未明确。
必须对系统作进一步的分析，逐步对他们对进行定义。
从该图可看出，流向数据终点“职工”的数据流是“工资”，而“工资”这个数据流的含义是什么？它是由哪些数据项组成的？还并不明确。
从职工工资条条上可以看出它包括的数据项有：职工姓名、职工号、基本工资、工龄津贴、教辅津贴、生活补贴、物价补贴、洗理费、书报费、其他应补、应发工资、房租、水费、电费、其他扣款和实发工资。
沿这个数据流图从输出端往输入端回溯分析，可以确定每个数据项的来源。
“应发工资”他是怎样得出来的呢？从图中可以看出工资是从变换4“发放工资”来的。
而变换4只是分发已准备好的工资，并不改变数据。
再沿着数据流图回溯，遇到数据存储“工资”，数据存储只是保存数据的场所，它包含的数据项和相关的输入/输出数据流相同，不会改变。
当回溯到变换3“处理事务”时，可知应发工资是由这个变换框计算出来的，因此需要为之确定相应的算法。
分析员知道应发工资=基本工资+工龄津贴+教辅津贴+生活补贴+物价补贴+洗理费+书报费+其他应补。
但这些数据项又是从哪里来呢？分析员暂时还不知道来源，在备忘录
中记下“必须确定应发工资中的数据来源”。
然后转去分析另外的数据项得到：实发工资=应发工资-房租-水费-其他扣款
事务数据=职工姓名+职工号+水费+电费
分析员就这样一步一步划分出系统的数据元素，搞清他们的来源和各个算法。
通常还把分析过程中得到的有关数据元素的信息记录在数据字典，把对算法的简明描述记录在IPO 途中。
2、细化数据流图
工资管理系统已定义了许多数据项。
但是，有些数据项是从哪里来的还不太清楚。
分析员要得到答案必须再次访问用户。
访问时分析员可以带上数据流图，从图中的源点开始沿着数据流循序讨论。
在图上，事务数据从职工流进变换“收集数据”中。
分析员对事务数据的描述是否正确？变换“收集数据”的功能是什么？变换“验证数据”也需要某种算法，描述正确吗？可通过数据流图、数据字典的分析来确认所讨论的内容。
对应发工资的算法，分析员知道：应发工资=基本工资+工龄津贴+教辅津贴+生活补贴+物价补贴+洗理费+书报费+其他补贴。
那么这些数据从哪里来？财务部门会计会告知，是从人事档案来的。
但是，在数据流图中没有人事档案这个数据存储，说明应该将他加入，并取名为“人事数据”。
人事数据是谁提供的呢？显然，系统中没有这些数据存在，他们一定是从某个数据源进入系统的。
经访问用户后可知，这些数据来自人事处。
由于这些数据不是固定不变的，因此需要一个新的变换“修改人事数据”。
分析员进一步完善图纸后可得到零层数据流图。
与上述分析得出的工资管理系统的零层数据流图相应的数据字典如下：
（1）数据流描述
事务=职工姓名+职工号卡水费+电费
工资=职工姓名+职工号+基本工资+工龄津贴+教辅津贴+生活补贴+物价补贴+洗理费+书报费+其他应补+应发工资+电费+房租+水费+其他扣款+实发工资
人事数据=职工姓名+职工号+性别+基本工资+工龄津贴+教辅津贴+生活补贴+物价补贴+洗理费+书报费+房租+其他应补（如补发工资）
报表=工资汇总表、房租水电扣款、基本工资分类表、工资签收表
（2）数据存储描述
数据存储名：事务数据文件
组成：{事务数据}
组织：按职工号大小顺序排列
数据存储名：人事数据文件
组成：{人事数据}
组织：按职工号大小顺序排列
数据存储名：工资文件
组织：按职工号大小顺序排列
（３）变换描述
变换名：收集数据
变换编号：１
输入数据流：事务数据
输出数据流：事务数据
变换逻辑：将职工原水电费登记到该职工名下
变换名：验证数据
变换编号：２
输入数据流：事务数据
输出数据流：已校对的数据
变换逻辑：对职工水电费进行校验
变换名：处理事务
变换编号：3
输入数据流：事务数据、人事数据
输出数据流：工资、报表
变换逻辑：获得事务数据、获得人事数据、计算应发工资、计算实发工资、写工资单、谢报表
变换名：发放工资
变换编号：4
输入数据流：工资
输出数据流：工资
变换逻辑：将工资分发给职工
变换名：产生报表
变换编号：5
输入数据流：工资表
输出数据流：工资汇总表、房租水电扣款表、基本工资分类表、工资签收表
变换逻辑：对工资表中的有关项目进行汇总产生各汇总报表
变换名：修改人事数据
变换编号：6
输入数据：修改数据项
输出数据：修改后的人事数据
变换逻辑：对相关的数据项的值进行修改
现在分析员的任务就是对零层数据流图的每一个变换进行检查，如果某一变换功能还比较复杂，不好理解，就应该对这个变换进行分解。
通过功能分解来达到细化数据流图的目的。
将比较复杂的变化分解成若干个子功能后，这些子功能就成了较低层次的数据流图上的变换，它们相应地也应有自己的数据存储和数据流。
例如下图中“处理事务”比较复杂，可进一步把这个变换细化。
这个变换可分解成：取数据；计算应发工资；计算借款数据；修改借款数据；写工资单；写报表
为了便于追踪，从上图变换3分解出来的新变换的编号是3.1、3.2……3.7。
一般来说，对其他变换也可以进行类似的分解。
然而对这个工资管理系统而言，其他变换没有必要再分解了。
分解完成后，相应的数据字典也应补充，以建立第一层数据字典。
由于本工资管理系统比较简单，有了数据流图的顶层、零层、第一层和相应的数据字典，就可以得出它的完整的数据流图（完整的逻辑模型）了。
在数据流图分解时，每个变动都可能引出新的问题。
这些问题的回答可以到处数据字典的新条目。
随着分析过程的深入，通过不断的提问和回答，把软件系统定义的越来越准确详细。
最终能对系统的功能要求有一个较全面地认识。
应该高度重视：通过各层数据流图和数据字典把对系统的完整认识描述出来，并作为正式文档保存。
3、复查计划
需求分析完成后分析员必须复查计划文档，验证资源、成本、进度等是否仍然合理。
如果需要修改计划，则必须召开管理人员复查会，逐个分析引起修改的原因，并审批对资源、成本和进度的变动。
本利工资管理系统没遇意外情况，最初的成本估计和进度表，现在仍然是合理的。
