第1个回答 2006-07-09
这个问题回答的很好！佩服！
第2个回答 推荐于2017-12-16
构成企业管理信息系统的5个基本要素
构成企业信息系统主要包括5个基本要素：企业的组织结构、流程、数据、商务规则与功能（性能）。其中从用户的角度主要关注流程，是以流程为核心的，通过流程将其他几个要素贯穿起来，需求分析人员也应该从这个角度来和用户沟通；从开发者的角度主要关注企业的数据、商务规则与功能，以便于系统的实现；从实施者的角度主要关注企业的组织结构与功能，以便于系统的发布与实施。
1） 企业的组织模型
即企业的组织结构关系，包括部门设置、岗位设置、岗位职责等。树型组织结构图是描述企业的组织模型的一种常用方法，它可用来搞清各部门之间的领导关系,每个部门内部的人员配备情况, 职责分工等情况,它是划分系统范围,进行系统网络规划的基础。在组织结构图中应将用户的组织结构逐层详细描述，每个部门的职责也应进行简单的描述。组织结构是用户企业业务流程与信息的载体，对分析人员理解企业的业务、确定系统范围具有很好的帮助。取得用户的组织结构图，是需求获取步骤中的基础工作之一。
用户环境中的企业岗位或角色，和组织机构一样，也是分析人员理解企业业务的基础，也是分析人员提取对象的基础。
对用户角色的识别常常遗漏的是计算机系统的系统管理人员，角色识别不全，对以后的功能识别会造成盲区。
（2） 企业的流程模型
即企业的业务流程，包含哪些流程、流程之间的关系、每个流程中包括哪些活动、每个活动涉及到的岗位。企业的作业流程首先要有一个总的业务流程图，将企业中各种业务之间的关系描述出来，然后对每种业务进行详细的描述，使业务流程与部门职责结合起来。详细业务流程图可以采用直式业务流程图形式。对企业而言需要定义关于业务流程图的描述标准，大家采用相同的图例来描述，便于管理。
业务流程图的优点 :
■绘图的过程,实际上是作业流程条理化的过程
■表达形象直观,易于和用户交流,易于项目组内部交流
调研的结果,需要得到用户的认同,这就需要和用户交流调研的结果,交流的文
档要通俗、易懂, 不能采用专业术语。
■可以作为培训实施人员与技术服务人员的文档
业务流程图的缺点 :
■对高层管理人员的实际需求调查的不清楚.
这一方面是由于用户没有接触过计算机, 对采用计算机后的管理会是什么样子?计算机能够完成当前手工操作的哪些内容?能够作哪些现在手工无法完成的工作等等没有清楚的概念,因此用户无法将这些问题反应出来. 另一方面说明分析人员没有经验,对原始材料挖掘不深,不能从用户 提供的材料中提炼处来用户的真正需求,不能找到当前管理中的问题。
■对各种业务之间的总体关系没有表达出来.
采用直式业务流程图可以将企业的每一种业务的处理流程清楚地表达出来, 但是各业务之间的联系却没有表示出来,单看一种业务的流程图很清楚,但是却不能综合在一起,没有整体的概念,作为需求分析的文档,在这方面表达的不够完整。
■在不利用工具的情况下,画法烦琐。
图形可以将流程描述的很清楚，但是还要附加以一些文字说明，如关于业务发生的频率、意外事故的处理、高峰期的业务频率等，不能在流程图中描述出的内容，需要用文字进行详细描述。
（3） 企业的数据模型
即企业中的信息载体有哪些？以及对这些信息载体的详细刻画，包括企业的各种单据、帐本、报表的描述。在需求报告中，应该将单据的描述格式化，需要描述的内容包括：
单据的用途，即单据用在什么地方？
单据的格式：需要明确的画出来，并有实际的有数据的样例，能够具体直观地说明问题；
单据中的数据项的具体描述：长度、类型、计算生成方法、约束条件等；
单据的数据项是由哪些不同类型的角色来填写地，包括用计算机可以填那些数据项。
单据中哪些数据是必填的，哪些是可以不用填的。
单据流量：平均每天产生多少条记录，高峰期的数量；
单据的分类：可以从多个角度上进行分类，如：按业务类型来分类（采购/销售/生产），按生成的方式来分类（手工录入型/自动生成型），按格式变化的频繁程度来分类（易变型/稳定型），按表现形式来分类（列表型/卡片型）等等。
单据之间的关系：引用关系等等。
同样对于需要的报表与帐本也可以参照上面的条目进行详细的刻画。
（4） 企业的商务规则模型
即企业中的商务规则有哪些?这些规则用在哪些地方? 商务规则可以从影响的范围划分为2类：一类是局部的规则，如不允许出现负库存，一类是整体的规则，如对所有的物料管理到批次。商务规则一般是隐藏在功能模型或者流程模型中，不需要单独描述，但是有些复杂的商务规则是需要单独抽取出来描述，如企业的各种单据记帐的商务逻辑，5）企业的功能模型
功能需求是用户的最主要的需求，对用户功能需求的描述可以采用文字描述也可以采用语言加图形的描述方式，只要能够将用户的需求描述地完整、准确、易于理解即可。对功能需求比较复杂的系统（如超过10个功能项），可以先描述一个概要，对简单的系统可以直接进行详细描述。对于用户的功能需求要进行分类，分类的方法应便于用户理解，如按照用户的部门设置情况，进行描述每个部门的需求，这样也便于组织用户进行评审。以下是分类方法的举例：
按部门分类：如采购科、销售科、计划科、生产车间、财务科、统计科、总经理等；
按功能类型分类：如单据录入、单据审核、单据查询、记帐、帐本查询、统计报表、系统维护等。
对功能需求的分类在不同的层次可以采用不同的方法。
对每一项功能应有一个功能编号，以便于与功能规格说明书中的章节进行对应。对每一项功能的描述，应指明用户的输入(input)、处理方法（process）、系统的输出(output)及对此项功能的其他要求。功能需求还应注明使用此功能的岗位。对系统管理员要求的特殊功能可以在此注明，非特殊要求可以在需求分析规格说明书中详细论述。如用户权限可分级，要有操作日志等。
功能需求与性能需求是密不可分的，笼统的性能需求没有任何意思，必须具体到某项功能需求上来，这是分析人员在分析系统时容易忽略的一项。
对上述的5个基本元素可以将他们描述为一个五元组〈组织，流程，功能，数据，业务逻 辑〉，对于用户来讲，他们习惯于从组织维来看待系统，即某个部门有哪些岗位，每个岗位参与了哪些流程的哪些活动（功能），在某个功能上操作了哪些数据，对这些数据进行了哪些逻辑处理；对于开发人员习惯于从功能维来看待系统，即某个功能操作了哪些数据，对这些数据进行了哪些逻辑处理，这个功能属于哪个流程，可以由哪些岗位来使用；对于设计人员可能习惯于从数据维来看待系统：即系统中有哪些数据，在这些数据上可以做哪些处理，这些处理用OO的思想来看即是对数据对象的操作。
对以上的5个基本元素进行描述实际上就是系统建模的过程，为确保模型的可操作性，除了上面的5个基本要素外，还需要重点描述的内容有：
（1） 新系统对应用模式带来的变化
包括对企业的组织结构、作业流程、单据帐本报表等的格式、商务规则等的改变。
（2） 新系统的界面模型
用开发工具将用户操作界面快速画出来，使用户心中有数。若时间允许，可将界面原型与数据库表、字段连接起来，真正做出系统雏形，即快速原型法。
构成企业信息系统主要包括5个基本要素：企业的组织结构、流程、数据、商务规则与功能（性能）。其中从用户的角度主要关注流程，是以流程为核心的，通过流程将其他几个要素贯穿起来，需求分析人员也应该从这个角度来和用户沟通；从开发者的角度主要关注企业的数据、商务规则与功能，以便于系统的实现；从实施者的角度主要关注企业的组织结构与功能，以便于系统的发布与实施。
1） 企业的组织模型
即企业的组织结构关系，包括部门设置、岗位设置、岗位职责等。树型组织结构图是描述企业的组织模型的一种常用方法，它可用来搞清各部门之间的领导关系,每个部门内部的人员配备情况, 职责分工等情况,它是划分系统范围,进行系统网络规划的基础。在组织结构图中应将用户的组织结构逐层详细描述，每个部门的职责也应进行简单的描述。组织结构是用户企业业务流程与信息的载体，对分析人员理解企业的业务、确定系统范围具有很好的帮助。取得用户的组织结构图，是需求获取步骤中的基础工作之一。
用户环境中的企业岗位或角色，和组织机构一样，也是分析人员理解企业业务的基础，也是分析人员提取对象的基础。
对用户角色的识别常常遗漏的是计算机系统的系统管理人员，角色识别不全，对以后的功能识别会造成盲区。
（2） 企业的流程模型
即企业的业务流程，包含哪些流程、流程之间的关系、每个流程中包括哪些活动、每个活动涉及到的岗位。企业的作业流程首先要有一个总的业务流程图，将企业中各种业务之间的关系描述出来，然后对每种业务进行详细的描述，使业务流程与部门职责结合起来。详细业务流程图可以采用直式业务流程图形式。对企业而言需要定义关于业务流程图的描述标准，大家采用相同的图例来描述，便于管理。
业务流程图的优点 :
■绘图的过程,实际上是作业流程条理化的过程
■表达形象直观,易于和用户交流,易于项目组内部交流
调研的结果,需要得到用户的认同,这就需要和用户交流调研的结果,交流的文
档要通俗、易懂, 不能采用专业术语。
■可以作为培训实施人员与技术服务人员的文档
业务流程图的缺点 :
■对高层管理人员的实际需求调查的不清楚.
这一方面是由于用户没有接触过计算机, 对采用计算机后的管理会是什么样子?计算机能够完成当前手工操作的哪些内容?能够作哪些现在手工无法完成的工作等等没有清楚的概念,因此用户无法将这些问题反应出来. 另一方面说明分析人员没有经验,对原始材料挖掘不深,不能从用户 提供的材料中提炼处来用户的真正需求,不能找到当前管理中的问题。
■对各种业务之间的总体关系没有表达出来.
采用直式业务流程图可以将企业的每一种业务的处理流程清楚地表达出来, 但是各业务之间的联系却没有表示出来,单看一种业务的流程图很清楚,但是却不能综合在一起,没有整体的概念,作为需求分析的文档,在这方面表达的不够完整。
■在不利用工具的情况下,画法烦琐。
图形可以将流程描述的很清楚，但是还要附加以一些文字说明，如关于业务发生的频率、意外事故的处理、高峰期的业务频率等，不能在流程图中描述出的内容，需要用文字进行详细描述。
（3） 企业的数据模型
即企业中的信息载体有哪些？以及对这些信息载体的详细刻画，包括企业的各种单据、帐本、报表的描述。在需求报告中，应该将单据的描述格式化，需要描述的内容包括：
单据的用途，即单据用在什么地方？
单据的格式：需要明确的画出来，并有实际的有数据的样例，能够具体直观地说明问题；
单据中的数据项的具体描述：长度、类型、计算生成方法、约束条件等；
单据的数据项是由哪些不同类型的角色来填写地，包括用计算机可以填那些数据项。
单据中哪些数据是必填的，哪些是可以不用填的。
单据流量：平均每天产生多少条记录，高峰期的数量；
单据的分类：可以从多个角度上进行分类，如：按业务类型来分类（采购/销售/生产），按生成的方式来分类（手工录入型/自动生成型），按格式变化的频繁程度来分类（易变型/稳定型），按表现形式来分类（列表型/卡片型）等等。
单据之间的关系：引用关系等等。
同样对于需要的报表与帐本也可以参照上面的条目进行详细的刻画。
（4） 企业的商务规则模型
即企业中的商务规则有哪些?这些规则用在哪些地方? 商务规则可以从影响的范围划分为2类：一类是局部的规则，如不允许出现负库存，一类是整体的规则，如对所有的物料管理到批次。商务规则一般是隐藏在功能模型或者流程模型中，不需要单独描述，但是有些复杂的商务规则是需要单独抽取出来描述，如企业的各种单据记帐的商务逻辑，5）企业的功能模型
功能需求是用户的最主要的需求，对用户功能需求的描述可以采用文字描述也可以采用语言加图形的描述方式，只要能够将用户的需求描述地完整、准确、易于理解即可。对功能需求比较复杂的系统（如超过10个功能项），可以先描述一个概要，对简单的系统可以直接进行详细描述。对于用户的功能需求要进行分类，分类的方法应便于用户理解，如按照用户的部门设置情况，进行描述每个部门的需求，这样也便于组织用户进行评审。以下是分类方法的举例：
按部门分类：如采购科、销售科、计划科、生产车间、财务科、统计科、总经理等；
按功能类型分类：如单据录入、单据审核、单据查询、记帐、帐本查询、统计报表、系统维护等。
对功能需求的分类在不同的层次可以采用不同的方法。
对每一项功能应有一个功能编号，以便于与功能规格说明书中的章节进行对应。对每一项功能的描述，应指明用户的输入(input)、处理方法（process）、系统的输出(output)及对此项功能的其他要求。功能需求还应注明使用此功能的岗位。对系统管理员要求的特殊功能可以在此注明，非特殊要求可以在需求分析规格说明书中详细论述。如用户权限可分级，要有操作日志等。
功能需求与性能需求是密不可分的，笼统的性能需求没有任何意思，必须具体到某项功能需求上来，这是分析人员在分析系统时容易忽略的一项。
对上述的5个基本元素可以将他们描述为一个五元组〈组织，流程，功能，数据，业务逻 辑〉，对于用户来讲，他们习惯于从组织维来看待系统，即某个部门有哪些岗位，每个岗位参与了哪些流程的哪些活动（功能），在某个功能上操作了哪些数据，对这些数据进行了哪些逻辑处理；对于开发人员习惯于从功能维来看待系统，即某个功能操作了哪些数据，对这些数据进行了哪些逻辑处理，这个功能属于哪个流程，可以由哪些岗位来使用；对于设计人员可能习惯于从数据维来看待系统：即系统中有哪些数据，在这些数据上可以做哪些处理，这些处理用OO的思想来看即是对数据对象的操作。
对以上的5个基本元素进行描述实际上就是系统建模的过程，为确保模型的可操作性，除了上面的5个基本要素外，还需要重点描述的内容有：
（1） 新系统对应用模式带来的变化
包括对企业的组织结构、作业流程、单据帐本报表等的格式、商务规则等的改变。
（2） 新系统的界面模型
用开发工具将用户操作界面快速画出来，使用户心中有数。若时间允许，可将界面原型与数据库表、字段连接起来，真正做出系统雏形，即快速原型法。
参考资料：Sawin系统分析之窗 [作 者] 任甲林
本回答被网友采纳
相似回答
