关于多表单系统在上篇已经简单描述了一下需求概述，通过需求概述，我们发现每个表单之间有一个共性（表单内容+动作）。如下图：
下面来详细分析一下系统需求和变化需求：
1.UI需求
从UI层面来分析，表单系统也只有“表单内容”（也就是上图中阴影部分）在变化，各个表单的内容不一样，有简单的，有复杂的。简单的表单，也就是一个实体（可理解成一张数据库表）就可以满足要求。复杂的表单，那就需要n个实体的组合才能满足需要。
关于UI逻辑，对于不同表单动作，有不同的UI界面，也就是要考虑UI的显示逻辑，例如某审核页面需要能修改某个栏位，如“希望完成时间”，甚至有的审核页面可以修改所有内容，另外表单处理的页面和表单检视的页面也不一样，处理页要上传处理报告，还有根据当前登录者的角色判断什么栏位显示，什么栏位不显示，什么功能显示，什么功能不显示，这就是操作权限和UI的联系。
关于UI需求应该还有很多，没有想出来，盼谢大家帮忙补充一下。
2.业务需求
从业务层面来看，每个表单的动作不一样，也就是每个动作处理的逻辑不同，简单的动作只要将资料插入一张表或将某个字段值改一下之类的简单操作，复杂的动作就是要操作n张表，包括判断，插入，修改，删除等等。
业务逻辑这东西不知道怎么讲好，这块在写起来是比较复杂的，也是系统的最难写的部分，呵呵，个人体会。
3.变化需求
像这样的多表单系统，最烦人的就是用户不断地变更需求，这在开发企业管理信息系统中是不可避免的。下面就简单描述一下几个常见的变化：
- 增加栏位。这点只有修改代码，想不修改也难，除非自动生成表单什么的，但是自动生成有其局限性，不能完全满足需求。
- 增加功能。这点也要修改代码。
- 增加审核流程。这点需要增加页面和动作处理逻辑了，这点只要系统的扩展性好（采用接口设计），加一个流程也不是很麻烦。
面对需求变化，我们应该有应对变化的方法，尽量减少我们修改代码的地方。
4.结语
最后，关于多表单系统的需求，我们就讲到这里，下篇将介绍开发模式的设计。