第5章系统分析概述 系统分析是应用系统思想和方法，把复杂的对象分解成简单的组成部分，找出这些部分的基本属性和彼此间的关系。 本章对系统分析阶段的任务、方法和工具进行概述。这一阶段产生的系统说明书(需求规格说明书)，既是后续开发工作的依据，也是衡量一个信息系统优劣的依据。系统分析是系统开发中最重要、也是最困难的阶段。结构化系统分析方法及数据流图、数据字典，面向对象系统分析方法及UML模型等工具是克服困难的有力武器。 5.1系统分析的任务 系统分析阶段的基本任务是： 系统分析师(system analyst，SA)与用户在一起，充分了解用户的要求，并把双方的理解用系统说明书表达出来。系统说明书审核通过之后，将成为系统设计的依据，也是将来验收系统的依据。 拟建的信息系统既要源于原系统，又要高于原系统。所谓“高于原系统”，就是要比现行系统功能更强，效率更高，使用更方便。但新系统不是无源之水，无本之木。“源”就是现行信息系统。因此系统分析师要在总体规划的基础上，与用户密切配合，用系统的思想和方法，对企业的业务活动进行全面的调查分析，详细掌握有关的工作流程，收集票据、账单、报表等资料，分析现行系统的局限性和不足之处，找出制约现行系统的“瓶颈”，确定新系统的逻辑功能，根据企业的条件，找出几种可行的解决方案，分析比较这些方案的投资和可能的收益。 1. 系统分析的困难 系统分析是研制信息系统最重要的阶段，也是最困难的阶段。 系统分析要回答新系统“做什么”这个关键性的问题。只有明确了问题，才有可能解决问题。否则，方向不明，无的放矢，费力不讨好。实际工作中常常有这种情形，即业务人员认为信息系统的开发只是技术人员的事，开发人员根据对用户要求的肤浅理解匆匆忙忙进行系统设计，编写程序。交给用户使用时，用户说“这不是我要的系统”。对系统分析缺乏足够的重视，是导致研制工期一再延长甚至以失败告终的重要原因，也是系统分析难于进行的主观原因。 系统分析的困难主要来自三个方面： 对问题空间的理解、人与人之间的沟通和环境的不断变化。 由于系统分析师缺乏足够的对象系统的业务知识，在系统调查中往往感到无从下手，不知道该问用户一些什么问题，或者被各种具体数字、大量的资料、庞杂的业务流程搞得眼花缭乱。一个规模较大的系统，有反映各种业务情况的数据、报表、账页，业务人员手中各种正规的、非正规的手册，技术资料等，数量相当大，各种业务之间的联系繁杂。不熟悉业务情况的系统分析师往往感到好像处在不见天日的大森林中，各种信息流程像一堆乱麻，不知如何理出头绪，更谈不上如何分析制约现系统的“瓶颈”。 另一方面，用户往往缺乏计算机方面的足够知识，不了解计算机能做什么和不能做什么。许多用户虽然精通自己的业务，但往往不善于把业务过程明确地表达出来，不知道该给系统分析师介绍些什么。对一些具体的业务，他认为理所当然就该这样或那样做。尤其是对于某些决策问题，根据他的经验，凭直觉就应该这样或那样做。在这种情况下，系统分析师很难从业务人员那里获得充分有用的信息。 俗话说“隔行如隔山”。系统分析师与用户的知识构成和经历不同，使双方的交流变得困难，因而系统调查容易出现遗漏和误解，这些误解和遗漏是研制系统的隐患，会使系统开发偏离正确方向，另外还使编写系统说明书变得十分困难。系统说明书是这一阶段工作的结晶，它实际上是用户与系统研发人员之间的技术合同。作为设计基础和验收依据，系统说明书应当严谨准确，无二义性，尽可能详尽； 作为技术人员与用户之间的交流工具，它应当简单明确，尽量不用技术上的专业术语。这些要求是不容易达到的，但必须努力达到。 最使系统分析师困惑的是环境的变化。系统分析阶段要通过调查分析，抽象出新系统的概念模型，锁定系统边界、功能、处理过程和信息结构，为系统设计奠定基础。但是，信息系统生存在不断变化的环境中，环境对它不断提出新的要求。只有适应这些要求，信息系统才能生存下去。在系统分析阶段，要完全确定系统模式是困难的，有时甚至是办不到的。 2. 系统分析师的素质要求 在系统开发中，系统分析师起着十分重要的作用。系统分析这一重要而困难的任务主要由系统分析师承担。他要与各类人员打交道，是用户和技术人员之间的桥梁和“翻译”，并为管理者提供控制开发的手段。系统分析师还必须考虑系统的硬件设备、数据输入、系统安全等各个方面。总之，系统分析师必须考虑系统的各种成分。 系统分析师的知识水平和工作能力决定了系统的成败。一个称职的系统分析师不但应具备坚实的信息系统知识，了解计算机技术的发展，而且还必须具备管理科学的知识。缺乏必要的管理科学知识，就没有与各级管理人员打交道的“共同语言”。很难设想缺乏财务基础知识的人能设计出实用的财务系统。系统分析师应有较强的系统观点和较好的逻辑分析能力，能够从复杂的事物中抽象出系统模型。他还应具备较好的口头和书面表达能力，较强的组织能力，善于与人共事。总之，系统分析师应是具有现代科学知识的，具有改革思想和改革能力的专家。 为了克服这些困难，做好系统分析工作，需要系统分析师与用户精诚合作。系统分析师应牢固树立“用户第一”的思想，虚心向用户学习。虽然隔行如隔山，但“隔行不隔理”。这个“理”就是人们认识事物的共同规律，就是系统的思想与方法，这是我们分析复杂事物的有力武器。系统论的思想方法强调系统的整体性、综合性、层次性，强调系统元素之间的有机联系。这也就是我们常说的要全面地看问题，认识事物要由表及里、去伪存真，要从事物之间的联系去认识事物，而不要孤立地看待事物。不论技术人员与用户的业务有多大差距，人们认识事物的方法都是相通的。如果说隔行如隔山，那么根据这个原理，就可以在这座“山”中打一个“隧道”，使两边相通。为此，还要有一定的技术和工具。这里说的工具是指一些合理的图表。直观的图表模型可以帮助系统分析师理顺思路，也便于与用户交流。本书第6~8章将讨论系统分析阶段要用到的模型及建模方法。 3. 产品经理 还有一个与系统分析师有相似职责的角色是产品经理(product manager)。产品经理的提出源自于宝洁公司(P&G)。20世纪20年代宝洁推出了一款叫作佳美(CAMAY)的香皂品牌，但销售业绩较差。宝洁公司员工麦吉利提出销售人员不应将精力同时集中到多个品牌中，而是应该把每一个宝洁品牌都当作一项独立的事业去经营，应为品牌配备专门的产品人员、销售人员等给予支持，品牌之间形成竞争。麦吉利的想法得到公司高层支持，他被认为是最早的产品经理。当时的产品经理负责品牌建设、市场销售等几乎所有事情，这种产品管理模式赢得了巨大成功。 从传统行业到软件行业，产品管理模式得到应用和推广。尤其在互联网蓬勃发展的这二十多年，互联网软件创新层出不穷，越来越多地引入产品管理制度，产品经理的职责也随之变化以适应IT行业的需要。在IT行业，苹果公司创始人史蒂夫·乔布斯(Steve Jobs)被公认为最伟大的产品经理。为了区别于传统行业的名称，这一角色称为“IT产品经理”，大多数情况下又专指软件类产品。 IT产品经理的职责主要包含以下五个方面。 (1) 市场调研。市场调研是指研究市场以了解客户需求、竞争状况及市场压力，发现创新或改进产品的潜在机会，形成商业机会、产品战略或商业需求文档。 (2) 产品需求定义及设计。通常采用产品需求文档描述产品需要做哪些事情，一般包含产品愿景、目标市场、产品功能的详细描述、功能优先级排序、产品用例、系统及性能需求、销售及支持需求等。产品设计主要包含产品外观，如用户界面设计和交互设计。 (3) 项目管理。带领来自不同团队人员在预算、进度等约束条件下按时开发并发布产品。 (4) 产品宣传与市场。 (5) 产品生命周期管理。包括产品定位、产品定价及市场、产品线管理、用户数据分析、竞争策略、渠道拓展、合作伙伴管理等。 通过以上描述可知，产品经理与系统分析师的职责有很大的重合，同时产品经理还承担了系统设计师的部分任务。 5.2系统分析的过程和方法 系统分析是分析领域业务和建立新系统逻辑模型的过程。系统分析的全过程如图5.1 所示。整个过程划分为三个阶段： 问题分析阶段； 需求分析阶段； 需求定义阶段。 图5.1系统分析全过程 5.2.1问题分析 问题分析是系统分析的起点，通过详细调查全面深入理解用户的业务，找出用户所面临的问题，准确把握用户真正的需要，为最终整理出符合用户需要的需求做准备。 1. 问题分析的步骤 问题分析实质上就是需求调研，需要从各种渠道收集大量资料和信息，从而获得对业务系统的理解并获得系统原始需求，这些原始需求是进行需求分析并建立系统逻辑模型的基础。 问题分析的过程可按如下操作。 (1) 需要明确项目的背景。要回答这些问题： 为什么会有这个项目？用户为什么想做这个项目？如果没有这个项目会怎样？ (2) 在了解背景的基础上，需要进一步了解以下五点内容。 ① 本项目解决了用户的什么问题？ ② 本项目涉及什么人、什么单位？ ③ 本项目的目标是什么？ ④ 本项目的范围是什么？ ⑤ 本项目的成功标准是什么？ (3) 找出关键涉众(stakeholder，也称利益相关人员)及待解决的问题。系统需求的主要来源是系统的各种相关者，他们是对系统成功感兴趣的所有人。涉众分为以下四类人员。 ① 系统的用户，即使用系统的人； ② 对该系统的建设有决策权的人，如用户的市场领导； ③ 对项目的成功有影响的第三方； ④ 系统会影响到的第三方。 在此过程中，尽可能多地列出可能的涉众，并列出每类涉众需要解决的问题。对于每一类涉众，描述本系统是如何影响他的，以及他是如何影响本系统的。下面以某空调服务公司为例说明空调维修服务系统的涉众分析(见表5.1 )。 表5.1空调维修服务系统的涉众分析表 序号涉众代表人物待解决的问题/对系统的期望 1 客户 宋山(某商厦负责人) 1. 维修服务响应速度慢，往往要延迟多日才安排工人上门。 2. 每次维修所花时间过长，整座大厦或部分场所温度失控，大厦商户和顾客怨声载道 2 业务经理 张丰 1. 工人安装与维护周期过长，工作效率低下。 2. 工人出工安排混乱，无法掌握某个工人在某一时段空闲。 3. 库存材料总掌握不清楚，经常出现缺货的情况 3 工人 李华 1. 信息不准确，经常发生到现场后发现维修部件、材料、工具与空调故障不匹配的问题。 2. 客户档案及空调维修历史信息缺失，不能迅速判定故障的原因 4 财务人员 王林 1. 维修款到账不及时，经常错过月度和季度账期。 2. 维修服务信息统计不及时，计算业务经理和工人的奖金不准确 5 库房人员 钱丽 1. 有些材料积压库房，有些又经常短缺。 2. 材料品种和规格太多，管理环节容易出错，经常有库房材料账实不符的情况 (4) 详细调查和分析业务流程，建立业务流程模型以描述用户处理业务的过程及过程中数据的流转，快速让分析人员、用户、开发人员对企业业务流程和管理流程达成共识。 2. 系统调查方法 详细调查是问题分析和需求调研的第一步，传统的系统调查方法有资料收集、访谈、实地观察和问卷调查等方法。 1) 资料收集 收集企业现有的文档资料是信息系统调查最基本的方法，也是最廉价和最有效的方法。收集的资料包括： 组织机构、部门职能、岗位职责的说明； 业务流程说明、操作规程文件； 管理工作标准和人员配备； 单位内部管理用的各种单据、报表、报告； 历史的系统分析文档。 2) 访谈 访谈法用得最普遍，实施起来也十分灵活。它既可以是一对一的采访，也可以是群组会议，大家各抒己见； 既可以是正式访谈，也可以是非正式访谈。通过详细的面谈，广泛而深入地了解用户的背景、心理和需求等。访谈实施的关键在于访谈问题的设计。访谈法的优点是可以激发访谈对象主动贡献、自由表达的愿望，得到更多反馈和详细信息，近距离接触还能获得更多隐性信息。缺点是耗时、成本高，受制于地理位置，也取决于分析员的交流能力。 3) 实地观察 “耳听为虚，眼见为实”，分析人员到用户工作现场，实地观察和跟踪用户的业务流程，对照用户提交的问题陈述，对用户需求可以有更全面、更细致的认识。它的优点是了解用户实际的操作环境、操作过程和操作要求，容易获得第一手的资料，收集到的信息可靠性高。缺点是观察过程容易被其他事务打断，不容易观察到包含各种特殊情形的全部业务场景。另外还需要注意的是，新系统目标不应只是观察到的那些操作的简单复制，分析人员不要受实际观察的拘束。 4) 问卷调查 问卷调查法将需要调查的内容制成问卷交由用户填写，通过回收和整理用户的回答获得用户的原始要求。本方法实施的关键在于问卷的设计。问卷调查法的优点是实施成本可以比较低，当需要调查大量人员时，非常有效，但获得的问卷的质量不一定能够得到保障。 3. 需求引导方法 以上是传统系统调查方法，适用于各种分析场景，在信息化建设领域，为了帮助用户更好地理解信息系统和信息技术的能力，引导他们发现现行组织管理和业务处理中所存在的问题，启发他们更好地表达原始需求，还可以使用一些需求引导方法，例如原型法、JAD联合会议、观摩法等。 1) 原型法 通过快速构造原型，提交给用户，请用户提修改意见，使用户明确需求。原型可针对整个系统，也可针对具体功能。原型法能够给予用户直观的感受，促进分析人员和用户深度沟通，准确掌握用户需要，澄清和纠正模糊和矛盾的问题。缺点是要投入额外工作量和成本。 2) JAD联合会议 JAD(joint application development，联合应用开发)是一种类似于头脑风暴的技术，在一个或多个工作会议中将所有利益相关者带到一起，集中讨论和解决最重要的问题。参加人员有企业领导、会议记录员、业务人员、开发人员等。JAD会议的优点是发挥群体智慧，提高生产力，对问题有更理智的判断，解决各部门及人员的目标冲突，减少犯错。缺点是会议参与人员多，难以控制，人员之间的意见容易互相干扰和影响。 3) 观摩法 用户或开发人员参观同行业或同类型成功的信息系统，让他们通过观摩样板系统，对信息系统的作用、功能、外在效果、人机交互方式等产生认识，通过类比思维来获得新系统的需求，缩短需求分析的周期。 5.2.2需求分析 1. 用户需要与系统需求 在本阶段，分析员与用户充分交流，准确、完整地获取系统需求。系统需求就是新系统必须完成的功能或其局限性。系统需求包括功能性需求和非功能性需求。 (1) 功能性需求。功能性需求是系统最主要的需求，表达系统必须完成的所有功能及其必要性和相容性，以满足企业完成业务活动和管理的需要，例如提交申请、填写派工单、填写材料入库单、统计费用等。功能性需求包括系统的软件功能需求和数据需求。 (2) 非功能性需求。非功能性需求也称为技术性需求，是和环境、硬件和软件有关的所有可操作目标。通常是响应时间、安全性、可靠性、易用性等技术指标和系统的质量特性。例如，系统必须能支持100个并发用户，保存订单的时间不能超过半秒等，涉及系统性能、可靠性、安全性等。 图5.2中对问题分析和需求分析进行了区分。问题分析阶段调查并分析涉众遇到的问题和对新系统的期望，反映了业务和用户的“需要”。用户需要可以采用自然语言表达，提出的是比较模糊和高层次的目标。需求分析则是对原业务抽象和升华的过程，包含业务管理流程的分析，设计流程改进和优化方案，根据业务和用户需要确定计算机信息系统的“需求”。计算机系统容不得半点模糊的表示，因此系统需求的描述应该非常具体和确切，适合采用形式化程度比较高的图示模型表达。 图5.2需要与需求 需要层面上提出的目标相对稳定，系统需求层面的内容抽象层次低，容易受技术因素和环境因素的影响，较易发生变化。 2. 需求分析的方法 许多大型应用系统的失败，最后均归结到需求分析的失败； 或者获取需求的方法不当，使得需求分析不到位或不彻底，导致需求分析反复进行，引发后续设计、编程、测试连锁反应，项目无法按计划完成； 或者各方配合不好，客户对需求不确认； 或客户需求不断变化，同样致使开发过程无法顺利进行。 为了提高需求分析效果，各种需求分析方法都强调模型的使用，通过建立模型的方式来描述用户的需求，为用户、开发方及相关参与方提供一个交流的渠道。这些模型是对需求的抽象，以可视化的方式提供一个易于沟通的桥梁。根据建模特点，主要有以下几种常用需求分析方法。 1) 面向过程的结构化方法 基于自顶向下、逐层分解的方法对数据处理功能进行分析，每个处理功能有输入数据和输出数据，一个功能可以分解为多个更小的功能。数据流图是该方法最重要的模型。 2) 面向数据的信息工程方法 信息工程是以数据为中心的分析方法。该方法关注系统中存储的数据的结构，采用在分析过程和功能之前先研究和分析数据需求。实体关系图是该方法最重要的模型。 3) 基于UML用例驱动方法 面向对象分析的方法中使用UML建立系统的需求模型。其中用例图用于为软件系统的功能需求建模，用例图是用户导向的，主要通过用户与系统之间的交互来描述系统的行为和提供的功能。领域类图描述了业务领域概念、属性及概念和概念之间的关系，既可以用于为数据需求建模，同时也可以用于软件系统的静态结构建模。该方法兼顾了系统的功能和数据两方面的需求，是目前最为流行的方法。 4) 基于敏捷过程的用户故事 采用非正式的自然语言，以最终用户的角度描述软件功能的方法。用户故事是最轻量级描述需求的手段，最初的文字可以非常短，指需要交代什么人因为什么原因要做什么事(who、why、what)，然后通过口头交流细化具体需求和验证条件形成软件功能需求。一般用于快速迭代的敏捷开发过程中，如Scrum。 5.2.3需求定义 需求分析是分析人员与用户反复沟通和谈判的过程，一旦双方就系统需求达成一致意见，接下来应该进行需求定义。需求定义阶段的任务是整理并建立最终的需求模型，详细定义和描述每项需求，确认约束条件及限制，编写需求规格说明。由于需求分析采用的方法和模型不同，需求定义的内容也有所不同，但基本上都会包括系统功能及流程、数据存储、人机操作方式等方面的需求细节的规定。 定义好的需求规格一般用Excel表格或Word文档来保存。在团队协作的需求分析中，文档的撰写、版本变更、合并等过程都由人工完成，很容易发生混乱，导致需求不一致、冲突和遗漏等问题的发生。借助于一些软件工具进行需求采集和管理，能够帮助项目团队更好地实现需求沟通和需求同步，规范需求的采集和定义，还可以实现需求的组织、跟踪、审查、确认、变更和验证。特别是需求的跟踪，它确保了每项需求能与设计、编码和测试等开发行为的关联，从而实现需求的追踪，增强团队协作开发能力。 5.3系统说明书 5.3.1系统说明书的内容 系统说明书是系统分析阶段的技术文档，通常包括以下三方面的内容。 1. 引言 说明项目名称、目标、功能、背景、引用资料(如核准的计划任务书、有关业务文件、项目合同等)、本文所用的专门术语等。 2. 项目概述 1) 项目的主要工作内容 简要说明本项目在系统分析阶段所进行的各项工作的主要内容。这些是建立新系统逻辑模型的必要条件，而逻辑模型是书写系统说明书的基础。 2) 现行系统的调查情况 新系统是在现行系统基础上建立起来的。设计新系统之前，必须对现行系统调查清楚，掌握现行系统的真实情况，了解用户的要求和问题所在。 列出现行系统的目标、主要功能、组织结构、用户要求、关键业务流程等，简要指出主要问题所在，并说明现行信息系统的概况和新系统的变动。 3) 系统功能需求 采用数据流模型、用例模型或用户故事描述新系统的所有功能，并对每个处理功能或用例进行详细说明，包括数据处理过程、业务规则、输入数据和输出数据的基本组成等。当篇幅过大时，或单独作为附件，可取名为需求规格说明书(requirement specification)。 4) 系统数据需求 采用领域类图(或实体关系图)描述新系统的所有对象及相互关系，并对对象属性(或实体属性)进行详细说明。 5) 系统其他需求 说明系统在性能、安全、故障处理、硬件环境等方面的要求。 3. 实施计划 1) 工作任务的分解 指对开发中应完成的各项工作，按子系统(或系统功能)划分，指定专人分工负责。 2) 进度 指给出各项工作的预定开始日期和结束日期，规定任务完成的先后顺序及完成的界面。可用PERT图或甘特图表示进度。 3) 预算 指逐项列出本项目所需要的劳务以及经费的预算，包括各项工作所需人力及办公费、差旅费、资料费等。 5.3.2系统说明书的审议 系统说明书是系统分析阶段的技术文档，也是这一阶段的工作报告，是提交审议的一份工作文件。系统说明书一旦审议通过，则成为有约束力的指导性文件，成为用户与技术人员之间的技术合同，成为下阶段系统设计的依据。因此，系统说明书的编写很重要。它应简明扼要，抓住本质，反映系统的全貌和系统分析师的设想。它的优劣是系统分析人员水平和经验的体现，也是系统分析师对任务和情况了解深度的体现。 总体来说，系统说明书应具有以下品质。 (1) 正确性。说明书中所表述的用户领域的业务、数据、功能等是正确的，新系统的逻辑模型应该与用户的期望相吻合。 (2) 完整性。说明书应包含新系统要完成的全部事情，不要遗漏任何有待解决的问题，对当前暂时不解决造成遗留的问题应进行说明，并注明什么人、什么时候去解决。说明书中的所有条目都有标识(页、图、表、参考资料)。 (3) 一致性。系统各项特征和需求的描述不相矛盾，避免冲突术语、冲突特性，不同人员在撰写文档时应使用统一的领域术语和文档风格。 (4) 无二义性。对系统每一项特征或需求有且只有一种解释，避免造成误解。 (5) 可修改性。文档的书写结构和风格易于后续的修改和维护。 (6) 可跟踪性。对每项需求实现条目化管理，记录其来源，为实现需求与设计、源代码和测试等环节的关联打下基础，从而方便在整个生命周期内进行需求跟踪。 对系统说明书的审议是整个系统研制过程中一个重要的里程碑。审议应由研制人员、企业领导、管理人员、局外系统分析专家共同进行。审议通过之后，系统说明书就成为系统研制人员与企业对该项目共同意志的体现，系统分析作为一个工作阶段，宣告结束。若有关人员在审议中对所提方案不满意，或者发现研制人员对系统的了解有重大的遗漏或误解，就需要返回，详细调查，重新分析。也有可能发现条件不具备、不成熟，导致项目中止或暂缓。一般来说，经过认真的可行性分析之后，不应该出现后一种情况，除非情况有重大变动。 上面提到的局外系统分析专家，指研制过类似系统而又与本企业无直接关系的人。他们一方面协助审查研制人员对系统的了解是否全面准确，另一方面审查提出的方案，特别是对实施后会给企业的运行带来的影响做出估计。这种估计需要借助他们的经验。 习题5 5.1系统分析师的职责是什么？系统分析师应具备哪些知识和能力？ 5.2为什么说系统分析阶段是最困难的阶段？ 5.3对现有系统的问题分析包括哪些内容？ 5.4请对高校学籍管理系统进行涉众分析。 5.5系统调查方法有哪几种？各自利弊是什么？ 5.6什么是功能性需求和非功能性需求？举例说明。 5.7系统说明书包括哪些内容？