OA系统需求说明书初步83178.docx
《OA系统需求说明书初步83178.docx》由会员分享，可在线阅读，更多相关《OA系统需求说明书初步83178.docx（34页珍藏版）》请在冰豆网上搜索。
OA系统需求说明书初步83178
文件编号
GYRT-ZYZD-KF15-0306
分发号
版本号
1.00
受控状态
受控
项目编号:
WebOA系统
软件需求说明书
项目承担部门：
撰写人（签名）：
完成日期：
评审人（签名）：
评审日期：
批准人（签名）：
批准日期：
文档信息
标题：
软件需求说明书
作者：
创建日期：
2003-3-20
上次更新日期：
2003-4-18
版本：
讨论稿
部门名称：
过程改进与质量保证部
修订文档历史记录
日期
版本
说明
作者
1.引言
目的
定义软件总体要求，作为用户、软件开发人员以及其他干系人之间沟通的基础；
描述功能要求、性能要求、用户和系统的接口要求、数据库要等内容，作为软件开发人员进行软件结构设计和编码的基础；
Forpersonaluseonlyinstudyandresearch;notforcommercialuse
作为软件总体测试的依据。
定义
Forpersonaluseonlyinstudyandresearch;notforcommercialuse
甲方：
xxx有限公司。
乙方：
xxx有限公司。
招标书：
由甲方提供的《招投标技术规范书》。
投标书：
由乙方提供的《技术方案书》。
参考资料
《招标书》
《投标书》
《项目管理制度》
xxxx质量管理体系文件
Iso9001：
2000
《软件工程国家标准汇编》
2.软件总体概述
软件标识
项目名称
项目名称：
尚学堂WebOA管理系统；
项目编号：
SXT-WEBOA-0101；
产品范围：
按照《招标书》中5.2的规定执行。
产品标识
产品名称：
产品简称：
版本号：
1.00
软件描述
系统属性
WebOA系统是xxx信息系统的子系统之一，项目完成后，WebOA子系统将和其它系统一起服务于xxx管理过程，这样就要求本系统在设计风格、开发工具、数据库等方面要与其他系统协调一致。
开发背景
随着网络的高速发展，网络OA系统逐渐受到关注。
一些大型企业集团（例如联想、海尔）正致力实现高层次的网络办公自动化，这将为他们节省大量的人力资源，节省大量的办公费用，大幅度提高办公效率。
开发网络办公系统的市场前景是广阔的。
大型企业需要高层次的网络办公自动化，他们往往会选择大型的软件公司合作开发，所需的开发费用和维护费用也是非常高昂的。
这些高昂的费用并非大多数中小企业能承受得起的。
中小型企业存在一个很大的低成本网络OA系统的需求，而我们公司可以开发这些低成本OA系统来满足这个需求。
尚学堂OA系统要实现：
a、企业内各种信息资源的共享
b、加强员工间的交流、提高整体工作效率
c、为领导各种有用数据，方便领导对公司情况的及时了解、提供决策支持
d、提供各种工作记录，以备事后查询
系统功能
个人办公
我的办公桌
高
打开个人办公桌，在个人办公桌上，是到达各种管理功能的快捷链接
我的便签
低
随手记录的信息
我的任务
低
任务管理
通信录
低
个人通信录
公文管理
公文维护
高
各种类型的公文管理、审批公文等
归档处理
高
对已完成流转的公文进行归档
公共信息
信息管理
中
进行新闻、通知、期刊、知识和规章制度的发布和管理，使企业的信息和知识快速传播和转移。
行政办公
会议管理
中
管理会议室的占用情况
资产管理
低
管理企业的资产信息
用品管理
低
管理企业用品的申请
车辆管理
低
企业车辆的管理
图书管理
低
图书的借出管理
消息管理
收件箱
中
接收的所有消息
发件箱
中
发送的所有消息
垃圾箱
中
已删除的消息
聊天记录
中
跟某个用户的聊天记录
工作流程
流程管理
高
如何定义企业的流程（可以灵活定义各种流程）
表单定义
高
如何针对不同的流程定义表单
组织管理
机构管理
高
公司组织架构管理
人员管理
高
公司人员管理
权限管理
模块管理
高
系统所有模块的管理
角色管理
高
系统的角色定义、给角色分配权限等
用户管理
高
系统帐号的分配、给用户分配角色、给用户分配权限等
系统管理
密码修改
低
代码定义
低
系统初始化
低
人事档案
人员履历
低
转正申请
低
离职申请
低
员工考勤
低
3.具体需求
系统角色设置
系统共有下列固有角色：
系统管理员、普通员工、部门领导、档案管理员，系统任何用户均应具有普通员工的权限
系统初始化数据
系统初始化如下数据：
组织机构：
总公司
总裁办
行政部
财务部
北京分公司
办公室
造价咨询部
财务部
招标代理部
软件开发部
OA项目组
CRM项目组
烟草行业项目组
市场部
技术服务部
上海分公司
研发中心
销售部
广州分公司
产品研发中心
人员与用户：
赵一zy，系统管理员，北京分公司技术服务部
钱二qe，烟草行业项目组经理
孙三ss，烟草行业项目组成员
李四ls，烟草行业项目组成员
周五ww，烟草行业项目组成员
吴六wl，烟草行业项目组成员
郑七zq，烟草行业项目组成员
王八wb，北京分公司办公室档案管理员
冯九fj，北京分公司软件开发部经理
陈十cs，北京分公司总经理
诸一一zyy，北京分公司办公室主任
卫一二wye，北京分公司财务部经理
蒋一三jys，北京分公司技术总监
沈一四sys，上海分公司总经理
韩一五hyw，广州分公司总经理
杨一六yyl，总公司财务部经理
角色：
请参考系统角色设置
模块：
请参考系统模块设置
功能需求
登陆界面
管理主界面
系统管理员登陆可看到以下界面，其它人员登陆系统，可看到的模块，请参考模块设置！
组织机构
组织机构管理主要包括机构管理和人员管理。
机构是一个树型结构，可以完成添加、删除操作。
主界面要求：
界面操作：
点击机构管理进入机构管理主界面，在主界面上列出顶级机构，点击某个机构的名称，可以查看这个结构的详细信息以及所有子机构列表（在子机构列表上，还可以点击机构名称进行进一步的导航）。
在列表界面上，可以点击“返回”以便返回上一级机构。
机构信息的浏览：
如，点击“北京分公司”，将可以列出此公司下面的所有部门：
机构信息的添加：
点击添加机构信息按钮，可以打开添加界面，在哪个机构层级上点击添加，就应该在本层级上添加机构！
如在进入“北京分公司”之后的页面上点击添加机构信息：
则添加成功之后
其信息被添加到本页面下面：
机构信息的删除：
点击确定之后，才能删除对应的记录，同时刷新一下本界面。
机构的信息主要包括：
名称
类型
描述
机构名称
机构编号
字符串
机构的编号是唯一的；机构的编号是自动生成的，编号的规则是：
本机构的编号＝XX（父机构的编号）_XX（本机构的序号）
机构描述
人员管理：
包括添加、删除人员的信息
人员管理主界面：
人员管理的添加：
点击选择，可以打开新的界面选择所添加人员所属的机构
点击单选框，变返回人员录入界面，继续录入人员的信息：
人员管理的删除：
在删除之前，跟机构管理一样，需要确认一下再删除，而且删除之后，需要刷新一下主界面。
人员的信息主要包括：
名称
类型
描述
姓名
性别
所属部门
职务
地址
电话
备注
【附加：
机构管理的第二界面，演示dojo树的使用】
权限管理
1、用户（User）可以拥有多个角色（Role），角色可以被分配给多个用户
2、权限的意思就是对某个资源的某个操作，现在规定：
a）所谓资源，即系统的模块
b）所谓操作，包括：
增加、删除、修改、查询等操作
3、权限管理系统的总体功能分为：
授权与认证
4、授权，指将权限授予角色或用户
a）如果用户A拥有角色B、角色C，那么，缺省的情况下，用户A将拥有被分配给角色B和角色C的所有权限（即默认情况下，用户A继承其拥有的角色所具有的所有权限）
b）如果用户拥有多个角色，那么用户的权限是这些角色权限的合集
c）如果用户拥有多个角色，而且角色之间的授权有冲突（比如对同一个资源的同一个操作，一个角色为“允许”，另外一个角色为“不允许”），将以优先级别高的角色为准（所谓优先级别，也就是对于这个用户所拥有的角色而言，是有顺序的，同一个角色在不同的用户那里可能拥有不同的优先级）
d）除了可以对角色进行授权外，也可以针对用户进行授权，也就是说，将权限授予用户。
针对某个资源的所有操作，我们可以设置这些权限对用户来说是“继承”或“不继承”
i.继承：
意思是这些权限将使用其（即用户）所拥有的角色的权限，而不使用其（即用户）单独设置的权限
ii.不继承：
意思是这些权限将使用其单独设置的权限，而不使用其所拥有的角色的权限
5、认证，指用户访问资源的某些操作时，根据授权，判断是否允许用户的访问
a）在用户访问的时候，需要进行即时的判断（是否有权访问）
b）应该提供查询的功能，可以查询某个用户所拥有的所有权限
总体上，可分为模块管理、角色管理和用户管理模块：
模块管理：
模块管理主界面参考：
因为模块是一个树状结构（本系统只支持两级模块的结构），我们可以点击其中一个模块以便打开其子模块来维护，比如点击“信件交流”：
可以在这个界面上添加模块信息以及删除模块信息
角色管理：
可以添加角色信息、删除角色信息以及给角色授权
给角色授权，选中其中一个角色，可以打开角色授权界面：
在这个界面上，按照两级模块的形式列出系统所有模块，以及在这些模块上面的CRUD（添加、读取、更新、删除）权限；所谓“启用”，意思是本设置有效，否则设置无效！
当点击选中其中某个模块的某个权限时，系统自动添加此权限！
【选中就开始生效，无需点击提交按钮】
用户管理：
因为用户实际上就是系统人员的帐号，而且每个人只能拥有一个帐号，所以用户管理主界面，实际上就是系统所有人员的列表！
【分配帐号】-给人员分配帐号，如果已经有帐号，则提示无法继续分配帐号，如果想修改帐号的话，需要先删除帐号，再重新分配
【删除帐号】-提示是否删除，如果确定，再发出删除请求，在删除成功之后，刷新界面。
【分配角色】-给用户分配角色，一个用户可以拥有多个角色，点击“分配角色”：
在分配角色的界面上，点击“给用户分配角色”，可以选择需要分配的角色，同时可以输入其优先级：
点击“分配角色”按钮，提交数据，这时候，所选择的角色，就会被赋予相应的用户：
如果想要修改某个角色的优先级，可以选择重新分配一次这个角色，同时给它指定另外一个优先级即可：
注意：
用户所拥有的角色列表，是按照优先级大小倒序排列的，即优先级最高的排前面。
【用户授权】-给用户单独授权
在主界面上点击“用户授权”，打开的授权界面跟角色授权类似：
但是，用户授权多了一个“不继承”选择框，只有在选择了这个框的前提下，给用户的单独授权设置才是有效的，否则它将使用其拥有的角色的权限！
公文管理
总共可分为公文管理以及公文归档
文档流转事实上是对工作流以及工作流中的文档进行管理，对于大多数企业来说，核心的管理就是工作流和文档的管理。
一般的企业都会有很多流程，比如：
请假流程
报销流程
收文/发文流程
收文：
处理收到上级部门及其它部门的公文
发文：
上级及有关部门需协调和解决的问题进行的一系列流程
流程的本质，就是很多人在一起完成一件事情
流程可能会经过不同的中间环节，在中间环节上，由相关人员进行处理
所有流程中间环节的处理过程，需要进行记录
【公文管理】可分为公文维护与公文归档处理：
在其主界面上，显示由当前登陆人员创建的所有公文。
可以在我的公文、待审核公文、已审核公文之间切换：
公文的添加：
点击其中一个公文形式（流程），打开此流程的公文添加界面：
重要的一点是，可以选择流程！
这些流程都是通过设计器或编写流程文件的方法创建的。
添加完成后，公文管理主界面是：
公文的删除：
用户可以对公文执行删除操作
公文的流转：
可以点击提交操作，将公文提交流程
用户只能对属于自己的公文（自己创建的公文）进行操作
在公文进入流程之后，不再允许用户对公文执行修改和删除操作
在公文流转结束以后，用户可以对公文设置成"归档"状态
用户登录系统之后，可以看到自己的待审批公文列表
在我的公文视图里，可以将这些公文进行提交，即提交到流程。
打开提交界面：
选择下一个步骤进行提交操作，提交完成后，在公文主界面上，不能再次对公文执行提交和删除等操作：
如果此时在流程中下一个节点的用户登陆，便可以在“带审批文档”视图中看到流到此人的文档。
下面是一个待审核公文列表：
执行审批操作：
点击保存审核信息之后，可以执行提交操作。
当然，也可以再次点击审核操作，这时候，需要打开界面，更改审核意见！
提交之后，根据相应的选择，公文将流到相应的人员那里，依次下去，直到流程的结束！
这就是公文管理主要过程！
在公文管理主界面上，可以点击“下载”，下载附件文档，以便查看详细内容；或者点击“查看审批历史”，可以查看相关文档的审批记录。
一旦文档经过审批并提交之后，在“待审批文档”列表视图中就会消失，但是在“已审批文档”中，却需要能够找到这些已被审批过的文档记录！
工作流程
【流程管理】
可以自定义流程（通过流程设计器）
流程可以随时作出修改
流程示例
发文流程
发文流程主要是上级及有关部门需协调和解决的问题进行的一系列流程，本流程对发文的全过程进行有效控制和跟踪，实现完善的发文流程。
发文流程主要包括：
公文生成：
选择按公文的类型预先设计好的公文标准格式模板，在向导的指导下轻松地进行公文的撰写。
审核：
生成的文稿经计算机网络送审核负责人进行审核，审核负责人在审核意见栏中签署审核意见后，初稿传回撰稿人处修改。
内、外部会签：
对于需要有关部门会签的公文，由公文管理人员按照会签要求，将公文发往有关部门签署意见。
签发：
审核通过和会签完毕的公文发往签发负责人，由签发负责人在签署意见栏中签署意见，并签名，同时确定或修改转送单位，签发完成或，返回公文管理部门。
处理：
由公文管理部门对签发完毕的公文进行处理，包括编号、分发、登记、存档、打印等功能。
查询：
可以按照多个条件进行查询。
发文流程可以根据企业需要随时调整流程，流程结束后由文件及相关信息直接归档。
归档后的文件，可以按机密等级分权限进行查询，查询权限可以由用户指定。
收文流程
收文流程主要是处理收到上级部门及其它部门的公文，对收文进行登记和维护，并提供查询,同时对收文的全过程进行有效控制和跟踪，实现完善的收文流程等。
收文流程主要包括：
收文登记：
电子文件直接存入数据库，直至文本文件向通过键盘或扫描仪输入原文后，经计算机识别系统将其转换为文本文件，再存入收文库。
内部转发：
将公文信息通过网络系统传送到相关的部门，根据文件的性质、保密程度与权限的不同，采用相应的加密处理，对文件的办理、传阅、查询等，应按不同的级别和部门给以限定。
拟办：
将待拟办的公文通过网络发送给拟办负责人，由拟办负责人直接在计算机上签署处理意见或选择拟办模板，拟办完成后，公文自动转去批办。
批办：
将待批办的公文通过网络发送给有关批办负责人，由批办负责人直接在计算机上签署处置意见或选择批办模板，批办完成后，公文自动返回公文管理部门。
注办：
当公文处理完毕后，由承办单位或个人在计算机终端“收文处理单”的“处理结果”栏中填写公文的办理结果。
返回公文管理部门，由公文管理部门注办并作归档等处理。
查询：
相关人员可以对收到的公文及其信息进行查询。
出差流程
出差流程是实现出差前的申请和审批、出差后的总结、审批和费用的报销等，同时对出差的全过程进行有效控制和跟踪，实现完善的出差流程等。
出差流程主要包括：
出差申请：
由出差申请人填写出差任务单，发送审批人进行审批。
出差审批：
审批人进行出差任务单的审批，审批完成后发送出差申请人。
出差返回：
出差申请人出差返回，填写出差情况汇报及差旅费，抱审批人进行审批。
出差汇报：
审批人进行出差情况汇报及差旅费的审批后，发送财务部进行审查及报销。
财务：
财务进行差旅费的审查及报销，最后系统自动存档。
查询：
公司领导及个人可对出差的情况进行查询。
流程管理的主界面如下所示：
在主界面上，应列出系统的所有流程，而且针对每个特定的流程，可以重新进行上传和发布。
点击流程名称，应能获得关于此流程的详细信息，如下所示：
【查看流程图片】
【查看流程定义】
表单定义
可以实现表单模板的动态定义，即针对不同的流程，可以定义对应的表单。
性能需求
本节说明软件数据处理能力和时间特性的需求。
数据处理能力可能包括：
支持的终端数、支持并行操作的用户数、处理的文件和记录数、表和文件的大小。
时间特性可能包括：
响应时间、更新处理时间、数据的转换和传送时间、运行时间等。
数据库需求
本节说明对软件应用的数据库的需求，如：
数据项、记录、文件标识、静态和动态的组织、存取能力等。
设计约束
其他标准的约束
本节描述由现有的标准或规则派生的要求，如：
a.报表格式；
b.数据命名；
c.会计准则；
d.审计追踪，等等。
硬件约束
本节包括各种软件运行的硬件约束，如：
a硬件配置的特点；
b内存储器和辅助存储器的容量。
属性
本节定义用户对软件的其他属性的要求，可能的内容如下所列。
如果软件需求说明书包括了下列属性，但在软件需求说明书的其他章节进行说明，须在相应小节指明。
可用性
定义某些需求（如：
检查点、恢复方法和重启动性等），以保证软件的可用性。
可靠性
定义软件在规定的时间内和规定的条件下，满足规定功能的能力。
效率
定义软件在规定的条件下，功能和性能水平与所使用资源量（如软件产品、硬件设施、耗材、操作人员、维护人员）之间的关系。
安全性
说明如何保护软件，以防止偶然或恶意的访问、使用、修改或泄密。
可维护性
规定需求以保证软件是可维护的。
可移植性
说明软件对软、硬件环境的兼容，它从一个环境移植到另一个环境的约束等。
...
外部接口需求
用户接口
本节说明为方便用户使用而提出的软件与用户界面的需求。
如:
屏幕格式、报表格式、菜单格式、输入输出时间、功能键的使用。
硬件接口
本节说明软件与硬件间各接口，可使用接口框图进行说明。
说明内容包括：
a）接口标识；
b）功能描述；
c）信号方向、格式、传输协议；
d）优先级；
e）响应时间；
f）异常处理。
对每一硬件，需提供名称、缩写、型号、数量，并说明其功能。
软件接口
本节指定需使用的其他软件产品（如：
数据管理系统、操作系统、数学软件包），以及同其他应用系统之间的接口。
如果已有完整的接口文件，需在本节指明。
说明内容包括：
a）接口标识；
b）功能描述；
c）数据流程和控制流程的方向；
d）数据格式、容量；
e）接口类型（如手动或自动）；
f）接口数据中断的优先级别；
g）中断响应时间；
h）异常处理等。
对每一个所需的软件产品，需提供名称、缩写、规格说明、版本号、来源等内容。
通信接口
本节指定各种通信接口，如局域网的协议等。
4.数据字典
以如下方式列出数据字典：
存折=户名+所号+帐号+开户日+性质+（印密）+1{存取行}50
户名=2{字母}24
所号=“001”..“”
如果数据字典在设计阶段完成或进一步完善，在此节说明。
5.附录
用户方组织机构图；
附录中还可能包括的内容有：
a原有系统的组织机构图、业务流程图、信息流程图；
b输入、输出格式样本；
c交叉索引等；
d《软件需求说明书》确认协议。
《软件需求说明书》确认协议
甲方：
XX
乙方：
XX
在甲方的大力配合与支持下，乙方制作了该《软件需求说明书》；甲方对该《软件需求说明书》经过详细审核，已确认该《软件需求说明书》中的各项内容翔实全面，该《软件需求说明书》中的内容已完全包括了《项目开发委托合同》中的《用户需求说明书》部分中关于软件产品的需求。
经过甲乙双方友好协商，达成如下协议：
1．该《软件需求说明书》是《项目开发委托合同》的补充文件，与《项目开发委托合同》具有同等的法律效力；
2．该《软件需求说明书》是《项目开发委托合同》中_____条__________款软件产品最终验收的唯一标准；
3．甲方在《项目开发委托合同》中_____条__________款软件产品最终验收前可提出对该《软件需求说明书》中的内容进行变更（包括增加、修改、删除），双方应就此签署《软件产品需求更改备忘录》或补充协议；
4．甲方同意乙方根据该《软件需求说明书》进行《项目开发委托合同》中_____条__________款软件产品的开发；
5．本协议一式二份，甲乙双方各执一份；
6．本协议自甲乙双方签字之日起生效。
甲方委托人（签字）：
乙方委托人（签字）：
甲方单位（盖章）：
乙方单位（盖章）：
年月日年月日
注：
此页为范文，可修改
仅供个人用于学习、研究；不得用于商业用途。
Forpersonaluseonlyinstudyandresearch;notforcommercialuse.
NurfürdenpersönlichenfürStudien,Forschung,zukommerziellenZweckenverwendetwerden.
Pourl'étudeetlarechercheuniquementàdesfinspersonnelles;pasàdesfinscommerciales.
толькодлял
升级会员 