|
|
|
|
|
信息需求分析也叫用户需求分析，这也许是系统分析中最困难的任务，是确定满足所选择方案的特定的信息需求。它是许多大型信息系统花费精力最多的领域。一个信息系统的信息需求至少应该包括：谁、在什么地方、什么时间、用什么方式、需要什么信息等。需求分析要仔细地定义出新系统的目标，要详尽地描述出新系统必须完成的各项功能，还要考虑经济的、技术的以及时间上的各种约束，当然还不能忽略组织原有的目标、业务过程和决策过程。错误的需求分析是导致系统失败以及系统开销过高的主要原因。依据错误的需求分析所设计的系统要么因性能差而不得不放弃，要么就需大幅度地修正。因此，需求分析的重要性绝不能轻视。
|
|
|
|
因此，开发大型信息系统的关键之一是能否对原系统和其所属的组织有一个彻底的理解，这是系统分析员在系统分析阶段的主要任务，而这一任务的圆满完成必须有包括系统运行管理人员在内的系统用户的大力支持和全面配合。
|
|
|
|
信息系统规模越大，系统分析工作就越复杂，这些分析工作不仅涉及复杂的技术背景，而且涉及复杂的组织管理背景，进行系统开发的计算机专业技术人员和系统运行与管理人员由于专业背景不同，而往往在信息交流方面存在巨大困难。因此专业的系统分析员是系统分析工作的主持者和主要承担者，他要担任系统运行与管理人员（即用户）和计算机技术人员之间的桥梁。
|
|
|
|
同时，在这一阶段中，系统用户也必须充分参与和配合系统分析人员以及计算机技术人员的分析工作。这主要是因为信息系统分析工作中的信息需求分析涉及面广，不确定性因素多，而且主要是面向组织的管理问题，分析工作的方式主要是调查和协商，就是要与直接或间接使用该系统的人打交道。系统分析就是要明确信息系统在支持组织的管理与决策方面要解决什么问题，因而必须对信息系统进行描述。由于信息系统是以人为主体的系统，人的思想与行为，如决策过程、信息需求的描述是系统分析的主要困难之一。必须综合运用定性、定量分析方法和有关知识与经验，对组织行为和管理决策过程进行科学分析，对各级各类管理人员的信息需求进行深入了解。在系统分析工作中，大量的工作是需要各级、各类管理人员和进行系统开发的系统分析员以及计算机技术人员进行联系和交流，这是明确问题，获取信息需求的主要方式。在系统分析工作中一般会涉及的系统用户主要包括：
|
|
|
|
|
|
|
|
（3）信息系统用户单位中主管信息管理工作的高层负责人，例如首席信息官（CIO）、主管信息工作的副总经理、信息中心主任等等；
|
|
|
|
（4）具体负责运行、维护信息系统的管理人员、技术人员和操作人员。
|
|
|
|
这些人员往往具有不同的专业背景、利益与习惯，因此在与系统分析人员和计算机技术人员的交流和协调以及它们之间的交流与协调过程中往往造成困难与冲突。因此，必须作为系统用户必须要与各类人员建立相互理解与信任的关系，善解人意，并努力促进人与人之间的相互理解、交流和协调。这是保证系统分析工作，进而保证整个信息系统建设工作能够比较顺利、圆满完成的重要因素。
|
|
|
|
|
|
|
|
系统分析工作中需要用户提供的信息大致可以分为4类：关于组织的信息、关于人的信息、关于业务工作的信息和关于工作环境的信息。
|
|
|
|
|
|
组织的使命、目标和发展战略。具体来说，就是关于组织的使命、宗旨的总陈述，组织在未来若干年（比如5—7年内）的发展方向与目标，为实现组织整体和长远目标而制定的发展战略与主要措施。一般在大、中型组织中都有相应的正规文件、资料记载这方面的情况，而对于某些中小组织和正在进行重大调整和改革的组织，就需要由组织的现任主要决策者予以提供这类信息。
|
|
|
|
组织的结构。组织结构的信息反映了组织内部的管理体制、职能分配和各管理部门、层次之间的关系。信息系统是为实现组织的目标服务的，了解组织结构问题的重点在于组织目标与结构的关系。如果现有组织在支持组织的整体目标方面存在矛盾与冲突，就必须收集相关信息以明确问题所在。一般的组织都有组织结构图等相关资料，如果没有或资料已经过时而不符合实际情况，就必须进行修改或重建。
|
|
|
|
职能部门的目标与宗旨。职能部门是整个组织的子系统。各个班组、科室、处、部以及其固定的和临时的下属组织都有其自己的目标和宗旨。在实际情况中，往往这些下属组织的目标与宗旨并不与组织的整体目标相一致，因此，必须明确了解这些职能部门的目标是怎样符合或不符合整个组织目标的，只有对组织结构有较为深入的了解才能更好地认识系统中各类信息的内容和流向。有关职能部门的这类信息一般应该由各级职能部门的负责人予以提供。
|
|
|
|
规章制度与政策。这些资料能够反映一个组织进行业务活动的规则与指导方针，信息系统应该贯彻执行这些规章制度与政策。在实际情况中，明文规定的和实际执行的规章制度与政策可能会有所差别，因此，需要由具体负责运行、维护信息系统的管理人员、技术人员和操作人员予以提供并解释这类信息。
|
|
|
|
|
|
权利与责任。这类信息可以从组织结构图和某些正式的组织文件中体现出来一些，但往往实际的工作关系与组织结构图和文件上的规定有所差别，在某些问题的实际决策者可能与形式上的职务并不相同，而与具体的人的情况、传统和环境有着很大关系。有时这类信息可能需要保密，但必须要提供给系统建设的主要负责人，否则建立的系统就不可能反映管理者的实际需要。
|
|
|
|
岗位任务。主要是指在组织的业务工作进行过程中，每个人实际在做什么。因此系统用户除了要提供各项描述业务工作内容的文件，还要说明各种岗位的实际工作情况。
|
|
|
|
人际关系。主要是指反映了一个组织内部人们在工作中处于何种关系，如何相互协调与配合。由于在实际工作中，任何组织都有非正式的组织和人与人之间的联系渠道，信息的实际传递途径可能与组织结构图上所描述的并不一致。系统用户需要说明相关的实际情况，以促进新建信息系统对组织发展与业务工作的优化，保留合理的人际交流，消除不合理、容易引发混乱和失误的问题。
|
|
|
|
信息需求。系统用户要提供每个人、每个工作岗位的信息需求给系统分析人员，使之能够了解系统所涉及的每个人、每个岗位需要哪些信息以及目前实际能够得到哪些信息，为以后系统数据流图的建立与分析提供依据。系统用户应该帮助系统分析人员评价出哪些是必要的信息，哪些是无用的信息。
|
|
|
|
|
|
任务和工作流程。主要是指现有系统的业务处理的全过程，有关数据资料在系统中传递与变换的步骤和每一步的任务，特别是在上述过程与步骤中数据的结构和内容的变化。
|
|
|
|
进行工作的方法与程序。主要是指每个工作岗位做些什么，由哪些人做，使用什么设备，遵循什么规则，业务的作业如何安排。关于任务和工作流程的信息集中描述数据形式与内容，而这里集中描述行为和程序。
|
|
|
|
工作安排和工作量。主要是指在给定时间内完成多少工作，说明工作的高峰期和低谷期。
|
|
|
|
绩效准则。主要是指工作评价标准，这些标准不只是用于计划进度和工作量，而且包括质量、可靠性、准确性以及其他信息处理工作希望得到的指标。可以在现有系统中设置某些检测点或控制点，以了解系统表现并按特定准则进行评价。
|
|
|
|
|
|
主要是指工作场地的设施布局方面的信息与文件、表格、传输数据和人员在工作场地的设置和流动情况以及可用的公共设施、专用仪器设备等资源。
|
|
|
|
需要说明的是，以上只是对系统分析所需信息类型的一般性描述，并不是在每种情况下都要提供上述所有类型的信息，哪些方面的信息是要提供的重点内容，应该根据系统开发的目标和现有系统的实际情况而定。
|
|
|
|
|
|
（1）提供现有文件，包括组织结构图、规章制度与政策、工作方法与程序等有关手册、岗位说明、各类表格与报告、文件处理流程与工作流程图、现有系统流程图、现有信息系统的计算机程序文档、数据字典、计算机操作手册等。
|
|
|
|
（2）采取面谈的方式，即与信息系统分析人员直接面对面交谈来提供有关信息。面谈是和系统开发人员交流思想的好方法，它有助于双方建立相互信任的良好关系。面谈一般适合提供一些定性信息，而不太适合提供定量信息。可以考虑采取开调查会的方式，约定一个大多数用户都空闲的时间，通过大家的讨论互相补充所提供的信息内容。面谈的缺点是容易受到用户自身素质与工作性质的影响，可能有些用户不愿意当面发表自己的意见，或者由于交谈时间比较短，或者由于受条件限制无法多次面谈等原因，而使得面谈所提供的信息精确度较差。面谈可以采取两种方式：第一，自由式交谈，即自由提问和回答的方式；第二，结构式交谈，即按照事先准备的谈话提纲进行交谈，这种方式可以对给定问题提供较为可靠的回答，问题可以分层次。
|
|
|
|
（3）回答系统分析人员所提供的调查问卷。先由系统分析人员把需要调查的内容制成问卷式表格，然后由系统用户进行填写。调查表一般包括自由式和选择式两种，对于前者用户可以对所调查的问题进行自由回答，一般适用于中层管理干部对定性问题的回答；对于后者用户需要从几种备选答案中选择合适的答案，一般适用于具体工作人员或基层干部对哪些过程简单、规程清晰的业务问题做出回答。
|
|
|
|
（4）引导系统分析人员进行实地观察与实践，即带领系统分析员或计算机技术人员直接观察或参加现行系统的业务实践。这种方式有助于缩短用户与开发人员的距离，取得共同语言，提供的信息也比较准确、可靠，但是花费时间太多，而且有些业务不可能让系统分析人员亲自观察和动手操作。
|
|
|
|
|
|
当系统分析员建立好系统逻辑模型后，系统用户要承担对该模型的评价任务。评价的主要内部包括：第一，建立的系统逻辑模型是否全面准确地反映了组织对信息系统的整体目标与功能的要求；第二，建立的系统逻辑模型是否反映了各级人员的具体的信息需求。在评价过程中，系统用户进行逻辑模型评价的方式主要是，和系统分析人员就系统逻辑模型充分的交换意见，反复讨论，并进一步提出用户的意见和建议，并必须最终使用户和系统分析人员对系统的逻辑功能达成共识。在此过程中，一定要遵循用户直接参与的原则，这是系统分析工作成功的关键，也是今后系统设计与实施阶段用户与系统建设的其他人员相互支持与配合的基础。
|
|
|
|
在对系统逻辑模型进行评价的过程中，系统用户应该明确一个原则，就是系统分析工作追求的是有限目标。在信息系统建设中，由于用户单位各部门各类人员的信息需求和目标的多样性，往往造成有些目标和需求不一致，甚至相互冲突。例如，在工业生产企业中，生产部门常常希望销售部门能够尽早提供比较准确的产品市场需求信息，以便对产品的生产制定合理的安排，而销售部门则希望生产部门跟踪市场的变化来及时调整生产计划。而且，信息系统的建设是长期任务，不是一次项目开发就能够全部完成的。因此，在一次系统开发中，系统分析工作实现的目标是有限的，不可能把现有系统中所有问题都提出来，更不可能全部都去解决。一次系统开发只能满足用户的部分信息需求，做到各个相关用户大体满意，其他问题需要留待后续的系统开发项目再解决。所以，在系统分析中，既要明确本次系统开发项目要集中力量解决哪些问题，即“做什么”，也要清醒地认识这次开发中哪些问题暂时不去解决，即“不做什么”，明确系统开发任务的边界。信息系统各部分之间联系密切，如果系统开发的边界不明确，就可能造成系统开发任务在开发过程中不断扩展而使得主要任务难以完成。
|
|
|
|
系统用户还应该理解，所有软件功能都是有成本的，业务人员所希望的某些软件特性可能在技术上行不通，或者实现它需要付出极高的代价，而某些需求则是在试图达到在操作环境中不可能达到的性能，或试图得到一些根本得不到的数据。此外，有些问题并不需要一个信息系统的解决方案，而是需要做一些管理上的调整，或者是做一些附加的培训，或者是对当前组织进行精简。
|
|
|
