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

《企业管理软件需求描述方法》由会员分享，可在线阅读，更多相关《企业管理软件需求描述方法（12页珍藏版）》请在装配图网上搜索。

1、企业管理软件需求描述方法V:1.0 精选管理制度企业管理软件的需求描述方法2021- -6 6- -8 8企业管理软件的需求描述方法 企业管理软件的需求描述方法 摘要本文介绍了企业管理软 件需求的5元素描述法：<；组织流程功能数据业务逻辑详细介 绍了对每个元素的描述方法、5个元素之间的关系描述方法提出 了针对不同的读者编写不同的需求文档的观点并给出了一些提高 需求可读性的建议。关键词 组织流程功能数据业务逻辑需求是整个软件项目最关键的一个输入据统计不成功的项目 中有 37%的问题是由需求造成的。和传统的硬件生产企业相比较 软件的需求具有模糊性、不确定性、变化性和主观性的特点在硬 件生产企业

2、中产品的需求是明确的、有形的、客观的、可描述 的、可检测的而软件需求不具备此特征。需求文档作为客户和开 发人员、开发人员之间进行交互的文档它将系统的需求进行了 “固化”是需求的载体其作用是至关重要的。笔者结合多年的企 业管理信息系统的开发经验总结了如下的需求描述的方法与经验 供各位同行参考。1 构成企业管理信息系统的 5 5个基本要素 对企业需求的 描述可以从 2个方面来进行描述一个方面是对客户现行系统的描 述一个方面是对系统未来的设想。总的而言无论是从那个方面来 描述构成企业信息系统主要包括 5个基本要素：企业的组织结 构、流程、数据、商务规则与功能（性能）。其中从用户的角度 主要关注流程是

3、以流程为核心的通过流程将其他几个要素贯穿起 来需求分析人员也应该从这个角度来和用户企业管理软件的需求描述方法沟通；从开发者的角度主要关注企业的数据、商务规则与功 能以便于系统的实现；从实施者的角度主要关注企业的组织结构 与功能以便于系统的发布与实施。（图 1）（1 1）企业的组织模型 即企业的组织结构关系包括部门设置、岗位 设置、岗位职责等。树型组织结构图是描述企业的组织模型的一 种常用方法它可用来搞清各部门之间的领导关系,每个部门内部的 人员配备情况,职责分工等情况,它是划分系统范围,进行系统网 络规划的基础。在组织结构图中应将用户的组织结构逐层详细描 述每个部门的职责也应进行简单的描述。组

4、织结构是用户企业业 务流程与信息的载体对分析人员理解企业的业务、确定系统范围 具有很好的帮助。取得用户的组织结构图是需求获取步骤中的基 础工作之一。用户环境中的企业岗位或角色和组织机构一样也是分析人员 理解企业业务的基础也是分析人员提取对象的基础。每个岗位的 职责可以进行详细的描述建议采用表格的形式如：（表 1） 对用户角色的识别常常遗漏的是计算机系统的系统管理人员 角色识别不全对以后的功能识别会造成盲区。企业管理软件的需求描述方法（2 2）企业的流程模型 即企业的业务流程包含哪些流程、流程之间 的关系、每个流程中包括哪些活动、每个活动涉及到的岗位。企 业的作业流程首先要有一个总的业务流程图将

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

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

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

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

9、务规则一般是隐藏在功能模型或者流程模型中不 需要单独描述但是有些复杂的商务规则是需要单独抽取出来描述 如企业的各种单据记帐的商务逻辑：（表 2）（5 5 ）企业的功能模型 功能需求是用户的最主要的需求对 用户功能需求的描述可以采用文字描述也企业管理软件的需求描述方法可以采用语言加图形的描述方式只要能够将用户的需求描述 地完整、准确、易于理解即可。对功能需求比较复杂的系统（如 超过 10个功能项）可以先描述一个概要对简单的系统可以直接 进行详细描述。对于用户的功能需求要进行分类分类的方法应便 于用户理解如按照用户的部门设置情况进行描述每个部门的需求 这样也便于组织用户进行评审。以下是分类方法的举

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

11、CASE的描述方式不失为一种好的 方法如：（表 3）功能需求与性能需求是密不可分的笼统的性能需求没有任何 意思必须具体到某项功能需求上来这是分析人员在分析系统时容 易忽略的一项。企业管理软件的需求描述方法对上述的 5个基本元素可以将他们描述为一个五元组组织 流程功能数据业务逻辑对于用户来讲他们习惯于从组织维来看 待系统即某个部门有哪些岗位每个岗位参与了哪些流程的哪些活 动（功能）在某个功能上操作了哪些数据对这些数据进行了哪些 逻辑处理；对于开发人员习惯于从功能维来看待系统即某个功能 操作了哪些数据对这些数据进行了哪些逻辑处理这个功能属于哪 个流程可以由哪些岗位来使用；对于设计人员可能习惯于从数

12、据 维来看待系统：即系统中有哪些数据在这些数据上可以做哪些处 理这些处理用00的思想来看即是对数据对象的操作。对此五个 基本元素之间关系的刻画可以采用矩阵的方式：（表 4） 对于上表中列的排列顺序可以根据面向的读者的不同而改 变。对以上的 5个基本元素进行描述实际上就是系统建模的过程 为确保模型的可操作性除了上面的 5个基本要素外还需要重点描 述的内容有：（1） 新系统对应用模式带来的变化 包括对企业的组织结构、作业 流程、单据帐本报表等的格式、商务规则等的改变。（2） 新系统的界面模型 用开发工具将用户操作界面快速画出来使 用户心中有数。若时间允许可将企业管理软件的需求描述方法 界面原型与数

13、据库表、字段连接起来真正做出系统雏形即快 速原型法。2 阅读需求文档的 4 4 类读者 需求报告的最终目的是给人来阅读的所以一定要考虑需求报 告的读者群有 4类角色可能阅读企业管理系统的需求文档：客户与用户业务高层； 用户的中层管理人员与具体人员；用户IT主管与开发人员包括设计人员、编码人员、同行的 专家；项目管理人员：包括项目经理、质量保证人员、测试人员、 需求管理员、配置管理员、计划人员等等； 不同的读者对文档的 阅读需求是不同的他们关注的信息是不同的。我见过了很多次需 求评审的失败（如果做好需求评审我会另外再撰文描述）总结下 来我认为和需求描述没有区分读者群是很有关系的。针对上述的 4种

14、分类我们具体的来分析一下每类读者的特点：（1）客户与用户业务高层 他们关心的企业是系统的目标性需求关 心的是系统总体的功能框架关心的是系统解决了哪些管理问题对 具体的需求是不关心的所以给他们阅读的文档应该是从总体上来 描述要高度抽象。由于他们的工作很忙很难有比较长的时间来读 这些材料所以要简短明了能够用 1页纸说明问题的就要不要用 2 页纸而且一般都要给高层进行需求汇报需要配上语言说明因此采 用企业管理软件的需求描述方法PowerPiont 片子也就成了一种常用的方法讲解需求与讨论一 般应掌握不要超过 1 小时。需求人员常犯的毛病是过多地关注了 企业的细节性需求而忽略系统的目标性需求所以在安排

15、需求获取 的步骤上、需求报告的编写上往往没有抓住企业高层最关心的问 题、没有抓住根本性的问题在给企业的高层汇报时当然很难通过 评审。（2）用户的中层管理人员与具体人员 企业的中层管理人员 关注的是企业的局部需求他们要求对自己的负责的局部系统能够 有总体的了解能够和其他的子系统衔接的很好业务流程很流畅覆 盖了自己需要的所有业务流程能够通过系统起到控制作用就行 了。具体的操作人员更关心自己的的哪些活动是否在系统中都能 处理软件是否可以很容易地操作他们关注的焦点更具体要求更直 观。所以对这类的读者可以通过比较详细的文档来描述需求了当 然应该以他们习惯的思维方式来描述不能从开发人员的角度来描 述。我看

16、到过很多几百页的需求文档给用户去阅读、去评审结果 要么用户不置可否要么直接讲看不懂为什么呢一是开发人员在文 档中分子系统、分模块、分功能点一层深入下去描述不符合用户 的思维习惯他们希望能够从业务流程、业务活动的角度来考虑问 题而不是功能；二是太多了用户也没有时间静下心来去消化、吸 收如此多的文档需求毕竟不是小说能够那么吸引读者。（3）用户 IT 主管与开发人员包括设计人员、编码人员、同 行的专家企业管理软件的需求描述方法大多数分析人员可能最擅长的就是些写这类的文档了往往也 是那这类的文档给所有的读者看其问题我们上边都说了这里我们 就不赘述了。需要注意的是在描述需求时候传统的做法是以功能为主线来

17、 展开描述实际上如果是以数据为主线来描述需求也是一种很好的 办法在我们上面谈到的五元组中从数据的角度来分析系统可以更 容易实现向 OOA、OOD 的切换。（4）项目管理人员：包括项目经理、质量保证人员、测试人员、 需求管理员、配置管理员、计划人员等等 把拿给开发人员看的需 求文档给管理人员看这也是分析人员常犯的毛病。管理人员实际 上最关心的是需求列表如下表所示：（表 5）在此基础上项目经理、质量保证人员可以据此来进入项目策 划过程测试人员可据此进入测试策划过程需求管理员、配置管理 员可以识别配置项制定相关的活动计划。没有这张表管理人员就 很难高效地开展他们的管理活动也就谈不到最基本的需求复用

18、了。在上述的表中需求的优先级是很重要的一列对项目经理进行 项目管理的平衡决策是很重要的实际上需求的优先级可能比需求 本身更重要。根据上面描述的论述我们可以看出需求文档不是一个文档而 是多个文档如：企业管理软件的需求描述方法（表 6）3 需求描述的表示技巧上面我们谈到了需求文档是人与人之间交互的文档是不同类 型的人之间交互的文档因此需求文档的可读性是一个很重要的方 面为了提高文档的可读性可以借鉴下面的一些做法：多用图表如某企业的业务与票据之间的关联关系可以用矩阵的方式描述为：（表 7）多用穷举的方式以便于发现遗漏的需求；通过适当的换行来提高可读性 ； 采用黑体、斜体、下划线、颜色等多种方式来突出重要内 容；定义标准的术语以减少二义性减少文档的页数； 在功能需求 的描述中对于类似的、统一的功能可以单独地进行详细描述其他 地方进行引用或做为术语进行定义以简化文档减少重复。如； 2 录入功能 2 打印功能 2 条件查询功能企业管理软件的需求描述方法2 排序功能等等结语语尽管你按照上述的方法去做了也不要期望能够编写出一份能 体现需求应具备的所有特性的文档无论你如何去细化、分析、评 论和优化需求都不可能达到完美但是你能够做到”;可接受”写一 份客户、用户、开发人员、管理人员都认可的一份需求而不是完 美的需求！