系统需求说明书v3

考勤软件系统需求说明书

Software Requirement Specification

目 录

第1部分 引言 ........................................................... 2

1.1产品的定义和范围 ................................................. 2 1.2预期的读者和阅读建议 ............................................. 2 1.3需求分析的目标与方法 ............................................. 2

1.3.1 需求分析的目标与任务 .................................... 2 1.3.2 需求分析的关键原则 ...................................... 3

第2部分 综合描述 ....................................................... 4

2.1产品的前景和起源 ................................................. 4 2.2产品的框架结构 ................................................... 5 2.3用户类和特征 ..................................................... 6 2.4运行环境 ......................................................... 6 2.5设计和实现上的 ............................................... 6 2.6假设和依赖 ....................................................... 7 第3部分 外部接口需求 ................................................... 8

3.1用户界面 ......................................................... 8 3.2硬件接口 ......................................................... 8 3.3软件接口 ......................................................... 8 第4部分 其他非功能需求 ................................................. 9

4.1性能需求 ......................................................... 9 4.2安全设施需求 ..................................................... 9 4.3安全性需求 ....................................................... 9 4.4软件质量属性 .................................................... 10 第5部分 系统规格说明 ............................................... 12

5.1 考勤管理 ....................................................... 12

5.1.1 模块综述 ............................................... 12 5.1.2 模块导航 ............................................... 12 5.1.3 系统自动统计考勤信息发送给相关人员处理 ................. 15 5.2 出差管理 ....................................................... 15

5.2.1 模块综述 ............................................... 15 5.2.2 项目出差 ............................................... 16 5.2.3 非项目出差 ............................................. 20 5.2.4 出差查询统计 ........................................... 24 5.3 请休假管理 ..................................................... 26

5.3.1 请假管理 ............................................... 26 5.4 系统管理 ....................................................... 31 附录A 风险分析 ......................................................... 32 附录B 词汇表 ........................................................... 33

１

第1部分 引言

1.1 产品的定义和范围

系统定义：本系统为辅勤管理而开发，主要用于获取、存贮、检索相应的数据，并

使信息更好的在部门间流动。

系统范围：提供业务资料的信息共享，提供工作流，支持考勤数据审批流转及安全的共享，为用户提供远程办公的可能，并对各类业务资料进行管理。

1.2 预期的读者和阅读建议

预期的读者：用户、技术总监、设计员、程序员、确认测试人员。

1.3 需求分析的目标与方法

1.3.1 需求分析的目标与任务

需求分析的主要目的是通过详细的需求调研，理清管理流程，并分析其中的问题，把握用户的管理需求，设计出应用系统的逻辑模型和功能模型。需求分析是应用系统开发过程中最为关键的一个环节，只有准确无误地把握用户需求，开发出的应用系统才能真正为管理人员提供更多的支持。需求分析的工作目标如下：

(1) 使系统开发人员正确理解业务流程和管理需求；

(2) 发现管理中的问题，并寻求利用信息技术解决问题的可能途径； (3) 促使员工对本岗位的流程进行重新整理和再思考； (4) 提出新系统的逻辑模型，设计出系统原型。 需求分析阶段需要完成的任务如下：

(1) 完成应用软件的详细调研工作，调研内容包括相关部门、相关岗位的工作流程、数据载体等；

(2) 对管理流程和数据进行分析，理清数据与流程之间的关系； (3) 识别用户的功能需求，提出新系统的逻辑模型和功能需求模型； (4) 完成系统基本录入界面和查询界面的原型；

(5) 根据分析的结果，主要由开发方（武汉佰钧成技术有限责任公司）撰写需求分析报告（即本报告），作为与用户方共同认可的有关系统开发的需求说明。需求分析报告须经用户方和开发方共同签字确认，作为系统设计、系统编码、试运行和验收的主要依据。

1.3.2 需求分析的关键原则

作为信息系统建设过程中的关键阶段，需求分析工作中需要坚持用户参与原则。由于需求分析的主要目的就是系统开发人员了解用户(即管理中的业务人员和各级领导)的工作过程、方法等所有与工作相关的事项。需求分析是系统开发人员与业务人员进行充分交流的关键时期，而且，需求分析过程中必定会发现管理中的许多问题，这时需要业务人员和开发人员一起讨论解决方法，业务人员从管理上考虑问题，开发人员则从技术上提供解决方案。因此，需求分析需要系统开发人员、相关部门的业务人员、各级主管的密切配合和深层次的参与。

第2部分 综合描述

2.1产品的前景和起源

该产品为针对企业的办公产品。它是一个在局域网上运行的基于B/S模式的考勤系统。在Lotus产品被广泛应用的今天，人们在使用其产品的同时已不仅仅局限于C/S模式，更多的则是关注B/S模式。我们正是根据市场的发展趋势，本着与国际发展大方向接轨的思想，并结合企业的实际需求，为企业量身定做出这套考勤管理软件。

产品背景和起源：企业并没有一套考勤管理软件，各个部门较为孤立，通过纸质文档进行考勤管理，本软件在深入认识的基础上，根据企业的实际情况，规划出一个用于整个企业的考勤管理系统，可以满足企业的需求。本系统存在以下先进性：

1. 企业应用考勤管理软件的各部门之间通讯与协作审批； 2. 各个部门都能在严格的权限控制下，使用为其定制的模块； 3. 本系统在许多方面都考虑了灵活性，能更好的适应企业的复杂需求； 该产品的制作过程是在ISO9000的严格体系控制下完成的，其中需求的获取要通过评审小组的评审，并经过开会讨论进一步完善其功能。因此本系统的质量是完全可以保证的。

2.2产品的框架结构

考勤系统结构2010年8月30日Monday考勤管理系统考勤统计出差管理请休假管理人员配置流程配置系统配置MS SQLNFS页 1

2.3用户类和特征

普通查询用户：只能对各类非敏感信息进行检索，查询，无法对其信息内容进行更改操作；

业务操作用户：拥有普通查询用户的所有权限，并可对自己的数据进行更改操作，并与其他业务操作用户进行协同工作；

高级操作用户：拥有业务操作用户的所有权限，并可对一些普通业务操作用户无法完成的操作，如删除重要文档等；

领导级用户：在系统中拥有极高的查询权，可看到各类敏感和非敏感的数据，并可进行审批等重要操作。

2.4运行环境

硬件配置：

 客户端：1.8HZ以上主频的CPU，M以上内存，5G以上剩余磁盘空间，10M以上网

络带宽；

 服务器端：2.4GHZ以上主频的双核CPU，带UPS，2G以上内存，60G以上剩余磁盘

空间，10M以上网络带宽

软件配置：  客户端：用户浏览器 Microsoft windows95/98/NT/2000（要求SP3以上补丁）+IE6.0（要

求SP1以上补丁）以上

 服务器端 ：操作系统Microsoft windows NT/2000/2003 Server + Lotus Domino Server 注：Domino服务器充当web服务器（开通http服务，Domino作为应用程序服务器和邮件服务器）

2.5设计和实现上的

必须使用的特定技术：在Domino中的Web编程技术、代理、防火墙技术 必须使用的特定工具：Lotus Domino Designer

必须使用的特定编程语言：Lotus 公式语言、LotusScript、JavaScript、Java Applet 网络管理数据库webadmin.nsf

所要求的开发规范或标准：设计和实现遵循制订的ISO9001质量体系标准规定的程序文件以及第三层文件

数据格式转换标准：使用Domino Designer的设计表单和视图等界面元素，一般不直接编写HTML页面，当客户机浏览器向服务器发出请求时，由Domino Web Server自动将界面元素转换成HTML页面发送给浏览器端。

2.6假设和依赖

需求变更：现在假设需求已经冻结，需求不会再变更。当确实需要需求变更将由项目变更控制委员会决定实现那些变更。并且需求填写《需求变更申请表》，通过审核后方能进行。需求变更会影响开发的原计划时间安排。 服务器拓扑结构：企业内部的局域网。

运行环境：现在假设运行环境非下面四种需求情况

1. 实时需求：Domino不适宜用来设计要接收实时信息的系统。

2. 大量信息报表的需求：Domino不适宜用来制作大量的交叉查阅的表格，并且要进行合

并和汇总的系统

3. 关系型数据：数据的相关性越强，Domino局限性越大 4. 大量用户访问相同的文档： 系统运行时，认为以下条件成立：

1. 2. 3. 4. 5. 6. 7. 8.

用户的需求是可穷举的；

用户的功能需求在系统开发过程中不会进行大的变更；

操作用户在进行文档的自定义流转时，会正确选择下一个接收人； 普通操作用户不会对系统恶意进行破坏；

系统服务器由专人负责管理，不会被无关人员接近；

用户已具有一定的计算机应用基础，无需进行此方面的培训；

系统管理员Domino体系比较熟悉，能够完成日常的维护工作；

Domino软件包已具备的功能，直接应用于系统中，不再进行重复开发；

第3部分 外部接口需求

3.1 用户界面

快捷键：暂时没有定义快捷键。

错误信息显示标准：应用标准windows提示框 用户登录页面： 提供统一登录验证口令的界面。

基本信息录入页面：用表单的形式提供各方面的信息录入界面。 各功能模块导航界面：能够在各可见功能项中相互切换。

3.2 硬件接口

系统通过Domino与硬件进行数据交换等工作，不直接深入硬件底层操作： 客户端自少要有网卡NIC与服务器上的数据库通讯，即保证物理设备上线路的畅通

3.3 软件接口

产品与数据库的SSL连接：

安全套接字层 (SSL) 是为通过 TCP/IP 来运作的 Domino 服务器任务提供通讯保密和验证的一种安全性协议。可以要求用户使用可靠的 SSL 连接来访问数据库。如果不要求 SSL 连接，则客户机既可使用 SSL 也可使用 TCP/IP 连接到服务器。可以对单个数据库要求 SSL 连接，也可以对服务器上的所有数据库都要求 SSL 连接 需要开通的服务：

服务器端要装有Lotus Domino Server

普通客户端要装有浏览器IE，要求版本6.0以上，并安装过SP1补丁，同时将办公自动化站点设为可信站点，同时自定义可信站点的安全性（详见《管理员手册》）

管理客户端要装有Lotus Administrator

与SQL数据库连接

通过ADODB与SQL数据库连接，读取人员信息，写入出差与请休假信息。

第4部分 其他非功能需求

4.1 性能需求

1

采用Browser/Sever模式，共享数据库信息，网络正常流量下（５Ｋ／Ｓ）数据库

文档存取反应时间不超过10秒

在不运行其他应用程序条件及网络正常流量下，服务器数据库文档存取时ＣＰＵ占用率不超过80％。

2

4.2 安全设施需求

1. 源代码要隐藏，包括管理员在内的人员无法察看。 2. 有条件可以安装防火墙

3. 用户在使用过程中的权限严格控制

4.3 安全性需求

产品必须满足的安全型或保密性策略

1. 用户关心的几种安全要求，要考虑进来，根据实际情况，能解决的都要在需求中说

明，拿不准的就作为待细化和明确内容提出来 2. 能够进行严格存取权限控制（ＡＣＬ），保证数据库信息安全。只有该数据库管理

者才可以进行权限配置操作。具有文书角色才可以进行新建操作。 3. 数据库要达到应用级安全。即使用SSL（安全套接字协议）验证客户机和服务器

+x．509验证

系统的安全，按照保密规定的要求，至少要达到“身份鉴别，访问控制，系统审计”三大要点，除此以外，我们还在办公自动化系统中，结合了多种方式来保证系统的安全可靠。

1．身份鉴别

任何用户要以自己的身份进入系统，就是说，进入系统前必须进行身份验证，以确

定当前用户”是谁”，未在系统注册范围内的用户，是被拒绝于系统之外的。 2．访问控制

用户通过身份验证后，系统自动根据使用者的身份确定其操作级别，并针对此级别显示不同的数据，提供不同的操作界面。级别不够的用户看不到存贮在系统中的敏感数据，也看不到越权的操作按钮。也就是说，无权察看的数据和无权进行的操作虽然存在于系统中，但对权限级别不够的用户是透明的。 3．系统审计

用户对任何一个子系统数据的访问，都会被系统自动记录在审计数据库中，系统会记录哪个时间开始，至什么时间结束，具体用户名，访问了什么数据库的数据，供管理员在必要时查阅。一旦某项敏感信息泄露，管理员可根据审计数据库找到相应数据被谁访问过，从而进一步追查相关数据汇密的可能性。

系统审计数据库不允许任何用户修改其内容，只能在一定时期内归到一个备份库中备查。

4．数据文件加密

服务器上的数据库文件采用Notes提供的强度加密方式进行加密处理，加密处理并不影响使用者的日常操作，而一旦非法用户将数据库文件复制到本地，由于其没有管理员的身份标识文件，无法打开数据库，也就无法对其中的任何数据进行读取。 5．数据库内容加密

系统中的数据内容，并不是以明文形式存贮在数据库中的，而是被Domino以其特有的编码方式，与其他设计元素一起存放在数据库文件中。因此，非法用户即使取得数据库文件，也不能直接查看其中的数据内容。 6．网络加密传输

系统采用SSL方式，对网络上传输的数据进行加密处理，这样即使非法用户通过侦听方式取得网上传输数据，也无法对其信息进行读取。

4.4 软件质量属性

1. 可靠性：当操作错误时（如忘记填写关键域而直接保存或者人员编码重复），系统

应提示错误信息，并且用户可以修改错误（继续填写关键域）。

2. 可用性：域的命名要具有可理解性，看见域名就知道相应含义，从而可以方便使用。 3. 可移植性：可以移植到其它的硬件基础上。

4. 可维护性： 具有产品软件维护所必须的规范文档及说明书。

5. 可操作性：普通用户只需能正常运行IE，会浏览网页，就可以在《用户使用手册》指导下进入办公自动化系统。 6. 可安装性：系统管理员只需具有Notes基本知识，就可以在《产品安装指南》指导

下安装软件的服务器端程序。

第5部分 系统规格说明

5.1 第一章 考勤管理

5.1.1 模块综述

考勤管理模块主要是对企业内部的出勤情况查询、统计的管理。

5.1.2 模块导航

用户在点击主界面左菜单 “考勤管理”，进入“考勤管理”模块。 导航内容包括以下几项：

员工日考勤明细

显示当天所有员工的打卡明细情况； 查询表单：选择年 与月 默认为当月。 选择日期 选择部门 日期控件 查询 查询结果 员工编姓名 号 A00 A01 张三 李四 日期 2010.08.05 2010.08.05 刷卡机号 3 上午刷卡时间 8:50:00 下午刷卡时间 17:40:00 异常 迟到 1 备注 出差

工月考勤明细：显示当月所有员工的出勤明细情况；查询格式见 查询表单：选择年 与月 默认为当月。 选择日期 选择部门 年 月 查询 查询结果 年月： 序号 1 部门 ＃＃ 员工编号 A00000 姓名 张三 周日 1 一 2 迟到 Q_WH_PIM_A88_05_员工月考勤明细表06-

二 3 三 4 迟到 。。。 。。。 。。。 。。。

员工月考勤报表：显示统计当月所有员工出勤，以报表形式；查询格式见

Q_WH_PIM_A88_06_员工月考勤报表06-27

查询表单：选择年 与月 默认为当月。 选择日期 部门 年 月 查询 查询结果 序号 部门 员工编号 姓名 出差 (天) 迟到(次) 早退(次) 旷工(天) 。。。 。。。

。。。 。。。

员工年度考勤：显示统计当年所有员工出勤；查询格式见 查询表单

选择日期 年 查询 查询结果 序号 部门 员工编号 姓名 （年度）实际出勤应出勤天数 天数 251 241 Q_WH_PIM_A88_07_员工年度考勤报表06-

请假天数 18 旷工天数 2 。。。 张三 。。。 。。。

。。。 部门日考勤统计：显示统计当月所有员工出勤；查询格式见 查询表单

选择日期 年 查询 查询结果 部门名称 ### 部门总人数 E:\\化四\\管理规定流程及报表\\

85

正常刷卡人数 60 迟到员工名单 早退员工名单 张三、李四、王五„„ 迟到人数 早退人数 5 5 旷工人数 2 旷工员工名单 出差人数 10 出差员工名单 请假人数

3 请假员工名单 视图区上按钮包括以下几项： 『上一页』：显示当前页面的上一页所有可阅览文件； 『下一页』：显示当前页面的下一页所有可阅览文件；

5.1.3 系统自动统计考勤信息发送给相关人员处理

后台代理每天自动运行完成统计功能。

 统计部门迟到及早退人数，如要超出10人以上或50%，发送给相关公司分管领导。

（）

 统计员工一个月内迟到10次以上或未打卡两次以上。发送给相关公司分管领导。

5.2 第二章 出差管理

5.2.1 模块综述

出差管理模块主要实现出差的审批流程和通知、核销、归档等的综合管理，分为项目出差、非项目出差。

5.2.2 第一节 项目出差

5.2.2.1 功能描述

1、 项目出差由项目秘书起草先交由各项目经理审批，如果是项目经理出差则交给

项目部主任审批。各项目经理审批完后如果是生产人员就还要给部门领导审批，最后所有人员交给项目部主任审批。完成审批之后通知出差人员。出差加来后到部门主任去核销。

2、 标题提示的格式为：部门/项目+人员+”自”+开始时间+“至”+结束时间+“出

差的请示”。

3、 起止时间为日期控件，只提供日期选择。 4、 选择开始与结束日期后自动算出共计天数

5、 出差人员表为动态表格，可以动态的增加删除人员。 6、 开始起草与关闭流程环节要将数据写入SQL数据库

7、 流程发送给主要领导审批后，在一定时间（一般三小时，可以在后台配置）内

领导没有审批系统自动发送给副领导审批。 8、 该模块需提供以下配置： 部门 专业

5.2.2.2 项目出差主表单设计

用户在“新建项目出差”导航栏中点击“项目出差”按钮，界面如下所示： 单号：项目号-CC-流水号 项目出差计划审批表 项目简称 出差事由 出差地点 出差起止时间 自 至 共 天 出差人员表 职位 职 称 部门主任审批意见 部门 专业 姓 名 员工编码 操作 增加 删除 项目经理审批意见

部门审批意见 项目部审批意见 字段标题 类型 标题 项目简称 出差地点 出差起止时间 部门 文本 文本 文本 日期 下拉列表 下拉列表 文本 文本 文本 文本 单选 取值范围及有效性检验 手工填写 SQL库配置 手工写入 控件输入 工艺部,公用系统室,管道室,设备室,电控室,土建室,项目控制部,采购部,施工部,信息技术部,安全质量部,财务部,项目部 跟据部门不同取值不同。通过后台配置取值 手工填写 手工填写 系统自动输入 系统自动输入 1、同意 2、不同意 备注 专业 姓 名 员工编码 职位 职 称 部门主任审批意见 项目经理审批意见 项目部审批意见

部门审批节点时输入，不同意时显示意框 项目经理审批节点时输入，不同意时显示意框 项目部审批节点时输入，不同意时显示意框 单选 1、同意 2、不同意 单选 1、同意 2、不同意

5.2.2.3 项目出差流程图

出差管理--项目出差项目秘书出差审批表是否项目经理部门主任副总工程师生产人员项目经理项目经理退回审批生产人员生产人员部门主任副总工程师部门主任退回审批出差返回核销项目部主任生产人员退回审批通知出差人员 5.2.2.4 流程环节说明：

1、起草环节

处理人：项目秘书

处理内容：填写主表单信息 操作：

 保存：保存主表单以下次再编辑。  提交：提交给下一处理人。  关闭：关闭当前页面。 下一节点：

 如果出差人员是项目经理 下一节点为项目部主任。  如果不是项目经理，下一节点为项目经理。

2、项目经理审核

处理人：出差人员项目经理 处理内容：项目经理意见 操作：

 保存：保存主表单以下次再编辑。  提交：提交给下一处理人。  关闭：关闭当前页面。 下一节点：

 如果出差人员是生产人员 下一节点为部门主任。  如果不是生产人员，下一节点为项目部主任。

3、部门主任审核

处理人：出差人员部门主任

处理内容：部门主任意见 操作：

 保存：保存主表单以下次再编辑。  提交：提交给下一处理人。  关闭：关闭当前页面。 下一节点：

 如果不是生产人员，下一节点为项目部主任。

4、项目部主任审核

处理人：出差人员部门主任 处理内容：项目部主任意见 操作：

 保存：保存主表单以下次再编辑。  提交：提交给下一处理人。  关闭：关闭当前页面。 下一节点：

 出差人员确认与核销。

5、出差人员确认与核销 处理人：出差人员

处理内容： 系统自动记录时间 操作：

 保存：保存主表单以下次再编辑。  提交：提交给下一处理人。  关闭：关闭当前页面。  核销：核销出差。 下一节点：

 部门主任核销。

6、部门主任确认核销

处理人：出差人员部门主任 处理内容： 操作：

 保存：保存主表单以下次再编辑。  提交：提交给下一处理人。  关闭：关闭当前页面。  关闭电子流：流程关闭。 下一节点： 无

5.2.2.5 视图列表

视图名称 按开始时间 文档来源 项目出差 字段名称及顺序 排序规则及特殊功能（降序） 开始时间，实际结束时间，起草时间 部门，项目简称，项目编号，地点，状态， 人员（显示一个人+“等”） 状态，部门，项目简称，项起草时间 目编号，开始时间，实际结束时间，地点 人员（显示一个人+“等”）, 项目简称，项目编号，开始起草时间 时间，实际结束时间，地点 人员（显示一个人+“等”）,状态 部门，项目简称，项目编号，起草时间 开始时间，实际结束时间，地点 人员（显示一个人+“等”）,状态 开始时间，实际结束时间，起草时间 部门，项目简称，项目编号，地点，状态， 人员（显示一个人+“等”） 按状态 项目出差 项目简称 项目出差 按部门 项目出差 按开始时间 项目出差

5.2.3 第二节 非项目出差

5.2.3.1 功能描述

1、 非项目出差由事务秘书起草先交由各部门主任审批，如果是部门主任出差则不

用审批。各部门主任审批完后如果是经营性出差就还要给经营部门领导审批，最后所有人员交给项目部主任审批。完成审批之后通知出差人员。出差加来后到部门主任去核销。

2、 标题提示的格式为：部门+人员+”自”+开始时间+“至”+结束时间+“出差的请

示”。

3、 起止时间为日期控件，只提供日期选择。 4、 选择开始与结束日期后自动算出共计天数

5、 出差人员表为动态表格，可以动态的增加删除人员。 6、 开始起草与关闭流程环节要将数据写入SQL数据库

7、 流程发送给主要领导审批后，在一定时间（一般三小时，可以在后台配置）内

领导没有审批系统自动发送给副领导审批。 8、 该模块需提供以下配置：同项目出差。

部门

专业

5.2.3.2 非项目出差主表单设计

用户在“新建项目出差”导航栏中点击“项目出差”按钮，界面如下所示： 单号：一般出差-CC-流水号 非项目出差计划审批表 出差类型 出差事由 出差地点 出差起止时间 自 至 共 天 出差人员表 职位 职 称 部门主任审批意见 部门 专业 姓 名 员工编码 操作 增加 删除 部门主任审批意见 经营管理部门经理审 批意见 项目部审批意见

字段标题 类型 标题 文本 取值范围及有效性检验 系统自动生成 备注 部门/项目+人员+”自”+开始时间+“至”+结束时间+“出差的请示”。 姓 名 员工编码 部 门 专 业 职 称 文本 文本 文本 文本 文本 手工填写 手工填写 系统计算 系统计算 系统计算

职 位 出差类型 出差地点 出差起止时间 部门主任审批意见 经营管理部门经理审批意见 项目部审批意见

文本 单选 文本 日期 单选 系统计算 □一般性出差 □各类会议 □培训 □经营出差 □其他 手工写入 控件输入 1、同意 2、不同意 部门审批节点时输入，不同意时显示意框 项目经理审批节点时输入，不同意时显示意框 项目部审批节点时输入，不同意时显示意框 单选 1、同意 2、不同意 单选 1、同意 2、不同意 5.2.3.3 非项目出差流程图

出差管理--非项目出差事务秘书出差审批表管理部门主任是通知出差人员否部门主任退回审批经营出差否管理人员是通知出差人员出差返回核销是经营部门主任退回审批管理人员否是通知出差人员项目部主任否审批退回通知出差人员 5.2.3.4 流程环节说明：

1、起草环节

处理人：事务秘书

处理内容：填写主表单信息 操作：

 保存：保存主表单以下次再编辑。  提交：提交给下一处理人。  关闭：关闭当前页面。

下一节点：

 如果出差人员是部门主任， 下一节点为部门主任核销。  如果不是部门主任，下一节点为部门主任审核。 3、部门主任审核

处理人：出差人员部门主任 处理内容：部门主任意见 操作：

 保存：保存主表单以下次再编辑。  提交：提交给下一处理人。  关闭：关闭当前页面。 下一节点：

 如果是经营出差，下一节点为经营部主任审核。

 如果不是经营出差，并且不是领导 下一节点为项目部主任审核。  如果不是经营出差，并且是领导 下一节点为经营部主任审核 

4、经营部主任审核

处理人：出差人员部门主任 处理内容：经营部主任审核意见 操作：

 保存：保存主表单以下次再编辑。  提交：提交给下一处理人。  关闭：关闭当前页面。 下一节点：

 如果不是经营人员，下一节点为项目部主任。

4、项目部主任审核

处理人：出差人员部门主任 处理内容：项目部主任意见 操作：

 保存：保存主表单以下次再编辑。  提交：提交给下一处理人。  关闭：关闭当前页面。 下一节点：

 出差人员确认与核销。

5、出差人员确认与核销 处理人：出差人员

处理内容： 系统自动记录时间 操作：

 保存：保存主表单以下次再编辑。  提交：提交给下一处理人。

 关闭：关闭当前页面。  核销：核销出差。 下一节点：

 部门主任核销。

6、部门主任确认核销

处理人：出差人员部门主任 处理内容： 操作：

 保存：保存主表单以下次再编辑。  提交：提交给下一处理人。  关闭：关闭当前页面。  关闭电子流：流程关闭。 下一节点： 无

5.2.3.5 视图列表

视图名称 按开始时间 文档来源 非项目出差 字段名称及顺序 排序规则及特殊功能（降序） 开始时间，实际结束时间，起草时间 部门，项目简称，项目编号，地点，状态， 人员（显示一个人+“等”） 状态，部门，项目简称，项起草时间 目编号，开始时间，实际结束时间，地点 人员（显示一个人+“等”）, 部门，项目简称，项目编号，起草时间 开始时间，实际结束时间，地点 人员（显示一个人+“等”）,状态 按状态 非项目出差 按部门 非项目出差

5.2.4 出差查询统计

查询所有出差信息。

查询表单： 开始时间 日期控件 结束时间 日期控件

出差类型 出差部门 查询 出差项目

查询结果 见：

序号 1 2 3 姓名 Q WH PIM A87 附录D 出差计划审批表

员工编码 部门 XX XX XX 专业 XX XX XX 张三 A0000XX 张四 A0000XX 张五 A0000XX 项目一般性各类经营„ 培训 出差 出差 出差 会议 „ „ …

5.3 第三章 请休假管理

请休假管理模块主要实现公司员工的请假 休假的综合管理； 请休假模块包括:请假 休假 两大模块；

5.3.1 第一节 请假管理

5.3.1.1 功能描述

1、 请假是员工按照规定的请假事项起草请假文档交由部门领导审批。部门领导审批完后

通知请假人员。假期完后要到部门领导那里销假。 2、 请假员工要严格按照公司的请假条例。 3、 起止时间为日期控件，只提供日期选项。 4、 选择开始与结束日期后自动计算总计天数。

5、 流程发送给主要领导审批后，在一定时间（一般三小时，可以在后台配置）内领导没

有审批系统自动发送给副领导审批。

5.3.1.2 员工请假流程图

请假管理请假人员请假申请表是否是领导部门主任审批不超过1天结束部门经理审批不超过3天结束人力资源部审批通知请假人员休假返回销假总经理不通过审批

5.3.1.3 员工休假流程图

休假管理休假人员休假申请表是否是领导是部门负责人审批人力资源部是否通过是审批通知休假人员核销是否通过是

5.3.1.4 流程环节说明：

1、起草环节

起草人：请假员工

处理内容：填写主表单信息 操作：

 保存：保存主表单以下次再编辑。  提交：提交给下一处理人。 下一结点：

 如果请假是部门主任，下一结点为部门经理审批 如果是部门经理，下一结点

为总经理。

 如果不是部门主任、 部门经理，下一结点为部门主任审批；

2、部门主任审核

处理人 ：部门主任 处理内容：部门主任意见 操作：

 保存：保存主表单以下次再编辑。  提交：提交给下一处理人。  关闭：关闭当前页面。

下一结点：部门经理审核

3、部门经理审核

处理人 ：部门经理 处理内容：部门经理意见 操作：

 保存：保存主表单以下次再编辑。  提交：提交给下一处理人。  关闭：关闭当前页面。 下一节点：

 人力资源部审核。

4，人力资源部审核

 处理人 ： 行政人员

 处理内容：审查 核对申请信息

操作：

 保存：保存主表单以下次再编辑。  提交：提交给下一处理人。  关闭：关闭当前页面。

下一结点：

 请假人员核查与核销

5、总经理审批

处理人： 总经理

处理内容： 总经理意见 操作：

 保存：保存主表单以下次再编辑。  提交：提交给下一处理人。  关闭：关闭当前页面。  关闭电子流：流程关闭。 下一节点： 无

5.3.1.5 请假主表单设计

用户在“新建人员请假”导航栏中点击“人员请假”按钮，界面如下所示： （编号）：部门-员工编号-QJ-流水号 姓 名 部 门 员 工 请 休 假 单 员工编号 联系电话 □带薪休假 □事假 □婚假 □产假 □病请假类型 假 □探亲假 □殡丧假 选择带薪休假显示（已休天数： 剩余天数：） 请假事由 外出地点 自 年 月 日 请假起止时间 天 部门主任 部门经理 人力资源部 总经理 字段标题 编号 姓名 部门 至 年 月 日 共计 类型 文本 文本 下拉列表 取值范围及有效性检验 部门-员工编号-QJ-流水号 手工填写 控件输入 备注 必填

请假类型 单选 □带薪休假 □事假 □婚假 必填 □产假 □病假 □探亲假 □殡丧假 如果是带薪休假则显示“已休天数” “剩余天数” 请假事由 外出地点 请假起止时间 部门主任审批 部门经理审批 人力资源部审批 总经理审批

文本 文本 日期 单选 文本 文本 文本 手工填写 控件输入 1、同意 2、不同意 手工填写 手工填写 手工填写 必填 必填 部门主任审批节点时输入 部门经理审批节点时输入 人力资源部审批节点时输入 总经理审批节点时输入 5.3.1.6 视图列表

视图名称 按开始时间 文档来源 请休假管理 字段名称及顺序 排序规则及特殊功能（降序） 开始时间，实际结束时间，起草时间 部门，项目简称，项目编号，地点，状态， 人员（显示一个人+“等”） 状态，部门，项目简称，项起草时间 目编号，开始时间，实际结束时间，地点 人员（显示一个人+“等”）, 部门，项目简称，项目编号，起草时间 开始时间，实际结束时间，地点 人员（显示一个人+“等”）,状态 按状态 请休假管理 按部门 请休假管理

第四章 系统管理

5.3.1.7 模块概述

系统管理主要用于对组织结构、人员注册、角色分配、等方面进行管理。通过系统管理员在此模块中的相关预设置，来完成在系统运行过程中需要的各种功能。如自动判断该人员的处室、部门；根据流程自动判断该环节的审核人员；委托办理人的权限等等。

5.3.1.8 功能详述

1、组织结构：

本系统将组织结构分为两个组织  单位、部、个人三层结构  项目组，项目成员两层结构

2、人员注册

人员注册注册工作由代理自动完成。人手动调整，注册内容包括姓名、所在部门、所在项目组、用户角色等方面的信息。已注册人员可以使用系统管理员分配的用户名和密码进入本系统。

3、角色分配

角色分配主要是在管理模块中选择具有相应的角色权限的文件以保证文件的正常流转。

4、系统审计

系统进入每个应用模块，进行每步操作，以及查看某个文档，都会被系统自动记录下来，形系统日志。只有系统管理员才能查看系统日志。

系统管理员从系统管理模块中进入，查看系统日志，系统日志按时间，操作者所属部门，操作者姓名分类排序，还包含操作开始时间，结束时间。日志支持全文检索功能。

附录A 风险分析

1. 软件规模不确定：

1) 产生条件：单位上层领导和相关应用人员认为系统应完成单位所有业务功

能，不断提出业务功能，要求系统实现；

2) 产生影响：导致系统边界不清，规模庞大，系统工期拖长

3）风险归避：对单位上层领导及相关应用人员强调概念及范围，一个软件不是万能的，只是企业信息化的一部分，应该完成自己应该完成的功能 2. 需求无限膨胀

1) 产生条件：用户在开发过程中，不断提出各项新增功能要求 2) 产生影响：导致系统功能、设计频繁变更，软件永远不可能做完 3) 风险归避：通过《需求规格说明书》，在一段时间内固化需求 3. 系统推广力度：

1) 产生条件：上层领导和相关人员对系统的认识和重视程度不够

2) 产生影响：导致系统无法正常被使用或真正的实用起来，产生相应效益 3) 风险归避：提高上层领导和相关人员对系统的重视程度，使其能理解实施

系统的必要性和重要性

4. 缺乏项目人员配合：

1) 产生条件：系统管理人员的变动，或其他项目的工作量较大 2) 产生影响：导致系统不能较好的推广，不能达到系统原定目标

3) 风险归避：尽量设置一个专职的系统管理员，并提高系统管理员的水平 5．系统安全方面技术问题：

1) 产生条件：由于系统对安全性方面很高 2) 产生影响：安全不能达到系统要求 3) 风险归避：提高项目开发人员技术水平；和相关人员协商在保证数据安全

的前提下，达成技术和安全的一致意见

6． 项目组成员变动：

1) 产生条件：公司组织、人员结构的调整 2) 产生影响：系统不能按时、安量完成 3) 风险归避：开发过程中给出完整的文档，以便后续开发人员能很快熟悉此

项目开发环境，投入开发

附录B 词汇表

建立词汇表的目的：

1. 为建立数据字典收集资料

2. 澄清和消除开发人员、用户之间的理解歧意（二义性）

1) 个人通讯录

各用户的私人通讯卡片，类似于个人卡片盒，用户可以使用它记录自己家人、朋友的地址、电话等信息； 2) 人员公共通讯录

公用的通讯薄，与个人通讯录比较相似，但是是全办公业务网中的人都可看到的（除标记为敏感信息的记录外）； 3) 系统公共通讯录

Domino的系统目录（Domino Directory），用户必须在其中进行注册才能拥有自己的用户名和口令，以进入系统； 4) 系统管理

分为办公自动化管理和Domino管理两部分，前者指对服务器IP，系统数据目录等进行配置的部分，后者指管理Domino服务器，主要是系统公共通讯录（Domino Directory）和邮箱文件等； 5) 待办事宜

指个人的待办事宜。