企业管理软件的需求描述方法.docx

《企业管理软件的需求描述方法.docx》由会员分享，可在线阅读，更多相关《企业管理软件的需求描述方法.docx（14页珍藏版）》请在三一文库上搜索。

1、企业管理软件的需求描述方法摘要本文介绍了企业管理软件需求的 5元素描述法： 组织，流程，功能, 数据，业务逻辑 ，详细介绍了对每个元素的描述方法、5个元素之 间的关系描述方法，提出了针对不同的读者编写不同的需求文档的观 点，并给出了一些提高需求可读性的建议。关键词组织，流程，功能，数据，业务逻辑需求是整个软件项目最关键的一个输入， 据统计，不成功的项目中有 37%的问题是由需求造成的。和传统的硬件生产企业相比较，软件的 需求具有模糊性、不确定性、变化性和主观性的特点，在硬件生产企 业中，产品的需求是明确的、有形的、客观的、可描述的、可检测的， 而软件需求不具备此特征。需求文档作为客户和开发人员

2、、开发人员 之间进行交互的文档，它将系统的需求进行了 固化”，是需求的载体， 其作用是至关重要的。笔者结合多年的企业管理信息系统的开发经 验，总结了如下的需求描述的方法与经验，供各位同行参考。1构成企业管理信息系统的5个基本要素对企业需求的描述可以从2个方面来进行描述，一个方面是对客户现 行系统的描述，一个方面是对系统未来的设想。总的而言，无论是从 那个方面来描述，构成企业信息系统主要包括5个基本要素：企业的 组织结构、流程、数据、商务规则与功能（性能）。其中从用户的角 度主要关注流程，是以流程为核心的，通过流程将其他几个要素贯穿起来，需求分析人员也应该从这个角度来和用户沟通；从开发者的角度主

3、要关注企业的数据、商务规则与功能，以便于系统的实现；从实施者的角度主要关注企业的组织结构与功能， 以便于系统的发布与实 施。茎统、功郁+性酸(图1 )(1) 企业的组织模型即企业的组织结构关系，包括部门设置、岗位设置、岗位职责等。树 型组织结构图是描述企业的组织模型的一种常用方法，它可用来搞清 各部门之间的领导关系，每个部门内部的人员配备情况，职责分工等 情况，它是划分系统范围，进行系统网络规划的基础。在组织结构图中 应将用户的组织结构逐层详细描述，每个部门的职责也应进行简单的 描述。组织结构是用户企业业务流程与信息的载体，对分析人员理解企业的业务、确定系统范围具有很好的帮助。取得用户的组织结

4、构图， 是需求获取步骤中的基础工作之一。用户环境中的企业岗位或角色，和组织机构一样，也是分析人员理解 企业业务的基础，也是分析人员提取对象的基础。 每个岗位的职责可 以进行详细的描述，建议米用表格的形式，如：岗位P所在部门。职茅相关的业务，一采购员口业努部口负麦商品采购、进货合同的线 定、供应商的选择E进货、合同管理e£qP(表1)对用户角色的识别常常遗漏的是计算机系统的系统管理人员，角色识别不全，对以后的功能识别会造成盲区。(2) 企业的流程模型即企业的业务流程，包含哪些流程、流程之间的关系、每个流程中包 括哪些活动、每个活动涉及到的岗位。企业的作业流程首先要有一个 总的业务流程图

5、，将企业中各种业务之间的关系描述出来， 然后对每 种业务进行详细的描述，使业务流程与部门职责结合起来。 详细业务 流程图可以采用直式业务流程图形式， 如图2所示。对企业而言需要 定义关于业务流程图的描述标准， 大家采用相同的图例来描述，便于 管理。（图2）业务流程图的优点：绘图的过程，实际上是作业流程条理化的过程表达形象直观，易于和用户交流，易于项目组内部交流调研的结果，需要得到用户的认同，这就需要和用户交流调研的结果交流的文档要通俗、易懂，不能采用专业术语 可以作为培训实施人员与技术服务人员的文档业务流程图的缺点：时高层管理人员的实际需求调查的不清楚.这一方面是由于用户没有接触过计算机 ，对

6、采用计算机后的管理会 是什么样子？计算机能够完成当前手工操作的哪些内容 ？能够作哪些 现在手工无法完成的工作等等没有清楚的概念，因此用户无法将这些 问题反应出来.另一方面说明分析人员没有经验，对原始材料挖掘不 深，不能从用户提供的材料中提炼处来用户的真正需求 ，不能找到当前 管理中的问题。时各种业务之间的总体关系没有表达出来.采用直式业务流程图可以将企业的每一种业务的处理流程清楚地表 达出来，但是各业务之间的联系却没有表示出来，单看一种业务的流 程图很清楚,但是却不能综合在一起，没有整体的概念，作为需求分析 的文档，在这方面表达的不够完整。旺不利用工具的情况下，画法烦琐。图形可以将流程描述的很

7、清楚，但是还要附加以一些文字说明，如关 于业务发生的频率、意外事故的处理、高峰期的业务频率等，不能在 流程图中描述出的内容，需要用文字进行详细描述。（3）企业的数据模型即企业中的信息载体有哪些？以及对这些信息载体的详细刻画，包括企业的各种单据、帐本、报表的描述。在需求报告中，应该将单据的 描述格式化，需要描述的内容包括：单据的用途，即单据用在什么地方？单据的格式：需要明确的画出来，并有实际的有数据的样例，能够具体直观地说明问题；单据中的数据项的具体描述：长度、类型、计算生成方法、约束条件等；单据的数据项是由哪些不同类型的角色来填写地， 包括用计算机可 以填那些数据项。单据中哪些数据是必填的，哪

8、些是可以不用填的。单据流量：平均每天产生多少条记录，高峰期的数量；单据的分类：可以从多个角度上进行分类，如：按业务类型来分类（采购/销售/生产），按生成的方式来分类（手工录入型/白动生成型）， 按格式变化的频繁程度来分类（易变型/稳定型），按表现形式来分类（列表型/卡片型）等等。单据之间的关系：引用关系等等。同样对于需要的报表与帐本也可以参照上面的条目进行详细的刻画。（4）企业的商务规则模型即企业中的商务规则有哪些？这些规则用在哪些地方？商务规则可以 从影响的范围划分为2类：一类是局部的规则，如不允许出现负库存, 一类是整体的规则，如对所有的物料管理到批次。商务规则一般是隐 藏在功能模型或者流

9、程模型中，不需要单独描述，但是有些复杂的商 务规则是需要单独抽取出来描述，如企业的各种单据记帐的商务逻 辑：库存保管帐库存成成帐5往来帐*采购入库单勰的方法术购发票尸销售发票e销售捏货单"采购付款单销售回款蛰（表2）（5）企业的功能模型功能需求是用户的最主要的需求，对用户功能需求的描述可以采用文 字描述也可以采用语言加图形的描述方式， 只要能够将用户的需求描 述地完整、准确、易于理解即可。对功能需求比较复杂的系统（如超 过10个功能项），可以先描述一个概要，对简单的系统可以直接进行 详细描述。对于用户的功能需求要进行分类，分类的方法应便于用户 理解，如按照用户的部门设置情况，进行描述

10、每个部门的需求，这样也便于组织用户进行评审。以下是分类方法的举例：按部门分类：如采购科、销售科、计划科、生产车间、财务科、统 计科、总经理等；按功能类型分类：如单据录入、单据审核、单据查询、记帐、帐本查询、统计报表、系统维护等;对功能需求的分类在不同的层次可以采用不同的方法。对每一项功能应有一个功能编号，以便于与功能规格说明书中的章节 进行对应。对每一项功能的描述，应指明用户的输入 （input）、处理方 法（process、系统的输出（output）及对此项功能的其他要求。功能需 求还应注明使用此功能的岗位。对系统管理员要求的特殊功能可以在 此注明，非特殊要求可以在需求分析规格说明书中详细论

11、述。如用户权限可分级，要有操作日志等。对具体功能需求采用USE CASE的描述方式不失为一种好的方法， 如：执行者行为系统响应，.发出查询命令EP-提供设置查询条件的界面录A需要的条件；团号？ 日期、线路' 状态列出符合条件的团队列袤，握供两个选择,一查看最蓼团队- 计划（-）查看团队更改记录*可选过程i 4查清最寰团欧诗薄Q显示选择的团队计划召可选迫程m 查着砌吏覆记录卜显示所选团队的更改记录国"（表3）功能需求与性能需求是密不可分的，笼统的性能需求没有任何意思，必须具体到某项功能需求上来，这是分析人员在分析系统时容易忽略的一项对上述的5个基本元素可以将他们描述为一个五元组

12、组织，流程， 功能，数据，业务逻辑，对于用户来讲，他们习惯于从组织维来看 待系统，即某个部门有哪些岗位，每个岗位参与了哪些流程的哪些活 动（功能），在某个功能上操作了哪些数据，对这些数据进行了哪些 逻辑处理；对于开发人员习惯于从功能维来看待系统， 即某个功能操 作了哪些数据，对这些数据进行了哪些逻辑处理， 这个功能属于哪个 流程，可以由哪些岗位来使用；对于设计人员可能习惯于从数据维来 看待系统：即系统中有哪些数据，在这些数据上可以做哪些处理，这 些处理用OO的思想来看即是对数据对象的操作。 对此五个基本元素 之间关系的刻画可以采用矩阵的方式：岗位角色）村业务流程F功能，数据商务规则始£

13、;*府材2（表4）对于上表中列的排列顺序可以根据面向的读者的不同而改变。对以上的5个基本元素进行描述实际上就是系统建模的过程， 为确保模型的可操作性，除了上面的5个基本要素外，还需要重点描述的内容有：（1）新系统对应用模式带来的变化包括对企业的组织结构、作业流程、单据帐本报表等的格式、商务规 则等的改变。(2) 新系统的界面模型用开发工具将用户操作界面快速画出来， 使用户心中有数。若时间允 许，可将界面原型与数据库表、字段连接起来，真正做出系统雏形， 即快速原型法。2阅读需求文档的4类读者需求报告的最终目的是给人来阅读的，所以一定要考虑需求报告的读 者群，有4类角色可能阅读企业管理系统的需求文

14、档：客户与用户业务高层；用户的中层管理人员与具体人员；用户IT主管与开发人员，包括设计人员、编码人员、同行的专家；项目管理人员：包括项目经理、质量保证人员、测试人员、需求管理员、配置管理员、计划人员等等；不同的读者对文档的阅读需求是不同的，他们关注的信息是不同的。我见过了很多次需求评审的失败(如果做好需求评审我会另外再撰文 描述)，总结下来我认为和需求描述没有区分读者群是很有关系的。针对上述的4种分类，我们具体的来分析一下每类读者的特点：(1)客户与用户业务高层他们关心的企业是系统的目标性需求，关心的是系统总体的功能框架，关心的是系统解决了哪些管理问题，对具体的需求是不关心的， 所以给他们阅读

15、的文档应该是从总体上来描述，要高度抽象。由于他们的工作很忙，彳艮难有比较长的时间来读这些材料，所以要简短明了， 能够用1页纸说明问题的就要不要用2页纸，而且一般都要给高层进 行需求汇报，需要配上语言说明，因此采用PowerPiont片子也就成了一种常用的方法，讲解需求与讨论一般应掌握不要超过 1小时。需 求人员常犯的毛病是过多地关注了企业的细节性需求，而忽略系统的目标性需求，所以在安排需求获取的步骤上、 需求报告的编写上往往 没有抓住企业高层最关心的问题、 没有抓住根本性的问题，在给企业 的高层汇报时当然很难通过评审。(2)用户的中层管理人员与具体人员企业的中层管理人员关注的是企业的局部需求，

16、 他们要求对白己的负 责的局部系统能够有总体的了解，能够和其他的子系统衔接的很好， 业务流程很流畅，覆盖了白己需要的所有业务流程， 能够通过系统起 到控制作用就行了。具体的操作人员更关心白己的的哪些活动是否在 系统中都能处理，软件是否可以很容易地操作，他们关注的焦点更具 体，要求更直观。所以对这类的读者可以通过比较详细的文档来描述 需求了，当然应该以他们习惯的思维方式来描述， 不能从开发人员的 角度来描述。我看到过很多几百页的需求文档给用户去阅读、 去评审， 结果要么用户不置可否，要么直接讲看不懂，为什么呢？ 一是开发人 员在文档中分子系统、分模块、分功能点一层深入下去描述，不符合 用户的思维

17、习惯，他们希望能够从业务流程、业务活动的角度来考虑 问题，而不是功能；二是太多了，用户也没有时间静下心来去消化、 吸收如此多的文档，需求毕竟不是小说，能够那么吸引读者。(3) 用户IT主管与开发人员，包括设计人员、编码人员、同行的专 家大多数分析人员可能最擅长的就是些写这类的文档了， 往往也是那这 类的文档给所有的读者看，其问题我们上边都说了，这里我们就不赘 述了。需要注意的是在描述需求时候传统的做法是以功能为主线，来展开描 述，实际上如果是以数据为主线来描述需求也是一种很好的办法，在我们上面谈到的五元组中，从数据的角度来分析系统可以更容易实现 向OOA、OOD的切换。(4) 项目管理人员：包

18、括项目经理、质量保证人员、测试人员、需 求管理员、配置管理员、计划人员等等 把拿给开发人员看的需求文档给管理人员看， 这也是分析人员常犯的 毛病。管理人员实际上最关心的是需求列表，如下表所示:序号丁w wtw vtrrv -a .需求呢功能、特性)功能描述忧先汲p+3qqQ4P（表5）在此基础上项目经理、质量保证人员可以据此来进入项目策划过程， 测试人员可据此进入测试策划过程， 需求管理员、配置管理员可以识 别配置项制定相关的活动计划。没有这张表管理人员就很难高效地开 展他们的管理活动，也就谈不到最基本的需求复用了。在上述的表中, 需求的优先级是很重要的一列，对项目经理进行项目管理的平衡决策

19、是很重要的，实际上需求的优先级可能比需求本身更重要。根据上面描述的论述，我们可以看出需求文档不是一个文档，而是多个文档，如：序号z文愣建议的格式，目标读者府1P目标与范困描述文 档中PPT文件用户品层与客户用户需求报告#WORD. VISO5C件疽段用户q需求规格定义，,WORD、VISIO 文件/IT主管、开发人员、额域专叙需求列表qEXCEL-、管理人员:（表6）3需求描述的表示技巧上面我们谈到了，需求文档是人与人之间交互的文档， 是不同类型的人之间交互的文档，因此需求文档的可读性是一个很重要的方面，为了提高文档的可读性可以借鉴下面的一些做法：在文档的描述中，适当运用链接，增强文档的可读性

20、；多用图表，如某企业的业务与票据之间的关联关系可以用矩阵的方式描述为：进货方式_!发票联fttglfi联进货报单佻采里代销验收单已销得姬知单+正常经销1 77。4X J代销进货1 Vd4J*1延期付款上瑚 对 入>j（表7）多用穷举的方式，以便于发现遗漏的需求；通过适当的换行来提高可读性 ；采用黑体、斜体、下划线、颜色等多种方式来突出重要内容；定义标准的术语，以减少二义性，减少文档的页数；在功能需求的描述中，对于类似的、统一的功能可以单独地进行详细描述，其他地方进行引用，或做为术语进行定义，以简化文档，减少重复。如；2录入功能2打印功能2条件查询功能2排序功能等等结语尽管你按照上述的方法去做了，也不要期望能够编写出一份能体现需求应具备的所有特性的文档，无论你如何去细化、分析、评论和优化需求，都不可能达到完美，但是你能够做到 可接受”，写一份客户、用户、开发人员、管理人员都认可的一份需求，而不是完美的需求！