确定培训需求工作流程图

10.1.2　第2阶段——分析

分析阶段的主要任务是分析终端用户的业务需求，并将项目目标细化为系统的功能和操作，也就是说，分析阶段是确定开发系统要“做什么”。

分析阶段包括三种主要活动:首先是收集业务需求，其次我们要绘制流程图，最后是确定系统建立方式。在完成系统分析进程之后，公司可能需要回到计划阶段。对于新系统要求的较强理解可能导致系统可行性的变化，从而使得预算和进度发生变化。

收集业务需求

确定系统的需求是系统开发过程中最重要的一个阶段。如果需求出错，那么系统必然是错误的。如果需求被完全正确地确定下来，接下来的设计和实施将会变得更简单而且成功的可能也更大。进行系统开发，在分析阶段首先要收集业务需求。

业务需求是指一份详细的员工、客户及利益相关者的需求，它引导和驱动着整个系统，因此在分析阶段首先需要分析员工、客户及利益相关者的信息需求。业务需求一般不涉及执行和技术方面的细节，以及对开发系统的具体技术要求。例如，系统某个业务需求表明，系统必须从产品、区域和销售代理等方面追踪所有客户销售信息。该需求明确了系统在业务方面必须完成的工作，但并没有任何关于系统如何满足需求的细节或建议。

分析人员往往通过面谈、调查、观察、联合应用开发会议(在10.2.2小节将详细介绍)等方式来确定新系统将满足什么需要，需要什么数据。业务需求一般通过开展调查来进行收集，系统用户会识别所有的业务需求，并评估这些需求。收集需求信息的目的是全面且详细地了解公司的问题，以及为即将要建立的系统如何解决该问题提供指导。

系统分析员根据调查结果给出需求定义文档。需求定义文档(requirements definition document)确定了最终的业务需求，并根据业务需求的重要程度进行优先排序。系统用户需对需求定义文档进行检查，并决定是否在上面签字。用户签字表示他们认可了所有的业务需求。

下面，举一个例子来说明需求分析对于系统开发的重要性。一家大型数据存储公司为了控制公司所有的信息系统，聘用了35名程序员，投入上亿美元来实施一个信息系统项目。但是由于该项目的基本目标、总体目标以及项目要求一直很模糊，导致该项目需求分析阶段的工作杂乱无章。项目最终在实施了7年之后被撤销，造成了公司资源的极大浪费和损失。经过事后调查发现，在该项目被撤销之前，竟然有1800多个业务需求，其中的900个工程条件是为实现另外900个用户需求所提出来的。项目需求阶段的工作的不顺畅就应该使管理层意识到该项目的问题，项目需求繁多导致项目的实施目标不明确，这样的项目应该立即叫停。

从上面的案例中，我们可以清晰地看出需求分析的重要性:不明确的、数量繁多和不断变更的需求必然导致系统开发的失败。能否抓住企业的关键成功因素和系统用户的根本需求是决定系统开发成败的关键。

绘制流程图

完成了收集需求的任务的同时，分析人员对企业的工作方式和业务流程也会有相当的了解，在此基础上，系统分析员就应该提出改进业务流程的方法，以使其更加有效率和有效力。流程建模便是帮助系统分析员改进业务流程的一个重要工具。流程建模是将系统与所处环境之间信息的捕捉、处理、存储和分布过程用图表的方式表示，简单的说，流程建模就是把业务流程图表化。数据流程图就是流程建模中最常见的图表之一。

数据流程图是描述系统数据流程的工具，它将数据独立抽象出来，通过图形方式描述信息的来龙去脉和实际流程以及数据存储。它可用于描述现存的系统，也可用于解释一个新系统是如何运行的。当需要对某个系统进行优化改进时，也可以在原有数据流程图的基础上进行直观的分析和理解，找出改进的方法。除此之外，结构化信息系统开发方法中还有一种常用的系统调查工具——业务流程图(Transaction Flow Diagram，TFD)。业务流程图就是用一些规定的符号及连线来表示某个具体业务处理过程。业务流程图的绘制基本上按照业务的实际处理步骤和过程绘制。换句话说，就是一“本”用图形方式来反映实际业务处理过程的“流水账”。绘制出这本“流水账”对于开发者理顺和优化业务过程是很有帮助的。

由此可见，数据流程图和业务流程图既可以真实地表达企业现有的工作方式或业务流程，也可以反映出对现有流程的改进。因而绘制流程图在项目分析阶段具有重要的作用，流程图所表达出来的对流程的改进意见，其实就是作为系统开发时的需求被考虑进去的。接下来，对数据流程图的基本成分和绘制方法做简要的介绍。

数据流程图的基本成分

数据流程图用到四个基本符号，即外部实体、数据处理、数据流和数据存储。

(1)外部实体:指系统以外与系统有联系的人或事物。它表示该系统数据的外部来源和去处，例如供货单位、顾客等。外部实体也可以是另外一个信息系统。在流程图中，用一个正方形，并在其左上角外边另加一个直角来表示外部实体，在正方形内写上这个外部实体的名称，参见图10-3所示。

(2)数据处理:指对数据的逻辑处理，也就是数据的变换。在数据流程图中，用带圆角的长方形表示处理。

(3)数据流:指处理功能的输入或输出，用一个水平箭头表示。箭头指出数据的流动方向。数据流可以是信件、票据，也可以是电话等。

(4)数据存储:指数据存储的逻辑描述。用右边开口长方条表示。在长方条内写上数据存储的名字。

数据流程图的绘制

上一部分提到在进行业务需求分析时，同时需要了解企业工作方式和业务流程，而后者的根本目的是分析出系统中合理的信息流动、处理、存储的过程，也就是数据流。绘制流程图时，其基本思想是先把系统看成一个整体，作为一个大的功能，明确系统的输入和输出，这样便可绘制出顶层(0层)数据流程图;系统为了实现这个整体功能，内部必然产生很多不同的数据流;对这些数据流的处理又可以分别看做一个小的功能，这些小功能内部又有数据的处理、传递、存储的过程。如此下去，自顶向下，逐层分解，一级一级地剖析，直到所有的处理步骤都具体到可以实现为止，从而得到1层、2层、3层等的数据流程图。

下面以学生选课系统为例说明画数据流程图的方法。首先，把整个学生选课系统看成一个功能。学生通过学生选课系统提交选课请求，由系统对请求进行处理，从而确定请求是否能够通过，由此可见，该系统的信息输入是学生的选课请求，输出是学生选课请求的通过通知单和未通过通知单，如图10-3所示。而系统在对选课需求进行处理时，需要对照“学生已修课程”和“课程要求”来决定请求能否通过，“学生已修课程”中记载学生已修课程的基本情况，“课程要求”中记载了要选修一门课程所必须具备的条件。所以，“学生选课系统”同时需要输入D1“学生已修课程”和D2“课程要求”两部分的相关信息。图10-3概括描述了系统的轮廓，标出了最主要的外部实体和数据流。还有一些外部实体、数据流没有画出来，随着数据流程图的展开再逐渐增加。

图10-3　学生选课系统顶层DFD

接下来，就可以分解到学生选课的具体操作流程。学生选课包括审核、打印拒绝通知单、写入数据、打印通过通知单四个部分。学生提交的选课申请需在P1部分参照“课程要求”和“学生已修课程”进行审核，审核之后可能得到两个结果:通过或未通过。通过的需经由P3流程将数据写入“学生已修课程表”中，并打印通过通知单，而未通过的直接打印未通过通知单，并将通知单的信息返回给学生。由此，可以将图10-3展开成图10-4。虚线框是图10-3中处理框的放大。图10-3的各个数据流都必须反映在图10-4上。此外还有新增的数据流。数据存储“学生已修课程”和“课程要求”是图10-3中原有的，可画在虚线框外(或一半在内，一半在外)。在图10-4中，与学生已修课程和课程要求有关的数据流更具体了。图10-4还可以进一步细化，生成二层图、三层图……直至所有的处理都详尽地表达出来。

数据字典

数据流程图描述了数据流的处理过程，表达出了系统的框架，但是它并不能表示出系统所有的内容，特别是有关数据的详细信息。为了描述清楚数据流程图中的数据流、数据存储、处理过程和外部实体，系统分析员还需要进一步定义数据字典。数据字典中有6类条目:数据元素、数据结构、数据流、数据存储、处理过程、外部实体，它是在数据流程图的基础上，对这六个条目的详细定义和说明。不同类型的条目由不同的属性描述。数据字典实际上是“关于系统数据的数据库”，在整个系统开发过程以及系统运行后的维护阶段，数据字典都是必不可少的工具。数据字典是所有人员工作的依据，统一的标准，它可以确保数据在系统中的完整性和一致性。数据字典必须由专人(数据管理员)管理，以保证数据的一致性。

图10-4　学生选课系统一层DFD

总之，数据流程图描述了系统的组成、结构和各部分之间的相互关系，而数据字典则是对系统具体细节的详细介绍，两者之间相互联系，相互补充，只有结合在一起才能更清楚地实现对系统的真实反映和表达。

确定系统的建立方式

经过以上步骤的分析后，企业需结合自身情况确定系统的建立方式，即在自行开发、直接购买和外包中选择一种能使企业获得最大利益的方式。有关这几种方式的优缺点及选择条件，我们将在10.3节中进行详细讨论。