第5章系 统 分 析
信息系统分析是信息系统开发的关键阶段。它的任务是通过对企业进行详细调查，充分分析用户要求，设计新信息系统的逻辑模型。逻辑模型描述了信息系统应该具有的功能，而不涉及具体的物理细节。换句话说，信息系统分析只解决信息系统“做什么”的问题，而不解决信息系统“如何去做”的问题。
系统分析是系统规划任务的延续，也是最困难的阶段。系统规划是面向全局、从战略角度去分析信息系统，而系统分析则是面向局部、从具体细致的角度去分析信息系统。系统分析所确定的内容是系统设计和系统实施的基础。系统分析阶段工作的深入与否直接影响着新系统的设计质量和经济性，在系统建设中起着重要的作用。
5.1系统分析概述
5.1.1系统分析的任务
在信息系统开发实践中，成功的经验和失败的教训使人们认识到，为了使开发出来的目标系统能满足实际需要，在着手编程之前，必须要有一定的时间用来认真考虑以下问题。
系统所要解决的问题是什么？
为解决该问题，系统应做些什么？
系统应该怎么去做？
在总体规划阶段，通过初步调查和分析，建立了信息系统的目标，已经回答了上面的第一个问题。而第二个问题的解决，正是系统分析的任务； 第三个问题则由系统设计阶段解决。只有明确了问题，才有可能解决问题。信息系统成功开发的关键在于对问题的理解和描述是否正确，这正是系统分析阶段的基本任务。
1. 对系统需求的理解和确切表达
在提出信息系统的功能之前，必须了解现行系统的现状。详细了解每个业务流程和业务活动的工作过程及信息处理过程，理解用户对信息系统的需求，包括对系统功能、性能方面的需求，对硬件配置、开发周期、开发方式等方面的意向，对系统可靠性、安全性、保密性的要求，以及对系统开发费用、时间和资源方面的限制等。为此要进行详细调查，以便对企业业务领域的各项活动进行详尽的了解，为设计信息系统的逻辑模型做资料准备。
2. 确定系统的逻辑模型
在详细调查的基础上，运用各种系统分析的理论、方法和技术，确定系统应该具有的逻辑功能，再用一系列图表表示出来，形成系统的逻辑模型。对上述采用图表描述的逻辑模型进行适当的文字说明，组成系统分析报告，它是系统分析阶段的主要成果。
应该注意的是，尽管在系统规划阶段，通过对系统的初步调查，得到了新信息系统的总体功能，并给出了项目开发计划，但系统分析阶段用户提出的开发要求更为详尽，必须从经济、技术和管理等各个方面对系统的开发环境和开发条件等再次进行科学的分析。
在系统分析阶段，应该坚持面向用户的原则，集中精力进行深入而详细的调查研究，认真分析用户系统，直到用科学的方法将系统的逻辑模型表达出来。
5.1.2系统分析的要求
随着信息系统复杂性的提高及规模的扩大，系统分析在系统开发中的地位越来越突出，对系统分析一般有以下要求。
1. 系统分析应该在充分理解用户需求的基础上进行
信息系统的最终目的是满足用户管理上的各种功能需求，信息技术是实现各种用户功能需求的手段。如果系统开发人员对用户需求理解错误，那么无论技术手段如何先进，其结果都是南辕北辙的。因此，充分理解需求是系统开发成功的重要保证。为了准确理解用户需求，系统开发人员必须同用户不断交流。
2. 系统分析由系统分析人员和用户协作完成
系统分析是围绕管理问题展开的，但会涉及现代信息技术的应用，由于用户和系统设计人员的工作和专业背景不一致等原因，双方交流时存在着隔阂，只有系统分析人员与用户充分交流和合作，信息技术才能很好地应用到用户的管理工作中，开发出来的系统也才能既满足用户需求，又做到技术先进。
3. 充分了解现有系统是系统分析的基础
信息技术在企业管理中的应用，并不是简单地用信息技术去对现行系统的再现和复制，而是要通过新系统的开发为企业带来效益和创造新机会，比现行系统功能更强、效率更高、使用更方便。企业信息系统的开发应该在总体规划的基础上，用系统工程的思想和方法对用户的管理业务活动进行全面的调查和分析，详细了解用户的各种管理业务活动的流程，分析现有系统的局限性和不足之处，然后根据企业的具体条件和信息技术的发展状况确定新系统的逻辑方案。随着企业信息化水平的提高，新系统的建立往往要求对现有系统中的业务流程进行重新构造。
4. 系统分析要避免重复工作
系统分析工作的主要成果形式是文档资料，这些文档资料既可以用来与用户进行交流，也可以用来进行系统设计，保证了系统开发的一致性。正确而规范的文档资料可以提高系统的可维护性，系统分析员在编制文档资料的过程中要认真、细致，尽量避免出现错误。一旦发现错误就要及时更正，不要把错误带到下一阶段的开发工作中。
5. 系统分析要讲究方法
系统分析是一项复杂的工作，好的分析方法既可以保证分析工作的顺利进行，又可以提高工作效率。在进行系统分析时，强调用逻辑模型的方式简单、明确地描述系统的现行状态，使用户能够从这些模型中直观地了解系统的概貌，避免用户和系统分析员双方在理解上的偏差，也使系统设计员能够直接根据模型进行系统设计，保证设计的正确性。因此，建立多种模型是系统分析员和用户、系统分析员和系统设计员之间联系的手段。
5.1.3系统分析的步骤
1. 现行系统的详细调查
集中一段时间和人力，对现行系统做全面、充分和详细的调查，弄清现行系统的边界、组织机构、人员分工、业务流程、各种计划、单据和报表的格式、种类及处理过程，企业资源及约束情况等，为系统开发做好原始资料的准备工作。
2. 组织结构与业务流程分析
在详细调查的基础上，用一定的图表和文字对现行系统进行描述。新系统的开发可以看作是对组织有目的的改造过程，详细了解各级组织的职能和有关人员的工作职责、决策内容对新系统的要求。业务流程的分析应当遵循原系统信息流动的过程逐步进行，通过业务流程图详细描述各环节的处理业务及信息的来龙去脉。
3. 系统数据流程分析
数据流程分析就是把数据在组织或原系统内部的流动和处理情况独立出来，舍去具体组织机构、信息载体、处理工作、物资、材料等，仅从数据流动过程考察实际业务。主要包括对于信息的流动、传递、处理与存储的分析。
4. 创建数据字典
数据字典是系统中各类数据描述的集合，是详细调查后数据收集和数据分析的主要成果，通常包括外部实体、数据项、数据结构、数据流、数据处理和数据存储。显然，不同的系统都有它们各自的数据流程图和数据字典。各种数据模型结合数据字典，就可以从图形和文字两方面对系统的逻辑模型进行完整的描述。
5. 建立新系统的逻辑模型
针对分析过程中了解到的用户需求及原系统业务和数据流程中存在的问题，建立新系统逻辑模型，用一组图表工具表达和描述，方便用户和分析人员对系统提出改进意见。
6. 提出系统分析报告
系统分析阶段的成果就是系统分析报告。它是系统分析阶段的总结和向有关领导提交的报告，反映这个阶段调查、分析的全部情况，该报告将被提交给用户领导、监理单位或有关专家审批。审批通过后将是下一步系统设计工作的依据。
在运用上述步骤进行系统分析时，调查研究将贯穿于系统分析的全过程。调查与分析经常交替进行，系统分析深入的程度将是影响信息系统成败的关键问题。
5.1.4系统分析的方法
利用详细调查，得到组织机构及其业务功能、业务流程及相关数据等，之后需要借助一定的技术、工具与方法进行分析和逻辑设计。实践证明，结构化系统分析方法是一种简单易用的方法。
1. 结构化分析的基本含义
结构化系统分析方法是自顶向下、逐步求精的系统分析方法，其核心特征是“分解”和“抽象”。分解是指将一个复杂的问题按照其内在的逻辑划分为若干个相对独立的子问题，从而简化复杂问题的处理。抽象是抽取出事物的本质特性而暂时不考虑它们的细节。结构化分析和建模的主要目的是减少分析时的错误，通过自顶向下地建立系统逻辑模型，降低系统设计的复杂性，提高系统的可维护性。
假设有系统S，它被分解为S1、S2、S3三个子系统，S1、S2、S3又被分解为S11、S12、S13，S21、S22，S31、S32，如果子系统仍然比较复杂，还可以再进一步分解，如此下去，直到每个子系统足够简单，能够被清楚地理解和表达为止，如图51所示。
图51复杂系统分解示意图
分解和抽象实质上是一对相互联系的概念。自顶向下的过程，即从顶层到第一层再到第二层的过程，称为“分解”； 自底向上的过程，即从第二层到第一层再到顶层的过程，称为“抽象”。换句话说，下层是上层的分解，上层是下层的抽象。这种层次分解使人们逐步了解更多的细节。对于顶层不需要考虑任何细节，只需要考虑系统对外部的输入和输出，然后一层层地了解系统内部的情况。
对于任何复杂的系统，分析工作都可以按照上述方式有计划、有步骤地进行，大小规模不同，系统只是分解的层次不同，即规模大的系统分解的层次多，规模小的系统分解的层次少。
2. 结构化分析的主要工具
结构化分析法是进行信息系统分析的行之有效的方法。结构化分析的核心是数据。数据包括在分析、设计和实现中涉及的概念、术语、属性等所有内容，并把这些内容定义在数据字典中。围绕数据字典，完成功能模型、数据模型和行为模型的结构化建模过程。围绕数据字典展开的结构化分析如图52所示。
图52结构化分析与数据字典
实体关系模型主要描述数据建模过程，刻画系统的静态特征，包括实体的属性和属性间关系。数据对象通过对实体的抽象，为后续阶段数据结构、数据库和类对象的分析与设计提供基础信息。
在结构化系统分析方法中，采用数据流程图对功能、操作流程进行抽象和分解，完成功能建模。通过将复杂问题自顶向下逐层分解，把操作流程由物理过程抽象为逻辑过程，完成对问题的逐级分解和抽象，最终解决问题。
状态转换图是系统的行为建模，通过外部事件的触发，导致系统采取相应操作。
5.2可行性分析
开发任何一个基于计算机的系统都会受到时间和资源的限制。事实上，许多问题不可能在预定的系统规模或时间期限内解决。如果问题没有可行的解，那么花费在这项工程上的任何时间、人力、软硬件资源和经费，都是无谓的浪费。因此，开发方在接受客户的项目之前，必须根据客户可能提供的时间和资源等条件进行可行性研究。
可行性分析是一个综合的概念，它综合运用多学科的知识，寻找一种可使得拟建系统达到最佳收益的方案。可行性研究的目的是用最小的代价在尽可能短的时间内确定该项目是否值得去解决，是否存在可行的解决方案。
5.2.1可行性分析的内容
可行性分析又称为可行性研究，是指在当前组织内外的具体条件下，进行某项目的必要性和可能性的分析，或者进一步确定系统开发工作必须具备的资源和条件，看其是否满足系统目标的要求。
可行性分析的根本目的不是解决问题，而是确定问题是否值得去解决，即解决新系统开发“是否可能”和“有无必要”的问题，是任何一项大型工程正式启动之前都必须进行的一项工作。这对于保证资源的合理使用、避免浪费是十分必要的，也是项目能顺利进行的重要保证。要达到这个目的，必须分析项目开发的利弊，从而判断原定的系统目标和规模是否现实，系统完成后所带来的效益是否大到值得投资的程度。因此，可行性研究实质上是要进行一次大大简化了的系统分析和设计的过程，也就是在较高层次上以较抽象的方式进行的系统分析和设计的过程。
可行性研究的任务，是在做出决策之前，全面论证信息系统开发的必要性、可能性、有效性和合理性。根据初步调查和信息系统方案，系统开发人员根据系统环境、资源等条件，判断所提出的信息系统开发项目在经济、技术、社会等方面是否具有可行性。社会环境的研究是可行性研究的前提； 技术上的可行是可行性研究的基础； 经济上的可行则是可行性研究评价和决策的主要依据。可行性分析的核心是进行经济可行性分析。技术上、管理上的先进与可行，不能离开经济的合理性，如经济上不合理或不利，则技术上再先进与可行，也不足取。
1. 经济可行性
经济可行性主要回答“这个系统的经济效益是否超过它的开发成本”这个问题，即估算项目的开发成本和投入使用后可能带来的利润，及对其他产品或利润的影响，进行成本效益分析，也称为投资/效益分析或成本/效益分析。当总收益大于总成本时，这个项目才值得开发。
通常在估计信息系统费用时，不仅要考虑设备费用，而且要计算材料及其他易耗品的费用、软件开发费用、管理费用、人员培训费用和将来系统投入运行后的维护费用。一些单位只考虑购买设备的费用，虽然这样一次性投资审批可以通过，但每年的维护费用却没有预算，出现“买得起、用不起”的局面。
对于大多数系统，一般衡量经济上是否合算，需要考虑利润值和总投入。信息系统经济效益的估算并不容易量化。一部分是可以用货币计算出来的效益，如加快流动资金周转、减少资金积压等，即直接效益。另一部分难以用金钱直接衡量，例如，信息系统加强了计划的准确性，减少了窝工； 加强库存管理，减少了资金积压； 加强用户管理，提高了客户的满意度和忠诚度； 提供更多的更高质量的信息，提高获取信息的速度； 提高企业员工的素质等： 即间接效益。这类经济效益的大小只能由管理人员根据经验进行估计。
大部分人都比较关注直接效益而忽视间接效益。然而，大量从事数据处理的信息系统目前主要表现出的是间接的经济效益，通常可以从以下几个方面考虑信息系统的间接经济效益。①提供了哪些以前不能提供的信息？②信息质量(如准确度、效率)有哪些提高？③完成了哪些以前不能或不易做的或不能及时处理的信息处理工作？④使用者查询信息的方便程度有怎样的提高？⑤节省了多少人力？⑥为高层管理者的决策提供了哪些帮助？⑦使本企业与外部单位的关系得到了怎样的改善？
2. 技术可行性
技术可行性分析主要是分析在特定条件下，技术资源的可用性和这些技术资源用于解决信息系统问题的可能性和现实性。主要回答“使用现有的技术能否实现这个系统”这个问题，需要根据客户提出的系统功能、性能要求及实现系统的各项约束条件，从技术的角度研究实现系统的可行性。在进行技术可行性分析时，一定要注意下述几方面的问题。
1) 考虑信息系统开发所涉及的技术问题
信息系统开发涉及多种开发技术、软件和硬件平台、网络结构、系统布局、输入输出、数据存储和信息安全等，应该客观分析这些技术对信息系统功能和性能的支持程度和可操作性，研究是否具备系统开发所需要的人力资源(管理人员、专业技术人员等)、软件资源、硬件资源和工作环境。如果在系统开发过程中遇到难以克服的问题，就会拖延进度，增大成本，甚至出现灾难性的后果。
2) 尽可能采用成熟的技术
成熟技术是被多人使用且被反复证明行之有效的技术，采用成熟技术开发信息系统具有较高的成功率。成熟的技术经过长时间和大范围地使用、补充和优化，其稳定性、可操作性、经济性都要比新技术好。因此，在能够满足信息系统开发需要、适应信息系统发展的条件下，应该尽量采用成熟的技术。
3) 慎重引入新技术
有时为了解决某些特定问题，或者确保信息系统具有更好的适应性，也需要采用新技术。由于没有经过大量实践验证，在选用新技术时，需要全面分析所选技术的成熟度。
4) 考虑系统开发人员的能力
有的技术或许是可行的，但是如果系统开发队伍中没有人掌握这种技术，也没有引进掌握这种技术人员的计划，那么这种技术对信息系统开发来说仍然是不可行的。
3. 社会可行性
信息系统是一个社会技术系统，因此除了经济和技术因素外，还有许多社会因素对信息系统的开发起着制约的作用，如要开发的项目是否存在侵犯、妨碍等责任问题。社会可行性是指所建立的信息系统能否在该企业实现，在当前操作环境下能否很好运行，即组织内外是否具备接受和使用新系统的条件。社会可行性涉及的内容比较广泛，需要从政策、法律、道德、制度、管理、人员等社会因素来考虑。可以从企业内部和企业外部两个方面，通过分析企业是否具备接受和使用信息系统的条件来分析信息系统的社会可行性。
1) 从企业内部看
(1) 调查高层管理者对信息系统的态度以及员工素质。如果他们对信息系统有误解甚至抵触，则说明开发信息系统的条件暂不成熟，最好先做好宣传和解释工作，或者寻找阻力最小的部门先突破，同时也要调查要开发项目的运行方式在用户组织内是否行得通，是否与原有其他系统相矛盾。
(2) 查看企业的各项规章制度是否完善，原始数据是否齐全。如果企业流程仍未定型，管理制度还在变动，甚至原始数据也不齐全，那么再先进的信息系统也难以发挥作用。
(3) 在特定的环境下，分析信息系统能否有效地支持工作并方便用户使用，需要考虑以下几个方面的问题： 手工业务流程、信息系统的流程，以及这两种流程的相近程度和差距、信息系统业务的专业化程度，信息系统能否满足用户的使用要求，信息系统操作的方便程度，用户的实际能力。
2) 从企业外部看
(1) 分析信息系统是否会为社会效益带来负面影响，是否与道德、法律、制度相抵触，是否会引发败德行为。
(2) 考虑业务伙伴的信息化现状。有些企业的信息系统建设会“身不由己”，他们需要按照供应链上强势企业的标准来调整本企业的信息化战略。
(3) 信息系统上线后，相关报表、票证格式的改变是否得到有关部门的认可，将直接影响企业的利益。
当然，可行性研究最根本的任务是对以后的行动方针提出建议。如果问题没有可行的解决方案，系统分析员应该建议停止这项开发工程，以避免时间、资源、人力和金钱的浪费； 如果问题值得解决，分析员应该推荐一个较好的解决方案，并且为项目制订一个初步的计划。
可行性研究需要的时间长短取决于工程的规模。一般说来，可行性研究的成本只是预期的工程总成本的5%~10%。
5.2.2可行性分析报告
在可行性研究结束之后，应该将结果用可行性报告的形式编写出来，形成正式的工作文件。根据国家标准《计算机软件文档编制规范》(GB/T 8567—2006)的相关指导性说明，可行性研究报告的编写内容如图53所示。
图53可行性报告内容
可行性分析报告反映了系统开发人员对系统开发的看法、是否符合使用者的原意、有没有偏离使用者的目标。这一报告应该提交到会议上正式讨论，会议除了用户的领导、管理人员、系统研制人员之外，还应该尽可能地邀请一些有经验的局外人员参加，共同讨论，充分估计各种可能出现的问题，集思广益。最后，由评审会成员签署意见，做出尽可能符合实际的判断，结论分为三类： 可立即进行、推迟进行，以及不能和不值得进行。
5.3详细调查的方法
5.3.1详细调查的目的和原则
1. 详细调查的目的
详细调查的目的在于完整掌握现行系统的现状，发现问题或薄弱环节，收集资料，为下一步的系统化分析和提出新系统的逻辑设计做好准备。要广泛地、多渠道地、多形式地听取用户的意见，增加用户的参与度。通过详细调查，加强开发人员与用户的沟通，提高用户(特别是领导层)对开发信息系统的认识。
2. 详细调查的原则
详细调查是指对组织的目标、规模、机构、职能、产品、业务、设备、业务、管理、决策和人员等方面进行的调查研究，是一项十分艰苦和细致的工作，需要高度重视、精心组织和细致工作。进行详细调查时，应该遵循以下基本原则。
1) 客观真实原则
业务调查必须从客观实际出发，坚持实事求是、准确可信的原则。实事求是指根据现实的实际情况进行调查，不要掩饰问题，充分反映现实需求，不夸大不缩小。准确可信是指所调查的内容真实可信，要准确地反映单位或者部门的实际现状。业务调查的结果将作为现行组织系统分析和信息系统开发的依据，任何虚假和不客观的调查内容都会给将要开发的信息系统留下隐患。因此，绝对不能仅凭调查人员自己的猜想和臆断对组织的业务过程进行曲解或歪曲。
2) 调查、分析、记录相结合原则
开发人员和用户缺乏共同的领域背景，对于用户描述的某些问题难以理解，或在理解上也难免出现偏差。调查的过程是学习的过程，也是分析的过程，解决方案需要共同研讨。如果不加分析，将无法弄清楚所调查的内容。因此需要强调调查与分析相结合。由于参与人员较多，对调查的结果应该采用规范的形式及时记录下来。
3) 全面性原则
任何系统都是由许多子系统有机地组合在一起而实现其功能的。系统调查中如果疏忽大意或偷工减料，就容易忽略某些处理过程或漏掉某些账表。这些被忽略的部分如果在分析、设计中仍未被发现，待系统实现后再添加进去——即使这是可能的，其花费也要成倍增长，有时根本就无法添加到系统中去。
4) 规范性原则
信息系统一般都比较复杂而且庞大。全面、真实地表达信息系统的逻辑模型，就需要有一套循序渐进、逐层深入的调查步骤和层次分明、通俗易懂的规范化逻辑模型描述方法。例如，利用一系列直观的图表，把要调查的内容全面、详细地列出来，既可提高调查质量，又可建立一套调查文档。
5) 启发性原则
调查是开发者通过与业务人员的沟通获得信息的过程。能否真实地描述系统，不仅需要业务人员的密切配合，更需要调查人员的逐步引导，不断启发。尤其在考虑计算机处理的特殊性而进行的专门调查中，更应善于按使用者能够理解的方式提出问题，打开使用者的思路。
5.3.2详细调查的范围
详细调查围绕组织及其现行系统进行，现行系统包括手工系统和已采用计算机的信息系统。但应该注意的是，信息流是通过物流而产生的，物流和信息流又都是在组织中流动的。因此所调查的范围就不能仅仅局限于信息和信息流，而应该围绕组织内部信息流所涉及领域的各个方面，如企业的生产、经营、管理等。下面给出详细调查的主要范围。
1. 组织机构和功能业务
组织机构是根据单位目标设置并组织起来的，功能业务是指各部门的业务和职能范围。应弄清开发单位的组织机构设置、岗位职能、行政隶属关系及组织的业务范围，理顺各部门的关系。当然，职能是可以变化的，业务功能相对于组织结构是独立的。把业务功能抽象出来，按功能设计系统和子系统，能使信息系统具有较强的生命力和良好的柔性。
2. 组织目标和发展战略
在初步调查中，已了解到组织的总体目标和发展战略，详细调查要进一步明确具体目标的发展战略，针对某个部门如何实现组织的总目标和发展战略，以及所包括的措施和指标，针对信息系统的开发对实现组织总目标和发展战略的作用，重点解决的问题等。
3. 业务流程和产品构成
业务流程和产品构成是反映组织生产过程的重要信息。某个组织有哪些业务，其中主要业务是什么，其业务是如何开展的，业务与部门的关系如何，生产什么产品，产品的构成情况如何，产品的生产情况如何，产品的销售情况如何，业务与产品的关系如何等。
4. 基本数据与信息处理
基本数据是针对信息系统所要求的数据。其数据应是原始数据，主要是各种文件、档案和表(包括报表、凭证、单据、账等)。对数据要分类整理。要明确数据的基本构成、基本属性、数据与部门的关系等。信息处理指现有系统信息处理的情况及对新系统信息处理的要求，即各个部门输入什么信息，输出什么信息，信息处理要经过哪些步骤，信息处理的时间要求、处理频率及信息量等。
5. 管理方式和管理方法
管理方式和管理方法是指管理过程中的一些规章制度、措施、手段等。对于某个组织，主要涉及哪些管理，管理的层次如何，有哪些行之有效的方法等。如对于某个企业来说，有计划管理、生产管理、质量管理、设备管理、仓储管理、营销管理、客户关系管理、人力资源管理、财务管理、后勤管理等。
6. 决策方式和决策过程
管理的核心是决策。任何组织的决策方式和过程都是重要的，各级管理层都需要决策，特别是高层管理者。用信息系统辅助决策，是信息系统设计的主要目标。要了解现行系统的决策方式和过程，要认真听取中、高层决策者的需求，如经常做什么决策，决策过程中需要哪些信息，现行的决策过程中缺少哪些信息等。
7. 可用资源和限制条件
要详细了解组织内的可用资源，其资源的使用情况，有哪些限制条件，并登记造册。其资源包括涉及与开发新系统有关的人力资源、财力资源和物力资源等。新系统要充分利用现有资源，发挥现有资源的作用。通过详细的摸底，知晓开发新系统还缺少哪些资源，为预算做准备。
8. 现存问题和改进意见
要广泛收集用户对组织内和自己工作中的现存问题的看法和建议，对问题要进行梳理，征求多方面的想法，明确急需解决的问题，用户想解决而又解决不了必须靠信息系统来解决的问题，特别是通过开发新系统能改进现存的哪些问题等。实际工作时应视具体情况而定。
总之，详细调查就是要弄清处理对象现阶段工作的详细情况，为后面的分析设计工作做好准备。
5.3.3详细调查的方法
详细调查是一项烦琐而艰巨的工作，要求系统分析员在最短的时间内、花费最少的代价获取全面、准确、可信的资料。这不仅取决于系统分析员的素质，而且取决于详细调查的方法。
现实情况下，系统分析开始阶段，系统分析员与组织的管理人员沟通相当重要。尽管国家对信息化水平有较高的要求，各类管理人员对信息系统都有不同程度的了解，但如何把现实的工作信息化还不可能有清晰的思路。系统分析员熟悉信息技术，有信息系统开发的经验，但对组织内部的具体业务不够了解； 组织内的各类人员精通自己的具体业务，多数对信息系统的开发、管理工作的信息化的实现没有概念。因此，详细调查要成立由组织领导人员、业务人员、系统分析员和信息技术人员组成的调研组。调查必须得到组织内主要领导或者分管领导的支持，在条件允许的情况下，可以通过行政手段实施调研工作。
详细调查的方法主要有面谈、问卷调查、收集资料、考察或参加业务实践等。这几种方法可选择采用，可按序进行，也可同时进行。
1. 面谈
面谈是指系统分析员通过口头提问的方式收集信息，面谈可以用来实现下列目标： 发现事实，验证事实，澄清事实，激发热情，让最终用户参与，确定需求以及征求想法和观点。为了取得较好的面谈效果，应该尽量选择精通本职工作、经验丰富、善于表达的业务人员参与面谈，面谈前应该列出调查提纲，让面谈对象了解面谈的内容，以便事先做好充分准备。谈话提纲要体现以下几点。
(1) 用户背景。包括用户受教育的情况、计算机使用情况、使用系统人数情况、使用系统人数的变化情况。
(2) 系统背景。包括目前运行的系统的情况(主要包括不足和问题)，用户功能需求、性能需求、领域需求、其他需求，与系统相关的数据收集情况。
(3) 维护。包括将来系统的维护安排、系统服务、系统培训。
与企业不同层次的人员面谈，面谈的内容有很大的差异。例如，与企业高层管理者面谈主要涉及企业宏观管理，内容包括企业战略、经营目标、管理目标、对企业长期计划的考虑、经常做的决策，做决策时所需要的信息等； 与部门管理者面谈的主要内容涉及本部门的工作目标、对企业的贡献、业务范围、业务流程、与外部的联系、人员分工状况、存在的问题等； 与基层部门的业务人员面谈时，要注重业务细节、数据细节、日常工作、与其他工作人员的业务关系、业务处理中经常发生的异常情况等。在面谈过程中，应该自始至终围绕着需要了解的内容提问，提问要步步深入，面谈的内容要及时总结。
面谈分为个人面谈和会议讨论两种形式。
(1) 个人面谈法。个人面谈是最重要和最常用的调查研究技术。个人面谈通过直接、面对面的交互达到收集信息的目的。面谈的双方是分析员、用户以及系统领域专家。用户提供对系统功能、性能等方面的需求； 领域专家提供系统背景、领域需求等方面的知识。在访问前，为做到有的放矢，要弄清访问的对象及各自的访问内容，访问目的是要了解更具体的内容。这一过程是分析员调研需求的过程，也是分析员学习和掌握系统背景知识的过程，它保证了需求获取的正确性。
(2) 会议讨论法。会议讨论法指开发方通过和用户召开需求讨论会议，以彻底弄清系统开发项目需求的获取方法。会议则体现了用户群体的集思广益。对于系统的不同用户，由于操作流程的不同、使用功能的不同、对软件运行环境要求的不同，对系统的需求也不尽相同。会议讨论保证各方需求获取的完整性、一致性。另外，开会也是一个提高认识、统一思想、达成共识的过程。
Barry Boehm在1996年提出了一种称之为W5H2原则的方法，该方法是针对项目特征和项目计划而提出的，但对于需求获取来说，同样具有理论指导价值。
Why： 为什么要开发该系统？
What： 系统将要开发的功能是什么?
When： 什么时候开发?
Who： 系统由谁负责?系统会有哪些相关的人、事物或其他系统?
Where： 所开发的业务处于整个系统的什么位置?
How： 完成系统的开发目标技术上采用何种方法?管理上如何进行?
How much： 开发系统需要哪些资源?分别需要多少?
面谈和会议结束之后，需要有详细的记录。在交流过程中，分析员主要应学会倾听、标记模糊和有疑问的地方，以便进一步咨询。
2. 问卷调查法调查表
面谈法虽然能获取大部分需求，但对系统性能、特殊需求需要进一步了解时，会难以抓住问题的实质。问卷调查法是就用户需求中的一些个性化的、需要进一步明确的需求(或问题)，通过采用向用户发问卷调查表的方式来彻底弄清系统开发项目需求的一种方法。系统分析员给用户提供规范的问卷调查表，用户就能明晰问题的主旨，问卷尽量以选择和判断为主，少用问答形式。问卷调查法比较简单，侧重点明确，能够大大缩短需求获取的时间，减少需求获取的成本，提高工作效率。
3. 资料收集
当研究一个现有系统时，系统分析员可以通过研究现有文档、表和工作规程来收集事实，建立对该系统的感性认识。企业的工作规程通常以规章制度、流程规定、历史资料、工作标准等形式形成文件，作为企业工作的依据和准则。而在完成日常工作时涉及的完整表格、手册和计算机数据库的样本等，例如财务报表、库存表，是进行相关设计的重要依据。
4. 考察或参加业务实践
参加业务实践是系统开发者亲临业务部门，专门从事一段时间的业务工作，或者实地考察对类似问题有经验的公司，如果这些公司愿意共享信息，就有可能获得有价值的信息，了解自己所不熟悉的工作，节省开发过程中的大量时间和费用。例如，系统分析员通过观察柜台开票过程，了解销售人员的每一个动作和决策过程，进而了解销售人员是如何确定物品价格、销售数量，以及每联发货票是如何流转等。观察和参加业务实践虽然是获得第一手资料的主要方法，但这种方法效率低、难度大，一般只作为辅助调查的手段。
5.4组织结构与业务流程
5.4.1组织结构与功能分析
组织结构与功能分析是整个系统分析工作中最简单的一环。组织结构与功能分析主要有三部分内容： 组织结构分析、业务过程与组织结构之间的联系分析、业务功能一览表。其中，组织结构分析通常是通过组织结构图来实现，作为后续分析和设计之参考。业务过程与组织结构之间的联系分析通常是通过业务与组织关系图来实现，是利用系统调查中所掌握的资料着重反映业务过程与组织结构之间的关系，它是后续分析和设计新系统的基础。业务功能一览表是把组织内部各项业务功能都用一张表的方式罗列出来，它是今后进行功能数据分析，确定新系统拟实现的功能和分析、建立、管理数据指标体系的基础。
1. 组织结构图
企业的组织结构是根据企业目标设置并组织起来的，明确企业内部的部门划分及各部门的职能范围，有助于系统分析员明确拟开发的信息系统所处的环境、功能和目标。组织结构图是一张反映组织内部之间隶属关系的树状结构图。在绘制组织结构图时应注意，除了信息系统不涉及的部门外，其他部门一定要反映全面、准确。企业组织结构图实例如图54所示。
图54企业组织结构图实例
2. 业务过程与组织结构联系分析
组织结构图反映了组织内部和上下级关系，但是对于组织内部各部分之间的联系程度、组织各部分的主要业务职能和它们在业务过程中所承担的工作等却不能反映出来，这将会给后续的业务、数据分析等带来困难。为了弥补这方面的不足，通常增设组织/业务关系表来反映组织各部分在承担业务时的二者的联系，它是后续分析和设计新系统的基础。
组织/业务关系表中的横向表示各组织名称，纵向表示业务过程名称，中间栏填写组织在执行业务过程中的作用。以计划部为例，其主要业务是进行企业各类生产计划，以便对企业的生产，以及生产所需的各项原材料的采购起到指导性的意义，而计划的制订受制于企业的销售情况和生产能力，所以销售部和生产部对计划的制订有约束作用。组织/业务关系表如表51所示。
表51组织/业务关系表
计划
销售
采购
工资
财务
人力
设备
生产
计划
*
√
√
生产
√
√
√
*
销售
#
*
√
采购
#
*
#
#
…
其中，“*”表示该项业务是对应组织的主要业务(即主持工作的单位)； “#”表示该单位是参加协调该项业务的辅助单位； “√”表示该单位是该项业务的相关单位(或称有关单位)； 空格则表示该单位与对应业务无关。
3. 业务功能图
每个组织都有各自的业务目标，功能是以组织结构为背景进行调查，最后归纳系统各层次的功能结构。业务功能图是把组织内部各项业务功能都用树状结构表达出来，其目的在于描述组织内部各部分的业务和功能，它是今后进行功能数据分析、确定新系统拟实现的管理功能和分析建立管理数据指标体系的基础，销售管理系统的业务功能图实例如图55所示。
图55销售管理系统的业务功能图实例
5.4.2业务流程分析与建模
1. 业务流程分析的基本含义
业务流程分析是在业务功能的基础上将其细化，利用系统调查的资料将业务处理过程中的每一个步骤用一个完整的图形串起来。业务流程分析可以帮助系统分析员了解该业务的具体处理过程，发现和处理系统调査工作中的错误和疏漏，修改和删除原系统的不合理部分，在新系统基础上优化业务处理流程，所以说，绘制业务流程图是分析业务流程的重要步骤。
业务流程图(Transaction Flow Diagram，TFD)，就是用一些规定的符号及连线来表示某个具体业务处理过程。业务流程图基本上按照业务的实际处理步骤和过程绘制。换句话说，就是一“本”用图形方式来反映实际业务处理过程的“流水账”，绘制出这本“流水账”对于开发者理顺和优化业务过程是很有帮助的。
有关业务流程图的画法，目前尚不太统一，但大同小异，只是在一些具体的规定和所用的图形符号方面有些不同，而在准确明了地反映业务流程方面是非常一致的。
2. 业务流程图的绘制
1) 基本符号
业务流程图的基本图形符号非常简单，只有6个。有关6个符号的内容解释则可直接用文字标于图内，符号所代表的内容与信息系统最基本的处理功能一一对应。圆圈表示业务处理单位，方框表示业务处理功能描述，报表符号表示输出信息(报表、报告、文件、图形等)，加竖线的方框表示存储文件，卡片符号表示收集资料，矢量连线表示信息传递过程，如图56所示。
图56业务流程图的基本图形符号
2) 绘制业务流程图的一般步骤
由于业务流程图的图形符号简单明了，所以非常易于阅读，便于系统开发人员理解业务流程。它的不足之处是对于一些专业性较强的业务处理细节缺乏足够的表现手段，比较适用于反映事务处理类型的业务过程，绘制流程图步骤如图57所示。
图57绘制流程图步骤
业务流程图要能够表达输入、输出、处理以及相关数据文件。在绘制业务流程图时，一般以功能为中心，找出业务活动的主线，明确系统的边界和范围。对于功能比较复杂的企业，可以先绘制一个简单的业务流程总图，再按照自顶向下的方法分层分级地展开，直到描述清晰为止。
3. 业务流程分析的内容
业务流程分析的目的是分析现有系统中存在的问题，以便在新系统建设中予以解决或改进。
业务流程分析过程包括以下内容：
（1） 分析原有业务流程的各个处理过程是否有存在的价值，其中哪些过程可以删除或合并；
（2） 现有业务流程中哪些过程不合理，可以对其进行改进或优化；
（3） 现有业务流程中哪些过程存在冗余信息处理，可以按照信息处理的要求进行优化；
（4） 业务流程的优化可以带来什么好处；
（5） 新的业务流程中人与计算机的分工，即哪些工作可以由计算机自动完成，哪些工作必须有人的参与。
例如，固定资产管理根据实际业务处理的内容，可以分为日常卡片处理、财务核算和报表查询等部分，其业务流程图如图58所示。
图58固定资产管理业务流程图
业务流程图绘制完成后，要反复检查。首先，检查业务流程图的工作流程是否正确，是否有遗漏的部分。其次，检查业务流程图的一致性，即高层的业务流程图中出现的各类报表单证、数据存储等一定要在低层的业务流程图中反映出来，并标出相应的操作人员； 再检查低层业务流程图中存在的业务活动是否有输入和输出的数据载体。最后，检查各类名称的命名是否正确。
5.5数据流程图
5.5.1过程建模与数据流程图
任何计算机系统都可以看做一个转换函数F:(x1,x2,…,xm)→(y1,y2,…，yn)，其中X=(x1,x2,…,xm)是输入的数据向量，Y=(y1,y2,…，yn)是结果向量，转换函数F就是功能模型。功能模型是在抽象层次上，给出输入向量X在F中的传递、变换过程。对F的描述，是自顶向下、逐层分解，直至得到输出结果Y。图59描述了系统将要转换的外部实体，以及转换结果对应的外部实体。
图59软件系统的外部实体以及转换结果
数据流程图(Data Flowing Diagram，DFD)也称数据流图，是结构化建模中最流行的功能建模工具，是描述现行系统数据输入、数据输出、数据存储及数据处理之间关系的一种强有力的工具，也是与用户进行紧密配合的有效媒介。它用简明的、图形化的方式表达信息系统业务处理和数据流之间的关系，以至于在面向对象分析过程中也能见到它的身影。通过数据流程分析，既可以将原系统的业务流程特点和用户需求展露无遗，分析系统的数据流向及其相互调用关系，又可以为系统设计打下基础。
数据流程图的特点如下。
(1) 抽象性： 在数据流程图中，去掉具体的组织机构、工作场所、物资流动等，只剩下信息和数据的存储、流动、使用以及加工的情况，可以抽象地总结出信息处理的规律。
(2) 概括性： 它把系统对各种业务的处理过程联系起来考虑，形成一个总体，给出系统的全貌。无论手工操作部分还是计算机处理部分，都可以用它系统地表达出来。
5.5.2数据流程图的画法
1. 基本符号
数据流程图使用4种基本符号代表处理过程、数据流、数据存储和外部实体，用以表达数据在部门内、部门间或组织间的逻辑流向、逻辑加工和转换过程。数据流程图所用的符号形状有不同的版本，可以根据需要选择使用。常见的两个版本数据流程图图例如图510所示。
图510数据流程图图例
1) 处理过程
处理过程又称加工过程，实现数据变换操作，即把流向它的数据进行一定的变换处理，产生新的数据，表明不同数据是通过哪些功能完成的变换。不同处理过程的名称不同。处理过程的名称应该适当反映该处理的含义，使之容易理解。每个处理过程的编号说明该处理过程在层次分解中的位置。通过DFD的分层来分解，细化对数据的变换过程。
2) 外部实体
外部实体是指在所研究的系统外，独立于系统存在但又和系统有联系的实体，它可以是某个人员、某个企业、某一信息系统或某种事物，是系统的数据来源或数据去向，即数据源或外部系统。图例中要注明数据源或外部系统的名字。在不同层次的DFD图中，数据源是不能改变的。确定系统的外部实体，实际上就是明确系统与外部环境之间的界限，从而确定系统的范围。
3) 数据存储
数据存储不是指数据保存的物理存储介质，而是指数据存储的逻辑描述。数据存储的命名要适当，以便于用户理解。图例中要注明数据存储名字或编号，在DFD图中保存数据，数据结果既可以是临时文件，也可以是持久文件。
为了引用方便，除了名称外，数据存储还可以再加一个标识，一般用英文字母D和数字表示。为了避免数据流线条的交叉，如果在同一数据流程图中出现同样的数据存储，则可以在重复出现的数据存储符号前加一条竖线。
指向数据存储的箭头表示将数据保存到数据存储中，由数据存储发出的箭头表示从数据库中读取数据。数据存储可以在系统中起“邮政信箱”的作用，为了避免处理过程之间有直接的箭头联系，可以通过数据存储发生联系，这样可以提高每个处理过程的独立性，减少系统的重复性。
4) 数据流
数据流就是一束按照特定的方向从源点流到终点的数据，它指明了数据及其流动方向。数据流是有方向的，表明数据变换是可追溯的过程，如注册信息、票据、电话等。数据流箭头上必须给出数据流信息，用于说明数据加工之间的信息传递，它可以由某一个外部实体产生，也可以由处理过程或数据存储产生。要对每一条数据流进行简单的描述，以使用户和系统设计人员能够理解它的含义。
教学管理系统的数据流图如图511所示。
图511教学管理系统数据流图
2. 绘制数据流程图的过程
数据流程图的绘制必须遵循自顶向下、逐层分解的原则，这是控制问题复杂性的有效方法，也是对系统进行细化分析的基础。逐层分解的方式不是一开始就引入太多的细节，而是逐步增加细节，实现从抽象到具体的转化。最上层的DFD图称为顶层或0层DFD图，也被称为语境模型，因为它反映的是与系统交互的外部系统或用户，如图512所示。
图512顶层数据流程图
随着系统功能的逐步分解，DFD图也逐层细化。1层DFD图描述系统各部分(子系统)之间的数据转换关系，之后的各层DFD图被逐步层次化以描述更多细节。
下面以“固定资产管理系统”为例，讲解绘制数据流程图的基本过程。
(1) 确定系统的外部信息源、数据源或与外部系统的接口。
固定资产管理系统是一个独立运行系统，无须与外部其他系统有接口或数据关联。为了画出顶层数据流程图，必须先识别不受系统控制但影响系统的外部因素，进而确定系统的外部实体和系统的数据输入源和输出对象。此步骤是画出顶层数据流图的基础。
(2) 画出顶层(0层)DFD图。
顶层数据流程图描述了整个系统的作用范围，对系统的总体功能、输入和输出进行了抽象，反映了系统和环境之间的关系。
图513给出固定资产管理系统的顶层DFD图。这一顶层图说明系统用户只有“财务处”和“公司领导”，并且“财务处”输入资产卡片，系统运行后得到的综合统计报表给公司领导。
图513固定资产管理系统的顶层数据流程图
(3) 第一次精化： 划分系统的子系统。
进一步展开顶层数据流程图，将得到许多中间层数据流程图。中间层数据流程图描述了某个处理过程的分解层次，而其又会被进一步展开。中间层数据流程图的展开应遵循化复杂为简单的原则，但需要注意的是： 不能失去系统原有的特性、功能和目标，而且要始终保持系统的完整性和一致性。如果展开的数据流程图已经基本表达了系统所有的逻辑功能以及必要的输入和输出，而且处理过程已经足够简单，不需要再进一步分解，就得到了底层数据流程图。底层数据流程图所描述的都是无须分解的基本处理过程。
在第一次精化过程中，将固定资产管理系统分为三部分，日常卡片管理、财务管理、报表统计查询，该系统子系统划分的结果如图514所示，为固定资产管理系统的1层数据流图。
图514固定资产管理系统的1层数据流图
每次细化数据流图时，要先画出系统的输入数据流和输出数据流，也就是要先确定系统的边界，再画系统的内部。同样，对每个处理过程来说，也是先画出它们的输入数据流和输出数据流，再画出该处理过程的内部。
(4) 逐层求精： 对各子系统进一步精化。
在逐层求精过程中，将第1层DFD图中的各部分按照需求进一步细化，以反映数据在各部分中的转换过程。对日常卡片管理和财务管理的分层细化如图515、图516所示。
图515日常卡片管理数据流程图
图516财务管理数据流程图
实际上通过加工的编号，也能找到它们各自对应的细分流程。
绘制数据流图实际上是一种迭代的过程，通常不能一次成功，需要不断地完善，直到满意为止。通过迭代逐步明确了系统的处理过程、数据流的变换。这样，不仅明晰了用户需求，而且为后续结构化设计奠定了良好的基础。
3. DFD图各部分元素的命名和分层注意事项
DFD图中各部分元素的命名切忌用空洞的名词，这样不仅会给系统设计带来歧义，而且难以确定数据的结构和组织方式。命名时应遵循以下原则。
(1) 用名词或名词短语，避免使用空洞、无意义的词汇；
(2) 尽量使用需求描述中的已有词和领域术语；
(3) 命名困难时考虑数据流划分是否正确，并重获需求；
(4) 顶层DFD图中的加工名就是信息系统项目的名字；
(5) 分层DFD图中，数据存储一般局限在某一层或少数几层中。
在逐层细化DFD图时，还要注意以下几点。
(1) 图的平衡关系。父子图(上下层图)中的输入、输出必须保持一致，不能随意修改数据流。子图的数据流可以是对父图数据流的分解。如图517所示。
图517子图数据流对父图数据流图的分解
(2) DFD图的编号。DFD图中数据处理部分的编号按层次进行，体现对系统加工过程中自顶向下的分解。
(3) 平衡规则。所有子图中涉及的外部环境，需要与顶层图的外部环境保持一致。
5.6数据建模和分析
5.6.1什么是数据建模
企业在管理过程中会产生、使用大量的数据，信息系统通常用数据库技术进行信息系统的数据存储与管理。
数据库系统是面向计算机世界的，而应用是面向现实世界的，两者存在着很大差异，要直接将现实世界中的语义映射到计算机世界是十分困难的，因此要引入信息世界和数据世界作为现实世界通向计算机世界的桥梁。一方面，信息世界是经过人脑对这些事物的认识、选择、描述，从纷繁的现实世界中抽取出能够反映现实本质的概念和基本关系而形成的对现实世界的抽象； 另一方面，信息世界中的概念和关系要以一定的数据方式转换到计算机世界中去，最终在计算机系统上实现数据存储。
数据建模是对现实世界数据特征的抽象，也就是说，数据模型是用来描述数据、组织数据和对数据进行的操作。按照用户的观点对数据建模称为概念模型或信息模型，它给出了信息系统开发过程中与各部分设计有关的所有数据对象。
5.6.2ER图的基本画法
1976年，美籍华人陈品山提出实体关系(EntityRelationship，ER)模型，它是结构化建模的可视化图形工具，由于它是面向现实世界的，不受数据库管理系统的约束，而且易于理解，因此被广泛使用。
ER图有3个基本元素，即实体、属性和实体之间的联系。
1. 实体
实体是现实世界中对客观事物的描述，可以是人、物或者抽象的概念。信息系统中包含的大量数据、涉及的概念、术语等都可作为实体，例如部门、商品及其类别等，实体用矩形框表示，并且将对应的名称填入框内作为标识。
2. 属性
属性是实体所具有的特性。一个数据对象可以由若干个属性来刻画。例如，“学生”实体可以由学号、姓名、年龄、系、年级等属性来刻画，“简历”这一实体可以用编号、姓名、性别、年龄、专业、手机号、特长等属性描述。属性用椭圆形框表示，框内为具体的属性值，用无向边把实体与其属性连接起来，如图518所示。
图518ER模型中属性的表示
3. 实体之间的联系
在现实世界中，事物内部以及事物之间是有联系的，这些联系在信息世界中反映为数据对象(实体)内部的联系和数据对象(实体)之间的关系，如班级“包含”学生，“包含”就是两个实体的联系，也称关系。表明实体在关系上的数量约束则称为基数，如“1”个班级包含“m”个学生，“1”个学生属于“1”个班级，其中的m>0，1和m就是对应基数。在ER模型中，关系用菱形表示，它通常是一个动词或动宾短语，分别将参与联系的实体用线段连接，并标上联系的基数。
两类实体之间的联系可以分为三类。
(1) 一对一联系(1∶1)： 如果对于实体集A中的每一个实体，实体集B中至多有一个实体与之联系，反之亦然，则称实体集A与实体集B具有一对一联系，记为1∶1。
例如，学校里面一个班级只有一个正班长，而一个班长只在一个班中任职，则班级与班长之间具有一对一联系。
(2) 一对多联系(1∶n)： 如果对于实体集A中的每一个实体，实体集B中有n个实体(n≥0)与之联系，反之，对于实体集B中的每一个实体，实体集A中至多只有一个实体与之联系，则称实体集A与实体集B有一对多联系，记为1∶n关系。
例如，一个班级中有若干名学生，而每个学生只在一个班级中学习，则班级与学生之间具有一对多联系。
(3) 多对多联系(m∶n)： 如果对于实体集A中的每一个实体，实体集B中有m个实体(m≥0)与之联系，反之，对于实体集B中的每一个实体，实体集A中也有n个实体(n≥0)与之联系，则称实体集A与实体集B具有多对多联系，记为m∶n。
例如，一门课程同时有若干个学生选修，而一个学生可以同时选修多门课程，则课程与学生之间具有多对多联系。
实际上，一对一联系是一对多联系的特例，而一对多联系又是多对多联系的特例。可以用图形来表示两个实体之间的这三类联系，如图519所示。
图519两类实体间联系
实体之间的关系不局限于两者之间，也可以是三者或三者以上，关系也可以具有属性，如果一个关系具有属性，那么这些属性也要用无向边连接起来，实体内部的联系通常是指组成实体的各属性之间的联系，联系的属性表示如图520所示。
一个实体集内部也可以存在多种关系，例如员工内部存在某一个员工领导其他员工的关系，如图521所示为实体内部之间的1∶n联系，
图520联系的属性
图521实体内部之间的1∶n联系
学生选修课程的ER图如图522所示。
图522学生选修课程的ER图
图523为ER模型实例，它是一个信息系统的局部ER图，展现了仓库管理中部分功能所涉及的数据及其关系。
图523ER模型实例
5.7面向状态转换的行为建模
正如按下电梯的楼层按钮，电梯可以由静止变化到上行或下行，信息系统中的功能可以用状态的变化来描述，即行为建模，描述通过外部事件的触发，导致系统采取相应操作，系统状态的改变用状态转换图来描述。
状态转换图(Status Transition Diagram，STD)通过描述系统状态及引起状态转换的事件来表示系统行为。STD图同时也反映了事件执行的行为。STD图主要由状态、转换和事件的图形符号构成。
1. 状态
图524状态转换图基本图例
状态是任何可以被观察到的系统行为模式，是同一数据对象在系统的不同运行时刻所具有的行为属性值，是事件触发后一系列动作的结果。STD的元素符号如图524所示。
状态转换图既可以表示系统循环运行过程，也可以表示系统单程生命期。当描绘循环运行过程时，通常并不关心循环是怎样启动的。当描绘单程生命期时，需要标明初始状态(系统启动时进入初始状态)和最终状态(系统运行结束时到达最终状态)。
STD图中的状态主要分为初态、终态、中间状态。
(1) 初态： STD图的起点，一个STD图仅有一个初态，用实心圆表示。
(2) 终态： STD图的终点，一个STD图可以有多个终态，用一对同心圆(内圆为实心圆)表示。
(3) 中间状态： 是STD图中临时的，或永久的(存储过程)状态，它包括名字、状态变量和活动。中间状态用圆角矩形表示，可以用两条水平横线把它分成上、中、下3个部分。上面部分为状态的名称，这部分是必须有的； 中间部分为状态变量的名字和值，下面部分是活动表，这两部分是可选的，状态变量描述状态属性，活动是该状态转换到下一状态时要执行的事件或动作。
2. 状态转换
状态转换图中两个状态之间带箭头的连线称为状态转换，表示由一个状态转换到另一个状态的关联，箭头指明了转换方向，表明状态变换是有序变换过程见图525。状态转换通常是由事件触发的，在这种情况下应在表示状态转换的箭头线上标出触发转换的事件表达式； 如果在箭头线上未标明事件，则表示在源状态的内部活动执行完之后自动触发转换。
图525状态转换图
3. 事件
事件是指在某一时刻发生的事情，是触发状态转换的条件或一系列动作。在中间状态的符号中，活动即是事件。事件是引起系统做动作/状态转换的控制信息。
在活动表中经常使用下述3种标准事件： entry、exit和do。entry事件指定进入该状态的动作，exit事件指定退出该状态的动作，而do事件则指定在该状态下的动作。需要时可以为事件指定参数表。
为了具体说明怎样用状态转换图建立系统的行为模型，下面举一个电话系统的实例。没有人打电话时电话处于闲置状态； 有人拿起听筒则进入拨号音状态，到达这个状态后，电话的行为是响起拨号音并计时； 如果拿起听筒的人改变主意不想打了，他把听筒放下(挂断)，电话重又回到闲置状态； 如果拿起听筒很长时间不拨号(超时)，则进入超时状态。如图526所示为电话系统的状态转换图。
图526电话系统状态转换图
5.8数 据 字 典
数据字典(Data Dictionary，DD)以结构化方式为在数据建模、功能建模和行为建模等过程中涉及的所有数据信息、控制信息做出详细的说明。它是系统所有相关人员对信息达成的一致的理解，是数据分析和数据管理的重要工具，是系统设计阶段进行数据库(文件)设计的参考依据。
数据字典的内容主要是对数据流程中的数据项、数据结构、数据流、处理逻辑、数据存储和外部实体等六个方面进行具体的定义，是随着数据流图自顶向下、逐层扩展而不断充实的，并保持数据字典和各类建模用图的一致性和完整性。
DD的定义形式多种多样，本节介绍词条描述和定义式。
5.8.1词条描述
词条描述详细说明了数据和控制信息在系统内的传播途径。包括以下词条信息。
1. 数据项(数据元素)
数据项又称数据元素，是不可再分的最小数据单位。在数据字典中，仅定义数据的静态特性，具体包括： ①数据项的名称、编号、别名和简述； ②数据项的长度； ③数据项的取值范围。
材料编号的数据项词条描述实例如表52所示。
表52数据项词条描述实例
数据项编号
ID201
数据项名称
材料编号
别名
材料编码
简述
某种材料的代码
类型及宽度
字符型，4位
取值范围
"0001"~"9999"
2. 数据结构
数据结构描述某些数据项之间的关系。一个数据结构可以由若干个数据项组成，也可以由若干个数据结构组成，还可以由若干个数据项和数据结构组成。
数据字典中对数据结构的定义包括数据结构的名称和编号、简述、数据结构的组成。如果是一个简单的数据结构，只要列出它所包含的数据项。如果是一个嵌套的数据结构(即数据结构中包含数据结构)则需列出它所包含的数据结构的名称，因为这些被包含的数据结构在数据字典的其他部分已有定义。用户订货单数据结构词条描述如表53所示。
表53数据结构词条描述实例
系统名进销存系统
数据结构名称用户订货单
数据结构编号DS03—01
简述用户所填用户情况及订货要求等信息
数据结构组成DS0302+DS0303+DS0304
备注DS0302、DS0303、DS0304是已经事先定义的数据结构
3. 数据流
数据流由一个或一组固定的数据项组成。定义数据流时，不仅要说明数据流的名称、组成等，还应指明它的来源、去向和数据流量等。入库单数据流词条描述如表54所示。
表54数据流词条描述实例
系统名
进销存系统
数据流名称
入库单
数据流编号
DS03—01
简述
车间开出的产品入库单
数据流来源
车间
数据流去向
库单审核模块
数据结构组成
入库单编号+日期+产品代码+产品名称+入库数量+单价+入库金额+单位+入库车间+经手人
数据流量
约30张/日
高峰流量
约50张/日
4. 数据处理
数据流程图中最底层的处理逻辑应该包括处理过程的名称、编号、简述、输入的数据流，处理过程仅对数据流程图中最底层的处理逻辑加以说明。计算电费数据处理词条描述如表55所示。
表55数据处理词条描述实例
系统名
成本计算
数据处理名称
计算电费
数据处理编号
P02—03
简述
计算应缴纳的电费
输入的数据流
数据流电费价格，来源于数据存储文件价格表； 数据流电量和用户类别，来源于处理逻辑“读电表数字处理”和数据存储“用户文件”
处理
根据数据流“用电量”和“用户信息”，检索用户文件，确定该用户类别； 再根据已确定的该用户类别，检索数据存储价格表文件，以确定该用户的收费标准，得到单价； 用单价和用电量相乘得该用户应缴纳的电费
数据结构组成
入库单编号+日期+产品代码+产品名称+入库数量+单价+入库金额+单位+入库车间+经手人
输出的数据流
数据流“电费”一是去外部项用户，二是写入数据存储用户电费账目文件
处理频率
对每个用户每月处理一次
5. 数据存储
数据存储指数据结构暂存或被永久保存的地方。在数据字典中，只能对数据存储从逻辑上加以简单的描述，不涉及具体的设计和组织。它包括： 数据存储的名称、数据存储编号、简述、组成及关键字等。数据存储在数据字典中只描述数据的逻辑存储结构，而不涉及它的物理组织。库存台账数据存储词条描述如表56所示。
表56数据存储词条描述实例
系统名
进销存系统
数据存储名称
库存台账
数据存储编号
F—01
简述
记录产品出入库数据的明细账
组成
日期＋产品代码＋产品名称＋入库数量＋零售数量＋批发数量＋库存数量
关键字日期＋产品代码
相关联的处理
P—02，P—03，P—04
6. 外部实体
外部实体是与数据有关的机构或个人，包括外部实体的名称、对外部实体的简述及有关的数据流等。车间外部实体的词条描述如表57所示。
表57外部实体词条描述实例
系统名
进销存系统
外部实体名称
车间
外部实体编号
S—01
简述
生产产品入库
输入的数据流
D—03
输出的数据流
D—01
编写数据字典是系统开发的一项重要的基础工作。一旦建立，并按编号排序之后，就是一本可供查阅的关于数据的字典，从系统分析一直到系统设计和实施都要使用它。在数据字典的建立、修正和补充过程中，始终要注意保证数据的一致性和完整性。
数据字典可以用人工建立卡片的办法来管理，也可存储在计算机中，用一个数据字典软件来管理。
从上述实例中可以看到，词条描述方法灵活可变，可以根据不同领域的词条特征来确定其需要定义的属性和描述逻辑。
5.8.2定义式
如果定义的数据或控制信息具有良好的数据结构，可借助巴科斯诺尔范式(BackusNaur Form，BNF)来清晰、准确、无二义性地定义数据。表58给出了数据字典定义式中的符号及其意义。
表58数据字典定义式中的符号意义
符号
含义
解释
=
被定义为
+
与
例如，x=a+b，表示x由a和b组成
［…，…］
或
例如，x=［a，b］，表示x由a或由b组成
［…|…］
或
例如，x= ［a| b］，表示x由a或由b组成
{…}
重复
例如，x={a}，表示x由0个或多个a组成
m{…}n
重复
例如，x=3{a}8，表示x中至少出现3次a，至多出现8次a
(…)
可选
例如，x=(a)，表示a可在x中出现，也可不出现
“…”
基本数据元素
例如，x=“a”，表示x为取值为a的数据元素
..
连接符
例如，x=1..9，表示x可取1到9之中的任一值
例如，银行存折的部分数据的定义式如下。
存折=户名+所号+账户+开户日+(印密)+1{存取行}50
户名=2 {字母} 24
所号=“001”..“999”
账号=“00000001”..“99999999”
开户日=年+月+日
5.9系统分析报告
5.9.1信息系统分析报告的作用
系统分析报告(或称为系统分析说明书)是在信息系统分析阶段工作结束后，由系统分析员编写的，它反映了这一阶段详细调查分析的全部情况，是系统分析阶段的最重要的文档。它把信息系统分析阶段产生的各种资料汇总起来，表达信息系统分析阶段的设计思想、设计依据以及所产生的逻辑设计方案。信息系统分析报告是系统分析员的工作成果，可以用它与用户交流，也是下一步系统设计与实现的纲领性文件。此外，系统分析说明书还可用来作为评价项目成功与否的标准，除非发现开发人员对系统的认识有比较重大的遗漏或误解，否则用户和开发小组都不能随意更改。
5.9.2信息系统分析报告的内容
信息系统分析报告是基于详细调查基础上的信息系统逻辑模型设计报告。信息系统分析报告可以采用文字报告加上图表附录的形式，也可以采用文字和图表穿插的形式。系统分析报告的内容要求如图527所示。
图527系统分析报告的内容要求
系统分析报告形成后，必须组织各方面人员，包括单位领导、管理人员、专业技术人员、系统分析人员等，对系统分析报告进行审查，尽可能地发现其中的问题、误解和疏漏，并及时纠正。对于有争论的问题，则要重新核实原始调査资料或进一步深入调查、研究，对于重大的问题，甚至可能需要调整修改系统目标，重新进行系统分析。
由于信息系统开发周期较长，阅读信息系统分析报告时，必须注意环境变化所引起的资料内容与当前事实的差异，这也是信息系统开发生命周期法的缺点。
本 章 小 结
系统分析是信息系统开发中的重要阶段，本章重点论述了信息系统分析的任务、要求、步骤和方法。通过详细调查，对企业现有系统进行描述和分析，提出新系统的逻辑方案。系统分析的本质是通过对现有系统的描述和分析，回答未来系统“要做什么”的问题。
系统分析阶段需要进行系统的可行性分析，综合考虑经济、技术、社会等多方面因素，只有在明确系统开发的可行性和必要性之后，才能对现行系统做深入而详细的调查，了解现行系统的组织结构、业务流程、功能体系、信息要素、管理方式、决策过程、资源条件和存在问题，彻底分析组织内部的管理状况和相应的信息处理过程。本章以结构化系统分析为主，介绍了信息系统分析阶段各项具体工作，详细阐述了多种逻辑模型的构成，包括基于业务过程的业务流程图、基于功能建模的数据流程图、基于数据建模的实体联系图、基于行为建模的状态转换图，最后讲解了数据字典及其多种定义形式。
系统分析阶段的成果是系统分析报告，该报告反映了系统分析的结果和对新系统的设想，是下一步进行系统设计和系统实施的依据。
本 章 练 习
1. 问题思考
(1) 系统分析的主要任务是什么？
(2) 为什么说系统分析是信息系统开发过程中最重要的一环？
(3) 详细调查的范围有哪些？
(4) 什么是数据流图？用数据流图描述储蓄存款的过程。
(5) 用什么模型工具进行数据建模？它的基本元素有哪些？如何表达？
(6) 什么是行为建模？它有哪些基本要素？
(7) 什么是数据字典？它有哪些基本内容？
(8) 可行性分析的目的是什么？其主要内容是什么？
(9) 系统分析报告包括哪些内容？
2. 专题讨论
(1) 列一份针对企业营销推广方案的调研提纲。
(2) 去某公司考察，画出企业的组织结构、业务功能、数据流程图。