合同模板管理系统需求说明书.docx

资源描述

合同模板管理系统需求说明书.docx

《合同模板管理系统需求说明书.docx》由会员分享，可在线阅读，更多相关《合同模板管理系统需求说明书.docx（17页珍藏版）》请在冰豆网上搜索。

合同模板管理系统需求说明书.docx

合同模板管理系统需求说明书

合同系统需求分析讲明书

1.需求分析

软件系统的设计与开发中，最重要是从用户的专业领域中整理出需要计算机处理的需求。

通过查看一些资料调研，发觉公司公司规模大，地域分散较广。

下属单位可能依照自身实际情况形成内部独立的合同治理工作模式，这对整个公司合同治理的标准化造成了困难；而且基础数据存留在基层部门，将形成信息孤岛现象，造成信息不准确，利用率低等问题，合同数据传输的滞后也会对企业决策层的决策产生阻碍。

因此能够总结公司合同治理的需求如下：

1）实现信息处理的标准化和数据化，在公司内部建立标准的合同治理流程和内容规范；

2）建立统一的数据库系统，实现全公司数据集中治理，幸免信息孤岛的出现；

3）在合同生命周期内，实现数据信息跟踪治理，包括差不多信息和履行信息的治理；

4）实现合同的归档治理，以及合同数据查询、统计等处理功能；

5）确保合同治理工作的规范性和安全性。

2.业务流程分析

调查治理业务流程应顺着原系统信息流淌的过程调查，本例中业务流程为：

首先销售员将拟好的合同提交销售部门经理进行审批，部门经理收到合同后对其内容，包括销售价格、付款条件、账期等进行审核。

若审核未通过，则将合同返回销售员进行修改；若审核通过，则将合同转交给合同治理人员。

随后合同治理员将合同信息录入系统。

业务流程图见图2－1：

图2-1业务流程图

实体

表单

业务流

图2-2业务流程图图例讲明

3.数据流程分析

依照对现实系统的详细调查与分析，开发合同治理系统总体设想流程是：

对销售员提供的信息进行人工审核，将通过审核的数据汇总录入计算机，进行数据录入处理程序，再将数据存储到相关信息文件中。

系统的数据流程见图2-3：

图2-3数据流程图

4.系统总体结构设计

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

Varchar

varchar

Varchar

datatime

是

否

主键

职员编号

姓名

职员类不

部门

固话

职位

手机

邮件

地址

生日

雇佣时刻

Consumer_list

Consumer_num

consumer_name

Consumer_lxr

Consumer_firm

Firm_address

Consumer_dia

consumer_phonenum

consumer_add

consumer_email

consumer_beizhu

State

chat

varchar

Char

Varchar

varchar

varcharr

varchar

char

是

否

主键

客户编号

客户名称

联系人

公司名称

公司地址

电话

手机

联系地址

邮件

备注

客户状态

Order_list

ord_id

ord_no

Ord_name

ord_dd

cus_num

xm_id

prd_name

qty

amtn

ord_st

bil_dd

xinyong

ord_rt

ordertype_id

jiluren

Adddate

Isdelete

Int

Varchar

varchar

datetime

int

char

decimal

Char

char

Char

char

int

char

Datetime

boolean

是

否

是

主键

外键

序号

合同编号

合同名字

签订时刻

客户编号

项目编号

项目名称

数量

单价

金额

执行情况

账期

信用额

收款情况

合同类不

建立人

系统时刻

是否差不多删除

Proj_info

proj_id

proj_cons

proj_name

proj_lxr

proj_ms

proj_sta

isDelete

char

varchar

char

varchar

Char

boolean

是

否

是

否

是

主键

项目编号

客户名称

项目名称

联系人

项目描述

项目状态

是否差不多删除

Admin

empl_id

Type

password

Numeric

char

boolean

Nvarchar

是

否

是

主键

用户名

职员ID

类不

密码

log

Admin

OperateTime

Operate

Numeric

Datatime

Varchar

是

主键

用户名

时刻

操作

publicNote

publicNoteID

publicNoteTitle

publicNote

publisher

admin

publishTime

Numeric

Varchar

numeric

datatime

200

是

否

是

否

主键

公告编号

公告标题

公告内容

公布人

操作人

公布时刻

listFile

listFileName

listFilePath

Ord_id

FileLength

Varchar

Int

long

200

是

否

主键

文档名

文档路径

合同编号

文档大小

5.2数据库概念结构设计（E-R图设计）

数据库概念结构设计的目标是产生出一个能反映组织信息需求的概念模型。

最广泛使用的概念模型是实体－联系（E-R）模型。

对合同治理系统实体关系的设计是建立在需求分析、系统分析的基础上的。

本系统的实体包括合同治理员、客户、合同、项目、账号、合同类不。

下面分不对这6个实体做E-R图设计。

1）一个合同治理员能够负责多个合同，因此职员和合同实体之间是一对多的关系，设计局部E-R模型如图3-3所示。

图3-3

2）　一个客户能够签订多份合同，因此客户与合同实体之间是一对多的关系，设计局部E-R模型如图3-4所示。

图3-4

3）一个客户会签订多个项目的合同，因此客户与项目实体之间是一对多的关系，设计局部E-R模型如图3-5所示。

图3-5

4）一个项目隶属于一个合同，因此项目与合同实体之间是一对一的关系，设计局部E-R模型如图3-6所示。

图　3-6

5）一个职员拥有一个账号权限，因此职员与账号实体之间是一对一的关系，设计局部E-R模型如图3-7所示。

图3-7

（6）一个合同拥有一个文档，因此文档跟合同实体时一一对应关系，设计E-R模型如图：

（7）一个治理员公布多个公告，因此治理员跟公告实体是一对多的关系，设计局部E-R模型如图：

归纳上述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

总结

作为一项系统工程，合同治理系统设计过程中有许多问题需要我们研究与考虑，其设计过程是一个通过不断地实践、总结经验、推进的过程。

由于上次单独做过一个有关于酒店的治理系统，整个开发过程差不多上自己完成的，因此这次设计并没有什么大的问题，反而对体会到数据库设计对总个系统开发是最重要的，因为数据库的结构会阻碍到系统的整体结构的,同时系统的业务流程是阻碍整个系统的质量的最重要的部分，因此我们通过调研了解了一下合同系统的业务流程，将系统的业务结构了解清晰，然后做出这份需求分析。

展开阅读全文