最后，考虑一种成本更高的方案：建立一个中央数据库，为开发完整的管理信息系统做好准备，并且把工资支付系统作为该系统的第一个子系统。这样做开发成本大约将增加到12万元，然而从工资支付这项应用中获得的经济效益并不变。因此，如果仅考虑这一项应用，投资是不划算的，但是，将来其他应用系统（例如，教学管理，物资管理，人力资源管理）能以较低成本实现，而且这些子系统能集成为一个完整的系统。如果校长对这个方案感兴趣，可以针对它完成更详尽的可行性研究（大约需要用1万元）。
⑥推荐最佳方案
低成本方案虽然诱人，但是很难付诸实现；高成本的系统从长远看是合理的，但是它所需要的投资超出了预算。从已经确定的系统规模和目标来看，显然中等成本的方案是最好的。
⑦草拟开发计划
应该为推荐的最佳方案草拟一份开发计划，把系统生命周期划分成阶段，有助于制定出相对合理的计划。当然，在这样的早期开发阶段，制定出的开发计划是比较粗略的，表2.3给出了所制定的计划。
表2.3 实现中等成本的工资支付系统的粗略计划
⑧写出文档提交审查
分析员归纳整理本阶段的工作成果写成正式文档（其中成本/效益分析的内容，根据表2.3所示的实现计划适当修正），提交由校长和财务科全体人员参加的会议审查。
(3)需求分析
需求分析的目的是确切地回答下述问题：“系统必须做什么？”
需求分析在可行性研究的基础上进行，前一阶段产生的文档，特别是数据流图（见图2.13），是需求分析的出发点。在需求分析过程中分析员将设计出更精确的数据流图，并将写出数据字典及一系列简明的算法描述，它们都是软件需求规格说明书的重要组成部分。
需求分析的主要任务是更详尽地定义系统应该完成的每一个逻辑功能。怎样完成这个任务呢？
任何数据处理系统的基本功能，都是把输入数据变成需要的输出信息。数据决定了处理和算法，看来数据应该是分析工作的出发点。必须经过计算才能得到的数据元素引出了必要的算法，算法反过来又引出了更多的数据元素。对数据的描述记录在数据字典中，对算法的描述记录在一组初步的IPO表中（目前描述的是说明数据处理功能的原理性算法）。
对系统有了更深入的认识之后，可以进一步细化数据流图。在细化数据流图的过程中，又会进一步加深对系统的认识。这样一步一步地分析，将更详尽更准确地定义出所需要的逻辑系统。
下面叙述工资支付系统的需求分析过程。 ①沿数据流图回溯
为了把数据流和数据存储定义到元素级，一般说来，从数据流图的输出端着手分析是有意义的。这是因为，系统最基本的功能是产生需要的输出数据，在输出端出现的数据元素决定了系统的基本构成。
从图2.13的数据终点“教师”和“职工”开始分析，流入他们的数据流是“工资明细表”。工资明细表由哪些数据元素组成呢？从该职业高中目前使用的工作明细表上可以看出它包含许多数据元素，表2.4列出了这些数据元素。这些数据元素是从什么地方来的呢？既然它们是工资支付系统的输出，它们或者是从外面输入进系统的，或者是由系统经过计算产生出来的。沿数据流图从输出端网输入端回溯，分析员应该可以确定每个数据元素的来源。如果分析员不能确定某个数据元素的来源，那么，工资问题的专家应该知道，因此需要再次调查访问。这样有条不紊地分析下去，分析员将逐渐定义出系统的详细功能。
表2.4 工资明细表上包含的数据元素
例如，表2.4中的数据元素“工资总额”是怎么得出来的呢？从图2.13可以看出，包含数据元素“工资总额”的工资明细表，是从处理4（“分发工资明细表”）输出到数据终点的，但是这个处理的功能是分发已经打印好的工资明细表，并不能生成新的数据元素。沿着数据流图回溯（即逆着数据流箭头方向前进），接下来遇到数据存储D3（“工资明细表”）。数据存储只不过是保存数据的介质，它不具有变换数据的功能，因此也不会生成工资总额这
项数据元素。再回溯则来处理3（“加工事务数据”），显然，工资总额是由这个处理框计算出来的，因此应该确定相应的算法，以便更准确地定义这个处理框的功能。
根据常识，工资总额等于各项收入（基本工资、生活补贴、书报费、交通费、洗理费、课时费或岗位津贴）之和。虽然不同教职工的基本工资、生活补贴、书报费、交通费和洗理费的数额可能并不相同，但是对同一个人来说，在一段时间内这些数值时稳定不变的，不需要在每次计算工资总额时都从外面输入这项数据。事实上，在输入的事务数据中并不包含这些数据元素，因此，它们必定保存在某个数据存储中。目前，还不知道这项数据保存在何处，分析员在笔记本中记下“必须搞清楚基本工资、生活补贴、书报费、交通费和洗理费等数据元素存储在何处。”此外，为了计算工资总额必须先计算课时费或岗位津贴，因此，分析员在笔记本中记下“必须弄清课时费或岗位津贴的计算方法。”然后，着手分析另一个重要的数据元素“实发工资”。
显然，从工资总额中扣除个人所得税、住房公积金和保险费之后，余下的就是实发工资。沿数据流图回溯可知，个人所得税、住房公积金和保险费的数值都由处理3（“加工事务数据”）计算得出。但是，目前还不知道怎样计算这些数值，分析员在笔记本中记下“必须搞清楚个人所得税、住房公积金和保险费的计算方法。”
②写出文档初稿
分析员在分析过程中不断加深对目标系统的认识，应该把获得的信息用一种容易修改、容易更新的形式记录下来。
通常，一个系统会涉及许多人，他们彼此理解是至关重要的。文档是主要的通信工具，因此，文档必须是一致的和容易理解的。结构化分析方法要求，在需求分析阶段完成的正式文档（软件需求规格说明书）中必须至少包含三个重要成分：数据流图，数据字典，以及一组黑盒形式的算法描述。
数据字典是描述数据的信息的集合。在分析阶段数据字典能帮助分析员组织有关数据的信息，并且是和用户交流信息的有力工具，此外，它还能起备忘录的作用。在设计阶段可以根据它确定记录、文件或数据库的格式。在实现阶段，程序员可以根据数据字典确定数据描述。在系统投入运行以后，数据字典可以清楚地告诉维护人员，具体的数据元素在系统中是怎样使用的，当必须修改程序时，这样的信息是极其宝贵的。
在手边没有数据字典软件包可用时，可以用卡片形式人工建立数据字典。例如，为工资支付系统中几个数据元素填写的数据字典卡片如图2.15所示。
图2.15 工资支付系统的数据字典卡片
分析员还应该以黑盒形式记录算法。所谓黑盒子就是不考虑一个功能的具体实现方法，只把它看作给予输入之后就能够产生一定输出的黑盒子。这正是在早期开发阶段分析员对算法应持有的正确观点，目的是用原理性算法准确地定义功能，算法的细节可以等到以后的开发阶段再确定。
通常使用IPO表记录对算法的初步描述。以后可以进一步精化它，而且在详细设计阶段可以把它作为HIPO图的一部分。图2.16是描述计算工资总额的初步算法的IPO表。
图2.16 描述工资总额初步算法的IPO表
目前写出的文档还仅仅是初稿，写出文档初稿的目的，一方面是记录已经知道的信息，另一方面是供用户审查。随着需求分析工作的深入，这些文档还将进一步修改完善。
③定义逻辑系统
通过前一步的工作，已经划分出许多必须在工资支付系统中流动的数据元素，并且把它们记录在初步的数据字典中，此外，还把某些算法以黑盒形式记录在IPO表中。上述这些工作成果正确吗？某些数据元素（例如，基本工资、生活补贴、书报费、交通费、洗理费）是从哪里来的呢？分析员必须设法得到这些问题的答案。
关于工资支付系统的详细信息只能来源于直接工作在这个系统上的人。因此，再次访问财务科长和具体处理工资事务的两位会计。数据流图（见图2.13）是使讨论时焦点集中的极好工具，从数据流图的数据源点开始，沿着数据流循序讨论。事务数据从教职工流进收集数据这个处理中，以前已经在数据字典中描述了组成事务数据的元素（图2.16中未列出这张卡片），这个描述正确吗？有没有遗漏？“收集数据”的功能是什么？审核数据的算法是什么？??对于分析员来说，数据流图、数据字典和算法描述可以作为校核时的清单或备忘录。必须审核已经知道的信息，还必须补充目前尚不知道的信息，填补文档中的空白。