diff --git a/doc/media/media/image1.png b/doc/media/media/image1.png new file mode 100644 index 00000000..210c547d Binary files /dev/null and b/doc/media/media/image1.png differ diff --git a/doc/media/media/image2.png b/doc/media/media/image2.png new file mode 100644 index 00000000..9f089358 Binary files /dev/null and b/doc/media/media/image2.png differ diff --git a/doc/media/media/image3.png b/doc/media/media/image3.png new file mode 100644 index 00000000..e3f75b0e Binary files /dev/null and b/doc/media/media/image3.png differ diff --git a/doc/media/media/image4.png b/doc/media/media/image4.png new file mode 100644 index 00000000..ae7c7c9b Binary files /dev/null and b/doc/media/media/image4.png differ diff --git a/doc/media/media/image5.png b/doc/media/media/image5.png new file mode 100644 index 00000000..ecce140a Binary files /dev/null and b/doc/media/media/image5.png differ diff --git a/doc/media/media/image6.png b/doc/media/media/image6.png new file mode 100644 index 00000000..c66449ab Binary files /dev/null and b/doc/media/media/image6.png differ diff --git a/doc/media/media/image7.png b/doc/media/media/image7.png new file mode 100644 index 00000000..6a50f434 Binary files /dev/null and b/doc/media/media/image7.png differ diff --git a/doc/media/media/image8.png b/doc/media/media/image8.png new file mode 100644 index 00000000..5d5b7694 Binary files /dev/null and b/doc/media/media/image8.png differ diff --git a/doc/media/media/image9.png b/doc/media/media/image9.png new file mode 100644 index 00000000..27961932 Binary files /dev/null and b/doc/media/media/image9.png differ diff --git a/doc/保密室管理系统软件需求构思及描述.docx b/doc/保密室管理系统软件需求构思及描述.docx new file mode 100644 index 00000000..ad9756c3 Binary files /dev/null and b/doc/保密室管理系统软件需求构思及描述.docx differ diff --git a/doc/保密室管理系统软件需求构思及描述.md b/doc/保密室管理系统软件需求构思及描述.md new file mode 100644 index 00000000..015d1f70 --- /dev/null +++ b/doc/保密室管理系统软件需求构思及描述.md @@ -0,0 +1,120 @@ +“保密室管理系统”软件系统的需求构思及描述 +======================================== + +背景介绍 +-------- + +保密工作历来是军队建设与发展中的生命线，事关国家安全与军事斗争全局。泄密必究，卖密严惩，已成为全军上下不可逾越的铁律。在各项保密任务中，保密室管理处于核心地位，尤其涉及涉密载体的全程管理——包括载体的建档入库、申请使用、审批跟踪与销毁处置等关键环节，直接关系到保密体系的安全与可靠。 + +随着军队信息化建设的深入推进，传统依赖纸质登记、人工审批的管理模式已日益凸显其局限性：效率低下、易出现疏漏，难以实现实时监控与动态管理，不仅影响办公效率，更可能导致涉密载体管理失控、丢失甚至外泄，造成难以挽回的损失。面对日益严峻的安全威胁和技术挑战，提升保密室管理的规范化、安全性与工作效率，已成为当前军队保密能力建设的紧迫任务。 + +为此，开发并应用一套数字化、流程化的保密室管理系统势在必行。该系统将实现涉密载体全生命周期信息化管理，既确保载体存放有序、监控无死角，也大幅简化审批流程，提高办事效率，节约人力与时间成本。它的建成与应用，将极大增强我军保密工作的系统性、安全性和管控力，为打赢信息化条件下保密斗争提供坚实技术支撑。 + +欲解决问题 +---------- + +- 涉密载体入库、取出、归还流程繁琐，依赖人工操作； + +- 审批流程繁琐、不透明，效率低下且难以追踪； + +- 载体状态更新不及时，易造成管理漏洞、失泄密问题； + +- 逾期归还未及时提醒，存在泄密风险； + +- 值班人员、审批领导信息不透明，沟通效率低； + +- 公告发布、制度传达依赖线下方式，效率低下。 + +软件创意 +-------- + +本系统通过构建一个集用户管理、载体管理、审批流程、公告发布、值班排班于一体的数字化平台，实现涉密载体全生命周期管理。结合身份认证、流程引擎、消息提醒等技术，确保操作可追溯、流程可监控、信息可共享，提升保密工作的规范化与智能化水平。 + +系统的组成和部署 +---------------- + +- **前端**：Web端界面，支持多角色登录（用户、保密室工作人员、审批领导）； + +- **后端**：基于微服务架构的业务逻辑处理、权限控制、流程引擎、消息推送等服务； + +- **数据库**：用于存储用户信息、载体信息、审批记录、公告、排班等数据； + +- **消息服务**：用于发送审批提醒、归还提醒等通知； + +- **硬件依赖**：服务器、网络设备、保密柜。 + +软件系统的功能描述 +------------------ + +**5.1用户功能：** + +- 注册与登录； + +- 涉密载体入库登记（名称、型号、序列号、状态、责任人、存放地点、密级）； + +- 查看个人载体存储记录； + +- 申请使用涉密载体（填写申请单，包括载体信息、时间、签字等）； + +- 查看审批进度； + +- 归还载体或申请延期； + +- 查看值班人员及审批领导信息（含联系方式）； + +- 查看公告； + +- 查看操作日志。 + +**5.2保密室工作人员功能：** + +- 管理用户信息； + +- 查看所有载体信息； + +- 处理审批通过的申请，取出载体并更新状态； + +- 发布公告； + +- 查看待归还载体并发送提醒； + +- 提交销毁申请； + +- 查看个人值班时间。 + +**5.3审批领导功能：** + +- 查看所有载体信息； + +- 审批使用申请和销毁申请； + +- 管理工作人员信息； + +- 进行值班排班（工作人员与审批领导）； + +- 查看公告； + +- 查看审批记录。 + +可行性及潜在风险 +---------------- + +**6.1可行性分析：** + +- **技术可行性**：基于成熟的Web开发技术（如Spring Boot、Vue.js、MySQL等），技术栈稳定，开发难度可控； + +- **资源可行性**：所需硬件资源为常规服务器与网络设备，投入适中； + +- **时间可行性**：项目模块清晰，可分阶段开发，预计2个月内可完成初版并上线试运行； + +- **规模可行性**：系统支持多角色、多流程，适合中小型单位使用，具备可扩展性。 + +**6.2潜在风险：** + +- **数据安全风险**：涉密数据需加密存储与传输，需加强权限控制与审计日志； + +- **系统稳定性**：高并发审批场景下需保证系统响应速度与可靠性； + +- **用户接受度**：需提供培训与技术支持，推动用户从线下转为线上操作； + +- **流程合规性**：需与单位现有保密制度对接，确保流程符合规范。 diff --git a/doc/保密室管理系统软件需求规格说明书.docx b/doc/保密室管理系统软件需求规格说明书.docx new file mode 100644 index 00000000..c511a85a Binary files /dev/null and b/doc/保密室管理系统软件需求规格说明书.docx differ diff --git a/doc/保密室管理系统软件需求规格说明书.md b/doc/保密室管理系统软件需求规格说明书.md new file mode 100644 index 00000000..1126a8aa --- /dev/null +++ b/doc/保密室管理系统软件需求规格说明书.md @@ -0,0 +1,369 @@ +**文档编号：*保密室管理系统* – SRS – *<1.0>*** + +***保密室管理系统*** + +**软件需求规格说明书** + +**日期：2025.09.10** + + +**文档变更历史记录** + +| 序号 | 变更日期 | 变更人员 | 变更内容详情描述 | 变更后的版本号 | +|------|-----------|----------|------------------------|----------------| +| 1 | 2025/9/10 | 王鑫 | 软件需求规格说明书初稿 | 1 | +| | | | | | +| | | | | | +| | | | | | +| | | | | | +| | | | | | +| | | | | | +| | | | | | +| | | | | | +| | | | | | +| | | | | | +| | | | | | +| | | | | | +| | | | | | +| | | | | | +| | | | | | +| | | | | | +| | | | | | +| | | | | | +| | | | | | +| | | | | | +| | | | | | +| | | | | | +| | | | | | + +**目录** + +[1. 引言 4](#_Toc485198808) + +[1.1 编写目的 4](#编写目的) + +[1.2 读者对象 4](#读者对象) + +[1.3 软件项目概述 4](#软件项目概述) + +[1.4 文档概述 5](#文档概述) + +[1.5 定义 5](#定义) + +[1.6 参考资料 5](#参考资料) + +[2. 软件的一般性描述 6](#_Toc208427296) + +[2.1软件产品与其环境之间的关系 6](#软件产品与其环境之间的关系) + +[2.2限制与约束 6](#限制与约束) + +[2.3假设与前提条件 6](#假设与前提条件) + +[3. 软件功能需求描述 7](#软件功能需求描述) + +[3.1 软件功能概述 7](#软件功能概述) + +[3.2 软件需求的用例模型 8](#软件需求的用例模型) + +[3.3 软件需求的分析模型 8](#软件需求的分析模型) + +[4. 其它软件需求描述 9](#其它软件需求描述) + +[4.1 性能要求 9](#性能要求) + +[4.2 设计约束 9](#设计约束) + +[4.3 界面要求 9](#界面要求) + +[4.4 进度要求 10](#进度要求) + +[4.5 交付要求 10](#交付要求) + +[4.6 验收要求 10](#验收要求) + +**1. 引言** + +### 1.1 编写目的 + +1)本文档的目的在于方便用户、分析人员和软件设计人员进行理解和交流。用户通过需求规格说明书在分析阶段即可初步判定目标软件能否满足其原来的期望，但是本文档主要是作为设计人员的软件开发的基本出发点和系统维护人员发现和添加新功能需求的基础，也是维护人员的技术支持文档之一。 + +2)本文档支持目标系统的确认。软件开发目标是否完成不应由系统测试阶段的人为因素决定，而应根据需求规格说明书中确立的可测试标准决定。 + +3)本文档控制系统进化过程。在需求分析完成后，如果用户追加需求，那么需求规格说明书将用于确定追加需求是否为新需求。如果是，开发人员必须针对新需求进行需求分析，扩充需求规格说明书，进行软件再设计。 + +### 1.2 读者对象 + +用户，软件设计人员，软件测试人员，项目管理人员。 + +### 1.3 软件项目概述 + +- 项目名称: 保密室管理系统 + +- 用户单位: 军队保密室 + +- 开发单位: 国防科大计算机学院22级软件工程张靖波小组 + +- 软件项目的背景和大致功能： + +保密工作历来是军队建设与发展中的生命线，事关国家安全与军事斗争全局。泄密必究，卖密严惩，已成为全军上下不可逾越的铁律。在各项保密任务中，保密室管理处于核心地位，尤其涉及涉密载体的全程管理——包括载体的建档入库、申请使用、审批跟踪与销毁处置等关键环节，直接关系到保密体系的安全与可靠。 + +随着军队信息化建设的深入推进，传统依赖纸质登记、人工审批的管理模式已日益凸显其局限性：效率低下、易出现疏漏，难以实现实时监控与动态管理，不仅影响办公效率，更可能导致涉密载体管理失控、丢失甚至外泄，造成难以挽回的损失。面对日益严峻的安全威胁和技术挑战，提升保密室管理的规范化、安全性与工作效率，已成为当前军队保密能力建设的紧迫任务。 + +为此，开发并应用一套数字化、流程化的保密室管理系统势在必行。该系统将实现涉密载体全生命周期信息化管理，既确保载体存放有序、监控无死角，也大幅简化审批流程，提高办事效率，节约人力与时间成本。它的建成与应用，将极大增强我军保密工作的系统性、安全性和管控力，为打赢信息化条件下保密斗争提供坚实技术支撑。 + +### 1.4 文档概述 + +1）软件的一般性描述部分。它包括软件产品与其环境的关系、软件受到的限制和约束以及软件开发前的假设与前提条件。 + +2）功能需求描述部分。它主要分为系统的划分，软件各子系统的功能，设计约束和性能、界面、交付、验收四个方面的要求。 + +3）其它软件需求描述部分。它包括性能要求、设计约束、界面要求、进度要求、交付要求和验收要求。 + +### 1.5 定义 + +***无*** + +### 1.6 参考资料 + +\[1\].软件工程.齐治昌，谭庆平，宁洪.北京:高等教育出版社，2012 + +\[2\].需求分析与设计.马素霞译.北京:机械工业出版社，2009 + +\[3\].面向使用的软件设计.刘正捷译.北京:机械工业出版社，2011 + +**2. 软件的一般性描述** + +### 2.1软件产品与其环境之间的关系 + +1）用户：系统的最终使用者，包括普通用户、保密室工作人员和审批领导。他们通过浏览器（如Chrome, Firefox）访问系统，进行业务操作。 + +2）硬件系统： + +服务器：系统部署在单位内部的物理服务器或虚拟机上，用于运行后端服务和数据库。 + +客户端PC：用户通过单位内网的计算机访问系统。 + +3）其他软件系统： + +数据库管理系统（DBMS）：如MySQL，用于持久化存储所有业务数据。 + +操作系统：服务运行Windows Server；客户端可运行Windows操作系统。 + +### 2.2限制与约束 + +1）网络约束：系统必须部署在单位内部网络（内网）中，与互联网物理隔离，确保数据安全。 + +2）浏览器约束：客户端需使用主流现代浏览器，不支持旧版IE浏览器。 + +3）安全约束：所有用户密码必须加密存储；数据传输需使用HTTPS（或内部加密协议）；操作日志必须完整记录，不可篡改。 + +4）性能约束：在100个并发用户的情况下，关键页面（如列表查询、提交申请）的响应时间应低于3秒。 + +5）合规性约束：系统流程设计必须符合国家及单位内部保密管理规定。 + +### 2.3假设与前提条件 + +1）用户假设：所有用户都经过单位审核和保密培训，会正确使用系统。 + +2）环境假设：单位内部网络环境稳定，服务器硬件资源充足。 + +3）数据假设：系统初始化时，需由管理员导入或创建初始的用户账户、审批领导账户和保密室工作人员账户。 + +4）管理假设：设有专职的系统管理员负责系统的日常维护、备份和用户基础管理。 + +**3. 软件功能需求描述** +======================= + +### 3.1 软件功能概述 + +表1.保密室管理系统功能概述表 + +| 标识 | 功能名称 | 功能描述 | +|-------|----------------------|--------------------------------------------------------------------| +| FU-01 | 管理用户 | 保密室工作人员可对用户账户进行增删改查、重置密码等操作。 | +| FU-02 | 登记入库涉密载体 | 用户登记新的涉密载体信息，包括名称、型号、序列号、密级等。 | +| FU-03 | 查询用户涉密载体 | 用户可查看自己存放的载体； | +| FU-04 | 申请使用涉密载体 | 用户提交使用申请，审批领导在线审批，结果通知用户和工作人员。 | +| FU-05 | 归还涉密载体 | 用户归还已取出的涉密载体。 | +| FU-06 | 提醒逾期涉密载体归还 | 系统自动监控归还时间，对逾期未归还的载体向用户和工作人员发送提醒。 | +| FU-07 | 申请延期使用涉密载体 | 用户在归期前可提交延期申请，由审批领导审批。 | +| FU-08 | 申请销毁涉密载体 | 工作人员提交载体销毁申请，由审批领导在线审批。 | +| FU-09 | 管理公告 | 工作人员可发布、编辑、删除公告；用户可查看公告。 | +| FU-10 | 管理值班排班 | 审批领导可对工作人员和审批领导自身进行值班排班。 | +| FU-11 | 查看公告 | 用户可以在保密系统查看发布的公告。 | +| FU-12 | 查看所有涉密载体 | 工作人员和领导可查看所有涉密载体。 | +| FU-13 | 审批涉密载体使用申请 | 领导审批用户提交的申请使用载体需求。 | +| FU-14 | 审批涉密载体销毁申请 | 领导审批保密室工作人员提交的销毁涉密载体需求。 | +| FU-15 | 审批涉密载体延期申请 | 领导审批用户提交的延期使用涉密载体申请。 | + +### 3.2 软件需求的用例模型 + + + +图1.保密室管理系统用例图 + +### 3.3 软件需求的分析模型 + +**3.3.1管理用户** + + + +图2.保密室管理系统-“管理用户”顺序图 + +
用例名管理用户
用例描述保密室工作人员可对用户账户进行增删改查、重置密码等操作。
参与者保密室工作人员
过程

  1. 保密室工作人员进入保密系统

  2. 进入管理用户界面

  3. 对用户信息进行增加、修改、删除。

操作完成返回操作成功的信息。

+ +表2.保密室管理系统-“管理用户”用例描述表 + +**3.3.2登记入库涉密载体** + + + +图3.保密室管理系统-“登记入库涉密载体”顺序图 + +
用例名登记入库涉密载体
用例描述用户登记新的涉密载体信息，包括名称、型号、序列号、密级等。
参与者用户
过程

  1. 用户进入保密系统

  2. 进入登记入库涉密载体界面

  3. 登记新的涉密载体信息，包括名称、型号、序列号、密级等。

+ +表3.保密室管理系统-“登记入库涉密载体”用例描述图 + +**3.3.3查询用户涉密载体** + + + +图4.保密室管理系统-“查询用户涉密载体”顺序图 + +
用例名查询用户涉密载体
用例描述用户可查看自己存放的载体；
参与者用户
过程

  1. 用户进入保密系统

  2. 进入查看涉密载体界面

  3. 查询自己存放的涉密载体信息。

+ +表4.保密室管理系统-“查询用户涉密载体”用例描述表 + +**3.3.4申请使用涉密载体** + + + +图5.保密室管理系统-“申请使用涉密载体”顺序图 + +
用例名申请使用涉密载体
用例描述用户提交使用申请，审批领导在线审批，结果通知用户和工作人员。
参与者用户、审批领导
过程

  1. 用户进入保密系统。

  2. 进入申请使用涉密载体界面。

  3. 提交涉密载体审批单，填写审批单的内容。

  4. 提交至审批领导处审批。

  5. 审批领导对申请进行审批。

+ +表5.保密室管理系统-“申请使用涉密载体”用例描述图 + +**3.3.5归还涉密载体** + + + +图6.保密室管理系统-“归还涉密载体”顺序图 + +
用例名归还涉密载体
用例描述用户归还已取出的涉密载体。
参与者用户
过程

  1. 用户进入保密系统

  2. 进入归还涉密载体界面

  3. 提交归还的涉密载体信息。

+ +表6.保密室管理系统-“归还涉密载体”用例描述表 + +**3.3.6提醒逾期涉密载体归还** + + + +图7.保密室管理系统-“提醒逾期涉密载体归还”顺序图 + +
用例名提醒逾期涉密载体归还
用例描述系统自动监控归还时间，对逾期未归还的载体向用户和工作人员发送提醒。
参与者无
过程

  1. 系统监控归还时间。

  2. 对截止到归还时间未归还的涉密载体，系统向用户和工作人员发送提醒。

+ +表7.保密室管理系统-“提醒逾期涉密载体归还”用例描述表 + +**3.3.7申请延期使用涉密载体** + + + +图8.保密室管理系统-“申请延期使用涉密载体”顺序图 + +
用例名申请延期使用涉密载体
用例描述用户在归期前可提交延期申请，由审批领导审批。
参与者用户、审批领导
过程

  1. 用户进入保密系统。

  2. 进入申请延期使用涉密载体界面。

  3. 提交延期使用涉密载体申请。

  4. 领导审批延期使用申请。

+ +表8.保密室管理系统-“申请延期使用涉密载体”用例描述表 + +**3.3.8申请销毁涉密载体** + + + +图9.保密室管理系统-“申请销毁涉密载体”顺序图 + +
用例名申请销毁涉密载体
用例描述保密室工作人员提交载体销毁申请，由审批领导在线审批。
参与者保密室工作人员、审批领导
过程

  1. 保密室工作人员进入保密系统

  2. 进入申请销毁涉密载体界面

  3. 填写申请销毁的涉密载体的信息并提交申请。

  4. 领导审批涉密载体的申请。

+ +表9.保密室管理系统-“申请销毁涉密载体”用例描述表 + +**3.3.9管理公告** + +图10.保密室管理系统-“管理公告”顺序图 + +
用例名管理公告
用例描述工作人员可发布、编辑、删除公告；用户可查看公告。
参与者保密室工作人员、用户
过程

  1. 保密室工作人员进入保密系统

  2. 进入管理公告界面

  3. 发布、编辑、删除公告

  4. 用户查看公告

+ +表10.保密室管理系统-“管理公告”用例描述表 + +**3.3.10管理值班排班** + +图11.保密室管理系统-“管理排班值班”顺序图 + +
用例名管理排班值班
用例描述审批领导可对工作人员和审批领导自身进行值班排班。
参与者审批领导
过程

  1. 审批领导进入保密系统

  2. 进入排班值班界面

  3. 保密室工作人员以及审批领导进行一周的排班。

+ +表11.保密室管理系统-“管理排班值班”用例描述表 + +**4. 其它软件需求描述** +======================= + +### 4.1 性能要求 + +1）响应时间：95%的常规页面操作（点击、查询、提交）响应时间小于2秒。列表数据分页加载，每页加载时间小于2秒。 + +并发用户数：系统应支持至少1000个用户同时在线操作，100个用户并发执行关键业务（如申请、审批）。 + +数据容量：数据库应能支持至少10万条载体记录、100万条操作日志的存储与高效查询。 + +### 4.2 设计约束 + +1）开发语言/框架：后端使用Java (Spring Boot)；前端推荐使用Vue.js。 + +2）数据库：使用关系型数据库MySQL。 + +3）运行环境：后端运行于JDK 11+环境；前端兼容现代浏览器。 + +4）安全性： + +必须实现基于角色的访问控制。 + +所有敏感数据（密码、序列号等）必须加密存储。 + +防止常见Web攻击。 + +5）可靠性：系统核心功能模块可用性应达到99.9%，出现异常应有友好错误提示并记录日志。 + +### 4.3 界面要求 + +1）风格：界面简洁、专业、色调庄重，符合政务类系统风格。 + +2）布局：左侧导航菜单，顶部显示用户信息和通知，中部为主工作区。 + +3）兼容性：兼容Chrome、Firefox、Edge等主流浏览器的最新版本。 + +### 4.4 进度要求 + +1）要求项目在2个月内完成开发、测试并上线试运行。 + +2）需提供详细的开发里程碑计划，包括需求确认、设计、编码、测试、部署等阶段的时间节点。 + +### 4.5 交付要求 + +1）可部署的软件系统安装包（Docker镜像）。 + +2）完整的源代码。 + +3）数据库初始化脚本。 + +4）软件需求分析文档、软件需求规格说明书、软件设计文档、、软件测试报告、安装部署手册等。 + +### 4.6 验收要求 + +1）验收依据：以本需求规格说明文档及双方确认的设计原型作为最终验收依据。 + +2）验收准则： + +- 所有功能需求均已实现并通过测试。 + +- 系统运行稳定，无重bug。 + +- 交付的文档齐全、内容完整正确。 + +- 完成对甲方管理员的系统培训。