团队作业(二):需求分析
《需求规格说明书》
项目名:电子公文传输系统
版本:0.1
编订:20181213戴宜钢、20181219王辰、20181222刘卓、20181226姚渊升、20181227李根、20181228陈维、20181229罗福、20181233徐海岩
日期:2020年10月25日
一、引言
(一)目的
该文档首先给出电子公文传输系统的整体结构和功能结构概貌,试图从总体架构上给出整个系统的轮廓。同时对功能需求、性能需求进行了详细的描述。便于用户、开发人员进行理解和交流,反映出用户问题的结构,可以作为软件开发工作的基础和依据以及确认测试和验收的依据。
本文档面向多种读者对象:
(1)项目经理:项目经理可以根据该文档了解预期产品的功能,并据此进行系统设计、项目管理。
(2)设计员:对需求进行分析,并设计出系统,包括数据库的设计。
(3)程序员:了解系统功能,编写《用户手册》。
(4)测试员:根据本文档编写测试用例,并对软件产品进行功能性测试和非功能性测试。
(5)用户:了解预期产品的功能和性能,并与分析人员一起对整个需求进行讨论和协商。
在阅读本文档时,首先要了解产品的功能概貌,然后可以根据自身的需要对每一功能进行适当的了解。
(二)背景
本次待开发的软件为电子公文传输系统。
电子公文使用计算机制作并生成板式, 最终成为含有红头和公章的电子数字公文 板式(OFD)文件。发送方用户在完成电子公文的起草、制作成OFD文件后,在客户端验证身份并通过使用客户端软件完成加密和上传操作。接收方通过相同的客户端软件验证身份后,接收加密态的公文信息并通过集成在客户端的解密功能在收方解密。
(三)定义
| 序号 | 缩写 | 定义 |
|---|---|---|
| 1 | Web App | web application,网页应用程序的简称 |
| 2 | B/S结构 | B/S结构(Browser/Server,浏览器/服务器模式),是WEB兴起后的一种网络结构模式,WEB浏览器是客户端最主要的应用软件。 |
| 3 | C/S结构 | Client/Sever,即客户端/服务器。C/S架构软件(即客户机/服务器模式)分为客户机和服务器两层:第一层是在客户机系统上结合了表示与业务逻辑,第二层是通过网络结合了数据库服务器。简单的说就是第一层是用户表示层,第二层是数据库层。需要程序员自己写客户端。 |
二、项目概述
(一)产品描述
电子公文传输系统是利用计算机网络和安全技术,实现政府部门与部门之间、单位与单位之间政府红头文件的起草、制作、分发、接收等功能,以现代的电子公文传输模式取代传统的纸质公文传输模式。
(二)产品功能
为加快整体的办公效率,在不改变现有的工作流程的情况况下,使发送红头文件像发送普通电子邮件一样快捷,同时能保证红头和公章,符合现行所有公文和公章的管理制度,保证文件的安全性、有效性、规范性、严肃性,保证文件传输的高效性,操作的简便性,环境的适用性,系统的集成性。缩短公文传输的时限,有效地提高公文的安全性能。
(三)用户特点
本软件的最终用户为各政府部门相关工作人员。能快速适应该软件,并充分感受到在公文传输工作中的效能变化,提出合理改进意见。
维护人员为政府部门更具有专业知识的相关人员,能够阅读了解接口约定,深入用户交流,便于调整软件功能,实现客户需求。
(四)一般约束
进行本软件开发工作的约束条件如下:
1.开发周期短:几星期的开发时间需要开发者采用敏捷开发并合理规划时间,做到多项任务并发。
2.所采用的方法与技术有限:项目团队成员的技术水平不够成熟,需要在开发中并发学习多种技术和能力。
(五)假设与依据
本项目能否成功实施,主要取决于以下的条件:
1.团队成员积极合作配合,为了项目的开发和实施,对个人时间进行合理规划同时为团队做出合理牺牲,配合队友完成任务。
2.学院教师提供完整详细的功能和性能需求资料,以便于团队对其进行分析,从而形成完善的软件需求。
3.团队掌握先进的能够适用于该项目的技术,这是系统的性能是否优化和项目能否成功的保证。
三、功能需求
(一)系统角色及登陆
该系统共有两种角色:普通用户,管理员用户。所有角色都具有需要验证的登陆功能,且管理员用户登陆后的页面包含额外功能。
1、普通用户:
功能:公文发布和上报、公文签收、公文分类查询、政务信息发布、检索与统计
用户通过输入账号密码,点击登录,登陆后可以发布和管理自己所发的文件,签收。
2、管理员用户
功能:可对用户分配相应的权限、创建新用户、激活长时间未使用的用户、向所有用户发送公告、修改组织通讯录
(1)、创建新用户
出于系统安全性考虑,不提供公开的注册接口,只能由管理员用户创建
(3)、管理公告
管理员统一管理所有公告,可修改、删除公告材料。
(4)、数据库管理
本软件具有数据库压缩整理、备份和恢复功能。
数据备份、恢复和压缩。数据库要以定期压缩,以提高速度。恢复数据库时,注意当时备份的日期,否则一经恢复,备份日期后的数据将会丢失。
(5)、公文模板库
平台预先设置公文模板库,起草公文的时候可以直接从公文模板库中选择相关的模板,公文模板库分为公共库和用户库两大类,公共库由管理员用户维护,只有管理员有修改权限;所有用户都可创建并维护用户库,且可以选择公开供他人订阅收藏。
(二)外部接口需求
1、用户接口
本系统采用C/S架构,所有界面使用APP风格,用户界面的具体细在功能需求文档中描述。
2、硬件接口
无特殊需求。
3、软件接口
无特殊需求。
4、通信接口
需开放相应网络端口。
(三)性能需求
1、精度
登录界面要进行判断,防止缓冲区溢出攻击。
2、时间特性要求
硬实时系统,任务执行时间超过截止时间立即按照多级反馈队列调度算法调度下一个任务,其中反馈队列的优先级由公文的内容决定。
3、灵活性
为了防止管理员用户维护系统导致间歇性系统不可用,实现“给奔跑汽车换轮胎”,需要维护两套任务队列,一套是进行修改前的队列,其中的任务会按照修改前的系统配置文件顺序执行,发生维护事件后的任务会进入另一套队列。当修改前的任务执行完毕后,就彻底完成了修改操作。在一次修改操作彻底完成前,会禁止所有管理员用户再次修改系统设置。
三、属性
(一)可用性
1、方便操作,操作流程合理
尽量从用户角度出发,以方便使用本产品。如:输入信息时,敲入回车键光标的自动跳转、输入法的自动转换、删除操作时系统提示确认删除等。
2、容错能力
系统具有一定的容错和抗干扰能力,在非硬件故障或非通讯故障时,系统能够保证正常运行,并有足够的提示信息帮助用户有效正确地完成任务。
(二)安全性
(1)在客户端和服务器端都进行加密,采用适当的密码协议保证传输安全。
(2)在硬件故障或通讯故障时,要确保系统的保密性。
三、类图
总体结构构想
用UML类图的形式进行描述
四、界面原型
页面
登录
启动(登录成功)
五、功能描述
(一)、概述
公文草件(电子签名)、电子公文(RSA加密)、传输(RSA解密)、收文(电子签名验证)
(二)特色
- 高效传输:文件数据压缩
- 简便操作:用户界面简洁、易操作、功能齐全
- 环境实用性:适用于各种系统
- 系统集成性:公文复印件以图片形式输出
(三)实现技术
- 加密技术:数字签名、身份认证、RSA非对称加密
- 文件操作:文件压缩、自动重新编辑、格式转换打印
- 后端构建:服务框架构建、数据库开发、网络通信、数据传输
- 前端开发:基于Spring框架开发软件
(四)功能描述
- 发信人部门验证身份,向系统上传需传输的文件,文件保存进对应部门数据库,文件中不包含红头和部门公章。
- 文件发送前,使用部门私钥进行数字签名,并进行RSA加密,进入待传输列表。
- 文件通过TCP可靠传输,发送至接收方数据库,系统通过邮件通知接收方及时接受文件。
- 接收方首先使用接收部门私钥对文件进行解密,继而使用发文部门私钥对文件进行验签,确认发送方身份。
- 确认无误后,系统为公文添加红头和发文部门公章,并存储进接收部门数据库,可供后续查阅。
- 系统在部门验证口令身份确认无误后,可向部门提供公文的读、执行操作。
- 在各部门之外还存在“管理员”用户,“管理员”可以对各部门公文进行读、执行操作。
- 本系统限制所有用户对存储公文的复写操作。
六、验收验证标准
| 测试功能 | 测试项 | 操作 | 检验点 | 预期结果 | 验收 |
|---|---|---|---|---|---|
| 登录功能 | 登录 | 输入用户名和口令完成登陆 | 用户名、口令检验 | 用户名是否存在、口令是否正确 | |
| 用户功能 | 公文制作 | 从外部导入的公文草件 | 公文文件的首页的红头信息 | 给公文文件首页添加上红头信息 | |
| 公文发送 | 选择收文单位和公文文件 | 发文单位发送文件 | 根据收文单位的公钥对发文进行RSA加密,最后将电子公文文件发送给指定收文单位 | ||
| 公文接收 | 打开传输过来的公文 | 传输过来的公文信息和传输前的一模一样 | 公文没有发生信息改变或缺失 |

浙公网安备 33010602011771号