11组软件工程组队项目失物招领系统——项目汇总

Github项目地址
https://github.com/ZZZ-JC/lost-and-found.git

 

需求规格说明书：

1      引言

1.1   编写目的

确定失物招领系统的功能、工作原理以及有效性需求，以标准的语言及表述方式整理系统需求，以供开发人员参考。

1.2   项目背景

在校园里，常常有人遗失物品或者捡到物品，但是他们没有一个良好的信息交流平台，只能在自己的朋友圈或者空间里求转发失物或者招领信息，这样的方式使得信息传递的速度非常慢，可能会使失主不能及时找到甚至找不到失物，给生活带来了极大的不便。

1.3   目标需求

本系统旨在方便失主寻找丢失物品、拾主归还捡拾物品，为失主和拾主搭建一个发布信息的平台，发扬拾金不昧的美好品德，体现大学生良好的个人修养。

1.4   约束与限制

前端：html+css+JavaScript Jquery必要的框架（bootstr/vue）（可以适配手机端的访问）

后端：SSM框架（javaweb）

数据库：MySQL

服务器：Tomcat

1.5   术语

术   语	解    释
DFD	系统数据流图
浏览信息	浏览以某种顺序排列的多条只显示主要内容的信息
查看信息	仔细阅读某一条信息的详细内容
失主	丢失物品的用户
拾主	捡到物品的用户
失物信息	失主发布的寻找失物的信息
招领信息	捡物用户发布的寻找失主的信息
申请领回	失主发现招领信息后，申请领回对应物品
申请提供	拾主发现失物信息后，申请提供对应物品
提供申请	名词，属性为提供的申请
失主寻物	失主发现物品丢失后，通过系统寻找物品
拾物寻主	拾主捡拾到物品后，通过系统寻找失主

 

1.6   参考资料

《软件工程基础》 胡思康编著 清华大学出版社

《需求工程与建模》课件

 

2      需求描述

2.1   概述

系统主要分为失物管理、招领管理，并引入悬赏机制——积分，积分累计到一定数量后，可以用来兑换相应的小礼品。

普通用户在未登录时仅可浏览、输入关键词搜索、查看所有失物信息和招领信息。登录用户具有的操作：

• 申请失物，发布失物信息
• 提供拾物，发布所拾物品信息
• 为多人认领的失物提供第三方参考信息

2.2   功能描述

2.2.1 用户注册

用户通过邮箱和手机号进行注册，也可选择第三方账号（QQ，微信等）注册，注册时必须录入工号（学生对应学号/老师对应工号），一个工号只能注册一个账号。

2.2.2 用户权限管理

针对于平台用户（已注册），系统采取了权限分级制度。

整个系统中使用三个级别对用户权限进行管理（0、1、2级），不同权限的用户有不同的功能。

2级为普通用户，权限最低；该级用户在不同事件中可能扮演失主、拾主这两种不同的角色；该级用户可以搜索、查看所有失物信息和招领信息，也可以发布失物信息和招领信息，对自己发布的信息进行修改、撤回。若发现冒领情况，可进行举报。

1级为客服，权限较高；该级用户除2级用户功能外，还可以根据信息急迫程度、物品贵重程度等因素人工置顶或删除相关信息。可以审核举报。

0级为系统管理员，权限最高，该级用户除1级用户功能外，还可以进行用户管理、权限核查、处理举报、修改失物或招领信息状态等操作。

2.2.3 发布失物信息/发布招领（拾到物品）信息

用户在搜索匹配之后未找到所需信息的情况下，可自行发布失物或招领信息。需录入信息如下：

• 物品名称
• 丢失/捡拾时间
• 关键词（设置选项，自行选择）
• 物品图片
• 描述信息
• 积分数量
• 招领信息还需额外设置验证问题。

2.2.4 搜索匹配

用户发布失物/招领信息之后，系统可以根据物品所标注的关键词自动匹配相应的失物/招领信息。

2.2.5 申请失物领取

失主对已发布并且未被认领的招领物品申请领回。功能上允许多人对统一招领信息同时申请失物领取。

申请时需回答验证问题，回答正确后才可与拾主在线交流，进一步确认详细信息。若交流中发现错误，失主和拾主均可拒绝领回，只要有任何一方拒绝领回，则申请终止。若交流中核对成功，则在失主和拾主同时确认接受领回后，填写物品领取时间地点反馈给后台留档，领回行动开始。

最终领回行动结束后双方需在系统修改失物状态为已领回。

2.2.6 申请拾物提供

拾主可对已发布且未领回的失物信息提供拾物。功能上允许允许多人同时对一条失物信息申请拾物提供。

申请需要提供拾物照片，失物发布者收到申请后可以根据提供的照片选择是否接受申请。如果接受拾物提供申请则可以与提供者进行在线交流。

后续操作和“申请失物领回”阶段操作相同。

确认领回后，拾主会获得失主悬赏的“悬赏积分”，失主则会扣除等数量的“悬赏积分”。

2.2.7 积分兑换

注册用户的累积积分可以用来兑换礼品。积分的兑换设定如下：

2.2.8 失物/招领信息状态

失物/招领信息状态分为4种：

• 未发布
• 待申请
• 申请、
• 待领回
• 已领回

2.2.9 举报机制

若发现一条状态为已领回的信息出现冒领情况，普通用户可申请举报，由客服审核举报，若审核成功，由系统管理员处理举报。处理过程为给予冒领者警告或处分，扣除招领用户相应“悬赏积分”，将招领信息状态更改为“待领回”，并开通三方在线交流权限。之后失主可重新领回失物并确认领回，系统管理员在确认领回后收回权限。

举报信息状态分为未提交、待审核、待处理、处理中、已处理、无效。

2.3   用户描述

本系统的适用对象为普通用户（大部分为师生）、客服及管理员。

管理员对计算机熟练程度较高，操作能力等较强。

大部分普通用户对手机基本操作熟练程度较高，掌握注册、登录、填写信息、上传照片等基本操作。不排除部分用户对基本操作不熟悉。因此手机客户端应易操作性强，使所有普通用户能轻松操作此软件。此外，普通用户中可能包含留学生和外教，因此系统应支持英文版本。

客服对计算机及手机基本操作熟练程度较高，可能对个别操作不熟悉。所以客服端系统应易操作性强，使所有客服能够在培训后轻松使用此软件。

前期调查发现，大部分师生认为信息及时性及信息完善程度对失物招领系统来说至关重要，防止冒领现象、增添奖励机制也很有必要。

3      可行性分析

本系统是一个基于Java.Web结构的失物招领系统，采用面向对象技术、数据库技术等先进技术开发的应用程序，现有的开发技术已非常成熟，且被广泛应用于各行各业，利用现有技术完全可以达到功能目标。考虑开发期限较为充裕，预计可以在规定的时间内完成开发。

3.1 操作可行性

本系统的研制和开发充分考虑用户工作流程、计算机操作水平等，尽可能提供更人性化、直观的界面，满足用户要求。系统的操作方式在用户组织内可行。

3.2 经济可行性

本系统为公益性系统，不涉及盈利。

资金投入主要分为：

（1）   基本建设投资：

硬件设备：服务器；

开发环境（IDEA）：Intellij IDEA；

数据库管理系统：MySQL workbench；

前端框架：bootstrap；

后端开发模式：spring+mybatis

软件平台：Apache。

（2）   其他一次性支出：系统设计和开发费用。

（3）   非一次性支出：系统维护费用。

本系统将尽力减少人力、物力费用，缩短了操作时间，最大程度地提高工作效率和系统性能。

3.3 法律可行性

所建议系统的研制和开发都选用正版软件，将不会侵犯他人、集体和国家的利益，不会违反相关的国家政策和法律。

3.4 可行性结论

经上述可行性分析，系统的研制和开发可以立即开始进行。

4      数据流图

（1）数据流图0层

 

 

 

 

（2）数据流图1层

 

5      面向对象的需求分析与建模

5.1   功能模型——用例图

 

5.1.1 用例图综述

“失物招领系统”通过普通用户、客服和系统管理员共同完成，普通用户可在不同事件中可能扮演拾主和失主两种角色，为方便理解，图中将其分别描述。

普通用户主要通过系统完成失主寻物和拾物寻主两大过程，其中失主包括浏览失物信息，搜索失物信息，发布招领信息，接收/拒绝“申请提供”，在线交流的功能；而拾主则是与之对应的有浏览招领信息，搜索招领信息，发布失物信息，接收/拒绝“申请领回”，在线交流的功能。除此之外，任何用户都对可以进行举报

客服主要进行置顶或失物/招领信息处理操作和对举报的审核。系统管理员主要进行用户信息管理和对举报的处理，。

5.1.2 参与者

包括普通用户（失主、拾主）、客服、系统管理员，同时抽象出“用户”。系统管理员是一种特殊的客服。

5.1.3 用例

失主：注册、登录、浏览/搜索/失物信息、发布招领信息、修改招领信息