今天, 作为一名企业专职的软件系统分析师, 其主要职责是为企业做需求分析。然而, 系统分析师是否已经熟练掌握了需求分析方法呢日长缨在手,明日缚住苍龙”。
背景介绍
人物：“我”
角色：IT部门系统分析师
公司介绍：勤缘电子贸易公司(化名), 年营业额达2亿,主要由销售部门、资材部和IT部门等组成。其中，销售部门负责业务, 资材部负责供应商的开发和采购电子元器件产品,IT部门则负责公司的订单管理系统的开发与实施。
系统目的: 该公司本年度把商机管理纳入日程。所谓“商机”是指能为公司带来业绩和利润的客户需求信息。商机一旦提交,公司的销售部、资材部等会就需求完成一些针对该商机而 进行业务的任务。本系统的目的是管理追综该商机及其任务。
现状描述: 前段时间经过业务访谈，已经完成了系统的需求捕获工作，确定了商机管理的范围和目标。
任务描述：商机追踪系统需求分析。
第一种武器： 长生剑——建模法
需求分析常常从建立模型开始,建模的原因主要在于:通过抽象降低复杂度,有助于回忆所有细节,有帮助于与开发者以及系统相关者交流，正所谓一图胜千言。同时，模型本身还可作为系统维护文档。
图形模型是图表和系统某些方面的示意性表示,多用一些符 表示较抽象的东西,诸如实体、处理过程、数据、对象、信息和连接等。需求分析阶段的重点是集中在系统需求高度抽象的问题上。
在建立模型之前,我们必须搞清楚两个关键概念,即事件和事物。“事件”指可以描述的、值得记录的，在某一特定时间和地点发生的事情。“事物”类似与系统交互的外部实体或参与者,同时,事物构成了系统存储信息的相关数据。
参照前面所描述的任务，在分析阶段我们为商机管理建立了事件列表、实体—联系图以及类图等模型数据流图等。而在设计阶段,我们创建的模型有界面设计、流程图、数据库设计、结构图等。
商机追踪系统的事件如下:
- 收到商机信息时
- ? 发布商机时
- ? 收到任务信息时
- ? 任务跟进时
- ? 任务处理完毕时
- ? 商机结案时
- ? 商机达成时
我们对现实世界中事件的认识有助于理解现代编程语言中的事件概念,更让我们认识到编程语言在发展过程中产生了诸多思想和种类,其目的都是为了更好地解决现实问题。
让我们列出商机追踪系统基于名词的事物的部分清单，其中包括：商机任务、BOM表、责任人、主题、内容、执行人、任务询价、议价、特价申请、评估、索样，等等。还有吗还有,如果没有了,那么恭喜,你的需求已经提炼完毕。
我们把事物列出来本身已经构成需求分析的符 系统。我们可以看到事物之间自然发生的的关系是很清楚的。商机和任务是一对多关系, 即一个商机至少引发一个任务,也可以引发多个任务。
我们看到,准确地定义系统的概念、事件、事物、流程是建立模型的基石。甚至可以说是一切需求分析方法的基础。
我们需要重点关注的模型图有实体类图和实体关系图(Entity Relation Diagram，ERD)。实体类图描述了实体和实体之间关系的一种图解方式。它可以通过多种Case工具制作,如Visio或Rose。它本身也是UML适用于需求分析的抽象层中的一种模型。实体关系图是一种数据模型,可以帮助我们分析和理解业务或系统的数据组件。
实体用单名称来命名,在ERD中用矩形框来表示。实体关系图用菱形框代表关系,它确定了一对实体之间在逻辑上和数量上的连系。关系的命名则要能描述关系的本质。例如“BOM商机”和“任务”之间是“被执行”关系,用语言表达为“ BOM商机被任务执行”或“任务执行BOM商机” 。
请客户评审ERD时,要让他们检查图中所显示的关系是否全部正确、合适和全面。
下图给出商机追踪的ER图。
第二种武器： 孔雀翎——用例法
用例的重要功能是用画用例图的功能来鉴别和划分系统功能。它把系统分成角色（Actor）和用例（Use Cases）。角色表示与系统交互以实现某种目的的人、硬件或软件系统。
判断角色唯一的标准是它们必须要在被划分进用例的系统部分以外。它们必须能刺激系统部分并接收返回。用例描述了当角色给系统特定的刺激时系统的活动。这些活动被文本描述，它描述了触发用例时受到刺激下反映的本质，输入和输出到其他活动者和转换输入到输出的活动。用例文本通常也描述每一个活动在特殊的活动线时可能的错误和系统应采取的补救措施。 用例也可以用活动图来表示。
这样说可能会非常复杂，其实一个用例描述了系统和一个角色的交互顺序。用例被定义成系统执行的一系列动作，动作执行的结果能被指定角色察觉到。
用例可以完成的目标如下:
- 用例捕获某些用户可见的需求，实现一个具体的用户目标。
- 用例由角色激活，并提供确切的值给角色。
- 用例可大可小，但它必须是对一个具体的用户目标实现的完整描述。在UML中，用例表示为一个椭圆。
用例转变了需求开发的角度，传统的需求分析方式是研究用户需要用系统做什么，而现在则是讨论用户需要实现什么。用例法的目的是描述。
通常我们是用如下方法确定用例：
- 首先明确执行者和他们的角色，然后确定他们各自参与了哪些业务过程。
- 系统所能反映的外部事件，然后把这些事件与参与的执行者和特定的用例联系起来。
- 用特定场景来描述业务过程，将这些场景归纳为用例，并确定每项用例涉及哪些角色。
商机追踪系统就采用了第一种方法，我召开了一系列用例获取和分析讨论会，每周一到两次，每次会前都要请用户思考他们需要使用新系统执行什么任务。我发现，用例的名称应该表明用户需要达到的目标，而描述用例则需要在名词中使用动词。如此一来，才能真正描述用户的执行任务，即分析员需要描述的用例。
经过需求分析, 该电子公司商机管理的角色如下:
- ? 商机成员：其职责是发布商机。
- ? 商机管理：其职责是处理和分配商机任务, 常有如下动作:商机分配、验证、询价、议价、索样、确定。
关于商机追踪系统“商机发布”用例的完全展开描述如下:
第三种武器： 碧玉刀——原型法
原型是模型、样品的意思，显然它借鉴了制造业承接批量订单前先索要样品的经验，在系统初始阶段以可以运动的原型来说明需求和分析需求，给人以豁然开朗之感。 这里的思想实际上是以设计来获取需求,以设计原型的“砖”引出了真正需求的“玉”。我们也应该看到现在软件工具的可视化也是促成原型法得以快速生成的原因所在。原型实际上也分为几种：界面原型、概念模型、数据模型。心理学亦表明人们对活动着的界面原型的理解力远远大于对静态事务的理解，这就好像影像对视觉的冲击力远远大于文本一样。
一个快速实现的原型在整个需求开发过程中具有如下作用：
- 明确并完善需求
- 研究和设计选择方案
- 可发展为最终产品
原型的好处有很多, 掌握如下的原则去构建原型相信能获得更佳的效果：
- 安排在项目计划中的创建原型的任务和安排资源。
- 创建之前要陈述用途。
- 创建废弃型原型要尽量快速和经济,最少投资开发那些用于回答问题和解决需求不确定性的原型。
- 对于已经理解的需求不要建立原型,除非是研究设计选择方案。
- 在屏幕显示和 告中使用看似真实的数据。
- 不能期望用原型去代替软件需求规格说明（Software Requirements Specification，SRS）。
- 设计原型可以参考同类型软件的界面, 但设计不要脱离现实需求和目标。
好，现在就让我们来一窥商机追踪系统原型界面的庐山真面目吧。
图2 新增商机
从上面的原型界面看来，它是HTML的 页格式, 看上去很真实。但我们也会发现，原型法和敏捷开发(XP)的区别在于功能：原型法侧重在于界面和概念的定义，而敏捷开发则重在功能的迭代实现。
背景介绍
人物：“我”
角色：IT部门系统分析师
公司介绍：勤缘电子贸易公司(化名), 年营业额达2亿,主要由销售部门、资材部和IT部门等组成。其中，销售部门负责业务, 资材部负责供应商的开发和采购电子元器件产品,IT部门则负责公司的订单管理系统的开发与实施。
系统目的: 该公司本年度把商机管理纳入日程。所谓“商机”是指能为公司带来业绩和利润的客户需求信息。商机一旦提交,公司的销售部、资材部等会就需求完成一些针对该商机而 进行业务的任务。本系统的目的是管理追综该商机及其任务。
现状描述: 前段时间经过业务访谈，已经完成了系统的需求捕获工作，确定了商机管理的范围和目标。
任务描述：商机追踪系统需求分析。
第四种武器： 多情环——传统结构法
历史总在发展，今天的软件分析技术已经发展到了后面向对象时代 ,即便如此,我们也不能忘记传统的结构方法。没有别的原因，只要它能解决问题，我们就不会嫌弃它年代久远。我们要明白分析方法本身是没有高低之分，重要的是运用的能否恰到好处。
让我们来看看数据流程图（Data Flow Diagram，ＤＦＤ）,它的视角就是从数据处理角度解决问题，可以画出第０层到第Ｎ层的数据流程图，每一层也代表着系统的层次结构。
我们不能忘记每天都在使用的流程图，流程图是个好东西，它是系统分析员的基本武器。也许我们觉得它很简单，然而我们真的就能画出一幅完美的流程图吗bsp;
当你画好一副流程图，用下面的观点去检查它，或许你能做得更好。
- ? 明白流程图的作用，它是用来表达业务流程的。所以，画流程图的前提是描述企业业务流程现状。要做到真实，这需要你花大量时间去访谈和调研，不要凭经验也不要凭推测。要如实且真实地反映企业现状是第一位的要求,否则让企业业务人员一眼就会看出破绽, 会大大降低客户对你的信任度。
- ? 内在逻辑要清晰。业务动作的来由和去向要分明，遵循一个流程再加一个判断的原则。不要连续几个判断却没有任何动作产生，也不要该判断分支的情况只有强制性的顺序业务动作，这二者的逻辑要经得起推敲，因为流程图的内在逻辑反映了业务运作的规律。
- ? 绘制跨部门流程图，角色要分明。角色对应职责，职责产生动作，动作引发结果。
- ? 流程图的基本要素要合理，比如业务动作描述要详实，尽量避免产生歧义。条件判断语言使用肯定语句，比如可以写“客户目标价在业务 价范围内”而不要说“客户目标价低于业务 价”，这将导致流程的逻辑走向不同于标准的流向。
- ? 关注基本要素, 万不可出现一个条件只出现“是”而不见“否”之类的条件判断。
请看下面本系统的业务流程图。
图:商机追踪流程图
第五种武器： 霸王枪——面向数据法
采用此种方法的基本观点在于所有的信息系统最终都转化为对数据的操作,而操作就分为“增、查、改、删（Create、Retrieve、Update、Delete,CRUD） ”, 当你看到某个事物或实体缺少了其中一个方法时, 本能的反映应该是觉得该事物遗漏了一个需求处理,自然要和用户提出并做出相应的用例分析。
典型的面向数据的分析设计包含了OLTP（Online Transaction Processing，联机事务处理）和OLAP（Online Analytical Processing，联机分析处理）这两大类的企业应用系统,以数据存储、收集维护、使用为中心的系统可用性和可伸缩性的重要程度甚至大于界面标准。
OLTP系统,实现的核心是SQL和关系数据库系统,关注的主要问题是现实的过程里面需要记录和操作的各种数据,有哪些人需要数据,他们又如何对数据进行处理。该环境中,用户的行为特点是利用MIS从数据库中进行数据的存储操作,且操作的频率高而每次操作时间短,故对性能提出了要求,数据库级别和SQL级的优化是例行任务。
OLAP系统关注的则是数据的分析,从中得到 表和商务决策,找出规律而不是数据的CRUD处理。近年来OLAP和数据挖掘对企业的价值越来越大,商务智能和数据挖掘系统的需求分析方法也是自树一帜。归纳起来是要把企业决策的非结构化转为结构化,以做企业的Dashborad(罗盘)和各部门的KPI(Key Performance Index，关键价值点)分析为主要诉求点。
OLTP建立在数据库上，而OLAP建立在数据仓库上, 商务智能（Business Intelligence，BI）建立在数据挖掘上。如果说OLTP的 表只能让你“知其然”，则OLAP 表让你“知其所以然”，BI 表让你“知其将来然”。
商机追踪的KPI是商机达成率，它的维度是客户、业务员、部门、商机类型，而度数值是商机达成数量。通过这四个维度建立数据仓库, 并透过分析商机历史和现状,以及通过数据挖掘知识预测商机的未来趋势和努力方向，为企业决策层进入理性的决策依据，从而产生项目的直接经济效益，使商务智能系统不再是停留在纯 表展示上，这会成为“一把手”不可或缺的决策依据，同时，也是业务人员进行业务活动的及时行动指南针。
分析 告表明BOM类型的商机是利润率更高、近效果更好的，因此，该类型商机是业务部门需要重点处理的。而其他类型的商机则可能费力不讨好，我们都知道80/20法则，而商务智能系统则会告诉我们何为20%，何为80%。
总之，商业智能系统的规划包括总体构建、建设推广、自动分析、高效 表四个阶段，最终达到业务数据的全面集成，能够及时地、有针对性地完成分析和预测 告。
第六种武器： 离别钩——面向服务(SO)法
Wiki百科是这样解释SOA（Service-Oriented Architecture，面向服务架构）的：“因特 环境下企业业务集成的需要,通过连接能够完成特定任务的、独立功能的一种软件系统架构。”
据Garnter预计，到2008年大多数的企业将使用面向服务的方法和架构来规划部署新的企业系统。
SOA乍一看是件新事物,根据认识论我们会问自己What、Why、How的问题。
SOA是什么bsp;
SOA是一种组件模型,它将应用程序的不同功能单元化。我们看到,传统的WEB/Http技术完成了人与信息沟通的使命,它是一种B2C的应用,而SOA基于XML/SOAP/WSDL的面向服务体系，则能够使信息系统之间交互和沟通, 导致了B2B/EAI/CB2C的服务 络应用。系统间呈现松耦合、整合和协同度高的特点。本质上处于SOA环境的系统个体能在沟通基础上形成协同工作,很好地实现协同商务。
SOA有什么好处bsp;
服务驱动方法能使企业体验到业务和IT上的好处,如下：
- ? 业务方面
效率: 业务流从传统“蜂窝式”重复的流程向高度利用共享服务应用转变。
响应:迅速适应和传递关键业务服务来满足市场需求为客户、雇员和合作伙伴带来更高水准的服务。
适应性: 降低了业务的复杂度,从而节约时间和资金。
- IT方面：复杂性减低,容易管理; 服务的可重用性增强使项目交付更及时;能有效集成现有系统。
目前商业企业信息化存在的问题,大多是封闭运行状态导致企业间上游供应商和下游客户信息不对称,无法协同和更好地满足消费者的协同需求和企业间商务协同与智能化的需求。同时,IT信息化标准不健全,包括电子交换接口标准、业务流程单据标准、票据格式标准等等。
SOA的出现能够有效地解决传统技术带来的系统封闭厂商依赖度强、耦合度高、扩展性差的问题,因为基于开放标准HTTP/SOAP/WSDL技术更容易扩展组合和变更,符合业务发展变化快的特点。
如何用SOA的方法建立系统strong>
SOA的构建遵循如下步骤：建模、组装、部署、管理、控制。
建立基于SOA的系统要注意三个原则：
- ? 业务驱动服务,服务驱动技术。
从抽象层次看,服务是业务和技术的中间层。 - ? 业务敏捷是基本的业务需求。
提供响应变化需求的能力是新的“元需求”。 - ? 应变而变的SOA。
IBM是随需而变,招商银行是因您而变, SOA是为变化而生,，到底为谁而变A作为一种服务是因客户变而变。
SOA依照协议进行访问,客户只需要服务却不需要知道服务在哪里,客户只要知道完成了,不需要知道你做了什么。
从技术层面上讲, 面向服务的实现是在于寻址、自举和通信协议三大机制的基础之上的。服务的寻址问题解决了服务如何才能被客户访问到的问题;服务的自举则是种机制,解决了新的服务如何被客户了解，如自己的功能参数和返回结果;通信协议则解决了异质 络间客户和服务的通信问题。
解决了此三个问题, 就可以构建一个分布式的、低耦合的、动态可扩充和发展规律的面向服务的基础架构,面前典型代表就是基于UDDI和SOAP的Web Service。
第七种武器：拳头
就算你手中没有刀也没有剑， 但只要你敢于”亮剑”, 亮出你的拳头, 这已是最好的武器 。需求分析本是个动词．它特别在乎实践。在实践中，你的分析能够让用户信服，得到客户和同事的认可就是最好的需求分析实践。
好的系统分析师都有一个明显的特质: “ 自信” , 他们总是能够坚持自己的想法, 即使面对不同意见, 也能去说服对方。我见过很多近乎偏执的系统分析师 , 我知道如果不偏执，就不会有感染力和说服力, 而缺乏说服力, 会让你的分析 告大打折扣, 这是优秀的系统分析师所不允许出现的。
记得在一次需求分析讨论会上,我与公司老总的观点产生了严重的分歧: 主要对系统的概念上发生了理解上的偏差，我没有因为他是“领导”，而主动“投降”，我一直坚持自己的观点，直到他说“你是个好的工作伙伴”。
“所谓商机，就是客户在特定时间内给业务的需求信息”,我如此强调道。
“ 那你第一次输入是商机,而紧接着其他部门的输入是商机还是任务呢机和任务概念没有很清楚啊。” 我们老总直陈我的问题点。
我回答道：“商机本来就是由业务录入,后面的就是各部门处理商机的任务了,不存在‘第一次’和‘第二次’的问题。” 我明白他没有搞清楚商机和任务之间的关系。于是我在白板上画了一张模型图, 画出了商机和任务的概念关系，先有了“商机”再由它引发了“任务”, 关联关系为一对多, “一个商机肯定要有很多任务去跟近才能化商机为业绩,化业绩为利润, 因为新商机才能引发了新的任务，这两个对象的关系要理清！” 我据理力争。
……
“我基本明白了你说的这两个事物的区别和联系了。很好,你是个很好的工作伙伴。”
我知道,他的意思是很欣赏我的“固执已见”。如果不这样,我们会缺乏一次真正探讨需求问题的机会。 换句话说，如果我不能坚持自己的观点,那就背离了一个系统分析的责任。
之所以讲出这段“个人故事”，并非自卖自夸，实乃自省之得。也许在很多时候，我们真的要敢于坚持到底,才能离真理更近一些。
据说香港李嘉诚曾在他的长江商学院开学典礼上给他的学员特别提起三个词：“优术”,“悟道”,“取势” 。作为运用信息技术为商业业务做需求分析的系统分析师们应当能够早日超越”术”, 到达“悟”的境界，就让我们用心去”悟”一次。
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！