我们小组目前完成了需求规格说明书、构件图、界面设计文档、类图、配置图和数据设计图的编写。如下：
需求规格说明书：
1.引言
1.1编写目的
确定失物招领系统的功能、工作原理以及有效性需求，以标准的语言及表述方式整理系统需求，以供开发人员参考。
1.2项目背景
在校园里，常常有人遗失物品或者捡到物品，但是他们没有一个良好的信息交流平台，只能在自己的朋友圈或者空间里求转发失物或者招领信息，这样的方式使得信息传递的速度非常慢，可能会使失主不能及时找到甚至找不到失物，给生活带来了极大的不便。
1.3目标需求
本系统旨在方便失主寻找丢失物品、拾主归还捡拾物品，为失主和拾主搭建一个发布信息的平台，发扬拾金不昧的美好品德，体现大学生良好的个人修养。
1.4约束与限制
软件：Linuxubuntu14.04；
数据库管理系统：SQLServer；
开发工具：Eclipse；
软件平台：Apache
经费限制：1万。
开发期限：5月初开始需求分析，7月初交付功能。
1.5术语
术语
解释
DFD
系统数据流图
浏览信息
浏览以某种顺序排列的多条只显示主要内容的信息
查看信息
仔细阅读某一条信息的详细内容
失主
丢失物品的用户
拾主
捡到物品的用户
失物信息
失主发布的寻找失物的信息
招领信息
捡物用户发布的寻找失主的信息
申请领回
失主发现招领信息后，申请领回对应物品
申请提供
拾主发现失物信息后，申请提供对应物品
提供申请
名词，属性为提供的申请
失主寻物
失主发现物品丢失后，通过系统寻找物品
拾物寻主
拾主捡拾到物品后，通过系统寻找失主
1.6参考资料
《软件工程基础》胡思康编著清华大学出版社
《需求工程与建模》课件
系统主要分为失物管理、招领管理，并引入悬赏机制——积分，积分累计到一定数量后，可以用来兑换相应的小礼品。
申请失物，发布失物信息
提供拾物，发布所拾物品信息
为多人认领的失物提供第三方参考信息
针对于平台用户（已注册），系统采取了权限分级制度。
整个系统中使用三个级别对用户权限进行管理（0、1、2级），不同权限的用户有不同的功能。
2级为普通用户，权限最低；该级用户在不同事件中可能扮演失主、拾主这两种不同的角色；该级用户可以搜索、查看所有失物信息和招领信息，也可以发布失物信息和招领信息，对自己发布的信息进行修改、撤回。若发现冒领情况，可进行举报。
0级为系统管理员，权限最高，该级用户除1级用户功能外，还可以进行用户管理、权限核查、处理举报、修改失物或招领信息状态等操作。
用户在搜索匹配之后未找到所需信息的情况下，可自行发布失物或招领信息。需录入信息如下：
物品名称
关键词（设置选项，自行选择）
物品图片
描述信息
积分数量
招领信息还需额外设置验证问题。
用户发布失物/招领信息之后，系统可以根据物品所标注的关键词自动匹配相应的失物/招领信息。
失主对已发布并且未被认领的招领物品申请领回。功能上允许多人对统一招领信息同时申请失物领取。
最终领回行动结束后双方需在系统修改失物状态为已领回。
拾主可对已发布且未领回的失物信息提供拾物。功能上允许允许多人同时对一条失物信息申请拾物提供。
申请需要提供拾物照片，失物发布者收到申请后可以根据提供的照片选择是否接受申请。如果接受拾物提供申请则可以与提供者进行在线交流。
后续操作和“申请失物领回”阶段操作相同。
确认领回后，拾主会获得失主悬赏的“悬赏积分”，失主则会扣除等数量的“悬赏积分”。
注册用户的累积积分可以用来兑换礼品。积分的兑换设定如下：
失物/招领信息状态分为4种：
未发布
待申请
申请、
待领回
已领回
若发现一条状态为已领回的信息出现冒领情况，普通用户可申请举报，由客服审核举报，若审核成功，由系统管理员处理举报。处理过程为给予冒领者警告或处分，扣除招领用户相应“悬赏积分”，将招领信息状态更改为“待领回”，并开通三方在线交流权限。之后失主可重新领回失物并确认领回，系统管理员在确认领回后收回权限。
举报信息状态分为未提交、待审核、待处理、处理中、已处理、无效。
本系统的适用对象为普通用户（大部分为师生）、客服及管理员。
管理员对计算机熟练程度较高，操作能力等较强。
客服对计算机及手机基本操作熟练程度较高，可能对个别操作不熟悉。所以客服端系统应易操作性强，使所有客服能够在培训后轻松使用此软件。
前期调查发现，大部分师生认为信息及时性及信息完善程度对失物招领系统来说至关重要，防止冒领现象、增添奖励机制也很有必要。
3.1操作可行性
本系统的研制和开发充分考虑用户工作流程、计算机操作水平等，尽可能提供更人性化、直观的界面，满足用户要求。系统的操作方式在用户组织内可行。
3.2经济可行性
本系统为公益性系统，不涉及盈利。
资金投入主要分为：
（1）基本建设投资：
硬件设备：服务器；
开发环境（IDEA）：IntellijIDEA；
数据库管理系统：MySQLworkbench；
前端框架：bootstrap；
后端开发模式：spring+mybatis
软件平台：Apache。
（2）其他一次性支出：系统设计和开发费用。
（3）非一次性支出：系统维护费用。
3.3法律可行性
3.4可行性结论
经上述可行性分析，系统的研制和开发可以立即开始进行。
类图：
构件图：
其它描述：无。
配置图：
综述：“失物招领系统”配件图描述了软件系统在硬件系统中的部署。配置图说明系统采用三层逻辑结构。“客户端”是应用界面层，部署三级权限用户操作界面（管理员，客服，用户），不同的权限对应不同的功能。“功能逻辑服务器”是逻辑应用层，实现系统的主要功能：失物管理，信息查询，系统管理。“数据库服务器”是数据服务层，提供对数据（失物信息，事件信息，客户信息等）的关系管理。
节点关系描述：在各节点间，“客户端”和“功能逻辑服务器”之间是实现依赖关系，“功能逻辑服务器”里的“信息查询”和“失物管理”功能都需要客户端用户进行实现，普通用户进行失物查询，申请，举报等功能，客服则实现审核，失物信息发布及管理反馈意见等功能。“功能逻辑服务器”和“数据库”服务器是依赖关系，“功能逻辑服务器”里的数据支持来自数据库。