完成的工作：
我们小组目前完成了需求规格说明书、构件图、界面设计文档、类图、配置图和数据设计图的编写。如下：
需求规格说明书：
1. 引言
1.1 编写目的
确定失物招领系统的功能、工作原理以及有效性需求，以标准的语言及表述方式整理系统需求，以供开发人员参考。
1.2 项目背景
在校园里，常常有人遗失物品或者捡到物品，但是他们没有一个良好的信息交流平台，只能在自己的朋友圈或者空间里求转发失物或者招领信息，这样的方式使得信息传递的速度非常慢，可能会使失主不能及时找到甚至找不到失物，给生活带来了极大的不便。
1.3 目标需求
本系统旨在方便失主寻找丢失物品、拾主归还捡拾物品，为失主和拾主搭建一个发布信息的平台，发扬拾金不昧的美好品德，体现大学生良好的个人修养。
1.4 约束与限制
软件：Linux ubuntu 14.04；
数据库管理系统：SQL Server；
开发工具：Eclipse；
软件平台：Apache
经费限制：1万。
开发期限：5月初开始需求分析，7月初交付功能。
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 可行性结论
经上述可行性分析，系统的研制和开发可以立即开始进行。
类图：
构件图：
综述：“学生失物招领系统”构件图描述了实现系统的源程序之间的依赖关系。在“信息查询”包中，“信息查询”通过“失物查询”、“用户查询”和“招领查询”构件的支持，可以实现用户的信息查询；“失物管理”通过调用不同构件的支持，实现用户对系统的相关操作；2级用户可以搜索、查看所有失物信息和招领信息，也可以发布失物信息和招领信息，对自己发布的信息进行修改、撤回。若发现冒领情况，可进行举报。1级用户根据信息急迫程度、物品贵重程度等因素人工置顶或删除相关信息，可以审核举报；0级用户可以通过“系统管理”包对系统进行用户管理、权限核查、处理举报、修改失物或招领信息状态等操作。“系统管理”需要“物品审核”、“权限管理”、“用户信息管理”等不同构件的支持。所有包的首先均需要“数据服务”的支持。
构件描述：“信息查询”包负责查询用户所需信息，“失物管理”包负责“挂失物品”的申请、选定、反馈、举报等功能的实现，“系统管理”负责实现对整个系统相关信息的管理操作，“2级、1级用户界面”负责传递“信息查询”和“失物管理”所需的参数，“0级用户界面”则提供“信息查询”、“失物管理”和“系统管理”所需的参数，“数据服务”通过已有的数据库管理系统所需对数据库进行SQL查询和修改的功能。
构件间关系：“信息查询”包与“2级用户界面”是实现依赖关系，必须由“2级用户界面”提供进行查询的相关参数，如失物地点、时间等查询条件，“信息查询”才能利用“数据服务”的支持获取相关信息。“课程管理”包和三级用户界面都属于实现依赖关系，“课程管理”依赖于三个界面提供进行相关课程操作的参数，如失物类型、反馈类型等。“系统管理”包与“0级用户界面”同样是实现依赖关系，对系统的管理高度依赖管理员的介入，需要提供“0级用户界面”传递大量操作参数，同时，“系统管理”部分功能的实现也依赖于“失物管理”包的支持 “信息查询”包、“失物管理”包和“系统管理”包都与“数据服务”有使用依赖关系，三个包均依赖“数据服务”提供的支持间接实现对数据库的查询和修改。
其它描述：无。
配置图：
综述：“失物招领系统”配件图描述了软件系统在硬件系统中的部署。配置图说明系统采用三层逻辑结构。“客户端”是应用界面层，部署三级权限用户操作界面（管理员，客服，用户），不同的权限对应不同的功能。“功能逻辑服务器”是逻辑应用层，实现系统的主要功能：失物管理，信息查询，系统管理。“数据库服务器”是数据服务层，提供对数据（失物信息，事件信息，客户信息等）的关系管理。
节点描述：主要有三个节点，分别是“客户端”“功能逻辑服务器”“数据库服务器”，节点里的配置描述如下：“二级用户界面”即“普通客户”，负责传递“失物管理”和“信息查询”所需的参数；“一级用户界面”即“客服”，则提供“失物管理”所需的相关参数；“零级用户界面”，即“管理员”，则负责提供“系统管理”的相关参数以及管理和控制；“数据服务”通过已有的数据库管理系统对数据库进行SQL查询修改和删除的功能；“信息查询”负责查询失物的相关所有信息；“失物管理”负责失物的提交，申请等功能的实现；“系统管理”负责实现对系统相关信息的管理。
节点关系描述：在各节点间，“客户端”和“功能逻辑服务器”之间是实现依赖关系，“功能逻辑服务器”里的“信息查询”和“失物管理”功能都需要客户端用户进行实现，普通用户进行失物查询，申请，举报等功能，客服则实现审核，失物信息发布及管理反馈意见等功能。“功能逻辑服务器”和“数据库”服务器是依赖关系，“功能逻辑服务器”里的数据支持来自数据库。
数据设计图：
分工：
张歆：学习数据库相关的知识，负责数据库的设计和实现；在设计文档中负责数据设计，以及类图和包图的绘制。
周淼：针对去年的文档和小组现状修改了需求规格说明书，重新进行了功能分析，并修改了相关的用例图，dfd图。学习spring+mybait企业级开发，准备在后期应用到项目中来。
庞治宇：编写部分前段网站，对所有文档进行整合。
邹林伸：部分文档编写，PPT制作和博客的发布和维护。
张嘉诚：搭建了一部分前端网站，完成了构建图、配置图的相关图片与文档。
王鹏翔：界面设计。