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