1.1.项目名称
校园内外OA系统
1.2.编写目的
本需求规格说明书是为了开发校园内外OA系统而编写，主要面向系统分析员、程序员、测试员、实施员和最终用户。本说明书是整个系统开发的依据，它对以后阶段的工作起指导作用。本文也是项目完成后系统验收的依据。同时本说明书还是《用户手册》和《测试计划》的编写依据。1.3.项目背景
随着学校不断的扩大，校园职工年年增加，需要管理的东西越来越多，传统的人工管理已经过时，而且效率很低，各方面的信息都不够全面，不够安全，管理比较混乱，在各方面的操作都比较麻烦，所以需建立一个高效的、稳定的、安全的、标准的、可扩展的自动化办公工具，即OA系统。1.4.参考资料
【1】《网络程序设计案例教程——ASP.NET+SQLServer》孙践知清华大学出版社2008年【2】《VisualC#网络编程技术与实践》梅晓冬，颜烨青编著清华大学出版社2008年【3】《C#网络应用编程》高春蓉[同译者作品]谷宇阎隽编著电子工业出版社2003年2.任务概述
2.1.项目总体目标
开发一个OA自动化办公统，应用在学校内网上。让学校有一个比较快速、高效、安全的文档管理系统，有了这个系统，学校可以对各类文档进行分类管理，可以保存，随时可以查看，除了学校领导可以登录这个系统外，其他教职工也可以登录，只需注册一个账号，就可登录查看文档，如果学校有什么通知，都可以通过这个系统进行发布，各层人员都可以很方便的查看重要文档。2.2.单位概况
该单位是一所大学，学校又分了多个学院，每个学院又分成了系，该校有校长一名，院长数名，每个学院有教职工数名，如下组织结构图所示图2.1单位组织结构图2.3.业务需求
开发本系统旨在提高服务质量、方便管理、节约成本。2.4.开发环境
开发语言：C#开发工具：MicrosoftVisualStudio20052.5.运行环境2.5.1.软件环境
操作系统：MicrosoftWindowsXP支持环境：数据库：MicrosoftSQLServer20002.5.2.硬件环境
普通PC机即可2.6.条件与限制
该系统只针对本院的领导，职工以及学校领导开放，需注册一个账号，每次需登录才能进该系统，进去之后可以对个人信息进行修改，可以查看各种公文，还可以发布公文，但发布之前必须先申请，要通过上级的审批后才能发布，如果是公共文档，审批通过后直接发布，其他用户都可以查看，如果是个人文档，审批通过后，要通过发送到接受方才能被查看。但是开发时间太短，可能在这段时间连需求都没有理清，更别说开发了。该院的管理机构比较复杂，涉及的人比较多，在短时间内无法了解他们的具体的管理流程和内容。开发出来的系统运行效果难以保证。3.功能需求
3.1.功能总体描述
OA系统主要是对有登录该系统权力的用户的个人信息管理，个人信息包括用户账号、姓名、密码、家庭背景、文化程度、注册登录时间等基本信息，当用户注册时需要输入这些信息，当然用户也可以修改自己的基本信息；该系统还包括公文管理和本职管理，公文管理主要是对学校，学院，以及个人的文档进行管理；本职管理主要是根据用户角色的不同而不同，例如，如果职务是校长，他可以审批文档和查看文档，如果是院长，他可以审批本院的文档和查看所有文档等；3.2.个人信息管理
3.2.1.业务介绍用户可以登录本系统，图3.1.用户登录活动图3.2.2.实体类图3.2.用户类图表3-1类名用户信息属性名用户编码部门号职称姓名说明用户编码用户所属部门号职称姓名密码出生年月家庭住址文化程度电话电子邮件注册时间登录时间密码出生年月家庭住址文化程度电话电子邮件注册时间登录时间3.3.公文管理
3.3.1.业务介绍学校公共文档管理、学院公共文档管理、个人文档公共管理、提示信息、申请发布文档、私人通讯；学校用户通过申请发布公文，需要通过上级审批，如果审批通过，则公文可以发布，且存于数据库中，而且可以被查看，也可发送给其他人，系统将给出提示信息，提示接收人接受文档；如果审批不通过，就把公文返回申请人处；公文同样被存入数据库，但是文档不能被发布；图3.3公文申请及发布活动图3.3.2.实体类图3.4公文管理所涉及的类的类图表3-2类名公共文档属性名文档编号面向部门号文档来源发布者编号文档名称发布时间审批标志文档连接地址说明文档编号面向部门号文档来源发布者编号文档名称发布时间审批表示文档连接地址文档编号发送者编号接受者编号发布日期阅读日期阅读标志文档名称文档连接地址信息编号接受者编号发送者编号信息内容个人文档文档编号发送者编号接受者编号发布日期阅读日期阅读标志文档名称文档连接地址信息信息编号接受者编号发送者编号信息内容信息发送时间阅读时间阅读标志用户信息用户编码部门号职称姓名密码出生年月家庭住址文化程度电话电子邮件注册时间登录时间信息发送时间阅读时间阅读标志用户编码用户所属部门号职称姓名密码出生年月家庭住址文化程度电话电子邮件注册时间登录时间3.4.本职管理
本职业务模块根据登陆的用户不同而显示不同的功能。1.员工无本职业务模块。2.院长本职业务模块：审批院系公共文档，查看所有文档3.系主任本职业务模块：审批院系公共文档4.人事主管本职业务模块：添加人员，删除人员，人员调动5.部门领导本职业务模块：审批本部文档1.员工位于工作流的底层，他们只负责发出他们的工作产品，也就是想部门主管申请发布本部门公共信息。但是作为网络OA系统的一个用户，员工可以更改个人用户信息、查看公共信息，也可以通过系统与其他用户建立私人联系，员工任务图如下：图3.4.员工任务的用例图2.人事主管是一名员工，拥有与“员工”一样的工作任务。但在学院里，他又有特殊的任务，即管理整个学院的人事，人事主管的任务如下：图3.5.人事主管任务用例图3.院长是一个特殊的角色，他不直接参与管理，但能看到整个工作流程的任何一个环节。他除了拥有一个普通用户的权限外，还可以查看全院的任何一条信息，包含私人信息，校长的任务图如下：图3.6.院长任务用例图4.部门主管除了更改个人信息、查询本部门公司公共信息、与其他用户建立私人联系外，还要审批本部门员工发布的公共信息，管理本部门的公共信息，接收外部门传来的公共信息，向主管申请发布公司公共信息等，部门主管的任务如下图所示：图3.7.部门主管任务用例图5.系主任的特殊任务是审批公司公共信息的发布，向各个部门发送指令，查看每个部门的公共信息，系主任的任务如下图所示：图3.8.系主任任务用例图主要的参与者和完成的功能:表3-3参与者员工人事主管院长部门领导系主任完成的功能个人信息修改、查询公共信息、个人信息联系、申请发布信息个人信息修改、查询公共信息、个人信息联系、人事管理个人信息修改、查询公共信息、个人信息联系、查看其他人的信息个人信息修改、查询公共信息、个人信息联系、申请发布信息、审核信息个人信息修改、查询公共信息、个人信息联系、公共信息审批4.非功能性需求
4.1.技术需求
表格4-1软硬件环境需求需求名称硬件要求系统平台运行环境支持标准网络协议的网卡Windows2000/WinXP/Win2003SunJavaJRM1.5ForWin/Linux详细要求IBM兼容机、IntelPentiumIII800/AMDK7以上处理器、128M以上内存ReaHatLinux9/Fedora系列4.2.性能需求
软件相应速度等的说明。4.3.质量需求
表格4-2产品质量需求主要质量属性正确性健壮性可靠性性能，效率易用性清晰性安全性可扩展性兼容性可移植性详细要求消息在不同系统平台之间进行传递和显示时不会出现乱码现象能够容纳100-200人同时在线交流，服务器端程序连续应工作半年以上应用程序异常退出及崩溃的机率小于等于5%用户消息发送与接收的延迟时间小于等于5秒不用安装，操作简便—保证用户的信息在传输过程中不被窃取、不会泄漏至外网可在当前需求基础之上进行功能上的扩展可运行在大多数主流的硬件环境中可运行在大多数主流的操作平台上4.4.安全保密需求
安全保密需求描述，但要注意区分不是软件权限的说明。5.总体设计
5.1.功能架构
图5.1总体功能结构图6.功能详细设计
6.1.个人信息管理6.1.1.功能说明
用户第一次登录可以对个人信息完善，同时对密码进行修改，登录登录帐号显示部分主要信息在页面上，设置快捷键退出后转到首页。6.1.2.功能结构
功能：修改个人信息，修改密码。图6.1.16.1.3.类设计
用户信息类：类名用户信息属性名用户编码部门号职称姓名密码出生年月家庭住址文化程度电话电子邮件注册时间登录时间说明用户编码用户所属部门号职称姓名密码出生年月家庭住址文化程度电话电子邮件注册时间登录时间6.1.4.用户界面设计
图6.1.26.1.5.类的算法与程序逻辑
根据登录的帐号到数据库查找相关信息，并显示需要的数据。6.2.公文管理6.2.1.功能说明
学校公共文档管理、学院公共文档管理、个人文档公共管理、提示信息、申请发布文档、私人通讯；6.2.2.功能结构
图6.2.1公文管理功能图6.2.3.类设计
6.2.2公文管理类图6.2.4.用户界面设计
学校公共文档管理图6.2.3学院公共文档管理图6.2.4个人文档公共管理图6.2.5提示信息图6.2.6申请发布文档图6.2.7私人通讯图6.2.86.2.5.类的算法与程序逻辑6.3.本职管理6.3.1.功能说明
1.2.3.4.5.员工无本职业务模块。院长本职业务模块：审批院系公共文档，查看所有文档系主任本职业务模块：审批院系公共文档人事主管本职业务模块：添加人员，删除人员，人员调动部门领导本职业务模块：审批本部文档6.3.2.用户界面设计
1.添加人员页面图6.3.12.人员调动页面图6.3.23.删除人员页面图6.3.34.查看文档页面图6.3.4图6.3.55.审批文档页面图6.3.67.数据结构设计
7.1.数据库的说明
此系统采用ACCESS数据库，而且每张表的外键均采用对应的表的ID字段，此风格是为了当外键表信息改变时，该外键表自增编号绝对不会产生变化。由此使用此风格。7.2.数据库关系图
图7.17.3.逻辑结构设计
数据表逻辑的逻辑结构如下E-R图所述,下图只将实体与实体的联系表示出来了图7.27.4.物理结构设计
1、部门—表名（Department）
2、职责—表名（Role）
3、信息—表名（Message）
4、用户—表名（officeuser）
5、个人文档—表名（Persondocument）
6、公共文档—表名（Publicdocument）
8.接口说明
8.1.软件接口
运行于Windows95及更高版本具有WIN32API的操作系统之上。8.2.硬件接口
本软件不需要特定的硬件或硬件接口进行支撑。486以上PC机均可运行此软件。
8.3.故障处理
正常使用时不应出错，若运行时遇到不可恢复的系统错误，也必须保证数据库完好无损。调试中遇到的问题及解决的方案：
1)遇到跳出“数据库已经关闭“提示信息阻止程序运行时
可以查看一下进行此项操作时，操作的表是否已经被关闭了或者是在没有关闭此表的情况下又一次运用打开语句打开此表。2)关于空记录带来的麻烦
有些空记录往往会使程序无法运行。此时你可用“ifnotisnull”语句先判断一下是否为空记录，再操作。8.4.其他要求
1)系统的功能实现情况:用户可在本系统下实现各种用户要求的功能。2)系统的安全性:对于系统的重要数据都有密码保护，具有一定的安全性。3)系统的容错性:用户输错数据都有提示信息，具有较好的容错性能。
4)系统的封闭性:用户的封闭性较好，用户基本上在提示信息下输数据。
因篇幅问题不能全部显示，请点此查看更多更全内容