xx总xxxxx项目
└技术平台问题：2005-06-28 14:07:05
├双方对流程引擎的理解
│├甲方理解的流程引擎的功能
│├乙方JPDL流程引擎的介绍
│├任务怎么进来的，怎么出去的（选择人、角色，期限，下一步）
│├下一步也是自己作的时，是否自动接受、跳出
│├新的任务如何醒目标志（上次刷新有10个任务，这次刷新，别人完成了2个，但新增了3个）
│├关联到->流程引擎问题：2005-06-18－22
││└阅读总xxxxx功能说明书文档
││ ├业务数据的一对多关系好像没有很明确（...实体...）：需要一个总体的描述
││ ├需要考虑已错（...实体...）数据的纠正
...
││ ├根据经验，状态的定义描述，最好辅助以状态流转图：否则容易出现遗漏或矛盾
││ ├4.2.5任务的统一要求－报警颜色
││ │└除了超过截至时间的需要红色报警外，时限已过2/3的和就差2小时的，也以黄、橙色提醒
││ ├6.12.1用户的信息要素，对应的角色应该可能是多个
││ │└用户姓名不得重复，可行吗？
││ ├角色－岗位－用户－操作的一对多关系：需要一个总体的描述
││ └流程引擎问题
││ ├流程步骤里缺少“接受”这个环节，依靠保存或提交的正确性来实现互斥
││ │└可能导致:用户输入很多信息后才发现被别人接受了，自己输的信息都浪费了
││ ├提交时，无法指定后续工作的办理者（文档上没有明确标出，乙方的流程引擎只支持角色不支持人）
││ ├从上面2个问题发现双方对流程引擎的具体功能、实现模式还有分歧
││ │├而很多需求是基于这样的假设前提的：双方都明了流程引擎要实现的功能
││ │└所以，是否也需要把现在的流程引擎的设想作一个公共的讨论
││ └关联自->双方对流程引擎的理解
│├流程引擎的权限是否细分到处理权、调阅权、浏览权
│├流程引擎的岗位涵盖的操作如果不够细，分支机构可能需要修改
│└乙方理解的流程引擎的数据记录和存储格式：以便日后统计查询
│ ├如果流程引擎已经提供方便、完整的数据查询接口：则无须了解其内部的表结构
│ └如果流程引擎没有提供方便、完整的数据查询接口：则需要了解其内部的表结构，以便自行查询
├...实体...的状态流转图（辅助，以免遗漏或矛盾）
└...实体...的实体关系（注意事项）