合同模板管理系统需求说明书Word文件下载.docx
《合同模板管理系统需求说明书Word文件下载.docx》由会员分享，可在线阅读，更多相关《合同模板管理系统需求说明书Word文件下载.docx（17页珍藏版）》请在冰点文库上搜索。
4.1用例描述
使用本系统的要紧有两个角色，他们是合同治理员（公司职员）和经理（超级治理），经理有绝对的权限使用整个系统，而合同治理员只能有一部分的权限，如图所示为各角色对应的用例。
4.2功能模块设计
本合同治理系统要紧实现如下功能：
职员信息治理、客户信息治理、合同信息治理，合同执行情况的全面跟踪监管操纵，并具有严格的系统用户分级权限操纵，保证了公司合同数据的严格保密性。
系统模块划分如图3-1所示，将系统分不5个模块，每个模块负责的功能相对专一。
图 3-1模块划分图
每个功能模块的功能描述如下:
（1）职员信息治理
治理所有参与合同治理动作的职员信息。
包括职员编号、姓名、部门、电话等。
（2）客户信息治理
客户治理模块要紧实现对客户的增、删、改、查等操作。
客户分为两种类型，重要客户和一般客户。
治理员能够添加客户、按照客户类型或者客户名称进行客户查询，通过查询条件的结果链接到客户的修改或者删除页面，对客户进行修改删除等操作。
（3）合同治理
合同治理模块要紧实现对合同的增、删、改、查等操作。
治理员能够添加合同，对合同进行查询，为了使查询更加简便。
系统提供两种查询方式，一种是按照编号进行查询，另一种是按审核标志进行询，能够通过查询的结果链接到合同的修改或删除页面，对合同进行修改或者删除。
（4）项目信息治理
治理所有项目信息。
项目信息包括项目编号、项目名称、联系人等。
（5）使用权限治理
本系统从合同信息的安全角度动身，将系统设计成具有严格的系统用户及分级权限操纵。
系统的职员分为两类用户：
一般用户和合同治理员。
使用不同用户名登录所具有的权限不同，保证了企业合同数据的严格保密性。
4.3系统流程分析
合同治理系统提供对公司内部合同的治理功能。
使用本系统，能够完成合同的录入、修改以及维护等操作，同时对合同治理员进行权限操纵，以满足安全性方面的要求。
本系统分为合同治理员和经理（即系统治理员）2种用户。
合同治理员默认能够添加、修改、删除和查询自己的合同；
经理能够查看和治理所有合同，并对合同进行统计及治理用户信息。
用户登录后自动读取该用户的操作权限，用户能够在导航栏中选择某一操作链接进入相应的操作页面。
为了更清晰地讲明系统框架，以便更好地设计该系统的解决方案，图3-2给出了系统流程图。
系统流程图展示了该系统所有功能模块之间的逻辑关系，其中的各个功能模块差不多上都代表了一个独立的页面，并将在下面的系统设计时期得到体现。
图3-2系统流程图
5.数据库设计
5.1数据库需求分析
合同治理系统的要紧目的确实是利用软件实现合同的录入、查询、编辑等功能，使工作人员对合同的治理更加容易，提高工作效率、降低治理成本。
具体分析如下：
（1）职员治理
Ø
扫瞄负责治理所有参与合同治理动作的职员信息。
添加、删除、修改，查找职员信息。
此权限只有经理（即系统治理员）具有。
（2）客户治理
扫瞄所有客户信息。
客户信息包括客户编号、客户名称、联系人等。
添加、修改、禁用和查找客户信息。
（3）合同治理
合同分类治理：
按采购类合同和销售类合同进行分类划分。
扫瞄与合同相关的明细资料。
合同信息包括合同编号、签订日期、客户名称、项目名称、货品名称、数量、单价、金额、合同执行状态等。
分不按合同号、客户名称及项目名称查找合同信息。
添加、修改、删除合同信息。
对合同信息进行实时处理。
如合同执行情况操纵，包括已执行、执行中、未执行三个状态。
按项目名称、客户名称、合同执行情况等几项内容或任意几项内容组合来对合同的执行情况进行综合查询。
按项客户名称对所有合同运作情况进行统计，包括合同总金额，执行中合同数量，未执行合同数量等。
（4）项目治理
扫瞄所有项目信息。
添加、修改、禁用及查询项目信息。
（5）账号治理
公司信息设置。
系统参数。
添加操作员。
修改密码。
其中，系统参数和添加操作员两个功能，只有经理（系统治理员）具有此操作权限。
（6）考虑到公司合同的保密性，对合同维护的各项操作需按照职员的工作类不区不给予。
故对系统分为两类权限：
合同治理员（级不为B）和经理（即系统治理员,级不为A）。
他们所具有的操作权限如下：
合同治理员所具有的操作权限：
合同治理员能够录入新的合同，并对自己录入的合同进行查询，也能够进行合同修改、更新及删除操作，但不同意查看其他人所签的合同，也不同意修改或删除其他人的合同。
经理所具有的操作权限：
经理拥有对所有合同的添加、删除、修改、合同查询、统计的权限和账号权限的设置。
数据字典
表名
属性名
类型
长度
必填字段
主键
讲明
Empolyee
empl_id
empl_name
empl_type
empl_dep
empl_dia
position
empl_mp
empl_email
Empl_address
birthday
Employe_time
char
varchar
Char
Charvarchar
Varchar
datatime
10
50
是
否
职员编号
姓名
职员类不
部门
固话
职位
手机
邮件
地址
生日
雇佣时刻
Consumer_list
Consumer_num
consumer_name
Consumer_lxr
Consumer_firm
Firm_address
Consumer_dia
consumer_phonenum
consumer_add
consumer_email
consumer_beizhu
State
chat
varcharr
char
客户编号
客户名称
联系人
公司名称
公司地址
电话
联系地址
备注
客户状态
Order_list
ord_id
ord_no
Ord_name
ord_dd
cus_num
xm_id
prd_name
qty
up
amtn
ord_st
bil_dd
xinyong
ord_rt
ordertype_id
jiluren
Adddate
Isdelete
Int
datetime
int
decimal
Datetime
boolean
4
8
9
外键
序号
合同编号
合同名字
签订时刻
项目编号
项目名称
数量
单价
金额
执行情况
账期
信用额
收款情况
合同类不
建立人
系统时刻
是否差不多删除
Proj_info
proj_id
proj_cons
proj_name
proj_lxr
proj_ms
proj_sta
isDelete
项目描述
项目状态
Admin
Type
password
Numeric
Nvarchar
用户名
职员ID
类不
密码
log
OperateTime
Operate
Datatime
时刻
操作
publicNote
publicNoteID
publicNoteTitle
publisher
admin
publishTime
numeric
200
公告编号
公告标题
公告内容
公布人
操作人
公布时刻
listFile
listFileName
listFilePath
Ord_id
FileLength
long
文档名
文档路径
文档大小
5.2数据库概念结构设计（E-R图设计）
数据库概念结构设计的目标是产生出一个能反映组织信息需求的概念模型。
最广泛使用的概念模型是实体－联系（E-R）模型。
对合同治理系统实体关系的设计是建立在需求分析、系统分析的基础上的。
本系统的实体包括合同治理员、客户、合同、项目、账号、合同类不。
下面分不对这6个实体做E-R图设计。
1）一个合同治理员能够负责多个合同，因此职员和合同实体之间是一对多的关系，设计局部E-R模型如图3-3所示。
1M
图3-3
2） 一个客户能够签订多份合同，因此客户与合同实体之间是一对多的关系，设计局部E-R模型如图3-4所示。
1M
图3-4
3）一个客户会签订多个项目的合同，因此客户与项目实体之间是一对多的关系，设计局部E-R模型如图3-5所示。
图3-5
4）一个项目隶属于一个合同，因此项目与合同实体之间是一对一的关系，设计局部E-R模型如图3-6所示。
1
m
图 3-6
5）一个职员拥有一个账号权限，因此职员与账号实体之间是一对一的关系，设计局部E-R模型如图3-7所示。
11
图3-7
（6）一个合同拥有一个文档，因此文档跟合同实体时一一对应关系，设计E-R模型如图：
11
（7）一个治理员公布多个公告，因此治理员跟公告实体是一对多的关系，设计局部E-R模型如图：
1m
归纳上述5项，能够定义5个实体：
职员、客户、合同、项目和账号，这些实体之间的相互联系见表3-1。
联系
合同治理员
维护
合同
客户
制定
签订
项目
隶属
职员
拥有
账号
表3-1
将局部E-R模型综合成整体E-R模型，如图3-9所示。
图3-8 整体E-R模型
5.3数据库逻辑结构设计
逻辑结构设计是将概念模型（E-R模型）转换成关系数据库。
按照3.3.2节介绍的转换规则，将E－R模型转换成关系数据库。
1）职员信息表（职员编号，姓名，职员类不，部门，固话，手机，邮件）
PK＝职员编号 NOTNULL。
2）客户信息表（客户编号，客户名称，联系人，电话，手机，联系地址，邮件，备注，客户状态）
PK=客户编号 NOTNULL。
3）合同信息表（序号，合同编号，签订时刻，客户编号，项目编号，项目名称，数量，单价，金额，执行情况，账期，信用额度，收款情况，合同类不，建立人，建立时刻）
PK=合同编号 NOTNULL。
FK=项目编号，参照表是“项目信息表。
FK=客户编号，参照表是“客户信息表”。
4）项目信息表（项目编号，项目名称，联系人，项目描述，客户名称，项目状态）
PK＝项目编号 NOTNULL。
5）账号治理（ID号，帐号，密码）
PK=ID号NOTNULL
总结
作为一项系统工程，合同治理系统设计过程中有许多问题需要我们研究与考虑，其设计过程是一个通过不断地实践、总结经验、推进的过程。
由于上次单独做过一个有关于酒店的治理系统，整个开发过程差不多上自己完成的，因此这次设计并没有什么大的问题，反而对体会到数据库设计对总个系统开发是最重要的，因为数据库的结构会阻碍到系统的整体结构的,同时系统的业务流程是阻碍整个系统的质量的最重要的部分，因此我们通过调研了解了一下合同系统的业务流程，将系统的业务结构了解清晰，然后做出这份需求分析。
升级会员 