第5章 系统分析概述

本章主要内容 5.1 系统分析的任务 5.2 系统分析的过程和方法 5.3 系统说明书

5.1 系统分析的任务 系统分析师与用户在一起充分理解用户的要求，并把双方的理解用书面文档——系统分析说明书表达出来。 也称需求分析。 分析的本质就是理解和发现。 观察、访谈  理解  表述 发掘 批判、革新

1、系统分析的困难 系统分析是研制信息系统最重要的阶段，也是最困难的阶段。 困难主要来自三个方面： 问题空间（problem domain）的理解 人与人之间的通讯 环境的不断变化

2、系统分析师 system analyst，简称SA。 任务包括： 理解和明确企业目标、经营业务和战略发展方向。 按照企业目标制定信息系统建设的目标并进行分解。 根据企业所处环境和条件制定适合企业信息系统的开发策略。 从可供选择的方法和工具中进行选择，确定适合信息系统开发的方法和工具。 与企业决策层和业务人员充分沟通，了解企业业务需求，准确建立企业的业务模型。 根据企业目标和技术发展动向，结合业务模型建立完善的信息系统逻辑模型。 对信息系统开发的组织、人员和进度计划提出建议。 撰写系统说明书。

系统分析师 具备的素质： 具备坚实的信息系统知识，了解信息技术的发展，懂得管理科学的知识 应有较强的系统观点和较好的逻辑分析能力，能够透过现象看到问题本质，从复杂的事物中抽象出系统模型。 具有突出的批判性思维和创新思维，善于接受新鲜事物，从经验积累中进行改革和创新。 还应具备较好的口头和书面表达能力，谈判和协商的能力，较强的组织能力，善于与人共事。

职位描述

系统分析师要成为业务专家 才能与用户交流顺畅，充分理解用户的要求。 才能确保系统满足了业务需求，甚至用更好的方法来解决业务需求。 在用户中建立可信度，用户才可能接受你的建议。

3、系统分析的内容 识别利用IT实现组织变革的机会 企业流程管理，业务流程改善 企业需求分析 信息系统需求分析和规格说明 企业管理模型 信息需求 信息系统需求分析和规格说明 需求采集、需求识别、需求表示、需求沟通 系统数据需求、用户体验分析、用户界面需求 影响安全性的因素、对伦理道德的考虑 需求规格说明书 信息系统开发方式的抉择

5.2 系统分析的过程和方法 分析的重要任务是识别和表达需求，建立系统的逻辑模型。 要解决以下问题： 如何采集信息、理解和分析问题？ 如何进行需求分析、确定需求？ 如何表述需求？

系统分析的过程 系统分析是分析领域业务和建立新系统逻辑模型的过程。

5.2.1 问题分析 通过详细调查全面深入理解用户的业务，找出用户所面临的问题，准确把握用户真正的需要，为最终整理出符合用户需要的需求做准备。 分析过程如下： 明确项目的背景 明确项目目标、范围、相关部门和人员 找出关键涉众（stakeholder，也称利益相关人员）及待解决的问题。涉众包括系统的用户、项目决策者、受项目影响的第三方等。 调查和分析业务流程，建立业务流程模型以描述用户处理业务的过程及过程中数据的流转。

涉众分析 某空调维修服务公司的维修服务系统： 序号 涉众 代表人物 待解决的问题/对系统的期望 1 客户 宋大山（华联商厦负责人） 1. 维修服务响应速度慢，往往要延迟多日才安排工人上门 2. 每次维修期所花时间过长，整座大厦或部分场所温度失控，大厦商户和顾客怨声载道 2 业务经理 张三丰 1. 工人安装与维护周期过长，工作效率低下 2. 工人出工安排混乱，无法掌握哪个工人在某一时段空闲 3. 库存材料总掌握不清楚，经常出现短货和缺货的情况 3 工人 李四 1. 信息不准确，经常发生到现场后发现维修部件、材料、工具与空调故障不匹配的问题 2. 客户档案及空调维修历史信息缺失，不能迅速判定故障的原因 4 财务人员 王五 1. 维修款到账不及时，经常错过月度和季度账期 2. 维修服务信息统计不及时，计算业务经理和工人的奖金不准确 5 库房人员 钱丽 1. 有些材料积压库房，有些又经常短缺 2. 材料品种和规格太多，管理环节容易出错，经常有库房材料账实不符的情况

系统调查方法 调查是识别需求的基础，是建立系统逻辑模型的基础。调查包括： 传统的系统调查方法有： 业务处理过程是什么样的？(干什么？) 业务过程应该怎样完成？(怎么干？) 业务谁负责，完成业务需要什么输入，能输出什么？ 传统的系统调查方法有： 资料收集 访谈 实地观察 问卷调查

调查方法1——资料收集 可以收集以下资料： 从现有文档中获取客观事实 组织机构、部门职能、岗位职责说明 业务流程说明、操作规程 管理工作标准和人员配备 单位内部管理用的各种单据、报表、报告 历史的系统分析文档 从现有文档中获取客观事实

调查方法2——访谈（interview） 与领域专家的面谈是获取需求的基本技术。 面谈类型： 优点： 缺点： 结构化面谈：有为面谈专门设计的问题 非结构化面谈：通常为开放式问题 优点： 激发面谈对象主动贡献、自由表达的机会，可以得到更多反馈，近距离接触还能获得隐性信息 缺点： 耗时、成本高，取决于分析员的人际交往能力，受制于地理位置

调查方法3——实地观察（observation） 直接参与到企业活动中，或观察他人执行活动来了解系统，“耳听为虚，眼见为实”。 优点： 收集到的信息可靠，获得确切的感性认识，了解物理环境和事务背景 缺点： 被观察者因为不自然可能与常规表现有差异，可能会漏掉特殊情形下的任务，观察会被打断

调查方法4——调查问卷（questionnaire） 调查表可以收集大规模的事实表格。 调查表类型： 固定格式调查表：只能选择问题答案 自由格式调查表：允许自由填写文字 优点： 方便填写，廉价，允许匿名，可以进行快速表格分析 缺点： 不够灵活，无法保证能深入回答问题，无法保证问卷回收数量，设计好的调查表十分困难

需求引导方法 一般用户在开发之初，对所要开发的信息系统应该具有的功能和所能达到的结果并没有清楚的认识，因此，需求调查比现行组织系统调查难度更大。 对用户进行引导和启发，让用户获得信息系统的感性认识，引导他们发现现行组织管理和业务处理中所存在的问题，从而发掘需求和找到解决方案。 采用以下需求引导方法： 原型法 联合应用开发（JAD）会议 观摩法

需求引导方法1——原型法 利用快速开发工具，根据用户的初步需求，构造出信息系统的初步原型。 优点： 缺点： 用户和调查人员深度沟通，能准确地反映了用户需求，澄清和纠正模糊和矛盾的问题。 缺点： 额外工作量，原型开发工具购买成本

需求引导方法1—— JAD会议 JAD，joint application development 参加人员： 优点： 缺点： 是一种类似于头脑风暴的技术，在一个或多个工作会议中将所有利益相关者带到一起，集中讨论和解决最重要的问题。 参加人员： 领导（主持人）、记录员、客户、开发人员 优点： 群体智慧，提高生产力，更理智的判断，降低犯错 缺点： 会议长度难以控制，人员之间容易受干扰和影响

需求引导方法1——观摩 在系统开发之初，可以让用户参观同行业或同类型成功的信息系统。 用户看到这些具体系统，将会对信息系统的功能、作用、外在效果、人机交互方式等产生直观印象，这样就会引导和启发用户，通过类比思维，提出自己信息系统的需求。 可采用研究类似产品或解决方案来替代观摩。

5.2.2 需求分析 系统需求是新系统必须完成的功能或其局限性。 需求分析就是识别需求的过程。

系统需求 需求有两种类型：业务性需求和技术性需求 功能性需求： 技术性需求： 涉及商业应用，是系统必须完成的活动或过程，即系统功能以及相关数据。 功能性需求是根据业务过程和业务规则确定的，有些容易获取，有些则是隐含的，需要去发现。 技术性需求： 技术性需求也称非功能性需求，是和公司的环境、硬件和软件有关的所有质量目标。 例如：系统必须能支持100个并发用户；保存订单的时间不能超过0.5秒等等，涉及系统性能、可靠性、安全性等质量特性。 通常是一些技术目标。

技术性需求 技术性需求也称非功能性需求，是和公司的环境、硬件和软件有关的所有质量目标。 例如：系统必须能支持100个并发用户；保存订单的时间不能超过0.5秒等等，涉及系统性能、可靠性、安全性等质量特性。 通常是一些技术目标

需要和需求 问题分析获得业务和用户的“需要”，可以采用自然语言表达，提出的是比较模糊和高层次的目标。 需求分析则是对原业务进行抽象和升华，根据业务和用户需要确定计算机信息系统的“需求”。系统需求是精确和具体的。 需要 需求

需求分析方法 需求分析的传统方法： 目前系统分析的一般做法是综合运用以上方法，最后统一采用UML来建立系统逻辑模型。 面向过程的结构化方法（自顶向下、逐层分解） 面向数据的信息工程方法（数据驱动） 面向对象方法（对象驱动、UML） 目前系统分析的一般做法是综合运用以上方法，最后统一采用UML来建立系统逻辑模型。

5.2.3 需求定义 需求分析是分析人员与用户反复沟通和谈判的过程。 需求定义就是在各方就系统需求达成一致意见后，整理并建立最终的需求模型，详细定义和描述每项需求，确认约束条件及限制，编写需求规格说明。

系统分析建模内容 流程建模 用例建模 领域对象建模 业务流程（业务流程图/UML活动图） 数据处理流程（数据流图） 领域对象模型（UML类图、UML状态图） 由UML类图可以替代ER数据模型

5.3 系统说明书 《系统说明书》是系统分析阶段的成果。 该文档主要描述了系统的需求，在软件工程领域也称作《需求规格说明书》（requirement specification）。

系统说明书的内容 引言 项目描述 实施计划 项目名称、目标、背景、引用资料、术语说明等 项目的主要工作内容 现行系统的调查情况 功能需求 数据需求 其他需求 实施计划 工作任务的分解 进度 预算

系统说明书的审议 系统说明书经过审议后，成为下一阶段工作的依据。 系统说明书应该具备以下品质： 正确性 完整性 一致性 无二义性 可修改性 可跟踪性 审议由项目技术人员、企业管理人员、专家等共同完成。