工作流系统需求分析
业务过程描述：
工作流是一种反映业务流程的计算机化的、实现经营过程集成与经营过程自动化而建立的可由工作流管理系统执行的业务模型。工作流起源于生产组织和办公自动化领域，其目的是将现有工作分解，按照一定的规则和过程来执行并监控，提高效率，降低成本。
下图是用户使用工作流系统的业务过程：
业务模型描述：
系统组成：
工作流管理系统由客户端、流程定制工具、流程监控与管理和工作流运行服务四个部分组成，下图是系统构件图：
系统功能划分：
工作流管理系统是指运行在一个或多个工作流引擎的软件上用于定义、实现和管理工作流运行的一套软件，从用户建模的过程来看在建立阶段功能主要是工作流过程和相关活动的定义和建模，在运行阶段包括运行流程的监控、管理以及执行过程中的人机交互等。
工作流管理系统由流程定制工具、流程监控与管理、工作流运行服务和客户端交互四个部分组成，整个系统的使用者可以分为四种：系统管理员、流程设计人员、流程管理人员、普通用户。
下图是整个工作流管理系统的顶层用例：
第一部分流程定制工具
本部分主要完成企业信息流中业务过程的图形化建模，定制工具提供丰富的图形化元素、简单易懂的建模方法以及完善的模型管理方式。
流程定制用例图：
打开流程模型
参与者：流程设计者。
前置条件：流程定制工具已经打开。
后置条件：被选择的流程模型中的内容被展开。
步骤序列：
1．打开流程模型列表或新建流程模型文件。
2．选择流程模型文件名称。
3．展开流程模型中的设计内容。
保存流程模型
参与者：流程设计者。
前置条件：某个流程模型已经被打开，并且被修改。
后置条件：修改过的流程模型存到了物理文件中。
步骤序列：
1．保存流程模型到物理文件中。
删除流程模型
参与者：流程设计者。
前置条件：拥有可被删除的流程模型。
后置条件：选中的流程模型被删除。
步骤序列：
1．用户打开流程模型列表。
2．用户选择想要删除的流程模型。
3．系统删除选中的流程模型。
导入导出流程模型
参与者：流程设计者。
前置条件：拥有可被导入的文件或导出的流程模型。
后置条件：流程模型被导出成文件或模型文件被导入到设计系统成为流程模型。
步骤序列：
1．用户打开可被导入文件列表或设计工具中的流程模型列表。
2．用户选择将被导入的流程文件或选择将被导出的流程模型。
3．系统把导入文件生成流程模型或把导出流程模型生成流程文件。
流程发布
参与者：流程设计者。
前置条件：拥有设计完成并可供发布的流程模型。
后置条件：流程模型被发布并可通过客户工具执行。
步骤序列：
1．用户打开流程模型列表。
2．用户选择发布的包或流程。
3．用户选择发布的运行服务器。
4．用户形成发布版本。
5．用户发布流程。
流程卸载
参与者：流程设计者。
前置条件：运行服务器上拥有发布的流程，并且卸载的流程当前没有运行实例。
后置条件：选中的流程被卸载。
步骤序列：
1．用户打开运行服务器中发布并且当前没有运行实例的流程列表。
2．用户选择要被卸载的流程。
3．卸载流程。
定制包
参与者：流程设计者。
前置条件：设计工具中有包图形元素，流程模型已经打开。
后置条件：在流程模型中定义了包。
步骤序列：
1．打开已有包或新建一个包。
2．用户添写包基本属性，包括名称、描述、创建者、创建时间等。
3．用户添写包版本信息。
4．完成包的定制。
定制流程
参与者：流程设计者。
前置条件：设计工具中有流程元素，流程模型、包已经打开。
后置条件：在流程模型中的包中定义了流程。
步骤序列：
1．打开已有包中的已有流程或在包中新建一个流程。
2．用户添写流程基本属性，包括流程名称、描述、创建者、创建时间、是否为子流程等。
3．用户设计流程中工作流相关信息，包括流程数据定义、流程输入输出参数定义、流程操作时限设置、流程事件定义、流程模型验证等。
4．完成流程的定制。
定制任务（活动）
参与者：流程设计者。
前置条件：设计工具中有各种活动结点、转移等图形元素，流程模型、包、流程已经打开。
后置条件：在流程模型中的包的流程中定义了活动结点。
步骤序列：
1．用户打开已有包中流程的已有活动结点或新建活动结点。
2．用户添写活动结点基本属性，包括活动名称、描述等。
3．用户设计活动中的工作流相关信息，包括活动数据定义、活动优先级别设置、路由信息、子流程调用、表单关联、任务通知设置、活动时限设置、参与者定义等。
4．用户设计活动结点间的转移信息，包括转移名称、描述、转移类型及转移条件。
5．完成活动的定制。
第二部分流程监控与管理
本部分对工作流在整个组织内的流动状况进行监视，并提供一系列的管理功能，实现安全性、过程控制和授权操作等方面的管理，同时还提供工作流相关的各类指标统计等。
流程监控与管理用例图：
监查已启动流程实例
参与者：流程管理者。
前置条件：流程监控管理工具已经打开，拥有表现流程运行状况的所有图形元素，包括不同状态下的流程、活动、转移等。
后置条件：监查到启动流程的实例运行情况。
步骤序列：
1．进入监查界面。
2．用户输入复杂查询条件获得启动流程运行实例列表。
3．用户选择想要监查的流程运行实例。
4．系统展开选中的流程运行实例。
5．关闭流程实例并退出监查界面。
查询历史流程实例
参与者：流程管理者。
前置条件：流程监控管理工具已经打开，拥有表现流程运行状况的所有图形元素，包括不同状态下的流程、活动、转移等。
后置条件：查询到历史流程实例的运行情况。
步骤序列：
1．进入历史流程查询界面。
2．用户输入复杂查询条件获得历史流程实例列表。
3．用户选择想要查询的历史流程实例。
4．系统展开选中流程获得实例详细信息。
5．关闭流程实例并退出查询界面。
各项指标统计
参与者：流程管理者。
前置条件：流程监控管理工具已经打开，拥有表现统计信息的各种图形元素，包括直方图、曲线图、列表等。
后置条件：获得了指标统计信息。
步骤序列：
1．进入指标统计界面。
2．用户输入指标及统计选项。指标有流程实例相关统计、活动实例相关统计、工作项统计、超时统计、系统负载统计等。
3．用户获得相应统计信息。
4．退出指标统计界面。
设置系统权限
参与者：流程管理者。
前置条件：流程监控管理工具已经打开，参与者拥有设置系统权限的权限。
后置条件：对系统权限进行了增删改操作。
步骤序列：
1．进入系统权限设置界面。
2．用户选择要进行的系统工作内容，包括组织机构维护、角色维护、子系统权限设置等。
3．用户设置选中的系统管理内容。
4．退出系统权限设置界面。
设置流程权限
参与者：流程管理者。
前置条件：流程监控管理工具已经打开，参与者拥有设置流程权限的权限。
后置条件：对流程权限进行了增删改操作。
步骤序列：
1．进入流程权限设置界面，并获得了流程列表。
2．用户选择要进行权限设置的流程。
3．用户设置选中的流程权限。
4．退出流程权限设置界面。
查询流程
参与者：流程管理者。
前置条件：流程监控管理工具已经打开。
后置条件：用户获取到的流程基本信息。
步骤序列：
1．用户输入复杂查询条件获得流程列表。
启动流程
参与者：流程管理者。
前置条件：流程监控管理工具已经打开。
后置条件：用户启动了一个流程。
步骤序列：
1．进入流程启动界面。
2．用户输入复杂查询条件获得可被启动的流程列表。
3．用户从列表中选择要启动的流程。
4．系统启动用户选中的流程，并分配好工作项。
5．退出流程启动界面。
挂起流程
参与者：流程管理者。
前置条件：流程监控管理工具已经打开。
后置条件：用户挂起了一个流程实例，使用其不能被普通用户使用。
步骤序列：
1．进入流程挂起界面。
2．用户输入复杂查询条件获得运行服务中的运行流程实例列表。
3．用户从列表中选择要挂起的流程实例。
4．系统挂起用户选中的流程实例。
5．退出流程挂起界面。
恢复流程
参与者：流程管理者。
前置条件：流程监控管理工具已经打开。
后置条件：用户恢复了一个挂起的流程。
步骤序列：
1．进入流程恢复界面。
2．用户输入复杂查询条件获得运行服务中挂起的流程实例列表。
3．用户从列表中选择要恢复的流程实例。
4．系统恢复用户选中的流程实例。
5．退出流程恢复界面。
终止流程
参与者：流程管理者。
前置条件：流程监控管理工具已经打开。
后置条件：用户终止了一个运行中的流程实例。
步骤序列：
1．进入流程终止界面。
2．用户输入复杂查询条件获得运行服务中的流程实例列表。
3．用户从列表中选择要终止的流程实例。
4．系统终止用户选中的流程实例。
5．退出流程终止界面。
回收垃圾工作项
参与者：流程管理者。
前置条件：流程监控管理工具已经打开。
后置条件：用户回收了垃圾工作项。
步骤序列：
1．进入回收垃圾工作项界面。
2．用户输入垃圾工作项条件。包括超时、异常等条件。
3．系统根据条件检索出垃圾工作项并生成列表信息。
4．用户选择要回收的垃圾工作项。
5．系统回收工作项。
6．退出回收垃圾工作项界面。
第三部分客户端交互
本部分主要完成工作流过程实例与客户之间的交互，也包括一些与工作流相关的信息的处理，如用户信息修改。
客户端交互用例图：
查询流程
参与者：普通用户
前置条件：客户端工具已经打开。
后置条件：用户获取到待启动流程信息。
步骤序列：
1．用户输入复杂查询条件获得待启动流程基本信息列表。
启动流程
参与者：普通用户
前置条件：客户端工具已经打开，运行服务中有待运行的流程。
后置条件：用户启动了一个流程。
步骤序列：
1．进入启动流程界面。
2．用户输入复杂查询条件获得待启动流程基本信息列表。
3．用户选择想要启动的流程。
4．系统启动选中的流程，并分配好工作项。
5．退出启动流程界面。
中止流程
参与者：普通用户
前置条件：客户端工具已经打开，运行服务中有运行的流程实例。
后置条件：用户中止了一个流程实例。
步骤序列：
2．用户输入复杂查询条件获得运行的流程实例。
3．用户选择想要中止的流程实例。
4．系统中止选中的流程实例。
5．退出中止流程界面。
查询工作项内容
参与者：普通用户
前置条件：客户端工具已经打开。
后置条件：用户获取到工作项内容信息。
步骤序列：
1．用户输入复杂查询条件获得工作项内容列表。
选取并执行工作项
参与者：普通用户
前置条件：客户端工具已经打开，用户拥有可执行的工作项内容。
后置条件：用户执行了工作项内容。
步骤序列：
1．进入工作项待办界面。
2．用户选取想要执行的工作项内容。
3．系统初始化选中的工作项内容。
4．用户与系统交互，完成工作项的执行。
5．退出工作项待办界面。
挂起工作项
参与者：普通用户
前置条件：客户端工具已经打开，用户拥有可执行的工作项内容。
后置条件：用户挂起了工作项内容。
步骤序列：
1．进入工作项挂起界面。
2．用户选取想要挂起的工作项内容。
3．系统挂起选中的工作项内容。
4．退出工作项挂起界面。
恢复工作项
参与者：普通用户
前置条件：客户端工具已经打开，用户拥有被挂起的工作项内容。
后置条件：用户恢复了工作项内容。
步骤序列：
1．进入工作项恢复界面。
2．用户选取要恢复的工作项内容。
3．系统恢复选中的工作项内容。
重定向工作项
参与者：普通用户
前置条件：客户端工具已经打开，用户拥有可执行的工作项内容。
后置条件：用户重定向了工作项。
步骤序列：
1．进入工作项重定向界面。
2．用户选取要重定向的工作项，并设置工作项的新执行者。
3．系统修改用户确认的工作项内容，重新分配选中的工作项。
4．退出工作项重定向界面。
修改用户信息
参与者：普通用户
前置条件：客户端工具已经打开。
后置条件：用户修改了自己的用户信息。
步骤序列：
1．进入用户信息修改界面。
2．用户修改基本信息与工作项代理信息，如登录名，密码等。
3．系统把用户修改信息更新到数据库。
4．退出用户信息修改界面。
第四部分工作流运行服务
本部分主要提供定制好的工作流业务过程的运行环境，对于系统最终用户来说不可见，主要包括实例化及执行过程模型，与外部资源交互，维护运行环境内部各种数据信息，协调恢复各种检查数据和恢复重起数据等。
下图是运行服务的设想构件图：
外部接口：
下图为工作流系统与外界系统之间的通讯构件图：
我就在旁边静静地呆着，不言不语，生怕惊扰这静谧的美好，惟愿时光驻留，变成永恒回忆；惟愿几十年后，两鬓斑白的我们仍然携手坐在阳台上，不谈悲喜，只闻花香。
携手的日子总是温暖多过于寒冷，欢笑多过于失意，此时此刻，感恩日子的温润让自己满足。一个人的独立，两个人的扶持，让光阴有滋有味，富有弹性。
时光清浅，流年素淡，携挽着光阴同行，缠绕着故事与共。酸甜苦辣和油盐酱醋茶的生活让日子交织着烟火味，感受生活的踏实和柔韧。
时光如梦，梦里梦外总是有许多憧憬美好，执着这份美好，烟火的生活在平淡中闻到花香，茶香和米香。
静坐时光，把喧嚣关在窗外，悠然恬淡。一缕缕柔风也会温润流年，一轮明月也会涌出丝丝柔情。
岁月静好，与君语；细水长流，与君同；时光如水，与君老。
相伴的时光，简单微笑着，从容平淡着。如若真心，那份灵犀，那份执意，那份默契，让一切俗世纷扰，也过得惬意悠然。
爱就一个懂，一份守，一个眼神就领会了眼眸里的含义，一个怀抱就温暖了整个身心。
光阴无言流淌，岁月无声的叩问着百味世事，彼此相视一笑，你在，我在，阳光还是那么明媚，日子还是那么温馨，你若安好，岁月无恙。
红尘陌上，择一方心灵的净土，种下文字的馨香，于文字中寻一份感悟，让心安暖；于岁月中守一份懂得，感恩生命。
朝霞暮露，四季更迭，花开花谢皆如画，月圆月缺皆如诗。当时光辗转着记忆的年轮，当清风摇曳起祝福的风铃，我在风中优雅的翩跹，回味携手的光阴，淡淡的犹如一朵茉莉花，洁白淡雅，清香宜人。
在素色光阴里，有古韵婉转的琴音入耳，有清幽淡然的花香入鼻，有真情实意的友情入心，有相处不厌的爱入魂，温柔地牵起时光的手，用善待一朵花开的温婉，来守望一生的幸福。人生会在知足中嫣然一笑，花香依旧。
凉风习习，花影阑珊，瓜果飘香，时光是多么轻盈、温柔和生动。
永远是多长，爱意有多浓，一切无足轻重，只想把此刻定格成温暖的笑靥。回味，感恩，彼此执手的岁月，是多么知足和无悔。
目录 1．序言 1.1编写目的 (3) 1.2项目背景 (1) 1.3定义 (1) 1.4参考资料 (1) 2．任务概述 2.1目标 (1) 2.2运行环境 (1) 2.3条件与限制 (1) 2.4用户特征 (1) 3．数据描述 3.1静态数据 (1) 3.2动态数据 (1) 3.3数据库介绍 (1) 3.4数据字典 (1) 3.5数据采集 (1) 4．功能需求 4.1功能划分 (1) 4.2功能描述 (1) 5．性能需求 5.1数据精确度 (1) 5.2时间特性 (1) 5.3适应性 (1) 6．运行需求 6.1用户界面 (1) 6.2硬件接口 (1) 6.3软件接口 (1) 6.4故障处理 (1) 7．其它需求 第二开发小组等
引言 1.1编写目的 信息技术高度发达的今天，利用信息技术对大量复杂的信息进行有效的管理成为一种普遍而实用的手段。一方面，这极大的减少了簿记和人力的开销，另一方面，现代计算机强大的计算能力和网络的普遍部署，大大简化了大量信息的处理和流动。同样，超市收银系统是超市日常经营管理的一个重要组成部分，该系统涉及了商品信息，营业额度，以及很多相关信息的综合处理。为了方便配合超市日常经营管理，系统把收银、退货、会员添加、库存提醒等信息管理工作集成到一个统一的平台，各管理人员分工协作、相互配合，及时了解超市日常营运情况。同时，也方便经营者对日常经营情况的了解。 本文档为超市收银系统的设计、实现、测试以及验收提供重要依据，也为评价系统功能和性能提供标准。本文档可供用户、项目管理人员、系统分析人员、程序设计人员以及系统测试人员阅读和参考。 1.2项目背景 项目委托单位：软件工程课程项目 项目开发单位：08信管软件工程第二开发小组 项目主管部门：08信管软件工程第二开发小组 项目规划： 阶段文档提交日期 需求阶段需求分析文档11月10日 分析设计软件设计文档11月15 日 测试软件测试文档12月20日 项目开发小组： 组长：王国敬 组员：张夏艳杨鹏坤胡杰朱相元王肖建 王世博赵笑天马中源康新伟 第二开发小组等
工作流系统需求分析 业务过程描述： 工作流是一种反映业务流程的计算机化的、实现经营过程集成与经营过程自动化而建立的可由工作流管理系统执行的业务模型。工作流起源于生产组织和办公自动化领域，其目的是将现有工作分解，按照一定的规则和过程来执行并监控，提高效率，降低成本。 下图是用户使用工作流系统的业务过程：
业务模型描述：
系统组成： 工作流管理系统由客户端、流程定制工具、流程监控与管理和工作流运行服务四个部分组成，下图是系统构件图： 系统功能划分： 工作流管理系统是指运行在一个或多个工作流引擎的软件上用于定义、实现和管理工作流运行的一套软件，从用户建模的过程来看在建立阶段功能主要是工作流过程和相关活动的定义和建模，在运行阶段包括运行流程的监控、管理以及执行过程中的人机交互等。 工作流管理系统由流程定制工具、流程监控与管理、工作流运行服务和客户端交互四个部分组成，整个系统的使用者可以分为四种：系统管理员、流程设计人员、流程管理人员、普通用户。 下图是整个工作流管理系统的顶层用例：
第一部分流程定制工具 本部分主要完成企业信息流中业务过程的图形化建模，定制工具提供丰富的图形化元素、简单易懂的建模方法以及完善的模型管理方式。 流程定制用例图：
打开流程模型 参与者：流程设计者。 前置条件：流程定制工具已经打开。 后置条件：被选择的流程模型中的内容被展开。 步骤序列： 1．打开流程模型列表或新建流程模型文件。 2．选择流程模型文件名称。 3．展开流程模型中的设计内容。 保存流程模型 参与者：流程设计者。 前置条件：某个流程模型已经被打开，并且被修改。 后置条件：修改过的流程模型存到了物理文件中。 步骤序列： 1．保存流程模型到物理文件中。 删除流程模型 参与者：流程设计者。 前置条件：拥有可被删除的流程模型。 后置条件：选中的流程模型被删除。 步骤序列： 1．用户打开流程模型列表。 2．用户选择想要删除的流程模型。 3．系统删除选中的流程模型。 导入导出流程模型 参与者：流程设计者。 前置条件：拥有可被导入的文件或导出的流程模型。 后置条件：流程模型被导出成文件或模型文件被导入到设计系统成为流程模型。 步骤序列： 1．用户打开可被导入文件列表或设计工具中的流程模型列表。 2．用户选择将被导入的流程文件或选择将被导出的流程模型。 3．系统把导入文件生成流程模型或把导出流程模型生成流程文件。 流程发布 参与者：流程设计者。 前置条件：拥有设计完成并可供发布的流程模型。 后置条件：流程模型被发布并可通过客户工具执行。 步骤序列： 1．用户打开流程模型列表。 2．用户选择发布的包或流程。 3．用户选择发布的运行服务器。 4．用户形成发布版本。
系统分析师辅导：工作流管理系统体系结构设计 摘要：工作流管理系统将最终成为覆盖于各类台式机与网络操作系统之上的业务操作系统，但工作流技术目前还不够完善。作者在深入研究了工作流管理联盟提供的工作流管理系统模型和各大主流工作流管理系统的基础上设计了一套功能全面的工作流管理系统体系结构。本文主要从该体系结构的三个层次深入介绍了该系统结构。 关键词：工作流管理系统、业务操作系统、软件体系结构、业务建模 1、引言 在一个组织内部存在着两种信息：一种是数据信息，另一种是业务信息。在组织之间也同样存在着两种信息：一种是数据信息，另一种是业务往来信息。如果这两种信息用计算机系统来管理，前一种属于组织内部的信息系统，后一种属于B2B电子商务系统。目前对数据信息的计算机管理系统（即：数据库管理系统）经过多年的发展已经成熟。对业务过程的计算机管理系统由于比较复杂，可变因素较多，难度大，因此发展还不成熟。工作流技术作为现代组织实现过程管理与过程控制的一项关键技术，为组织的业务处理过程提供了一个从模型建立、管理到运行、分析的完整框架。同时，工作流管理系统（Workflow Management System ,WFMS）通过一套集成化、可互操作的软件工具为这个框架提供了全过程的支持。Thomas Koulopoulos曾预言：工作流管理系统将最终成为覆盖于各类台式机与网络操作系统（如：Windows,Unix,Windows NT）之上的业务操作系统BOS（Business Operating System）,它将带来操作系统的一次革命。但是目前工作流技术无论从理论上还是从实践都还不够完善，要实现Thomas Koulopoulos的预言可能还需有一段路要走。本文主要介绍了由作者独立设计一套工作流管理系统体系结构，以供工作流技术爱好者参考。 2、工作流管理系统的基本概念 顾名思义，工作流就是工作任务在多个人或单位之间的流转。在计算机网络环境下，这种流转实际上表现为信息或数据在多个人之间的传送。工作流管理联盟( Workflow Management Coalition ，WfMC)对工作流的定义是：“业务过程的部分或全部在计算机应用环境下的自动化”。她所要解决的主要问题是，“使在多个参与者之间按照某种预定义规则传递的文档、信息或任务的过程自动进行，从而实现某个预期的业务目标，或者是促使此目标的实现”。 工作流管理系统就是通过管理一序列的工作活动以及相关人员、资源、信息技术资料来提供业务处理程序上的自动控制。工作流管理系统通过计算机软件来定义、管理和执行工作流程。在工作流管理系统中计算机运用程序的执行顺序是由工作流逻辑的计算机描述来驱动的。她的主要目标是对业务过程中各步骤(或称活动、环节)发生的先后次序，以及同各个步骤相关的人力、资源、信息资料的调用等进行管理，从而实现业务过程的自动化。当然这种管理可能会在不同的信息及通信环境下实现，所涉及的范围可以小至一个只有几人的工作组，也可以大到政府、企业组织各个机构之间。工作流管理系统将人员、组织结构、设备资源、信息源（如数据库、文件系统、电子邮件、计算机辅助设计工具等）整和成一个整体。这样，工作流管理系统就成为了一个理想的用来收容业务逻辑的业务知识仓库，并给予业务逻辑一个易操作易控制的界面。 工作流管理系统的最大优点就是实现具体应用逻辑和过程逻辑的分离，实现在不修改具体功能的情况下，通过修改业务流程模板来改变系统的功能，完成对组织生产经营过程的部
版本号： 数据采集需求说明书项目名称：
变更记录 变更审阅
一、引言 1．编写目的 这部分说明文档编写目的，描述本系统特点及使用数据仓库技术实现的业务目标。 2．背景 这部分是项目背景描述。 3．参考资料 这部分列出本文档引用资料的名称，并说明文档上下级关系。 4．术语定义及说明 这部分列出本文档中使用的术语定义、缩写及其全名。 5．一般约束 这部分描述本系统开发过程中的各种可预见的约束条件，例如工具性能约束、开发技术支持约束、软件范围约束等。 二、数据源分析 1．数据源概述 这部分将对本项目中涉及的数据源名称及其业务功能作出简单描述，如果多个数据源之间有关联，那么需要说明他们之间的关联关系。 2．数据源物理环境描述 （1）硬件平台 这部分记录所有数据源程序运行环境需要的硬件平台，包括： ●数据源服务器所在的硬件平台环境 ●数据源程序运行监控硬件平台环境 这里的硬件环境包括机器的型号、硬盘的容量及其速度以及网络环境等。 （2）软件平台 这部分内容是记录所有与数据源程序相关的软件平台，包括： ●数据源服务器所在的软件平台环境 ●数据源程序运行监控软件平台环境
这里的软件环境包括操作系统的种类和版本、数据库的种类和版本等，对监控平台还要关注应用软件。 （3）网络平台 这部分记录与数据采集程序有关的所有网络环境的定义。 3．数据源数据更新特征 这部分对每一个数据源中本次项目中涉及的主表的数据更新状态进行分析，例如是日更新还是月更新以及更新的标志，以作为以后编写增量采集程序的基础。 4．数据源可以提供的文件格式 这部分对本项目中涉及的数据源可以提供的数据格式进行记录，供确认采集需求使用。 三、数据仓库环境分析 1．数据仓库数据量预估 这部分评估本次项目中所有与数据量有关的参数，包括数据源历史数据量、数据源日增量、数据仓库历史存储时间，并根据这些参数估算本次项目中需要向数据仓库增加的数据量。 2．数据仓库粒度定义 这部分根据业务需求和数据源数据分析确定本次项目中涉及的业务实体的粒度。这里讨论这个问题，是因为粒度的高低关系到数据采集的难度。 3．数据仓库运行环境描述 （1）硬件平台 这部分记录所有数据源程序运行环境需要的硬件平台，包括： ●数据仓库服务器的硬件平台环境 ●数据仓库运行监控硬件平台环境 这里的硬件环境包括机器的型号、硬盘的容量及其速度以及网络环境等。 （2）软件平台 这部分记录所有与数据源程序相关的软件平台，包括： ●数据仓库服务器的软件平台环境 ●数据仓库运行监控软件平台环境 这里的软件环境包括操作系统的种类和版本、数据库的种类和版本等，对监控平台还要
流程业务需求 Prepared by 拟制方进 Date 日期 2013-10-16 Reviewed by 评审人Date 日期 Approved by 批准Date 日期
1工作流建设目标 为某某公司建立统一，集成的工作流系统平台，实现业务审批流程电子化。体现某某公司业务执行的透明度和规范化，提高业务处理效率和协作效率。 1.1管理需求 管理模式：通过实施工作流理顺业务流程，即销售业务审批流程，设计业务审批流程，行政管理审批流程等，提高业务协作效率，实现公司有效规范的管理目的 数据集成方面：工作流系统与业务系统集成，共享业务数据，实现单一创建多出引用原则 技术方面：要求系统在集成性，稳定性，拓展性，可适应性方面符合某某公司的发展需要。对于权限和安全性方面，提供可靠的保障。同时需要支持移动设备的审批。 组织和人员：通过工作流的建立帮助企业实现业务处理的完整性，实现业务和公司规范执行的有效结合。帮助企业梳理业务，规避风险，提升工作质量。 1.2技术要求 ◆流程设计工具实现流程定义，实现，人员，角色，部门定义。实现流程版本控制 ◆流程设计工具实现表单定义 ◆实现流程中不同的节点和不同的表单关联 ◆工作流节点支持脚本扩展,比如编写beanshell脚本,或其他语言的脚本 ◆实现表单中，一对多的主子表单的关联，比如在《担保支付运费服务协议》中除 了有正文合同，可能还有授权委托书a1，授权委托书a2，第三方代付费用，结算 方案确认合同等等。 ◆对于流程审批的人员管理如何设定 ◆审批委托设定，比如部门经理a出差，委托经理b待审批流程。 ◆手持设备访问工作流，进行审批动作 ◆流程中的某个节点长期没有审批，设置一个阀值，超过该阀值触发邮件动作提醒， 或终止流程等业务动作。 ◆工作流系统与其他业务系统集成方式
案例one：教学管理系统（用例驱动的交互式需求获取） 以一个教学管理系统JXGL的分析与设计作为示例，说明用例驱动技术在软件项目开发中的应用。 高等学校的教学管理内容十分丰富，工作繁多。作为一个示例，规定开发教学管理系统JxGL只处理每学期的课程选修注册和学生的成绩管理。教学管理系统JXGL的用户是学校的学生、教师和教学管理员。学生使用JXG系统查询新学期将开设的课程和授课教师的情况，选择自己要学习的课程，并进行登记注册。学生还可以使用JXGL系统查询自己的课程成绩。教师使用JXGL系统查询新学期将开设的课程、参加听课的学生情况，以及学生的考试成绩。教学管理员使用JXGL系统进行教学管理，包括新学期的课程选课注册管理和学生成绩管理。 1.需求描述: 对教学管理系统JXGL要求提供两个方面的服务: (1)选课管理，负责新学期的课程选课注册工作; (2)成绩管理，负责学生成绩管理。 在选课管理方面应填写的用户需求描述如下。 (1)录入与生成新学期课程表 教学管理员在新学期开始前录入新学期课程，打印将开设的课程目录表，供师生参 考选择。若某课程的实际选课学生少于10人，则停开该课程，把该课程从课程目 录表中删除;若某课程的选课学生多于30人，则停止选课。 (2)学生选课注册 新学期开始前一周为选课注册时间，在此期间学生可以选课注册，并且允许改变或 取消注册申请。 每个学生选课不超过4门课程。每门课程最多允许30名学生选课注册。 学生可以在图书馆、各系资料室、学生宿舍等处的计算机上联网进行选课注册。在 选课注册结束后，教学管理员打印学生选课注册名单和开课通知书，送交有关部门 和授课教师。 (3)查询 可以查询课程信息、学生选课信息和学生、教师信息。 学生、教师、教学管理员可以查询课程表，获得课程信息。查询的关键词以是:课 程名，授课教师名，学分。 教师、教学管理员可以查询学生选课情况。查询的关键词可以是:学生名、程名， 授课教师名，学分。学生只允许查询自己的选课信息，不允许查询别人选课信息。 学生、教师、教学管理员可以查询学生或教师的信息。查询的关键词可以是学生名、 教师名，性别、班级、职称。 (4)选课注册信息的统计与报表生成。 教学管理员对学生的选课注册信息进行统计(按课程，按学生，按班级)，印汇总统 计报表。 在成绩管理方面应填写的用户需求描述如下: (1)成绩录入:
工作流系统设计手册 一、引言 工作流管理是目前被业界广泛应用并迅速发展的技术，它的主要功能是使业务处理过程自动化，协调人和各种应用程序的工作。工作流管理系统（Workflow Management System，简称：WfMS）以企业业务过程为核心，结合了计算机支持协同工作以及企业信息系统的相关技术，立足于过程自动化，着眼于整体效率的提高。随着计算机软硬件技术的发展，特别是Internet 和Intranet的迅速普及，工作流管理系统的应用范围已不仅仅限于传统办公环境（如保险、银行、法律、行政管理等）和工业制造中，而且逐渐扩展到企业应用环境中。 1993年成立的工作流管理联盟（Workflow Management Coalition，简称：WfMC）给出了一系列工作流的规范。其主要概念有： 工作流 工作流是一类能够完全或者部分自动执行的经营过程，它根据一系列过程规则，文档信息或任务能够在不同的执行者之间传递与执行。 工作流是一种反映业务流程的计算机化的模型，实现经营过程集成与经营过程自动化而建立的可由工作流管理系统执行的业务模型。 工作流管理系统
它是一个软件系统，完成工作流的定义和管理，并按照在计算机中预先定义好的工作流逻辑推进工作流实例的执行。并监控其工作状态。工作流管理系统可称为企业的业务操作系统。（Business Operating System，简称：BOS） 工作流系统参考模型 有关工作流管理联盟更详细的规范请参见https://www.doczj.com/doc/0b4095441.html, 二、JU工作流管理系统 根据国际工作流管理联盟的标准模型，实现了过程定义工具、工作流执行服务（工作流机）、工作流管理工具以及工作流客户应用（人工动作）和供工作流执行服务（工作流机）直接调用的应用（自动化动作）。 人工动作必须与表单绑定。表单提供了人机交互的工作界面，而表单的后面是标准通用的关系型
鞋店进销存管理系统 一.项目背景 随着计算机技术的不断发展, 它已经成为人们工作和生活中不可缺少的工具。早在1954年，银行、大公司和大企业纷纷采用计算机进行账户和账目管理、生产管理、库存管理、销售管理、统计报表等。从数据的收集、存储、整理到检索统计，应用的范围日益扩大，使计算机的应用很快超过科学计算，成为最大的计算机应用领域。 鞋店管理的特点是信息处理量比较大，所存的鞋种类多，而且由于进货单、销售单、需求单等单据发行量特别大，关联信息多，查询和统计的方式各不相同等原因,因此在管理上实现起来有一定困难。在管理的过程中经常会出现信息的重复传递，单据报表种类繁多，各个部门管理规格不统一等问题。 在本系统的设计过程中，为了克服这些困难，满足计算机管理的需要,我们采取了下面的一些原则： 1、统一各种原始单据的格式，统一账目和报表的格式。 2、删除不必要的管理冗余，实现管理规范化、科学化。 3、程序代码标准化，软件统一化，确保软件的可维护性和实用性。 4、界面尽量简单化，做到实用，方便，尽量满足书店中不同层次员工 的需要。 二.定义 “鞋店进销存管理系统”为用户提供添加、修改、查询、退货操作等服务。用户在登陆界面输入用户名，密码后系统核对正确进入系统内部。系统就要求用户选择事务类型（添加、修改、查询、退货等），直至用户选择退出应用服务，询问用户是否退出应用服务，如果用户选择结束，系统重回登陆界面。用户进入添加界面后，首先可以输入的数字必须大于等于100），否则系统显示输入有误。用户点击确认后，由系统查询，判断该取值是否超出库存量，如果没有，则系统会显示确认界面，用户单点击“确认”后，系统自动生成账单，并在后台进行工作，系统进行清
需求分析说明书 专业：集成电路 班级：2011级2班 姓名：杨丽娟 1108040215 和黄丽婷 1108040228 小组成员：杨丽娟黄丽婷
目录 1．引言 (8) 1.1编写目的 (8) 1.2项目背景 (8) 1.3定义 (9) 1.4参考资料 (9) 2．任务概述 (9) 2.1目标 (9) 2.2运行环境 (10) 2.3条件与限制 (10) 3．数据描述 (10) 3.1动态数据 (10) 3.2数据采集 (4) 4．功能需求 (10) 4.1功能划分 (10) 4.2功能描述 (10) 5．性能需求 (11) 5.1数据精确度 (11) 5.2时间特性 (11) 5.3适应性 (11) 6．运行需求 (12) 6.1用户界面 (12) 6.2硬件接口 (12) 6.3软件接口 (12) 6.4故障处理 (12) 7．其它需求 (12) 8. 经简化后的要求 (12)
1．引言 1.1编写目的 这次的编写目的是源于本次的课程设计，马老师布置任务为设计一个可以实时采集电压数据的嵌入式开发板上的程序，要求我们分组完成课程设计。于是为明确软件需求、安排项目规划与进度、组织软件开发与测试，撰写本文档。 该文档是需求分析文档。 1.2项目背景 1.0有一数据采集器（程序中用采集ad转换器数据代替），要求采集ad转换器的数据操作。现要求将操作采集的数据能够生成数据文件，并且将生成的文件上进行保存。 1.3参考资料 《用户设计要求说明书》 《项目开发计划》
《嵌入式系统原理》 《接口与应用》 《嵌入式原理》 2．任务概述 2.1目标 将嵌入式机器的采集数据生成数据文件本机保存，并允许远程控制该采集并保存的数据，方便用户的使用和远程数据监控。 总体功能要求如下： （1）本机配备彩色触摸屏； （2）允许本地生成文件； （3）允许文件保存； （4）仪器采集的数据可访问 （解释起来就是：在本机与嵌入式机上都能对数据文件的保存，随时的（嵌入式机器）上传或（计算机）下载文件的软件，且可通过网线或串口与嵌入式机联系起来，连着同步上传文件。） 2.2运行环境 操作系统：linux操作系统、windows操作系统 运行环境：嵌入式开发板、仪器控制界面软件，远程控制软件，终端，以及各种串口软件。 2.3条件与限制 1.远程监控数据必须安装交叉编译环境。 2.具体电压值在-2500mv到+2500mv之间。采集精度在20位。 3.数据采集周期：最快为1000ms采集一次。 3．数据描述 3.1数据采集 嵌入式控制面仪器板主要是通过串行通讯的串口实现对各个数据的采集，包括对ad转换器数据的采集和相关参数的控制。本地嵌入式系统通过以太网通信，实现远程控制和数据的相互存储和处理。
西北工业大学软件与微电子学院 <工作流管理系统> 需求规格说明 版本：1.0 编写：年月日校对：年月日审核：年月日批准：年月日
目录 1引言 (1) 1.1编写目的 (1) 1.2背景 (1) 1.3定义 (1) 1.4参考资料 (2) 2任务概述 (2) 2.1目标 (2) 2.2用户特点 (2) 3需求详述 (3) 3.1关键信息 (3) 3.1.1名词解释 (3) 3.2过程描述 (5) 3.2.1系统管理 (5) 3.2.2流程设计 (8) 3.2.3业务管理 (14) 3.2.4用户操作 (23) 4说明 (26)
1引言 1.1编写目的 本需求规格说明书对系统所要实现的功能分模块进行了详细说明，它是一份描述系统整体结构及工作流程的文档。本需求规格说明书主要向客户方及与本项目相关的人员发放，使他们了解该软件的功能结构详细情况。 1.2背景 待开发系统是由631所提出的，针对该所的业务要求及外协任务说明。该系统包括四个子系统： 系统管理； 流程设计； 业务管理； 用户系统。 本系统由西北工业大学软件与微电子学院负责开发，系统的开发环境为：Windows＋J2EE。 1.3定义 WfMC（Workflow Management Coalition）：工作流管理联盟。 流程设计：创建工作流模型，根据实际的业务流程创建可视的流程模型。 业务管理：是对工作流模型和实例进行监控和管理。 活动：是一项工作的原子单元。有时会使用节点代替活动。 流程：是活动的集合，有时会使用工程代替流程。 角色：指工作流模型的参与者和任务承担者，和权限相关联。 用户：指工作流系统的使用者。 连接：是两个活动之间顺序依赖的根据，有时会使用边代替连接。 变量：是工作流的数据单元，被称做工作流相关数据。
Toward Workflow Block Activity Patterns for Reuse in Workflow Design Lucinéia Heloisa Thom and Cirano Iochpe Federal University of Rio Grande do Sul, Brazil; Vinícius Amaral and Daniel Viero, iProcess, Brazil 1.I NTRODUCTION Research on both business process modeling and implementation issues re-lated to workflow technology have quickly increased over the last years. The most significant initiatives are in the field of standardization [1], [2], [4], specification [5] and workflow definition languages [6], [7], [3]. However, since it is a relatively new and still evolving technology, workflow design pre-sents some challenges, especially with respect to techniques that can en-force correctness as well as efficiency during both the requirements analysis and the modeling phase of the workflow project. Within this context, research on workflow patterns has attracted increasing attention mainly because of the advantages of reusing patterns [8], [9]. The most extensively studied are in the field of control/data flow patterns [10], [11] as well as resource and application–oriented patterns (12). Such pat-terns are being used not only in business/workflow process modeling but also in critical evaluations of workflow languages and workflow tools (13). However, a lot less research can be found relating workflow design to a set of recurrent business process “pieces” or “parts” that must be atomically exe-cuted by the workflow process (e.g., an activity request execution and a noti-fication activity). Although one can precisely characterize the semantics of such business process “pieces” [14], [15], [16] and they have to be recur-rently re-designed in practically every workflow modeling process, there is no known research relating these business process structures to workflow pat-terns. 1.1 Approach Our approach applies the concept of block activity to well-known business processes. An activity set is a self-contained set of activities and transitions [7]. Transitions in the set should refer only to activities in the same set and there should be no transitions into or out of the set. Activity sets can be modeled as block activities. The block execution starts at the first activity in the set and executes the next activities by following the partial order im-posed upon them by the transitions until an exit activity is reached. Work-flow execution then returns to the next activity following the block. In this paper, we apply the block activity concept in order to represent a set of business (sub-)process types (e.g., logistic, financial, information and de-cision) that we call “workflow block activity patterns”. These patterns are re-lated to a set of specific atomic structures that are frequently found in busi-ness processes and have already been identified in the literature [14], [15],
高校学生学籍管理信息系统 系统需求规格说明书 （系统需求分析报告）
目录 1-------------------------------------------------------------------概述1．1----------------------------------------------------------------背景1．2-------------------------------------------------------------系统目标1．2．1------------------------------------------------------应完成的任务1．2．2------------------------------------------------------不完成的任务1．3------------------------------------------------------------业务模式1．4-------------------------------------------------------------业务状况2---------------------------------------------------------------用户需求2．1-------------------------------------------------------------业务需求2．1．1---------------------------------------------------------使用范围2．1．2----------------------------------------------------------功能要求2．1．3----------------------------------------------------------权限管理2．2-------------------------------------------------------------性能需求3---------------------------------------------------------------业务流程3．1-----------------------------------------------------与其他系统的关系3．2----------------------------------------------------------业务流程图4---------------------------------------------------------------业务逻辑4．1-------------------------------------------------------------业务分解4．2------------------------------------------------------------业务描述5---------------------------------------------------------------数据分析5．1------------------------------------------------------------数据单据5．2------------------------------------------------------------数据分析5．2．1---------------------------------------------------------数据分类5．2．2---------------------------------------------------------数据描述6-------------------------------------------------------------------附件
工作流系统需求分析及设计 业务过程描述： 工作流是一种反映业务流程的计算机化的、实现经营过程集成与经营过程自动化而建立的可由工作流管理系统执行的业务模型。工作流起源于生产组织和办公自动化领域，其目的是将现有工作分解，按照一定的规则和过程来执行并监控，提高效率，降低成本。 下图是用户使用工作流系统的业务过程：
业务模型描述：
系统组成： 工作流管理系统由客户端、流程定制工具、流程监控与管理和工作流运行服务四个部分组成，下图是系统构件图： 系统功能划分： 工作流管理系统是指运行在一个或多个工作流引擎的软件上用于定义、实现和管理工作流运行的一套软件，从用户建模的过程来看在建立阶段功能主要是工作流过程和相关活动的定义和建模，在运行阶段包括运行流程的监控、管理以及执行过程中的人机交互等。 工作流管理系统由流程定制工具、流程监控与管理、工作流运行服务和客户端交互四个部分组成，整个系统的使用者可以分为四种：系统管理员、流程设计人员、流程管理人员、普通用户。 下图是整个工作流管理系统的顶层用例：
第一部分流程定制工具 本部分主要完成企业信息流中业务过程的图形化建模，定制工具提供丰富的图形化元素、简单易懂的建模方法以及完善的模型管理方式。 流程定制用例图：
打开流程模型 参与者：流程设计者。 前置条件：流程定制工具已经打开。 后置条件：被选择的流程模型中的内容被展开。 步骤序列： 1．打开流程模型列表或新建流程模型文件。 2．选择流程模型文件名称。 3．展开流程模型中的设计内容。 保存流程模型 参与者：流程设计者。 前置条件：某个流程模型已经被打开，并且被修改。 后置条件：修改过的流程模型存到了物理文件中。 步骤序列： 1．保存流程模型到物理文件中。 删除流程模型 参与者：流程设计者。 前置条件：拥有可被删除的流程模型。 后置条件：选中的流程模型被删除。 步骤序列： 1．用户打开流程模型列表。 2．用户选择想要删除的流程模型。 3．系统删除选中的流程模型。 导入导出流程模型 参与者：流程设计者。 前置条件：拥有可被导入的文件或导出的流程模型。 后置条件：流程模型被导出成文件或模型文件被导入到设计系统成为流程模型。 步骤序列： 1．用户打开可被导入文件列表或设计工具中的流程模型列表。 2．用户选择将被导入的流程文件或选择将被导出的流程模型。 3．系统把导入文件生成流程模型或把导出流程模型生成流程文件。 流程发布 参与者：流程设计者。 前置条件：拥有设计完成并可供发布的流程模型。 后置条件：流程模型被发布并可通过客户工具执行。 步骤序列： 1．用户打开流程模型列表。 2．用户选择发布的包或流程。 3．用户选择发布的运行服务器。 4．用户形成发布版本。
工作流程引擎需求分析 1 文档目录 2 背景 3 目标 在应用系统上建立一个工作流程系统。 1.能够快速定制开发客户需要的业务流程。 2.在流程实施后，客户能够自行设置该流程的各执行步骤的参与人（执行人） 3.能够监视每条业务流程的运作轨迹。 4.业务流程可以对应用系统上的任何业务数据进行操作。 4 概念与名词解释 流程模型：名称、任务、执行人等 名称：如新员工转正流程。 任务：流程中每一个执行的步骤称为任务，如：发起流程、审批等 任务-执行条件:每一个任务的前置执行条件，如必须哪些任务执行完才能进入本任务。 任务-数据条件:每一个任务的前置数据条件，如目前数据中符合什么条件才能进入本任务。 执行人：任务由谁可以操作，可以是用户或者组织 流程实例：由流程模型为模板创建的一个对象（正在使用的流程）
5 基本业务描述 5.1任务间的对应及流转关系 5.1.1一对一任务 第一个任务在完成后，根据执行条件判断，转到第二个任务 5.1.2一对多任务 第一个任务在完成后，根据各个执行条件判断，转到第2.1任务或者转到第2.2任务或者同时转到第2.1、2.2任务 5.1.3多对一任务
在第1.1任务完成，第1.2任务完成后，根据各自的执行条件，确定转到任务2 或的关系： 在C条件判断时：当A、B中一个通过后，C判断通过。 与的关系 在C条件判断时：当A、B中全部通过后，C判断通过。 处理方式：权值方式。 或的关系： A权值是1，B权值是1， C要求得到A+B>=1时通过。 与的关系 A权值是1，B权值是1， C要求得到A+B>=2时通过。 5.2实体关系图 6 主要功能模块 6.1流程模型 确定流程的模型：名称、任务、执行人 任务：名称、前置条件（任务的下一任务）、任务执行人（用户、组织）6.2流程实例 由流程模型为模板创建的一个对象（正在使用的流程）
需求分析报告 《高校学生学籍管理信息系统》 目录 1-------------------------------------------------------------------------------概述 1．1-----------------------------------------------------------------------------背景 1．2-----------------------------------------------------------------------------系统目标1．2．1------------------------------------------------------------------------完成的任务1．2．2------------------------------------------------------------------------不完成的任务1．3-----------------------------------------------------------------------------业务模式 1．4-----------------------------------------------------------------------------业务状况 2---------------------------------------------------------------------------------用户需求 2．1-----------------------------------------------------------------------------业务需求2．1．1------------------------------------------------------------------------使用范围2．1．2------------------------------------------------------------------------功能要求2．1．3------------------------------------------------------------------------权限管理 2．2-----------------------------------------------------------------------------性能需求 3---------------------------------------------------------------------------------业务流程 3．1----------------------------------------------------------------------------与其他系统的关系3．2----------------------------------------------------------------------------业务流程图 4---------------------------------------------------------------------------------业务逻辑 4．1-----------------------------------------------------------------------------业务分解 4．2-----------------------------------------------------------------------------业务描述
通达OA工作流分析 （本文由OA软件用户经研究撰写，仅供参考） 1>建立组织机构、角色、用户 1.2>前台截图 略 1.3>后台结构 1.3.1>SQL分析 select * from department; select * from user_priv; select * from [user]; 1.3.2>数据分析 1.3. 2.1>部门表(department) 1.3. 2.3>角色表(user_priv) 1.3. 2.2>用户表(user) 2>建立表单(flow_form_type) 2.1>建立过程 在软件中的建立过程省略，此部分不是重点，因为我们要开发的软件想做到表单自定义还不现实。
2.2>SQL分析 select * from flow_form_type where form_id=25 2.3>结果记录 3>流程及步骤设置 3.1>建立流程分类(flow_sort): 3.1.1>建立过程 使用系统自带的默认流程分类不变 3.1.2>SQL分析 select * from flow_sort 3.1.3>结果记录 3.2>建立流程(flow_type): 3.2.1>建立过程 a>在工作流设置->定义流程，点击“新建流程”； b>在编辑流程“基本属性”时，定义“流程分类”为“生产”，定义“流程排序号”为0， 定义“流程名称”为“物资需求计划”，定义“流程类型”为“固定流程”， 定义“表单”为“物资需求计划”，定义“允许附件”为“是”； c>在编辑流程“监控人员”时，定义“[供应部] 张三”为监控人员； 3.2.2>SQL分析 select * from flow_type where flow_id=31 3.2.3>结果记录 结果：在flow_type表生成1条记录: