一、概述
系统分析阶段也称为逻辑设计阶段，任务是根据系统规划的输出物《系统设计任务书》所确定的范围，对现有系统进行详细调查，描述其业务流程，指出局限性和不足，确定新系统的基本目标，提出新系统的逻辑模型，也就是解决新系统“做什么“的问题。
系统分析是整个系统建设的关键阶段，这也是信息系统建设与一般工程项目的重要区别所在。系统分析阶段的工作成果体现在《系统需求规格说明书》，这是系统建设的必备文件，也是系统设计和将来系统验收的依据。
二、系统分析的任务
系统分析阶段的基本任务是系统分析师和用户在充分了解用户需求的基础上，把双方对新系统需求的理解表达为《系统需求规格说明书》。
三、系统分析的难点
1、系统分析师与用户对系统的理解不同
2、系统分析师与用户沟通困难
3、环境不断的变化，系统分析阶段需要充分考虑这种变化，但这很难，甚至不可能
四、对系统分析师的要求
1、具有扎实的专业知识
2、具备管理科学的知识
3、较强的系统观点和逻辑分析能力
4、较好的口头和书面表达能力
5、较强的组织能力
6、善于与人共事
五、详细调查
系统分析阶段的详细调查与系统规划阶段的初步调查不同，其目的是深入了解具体情况和具体问题，为提出新系统的逻辑模型提供可靠的依据，其细微程度比初步调查高得多，工作量也大得多。
1、详细调查的原则
详细调查的对象是现有系统。调查过程中，需要遵循以下原则：
1）自顶向下全面展开
2）用户参与
3）分析系统有无改进的可能性
4）采用工程化的工作方式
所谓工程化的方法就是将调查中的每一步工作事先都计划好，按照先计划、后分工实施的原则，对多个人的工作方法、工具和成果统一规范，相互沟通，加强协调。
5）全面铺开与重点调查相结合
6）主动沟通和友善的工作方式
2、详细调查的内容
1）现有系统的运行环境
2）组织结构
3）业务流程
4）系统功能
5）数据与数据流程
6）资源情况
7）约束条件
8）薄弱环节
3、详细调查的方法
1）收集资料
2）开调查会
3）个别访问
4）书面调查
5）抽样调查
6）现场观摩
7）参加业务实践
8）阅读历史文档
六、系统分析的内容
1、现有系统分析
不管现有系统是还在运行或已经停用，它与新系统之间总存在“藕断丝连”的关系，对其进行分析，并与新系统进行比较，即可获得许多重要的信息。分析过程中，需要多跟用户沟通，了解他们对现有系统的认识和评价，尤其是负面评价，这些都是新系统需要克服和解决的，弥足珍贵。
值得注意的是，所谓现有系统，不一定是已经在计算机上运行的系统，也可能是一个人工的数据处理过程。
现有系统分析过程：
1）获得现有系统的物理模型
2）抽象出现有系统的逻辑模型
3）建立新系统的逻辑模型
4）建立新系统的物理模型（系统设计阶段）
2、组织结构分析
组织结构是系统分析师了解企业基本活动的切入点，即使现有结构不尽合理，可能需要调整，但调查工作还是要从组织结构开始。
组织结构调查就是对企业组织结构与职责进行分析，明确企业内部的部门划分，以及部门之间的关系。特别注意了解两个问题：
1）切实了解各部门的职责
2）明确企业的边界
3、系统功能分析
在掌握企业组织结构的基础上，以组织结构为线索，层层了解各个部门的职责、工作内容和内部分工，就可以掌握系统的功能体系，并用功能体系图来标识。功能体系图完全是一个以业务功能为主体的树形图。
系统功能调查是指对系统的功能构造进行的调查。每个系统都有一个总目标，而总目标的达成，又依赖层层子系统，分散到更具体的各个子功能。因此系统功能分析，需要
1）确定系统所有功能
2）分析各功能的关系和流程
4、业务流程分析
组织结构图描述系统内部各部门的划分以及它们之间的关系；功能分析图则表明这些部门的管理功能。这二者反映了系统的总体情况，而系统的细节则由业务流程分析给出，包括明确部门职能如何完成，细节情况如何等。
业务流程分析的目的是了解业务流程过程，明确各部门之间的业务关系和每个业务处理细节，为业务流程合理化改造提供参考，系统的数据流程变化提供依据。同时也能为系统分析师发现和纠正调查工作中的错误，弥补疏漏，修改或删除系统的不合理部分，进而优化业务处理流程。
1）业务流程分析的步骤
通过调查掌握基本情况，描述现有业务流程，确认现有业务流程，对业务流程进行分析，发现问题并提出解决方案，提出优化后的业务流程。
2）业务流程分析的方法
价值链分析法，重点分析对顾客最有价值的业务流程
客户关系分析法，把CRM用在分析上
供应链分析法，从企业供应链的角度分析企业的业务流程
基于ERP的分析法，ERP的基本思想是将企业的业务流程看作一个紧密的供应链，将供应商、采购、生产、销售，以及客户联系起来。
业务流程重组，重新审视企业的价值链，从功能成本的比较分析中，确定哪些环节具有比较优势
3）业务流程分析的工具
业务流程图、业务活动图示、UML活动图等。
业务流程图和数据流程图、流程图
4）业务流程图
业务流程图和数据流程图、流程图
5）业务活动图示
BAM
6）业务流程建模
企业业务流程包含三个要素，分别是实体、对象和活动。描述业务流程模型最常见的方法是形式化描述和图示化描述，有标杆瞄准（Bench marking),IDEF(Integration DEFinition method，集成定义方法）、Petri网、DEMO（Dynamic Essential Modeling of Organization，组织动态本质建模法）和业务流程建模语言等。
【标杆瞄准】
连续、系统化地对外部领先企业进行评价的过程，通过分析和评价，确定出代表最佳实践的经营过程和工作过程，以便合理地确定本企业的业务流程。
【IDEF】
一系列建模、分析和仿真方法的统称，从IDEF0到IDEF14。
IDEF0（功能建模）
IDEF1（信息建模）
IDEF1X（数据建模）
IDEF2（仿真建模）
IDEF4（面向对象建模）
IDEF8（用户界面建模）
IDEF10（实施架构建模）
IDEF14（网络规划）
IDEF0模型形象、直观、易于理解和分析，但不适合复杂业务流程。
【DEMO】
DEMO方法定义了信息系统中行为角色之间的通信方式。DEMO的核心是业务事务，由发起者和执行者两个角色实现。
【Petri网】
一种从流程的角度出发描述和分析复杂系统的模型工具。经典的Petri网有2种元素，分别是变迁（用方框表示）和位置（用圆圈表示），有向边表示二者之间的关系。
【UML活动图】
UML中，主要使用活动图来对业务进行建模。
5、数据与数据流程分析
数据与数据流程分析是以后建立数据库系统和设计功能模块处理过程的基础。系统调查过程中收集的数据资料只是原始材料，必须加以汇总、整理和分析，才能理清其中的关系，为以后的数据库设计奠定基础。
1）数据汇总分析
数据汇总工作较为烦杂，通常可分为几个步骤：
（1）将数据原始资料按业务流程分类编码，按处理过程的顺序排列
（2）按业务流程自顶向下地对数据项进行整理
（3）原始数据和最终输出数据分类整理，原始数据构成基本表，最终输出数据反映业务指标
（4）确定数据的字长和精度
2）数据属性分析
（1）数据静态分析
指分析数据的静态属性，包括类型和长度、取值范围、业务量、使用该数据的业务、重要程度和保密程度。
（2）数据动态分析
数据动态特性有3种，固定值属性、固定个体变动属性和随机变动属性。
固定值属性，一般不会变动，如会计科目，客户基础资料、物料主数据等；
固定个体变动属性的数据项，对总体相对固定，但对个体则是变动的，如客户每次订购的商品和数量，库存余额，总账余额，未结销售订单等；
随机变动属性的数据项是随机出现的，值也跟随变动，如产品月销售量等，因为有些月份，可能有些产品没有销售量。
（3）数据的存储分布
固定属性数据存放在基本表，随机变动属性数据存放于视图或处理文件中；又如，要考虑哪些数据存放在本地设备，哪些存储在网络服务器或系统主机等。
3）数据流程分析
把数据抽象、独立出来，舍去具体的企业组织结构、物质、信息载体等，目的在于发现和解决数据流通中的问题。
结构化分析方法（SA）是一种面向数据流的分析方法，数据流图（DFD）是主要工具之一。而面向对象分析方法（OOA），是通过对象之间的交互来处理数据流程。
七、系统分析方法
主要有结构化分析方法和面向对象方法，以及面向问题域分析（Problem Domain Oriented Analysis，PDOA）方法。PDOA强调描述，少强调建模，核心元素是问题框架。
1、结构化分析方法（SA）
SA的基本思想是自顶向下，逐层分解。核心是数据字典，围绕这个核心，有3个层次的模型，分别是数据模型、功能模型和行为模型（也称为状态模型）。实际工作中，一般用E-R图表示数据模型，数据流图（DFD）表示功能模型，状态转换图（STD）表示行为模型。
1）SA的系统分析模型
2）状态转换图
3）数据字典
数据字典实际上是“关于系统数据的数据库”。在整个系统开发过程和系统运行于维护阶段，数据字典是必不可少的工具。它是所有人的工作依据，统一的标准，确保数据在系统中的完整性和一致性。
为了保证其一致性，数据字典必须要有专人（数据管理员）管理。任何人要修改数据字典的内容，都必须通过数据管理员。同时数据管理员也负责通知和提供最新版本的数据字典。
数据字典一般有6类条目，分别是数据元素、数据结构、数据流、数据存储、加工逻辑和外部实体。
（1）数据元素
也称为数据项，是数据的最小组成单位，例如，课程号，课程名等。对数据元素的描述，应包括其名称、编号、别名、类型、长度、取值范围和取值的含义等，除此之外还包括简要说明，以及相关的数据结构。
（2）数据结构
重点描述数据元素之间的组合关系，即说明数据结构包括哪些成分。
（3）数据流
（4）数据存储
数据存储的结构
（5）加工逻辑
判定树、判定表、结构化语言等
（6）外部实体
数据的来源和去向。外部实体的描述应包括其名称各，编号，简要说明，相关数据流等。
2、面向对象分析方法(OOA)
OOA的基本任务是运用OO方法，对问题域进行分析和理解，正确认识其中的事物及关系，找出描述问题域和系统功能所需的类和对象，定义它们的属性和职责，识别它们之间形成的各种联系，最终产生一个符合用户需求，并能直接反映问题域和系统功能的OOA模型及其详细说明。
OOA建立用例模型，从用户角度描述系统所需的功能和服务；然后通过分析模型，对需求进行深入分析，获取关于问题域本质内容。简单来说，通过用例图来描述系统提供的功能和服务；类图和对象图描述系统的基本逻辑结构，展示对象和类如何组成系统；交互图展示系统的行为。
1）UML（统一建模语言）
UML的结构包括构造块、公共机制和规则三个部分。
UML有三种构造块：事物、关系和图。事物就是建模元素，关系把事物结合在一起，图是多个相互关联的事物的集合。事物有结构事物，行为事物，分组事物和注释事物；关系主要有依赖、关联、泛化和实现4种；图则有用例图、类图等14种之多。
公共机制是指达到特定目标的公共UML方法，包括规格说明，修饰、公共分类和扩展机制。规格说明是事物语义的细节描述，是模型的真正核心；修饰是每个事物的简单记号；公共分类为类与对象、接口与实现；扩展机制包括约束、构造型和标记值等。
规则是规定构造块如何放在一起。
2）用例模型
从用户角度出发，对系统提供的服务建模，而不关心系统内部结构和设计。用例方法是一种需求合成技术，将获取的需求先记录下来，然后整理和提炼，从而建立用例模型。建立用例模型，一般需要经历4个阶段：识别参与者，合并需求活动用例，细化用例描述和调整用例模型；其中前三个步骤为必需。
用例图的元素是参与者、用例、通信关联。用例就是服务。参与者是系统之外，并与系统交互的任何事物，既可以是系统用户，也可以是外部系统、设备或实体。通信关联表示参与者与用例，或者是用例与用例的关系。箭头所指，被动接受者；箭尾所向，主动发起者。
（1）识别参与者
参与者一定在系统之外，不是系统的一部分。可以通过一些问题来帮助识别参与者：谁使用？谁安装？谁维护？谁关闭？有哪些系统使用本系统？谁从本系统获取信息？谁给本系统传递信息？是否有事情在预计时间内发生？
参与者可能有多个，根据职责重要程度不同，分为主要参与者和次要参与者。次要参与者帮助主要参与者完成工作，不能脱离主要参与者而独立存在。开发用例的重点是找到主要参与者。
（2）合并需求获得用例
找出所有参与者后，为每一个参与者确定用例，即考察它们对应哪些需求，然后进行合并。我觉得是把相同用例合并在一起。用例命名采取动宾结构。注意用例和用例包含的工作步骤不要混淆。一个用例可以包含多个步骤，或者子功能。另外，还要注意区分业务用例和系统用例。业务用例是指人工、线下的操作，不靠系统完成，不属于系统的一部分。我们只需识别系统用例。
（3）细化用例描述
一个用例，至少包含用例名、参与者、目标、前置条件、事件流（基本事件流和扩展事件流）、后置条件。用例规约还可能包含非功能需求和用例优先级。用例建模，主要工作是书写这些用例规约，而不是画出用例图。事件流指用例中的工作步骤。
一个复杂系统会有比较多的用例，可以建立多张用例图，还可以进行分组，按主题划分。
用例描述示例
（4）调整用例模型
前面建立初步模型后，可以利用用例之间的关系来调整用例模型。用例之间的关系有包含、扩展、泛化。利用这些关系，把一些公共信息抽取出来，以便复用，提高用例模型的维护性。
调整用例模型一般是在用例模型完成后，模型建立之初不必急于抽象用例之间的关系。凡事有两面，利用用例关系，会增加用例数量，增加模型的复杂度，需要谨慎。
3）分析模型
建立用例模型之后，还要对需求进行深入分析，获取关于问题域本质内容的分析模型。分析模型描述系统的基本逻辑结构，展示对象和类如何组成系统（静态模型），以及它们如何保持通信，实现系统行为（动态模型）。
用例模型描述系统外部；分析模型剖析系统内部。
建立分析模型的过程大致包括定义概念类、确定类之间的关系、为类添加职责、建立交互图等。
（1）定义概念类
OOA的中心任务就是找到系统中的类和对象，然后将这些类和对象反映到系统设计和代码中的类和对象。
发现类的方法，应用最广泛的是名词短语法。先识别有关问题域描述中的名词或名词短语，作为候选对象进行考察：
阅读和理解需求文档或用例描述
筛选出名词或名词短语，建立初始类清单候选
将候选类分成三类：显而易见类，明显无意义类，不确定类别类
舍弃明显无意义类
考察不确定类别类，合并到显而易见或明显无意义。有一些可能只是类的属性。
（2）确定类之间的关系
【关联】
关联提供了不同类的对象之间的结构关系，它在一段时间内将多个类的实例连接在一起。
关联关系体现的是对象（实例）之间的关系，而其他都是类之间的关系。
【依赖】
两个类A和B，如果B的变化会引起A变化，则称A依赖于B。
【泛化】
泛化关系描述了一般事物与该事物中的特殊种类之间的关系。
泛化和继承相反。子类继承父类，父类是子类的泛化。
【共享聚集】
聚合。表示类之间的整体与部分的关系，其含义是部分可能同时属于多个整体，部分与整体的生命周期可以不相同。
【组合聚集】
也表示类之间整体与部分的关系，但部分只能属于一个整体，部分与整体的生命周期相同，部分随整体一起创建，一起消亡。
【实现】
将说明与实现联系起来。接口是对行为而非实现的说明，而类则包含了实现的结构。
有关实现、泛化和依赖的分别，可以这么记：泛化是父子关系，亲生骨肉，所以是实线；实现、依赖，关系都比较虚。依赖，有比较强的关系，一个发生变化，会影响另外一个，所以是实箭头。那么实现相对来说比较宽松，虚箭头。
（3）为类添加职责
为类添加属性和方法。
属性是描述类静态特征的一个数据项。从建模角度看，属性越简单越好。要保持属性简单，应该只定义与系统责任和系统目标有关的属性，且只使用简单数据类型；避免冗余属性和类关联属性。注明名称、解释、数据类型和相关要求。
方法则描述类动态特征。根据封装性原则，信息和其相关行为应该在同一类；同一事物也尽量在同一类。
本过程中注意避免不断细化。
（4）建立交互图
交互图有顺时图（时序图，序列图），
交互概览图（活动图和顺序图的混合物），
通信图（协作图），
定时图。
八、系统需求规格说明书
系统需求规格说明书也称为系统分析报告，或简称为系统说明书，它是系统分析阶段的技术文档，也是系统分析阶段的工作成果。
1、系统需求规格说明书的内容和格式
分为九大部分
1）引言
对项目和本说明书做一个概要性的描述。简述本说明书适用的项目，系统用途，项目特性，投资方，需方，用户，承建方和支持机构，相关保密性和私密性要求等。
2）引用文件
引用文档的编号，标题，修订版本和日期，来源
3）需求
分条详述系统需求。
包括功能、业务（包括接口，资源，性能，可靠性，安全性和保密性等）和数据需求，即系统验收的条件。每个需求都以利于客观测试的方式进行陈述，并附上合格性方法说明。
4）合格性规定
定义一组合格性规定，配合第3点。合格性方法包括演示、测试、分析、审查或其他特殊的合格性方法。
5）需求可追踪性
针对子系统，系统级不适用。说明子系统需求的双向可追踪性，即每个需求可对应系统的某个功能；系统每一个功能也可以找出相应的需求。
6）非技术性需求
系统交付日期和里程碑设置。
7）尚未解决的问题
尚未解决的遗留问题。
8）注解
有助于理解本说明书的一般信息。如背景，词汇表，原理等。
9）附录
为便于维护本说明书而单独编排的信息，如图表，分类数据等。
2、系统需求规格说明书的评审
系统需求规格说明书在整个系统开发中占有非常重要的地位，应该进行评审。评审员包括核心开发人员，企业领导，业务代表，系统分析师和外聘的专家等。评审过程中，如果发现较大错漏或不满意，需要返工，重新进行系统调查和分析，直至通过。
一旦通过评审，系统需求规格说明书将称为系统开发中的权威性文件，是系统功设计的主要依据。同时，也是项目验收的标准之一。
