浅谈程序员第五期：管理类型软件需求分析指南 2.doc

《程序员》第五期 需求分析指南（管理类软件） 撰稿 高 展 摘要：本文以一个小型商业企业为例，阐述如何使用“全程建模”方法进行需求分析，避免软件开发变成胡子工程，并特别指出全程建模方法对形成用户手册的重要作用。 一 管理软件失败的症结 平心而论，管理软件（以下简称软件）的成功率很低，据权威统计，在美国，MIS成功率只有60%，在国内，大型管理软件的运行成功率相当低。 大家已经十分清醒地认识到，造成软件失败的原因是需求分析的问题，但是为什么需求会不准、不全，则莫衷一是。 所谓需求，体现为用户进行业务活动时，要求软件帮助或替代人的一部分工作，所以软件的功能是用户业务活动的电子化体现。这样，对需求的把握完全在于对用户业务活动的清晰程度。 实际上大家都有体会：“没有编不出来得软件，只有说不出来的要求”。可惜的是，大多数软件开发人员并没有把对需求的认识上升到用户业务高度去认识，而是直接从功能角度去体现需求。 本文将结合上期《软件工程大趋势：全程建模》一文，介绍如何运用“全程建模”方法进行需求分析工作。 二 需求分析总体思路 需求分析包括两个阶段，业务分析与需求定义，而业务分析是具有决定性作用的，在此基础上，需求就会十分轻易地“推导”出来。 业务分析的目的是要彻底认识用户业务活动,“全程建模”方法提供了解企业活动的有效手段：以业务流程分析为核心了解企业的业务活动。 在业务流程中业务信息扮演了极其重要的角色：穿针引线。业务信息也可以称做业务数据、业务表单、业务单证（如领料单、记账凭证、销售报表），所以业务单证的分析是在业务流程分析后将自然而然展开。 企业的业务活动是在具体的工作人员之间进行，但是如果企业规模比较大，加之开发人员往往不具备用户的业务背景知识，所以，如果上来就直接分析每个人是如何与其它人合作工作的，往往会掉入具体的“业务泥潭”，工作进展缓慢，常常是匆匆收兵，打道回府，闭门造需求，祸根从此埋下，胡子工程在所难免。 “全程建模”方法为业务流程分析指明了一条循序渐进的通途：以企业组成层次为线索，从宏观、中观、微观剖析企业的业务流程。这样企业的组织结构分析成为进行业务流程分析的前提。 所以，按照“全程建模”方法，业务分析包括三个阶段的工作： 组织结构分析 业务流程分析 业务数据分析 三 业务素材的准备 有企业工作经历的人都知道，业务活动是依据管理制度来进行的，岗位说明书、ISO9000质量体系文件为业务分析提供了很好的素材。 一般来讲，岗位说明书至少包括两方面的内容，一方面描述如何完成本职工作，另一方面描述如何与他人合作。 在ISO9000质量体系文件中，质量手册中的大部分质量要素就是业务活动的分类，在2000版ISO9000中，“质量要素”已经修改为“质量活动”。质量程序文件主要描述的是在岗位间工作交接过程，工作指导书描述的是如何完成本职工作。 下面我们以一个小型商业企业为例，阐述如何进行业务分析和需求定义，首先我们讨论如何进行业务分析，它由三个步骤组成：组织结构分析、业务流程分析、业务数据分析。 三 组织结构分析 手段：利用组成结构树描述企业的组织结构。 目的：全面展开各个岗位的本职工作。 “全程建模”方法指出，应当按部门、岗位、任务、步骤的层次展开组织结构的描述，图1到图4分别描述了企业的部门组成结构、部门的岗位组成结构、岗位的任务组成结构、岗位任务的步骤组成结构。在图4中“记保管帐”这项工作步骤被分解成子步骤。 图 1 企业的部门组成结构 图 2 部门（业务部、财务部）的岗位组成结构 图 3 岗位（保管员）的任务组成结构 图 4 岗位任务（或物出库）的步骤组成结构 四 业务流程分析 手段：利用事件流图、PAD(问题分析图)描述业务流程，利用顺序图验证业务流程。 目的：分门别类描述所有业务活动。 “全程建模”方法指出，业务流程的描述分别在企业间、部门间、岗位间、岗位内等四个层次展开，体现了以宏观、中观、微观方法的观察问题的思路。在进行每个层次的描述之前，都要确定当前层次的业务活动类型，然后以一环紧扣一环的方式把每个业务活动的过程展开，从而得到业务流程的描述。 对本文中的例子而言，在企业间进行的业务活动种类为：销售、采购，在部门间，还将进行财务核算工作。 1企业间的业务流程 图5、图6分别描述了企业间的销售流程、采购流程，图7说明如何用顺序图验证企业间的销售流程。销售流程由事件“订货”、“发货”、“交货款”、“提供收款凭证”组成，每个事件携带业务数据，如“交货款”携带了业务单证“订单”、“发货清单”。 图 5 企业间的销售流程 图 6 企业间的采购流程 图 7 验证企业间的销售流程 2部门间的业务流程 图8描述了企业内部门间的销售流程、采购流程、财务核算流程，图9说明如何用顺序图验证企业内部门间的销售流程。 图 8 部门间的业务流