笔者常常在思考一个问题,什么是系统分析师?什么样的人是优秀的系统分析师?什么样的人是企业真正需要的系统分析师?系统分析师也许很神秘,也许很抽象,他有很多其他称谓,比如需求分析师、分析师等等。你可以说系统分析师是IT技术专家,也可以说他是业务专家,甚至可以说系统分析师是管理专家,那么他到底是什么?

也许,有一点我们可以确定,系统分析师连接着用户的需求,系统分析师主导着开发的实现,系统分析师的素质高低对IT项目的成败起到很重要的作用。

近年来,我国IT软件产业发展规律迅猛,需要大量IT人才,尤其需要居于IT人才金字塔顶端的系统分析师人材,笔者以自己的做系统分析师一些经验和对这个职业的理解，试图用一些文字研究系统分析师的素质和能力模型，以飨读者和广大IT技术人员、系统分析师同仁。

要想成为一名优秀的系统分析师，首先必须弄明白与系统分析师相关的一些职业理念和相关的工作概念定义。

一、 如何理解系统、信息系统、系统分析、系统设计、系统分析师？

系统是一组为实现某些结果相互联系、相互作用的部件的集合体。而信息系统是一组完成收集、处理、储存信息和以输出完成商业任务所需信息作为提交的系统。系统分析是理解并详细说明信息系统应该做什么的过程。系统设计是详细说明信息系统的诸多组件在物理上是怎样实施的过程。

系统分析师是使用信息技术的商业专业人员，利用分析和设计技术解决业务问题。他是团队中的一种角色,主要负责与涉众客户代表协同工作,以便对项目需求进行获取、分析、编写说明规格、确认和管理,也可称需求分析师,业务分析员等。

做一名系统分析师，要首先认识什么是系统分析师。对于同样一件事物的认识，每个人都会不一样，“一千个人有一千个哈姆雷特”，这关乎到认识论。其实,一个人的认识正好折射出了他的经验、水平、层次、能力。一句话，大道由简，我们也许熟悉了很多系统分析方面的技术，然后我们需要问自己是不是真的懂这个职业的本质含义所在，一定不要舍本求末。

上面的定义很简单，但反映了一些基本的要素。系统分析师首先是商业人员，然后才是IT技术人员，但系统分析师不是程序员，他的使命是解决业务问题，手段是信息技术。他不但要理解还要会详细地说明，这意味着他的商业知识、理解分析能力以及表达能力是比较基础的核心能力。还有, 系统分析最重要的是实践过程。系统分析师最好和业务人员打成一片,这样才会获得用户的信任。

顺便需要说明的是，信息系统有很多种类型,常见的有OLTP、 MIS、EIS、DSS。当然,你还可以谈很多,其实，任何一个名词都足够写一本书,你就大胆地讲出你的理解吧。但一定要记得总结,用一句话能总结出来就不用两句话,系统分析这个职位对思维的清晰要求颇高。

二、系统分析师需要哪些技能？

首先，系统分析师应熟悉如何建立信息系统，这要求相当高的信息技术能力，包括软件工程、主流技术架构、网络、数据库技术等等。

第二,系统分析师应必须熟悉自己正为之工作的商业行业，以及该行业如何使用各种类型系统的情况。

最后，系统分析师应需要熟悉相当多的人及其工作方式，因为这些人是信息系统的使用者，或者说是系统分析师的“客户”。

系统分析师是“通才”，正是因为他们连接了IT和业务。优秀的分析师其实懂三种“世界”的语言，即计算机语言、商业语言、人的语言。

对于商业，有些分析师一生专门研究一个特定的商业行业，比如制造业、零售业、服务业或贸易行业。一个非常熟悉某特定行业的分析师能够为这个行业的公司解决一些复杂的问题。

熟悉这个公司则需要花费一些时间，尤其是细节方面，包括组织结构、使命、成功的因素、战略和计划、企业文化和企业价值。

总之,系统分析师=行业业务专家+IT技术专家+管理专家。

三、系统分析师解决问题的大致过程是什么？

系统分析师解决问题的大致过程一般如下：

（1）研究和理解问题。

（2）核实解决问题的效益大于成本。

（3）确定解决问题的需求。

（4）制定一套可能的解决方案，提供多种可供选择的方法。

（5）决定最佳方案并推荐给决策层。

（6）详细说明所选方案的细节。

（7）实施解决方案。

（8）监控结果是否达到预期结果。

这个是经过归纳的大致过程,实际还有其他经典的过程,与之的区别只是形式上不同，但求解问题的过程是一致的。

上面的步骤是经过归纳过的，也许不同类型的系统，不同类型的企业工作方法不尽相同，但从宏观的角度看的确是类似的。

四、系统分析原型法的意义

原型(Prototype) 即样品、模型的意思。把系统主要功能和接口通过快速开发制作为“软件样品 ”，以可视化的形式展现给用户，及时征求用户意见，从而明确无误地确定用户需求。另外，原型也可用于征求内部意见，作为分析和设计的接口之一，可方便于沟通。

对原型的基本要求包括：体现主要的功能、提供基本的界面风格、展示比较模糊的部分以便于确认或进一步明确。原型最好是可运行的，至少在各主要功能模块之间能够建立相互连接。

原型法意义在于可视化、强化沟通、降低风险、节省后期变更成本、提高项目成功率。一般来说，采用原型法后可以改进需求质量。虽然投入了较多先期的时间，但可以显著减少后期变更的时间。原型法投入的人力成本代价并不大，但可以节省后期成本。对于较大型的软件项目来说，原型系统可以成为开发团队的蓝图。另外，原型通过充分和客户交流，还可以提高客户满意度。

原型法是在计算机技术发展到一定阶段，用户应用需求高涨的情况下发展的一种方法论，但它同时又是对开发人员有高要求的一种方法论。

原型法的基本思想如下: 原型法是确定需求策略，是对用户需求进行抽取、描述和求精。它快速地、选代地建立最终系统工作模型，对问题定义采用启发的方式，由用户作出响应。原型法实际上是一种动态定义技术。

原型法被认为对于大多数企业的业务处理来说，需求定义几乎总能通过建立目标系统的工作模型来很好地完成，而且这种方法和严格定义方法比较起来，成功可能性更大。

原型法开发策略基于如下的假设：

（1）并非所有的需求在系统开发以前都能准确地说明。

（2）有快速的系统建造工具。

（3）项目参加者之间通常都存在通信上的障碍。

（4）需要实际的、可供用户参与的系统模型(system model)。

文字和静态图形是一种比较好的通信工具，然而其最大的缺点是缺乏直观的、感性的特征，因而往往不易理解对象的全部含义。交互式原型系统能够提供生动活泼的规格说明，用户见到的是一个“活”的、运行着的系统。理解纸面上的系统和操作运行在机器上的系统，其差别是十分显著的。因此，当能够提供一个生动的规格说明成为可能的话，人们就不会满足于一个静止的、被动的规格说明。

总之，当提供一个活生生的系统模型时，人们对它的了解将比说明性材料好得多。

（5）需求一旦确定，就可以遵从严格的方法。

（6）大量的反复是不可避免的、必要的，应该加以鼓励。

在信息系统设计的过程中，常用的各种不同形式的部分原型有：

（1） 对话原型

原型模拟预期的终端交互，使用户可以从屏幕上查看他们将接收什么、进行的操作，并提出遗漏之处，从而加深正确的理解。终端对话的设计效果直接影响着系统的可用性和用户对系统的接受程度。

（2） 数据输入原型

建立数据输入的原型，可以检查数据的输入速度和正确性，还能进行有效性和完整性的检查。

（3） 报表系统原型

提供给用户的各种报告应在整个系统实现之前给用户看，报表子系统需要经常进行大量修改以满足系统的需要，因此，可以把报表生成器作为原型。

（4） 数据系统原型

首先生成一个含有少量记录的原型数据库，这样用户和分析师与它可以进行交互，生成报表和显示有用信息。这种交互经常导致产生对不同的数据类型、新的数据域或不同的数据组织方式的需求，还可以在原型化工具的帮助下探索用户将如何使用信息以及数据库是什么样的。

（5） 计算和逻辑原型

有时一个应用逻辑或计算是复杂的。审计员、工程师、投资分析师和其他用户可以使用高级程序设计语言建立他们所需的计算实例。这些实例可以组合在一起构成一个大的系统，与其它应用系统、数据库或终端相连接，用户可以使用这些计算原型检验他们所求结果的准确性。

（6） 应用程序包原型

在一个应用程序包和其它应用系统相连或实际使用之前，可以通过一个小组用户来鉴定这个应用程序包是否令他们满意，若不满意可以进行大量的修改，直到令他们满意。

（7） 概念原型

原型法是近年来流行的软件需求捕获方法之一。我们应该明白原型法是手段而不是目的。需要回答的要点是,原型法的背景、概念、定义、意义、如何实现原型、最好能够举例说明。

能够回答这些问题才能说明你完全掌握了原型法。很显然,提出这种问题的企业对这种方法在实际工作中是会相当倚重的，因此您不仅要知之还要行之。

以一个简单的案例来说明，王五是某家大型电子商务贸易公司的系统分析师,他负责做了一个询盘系统。由于询盘系统牵涉到许多抽象专业知识,因此为了便于沟通,王五经过一番研究制作了界面原型设计,并给出了解决方案,领导和客户看了原型设计后通过该需求方案。这个案例说明,今天的需求分析,不再是分析师和客户之间的访谈,更是一种通过实际原型(模型)互相启发,从而发现需求,归纳总结需求的一个实践过程。但我们可以看到,原型法只是一种手段,与用户良好的互动和沟通是获得需求的基本点所在。

六、如何进行有效的需求开发过程?

需求描述了客户需要或目标,或者描述了为满足这种需要或目标，产品必须具有的条件或能力,它是种特性,要求产品为涉众提供价值。

系统需求是系统必须完成的功能和局限性。功能需求是描述系统必须完成的活动或过程的一种系统需求,它就是系统要投入的商业应用。用户需求(User Requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例（Use Case）文档或方案脚本（Scenario）说明中予以说明。功能需求(Functional Requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。而所谓特性(Feature)是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。

系统分析阶段的活动则有如下几种（表1）,同时列举了其对应解决相应的关键问题。

表1

分析阶段的活动
  关键问题

收集信息 是否已经拥有了全部的信息来定义系统所必须完成的工作？
定义系统需求 需要系统做什么？
构建可行性的发现原型 可以证明此种技术能够实现想让它完成的那些功能吗？
是否已经构建出一些原型让用户能够完全理解新系统的潜在功能？

产生评估方案 创建系统的最好方案是什么？
与管理部门一起复查各种建议 是否应该继续设计和实现我们提出的系统？

解决关键问题的方法，大致如下：

（1） 搞清楚系统相关者,通过组织结构图找系统角色,他们是系统的主要使用力量。

（2） 系统开发的分析阶段的目标是理解商业功能和获得系统需求。

（3） 在改正旧系统到新系统的转换过程中，关键是新系统。通过调查问卷，面谈去理解新系统的限制。通过复查现有文档，去理解信息的过程。通过研究商业过程和供应商，去理解新系统的功能。最终是为新系统开发出系统需求和模型。

以上的描述是一种系统分析的流程,下面介绍从需求角度看分析师的业务问题。

需求开发依先后顺序可以分为：需求获取（Elicitation）、分析(Analysis)、编写规格说明（Specification）和验证（Verification）四个阶段。这些子项包括软件类产品中需求收集、评价、编写文档等所有活动。

需求开发活动包括以下几个方面：

（1） 确定产品所期望的用户类。

（2）获取每个用户类的需求。

（3） 了解实际用户任务和目标以及这些任务所支持的业务需求。

（4）分析源于用户的信息，以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息。

（5）将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件。

（6）了解相关质量属性的重要性。

（7）商讨实施优先级的划分。

（8）将所收集的用户需求编写成规格说明和模型。

（9）评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说明之前将问题都要弄清楚。

需求分析（Requirement Analysis）包括提炼、分析和仔细审查已收集到的需求，以确保所有的风险承担者都明白其含义并找出其中的错误、遗漏或其它不足的地方。分析的目的在于开发出高质量的需求，这样你能做出实用的项目估算并可以进行设计、构造和测试。

通常把需求中的一部分用多种形式来描述，如同时用文本和图形来描述。分析这些不同的视图将揭示出一些更深的问题，这是单一视图无法提供的。分析还包括与客户的交流以澄清某些混淆，并明确哪些需求是更为重要的。其目的是确保所有风险承担者尽早地对项目达成共识并对将来的产品有个相同而清晰的认识。下面是需求分析中经常使用的方法:

（1）绘制系统上下文示意图

这种示意图是用于定义系统与系统外部实体间的界限和接口的简单模型。同时它也明确了通过接口的信息流和物质流。

（2）创建用户接口原型

当开发人员或用户不能确定需求时，开发一个用户接口原型———个局部的可能实现——这样使得许多概念和可能发生的事更为直观明了。用户通过评价原型将使项目参与者能更好地相互理解所要解决的问题。注意要找出需求文档与原型之间的所有冲突之处。

（3）分析需求可行性

在允许的成本、性能要求下，分析每项需求实施的可行性，明确与每项需求实现相联系的风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍。

（4）确定需求的优先级别

应用分析方法来确定使用实例、产品特性或单项需求实现的优先级别。以优先级为基础确定产品版本将包括哪些特性或哪类需求。当允许需求变更时，在特定的版本中加入每一项变更，并在那个版本计划中作出需要的变更。

（5）为需求建立模型

需求的图形分析模型是软件需求规格说明极好的补充说明。它们能提供不同的信息与关系，以有助于找到不正确的、不一致的、遗漏的和冗余的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。

（6）创建数据字典

数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定义。在需求阶段，数据字典至少应定义客户数据项以确保客户与开发小组是使用一致的定义和术语。分析和设计工具通常包括数据字典组件。

（7）使用质量功能调配

质量功能调配(Quality Function Deployment，QFD）是一种高级系统技术，它将产品特性、属性与对用户价值联系起来。该技术提供了一种分析方法以明确哪些是客户最为关注的特性。QFD将需求分为三类：期望需求，即客户或许并未提及，但如若缺少会让他们感到不满意；普通需求；兴奋需求，即实现了会给客户带去惊喜，但若未实现也不会受到责备。

系统分析师需要掌握需求捕获、需求分析和需求确认方法,并且要有一定的实践经验,因为需求分析是门需要实践的学问。

需求捕获的方法其实有多种,你可以熟悉每一种方法。通过文档概要、面谈、观察、原型、调查表、供应商调查、联合应用会议等等方法是可以获得需求的。但在实际中,你不必十八般武艺样样都要使出来, 本质上持续不断的捕获高质量的需求的方法只有一个，就是和业务人员打成一片,这样,不再是你去找需求,需求可能会来找你了,这是一种主动需求的方法,所以系统分析师一般都需要有良好的人际互动能力。

当然,需求捕获还是有其自身的方法的, 要讲需求捕获必先谈到收集信息, 信息不足则“巧妇难为无米之炊”。其实这里有三个经典的问题,会是系统分析师经常用到的或提到的问题。由信息收集到需求捕获，再到需求分析是需求开发的中轴线,而能否收集到必要的有效的需求信息, 请仔细体会如下三个问题。

（1）商业过程和操作是什么，即你要干什么

系统分析师核心是理解商业过程,一般用户只会对现状回答,但分析师要能识别在改进的系统中哪些要保留，哪些要删除。这个问题是沟通的第一步,回想当年笔者第一次就这样问用户：“你的流程是什么？你有什么问题”,何其愚也,从问用户的问题可以看出这个分析师是不是有经验。

（2）商业过程应该怎样完成，即系统分析师该如何完成它,或者说需要哪些步骤

用户谈的是老系统的完成办法,而系统分析师的核心是新系统应该如何支持这项功能,而不是在现有系统下如何执行。分析师重要的是超越现在,使新技术带来的商业处理方法更高效。

（3）需要什么样的信息，即为了完成商业过程，系统分析师要使用哪些信息，使用什么样的表单或报告。

有价值的系统分析师有一套需求捕获的手法，有价值的系统分析师一定会从理论到实际仔细研究需求分析的过程。

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号