团队作业3--需求改进&系统设计

一、作业要求

这个作业属于哪个课程	计科22级34班
这个作业要求在哪里	作业要求
这个作业的目标	<根据需求进行改进，系统设计>

二、团队成员

• 队名

  物归原主队

  团队成员

  姓名	学号
  欧可贵	3121002717（队长）
  方伟城	3122004564
  李梓灏	3122004695
  吴灿豪	3122004710
  李建龙	3122004529
  陈东阳	3122004558
  龙杜冰	3122004578

三、需求&原型改进

问题1：用户如果只是丢了一张校园卡，如何在众多帖子中迅速找到自己的校园卡？
修改：对帖子实行分类，分为校园卡、随身物品、贵重物品等，如果发贴用户选择了校园卡，可以添加选项框填写校园卡号。方便用户通过自己的学号迅速定位。

问题2：用户如何确定帖子中的物品就是自己的？
修改：通过添加聊天界面，在对物品进行认领时，两方确认物品的详细信息，例如有无特殊记号，有无购买记录等。

加分部分：

用户痛点：
在拾取到物品后，面对众多的表白墙、校园墙，如果只上传到添加了的功能墙，是否能保证失主也添加了这个功能墙，失主是否真的能看到自己遗失的物品。

使用场景：
使用前：失主在一众校园墙、表白墙翻遍朋友圈记录，却难以寻找到自己丢失的物品，随后又辗转多个饭堂的失物招领处寻找自己的物品。
使用后：失主能够登录网站对物品进行筛选，可以获得拾取者的联系方式或者知道自己的物品被放在了某个失物招领处。

完善需求规格说明书

初稿的不足：主要功能描述的不够细致，非必须实现的功能没有明确的划分，对于定位与认领功能和客服与存放功能规划至初开发非必须实现。

场景描述：小李找回遗失的手机
角色：

• 小李（学生用户）
• 小王（学生用户）
• 管理员（负责审核和管理内容）

背景：
小李是一名大一的新生，刚刚适应大学生活的一段时间里，她的手机不小心丢失了。因为手机里存有很多重要的资料和与家人、朋友的联系信息，小李非常着急。

一、丢失物品发布求助帖子

场景：

一天晚上，小李在校园图书馆学习，突然发现自己的手机不见了。她的心情非常焦虑，因为手机上存有不少课堂笔记和重要的学习资料。

于是，小李通过校园失物招领系统发布了一条求助帖子。她在帖子中上传了手机的照片，描述了手机的品牌、型号、颜色以及最后一次使用手机的时间和地点（图书馆的二楼）。

小李选择了物品类别：“贵重物品”，并要求填写遗失时间（她选择了当天的日期）和丢失地点。

二、寻找招领信息

场景：

与此同时，小王在校园内走动时，在校门口发现了一部手机，他觉得这部手机可能是别人丢失的，便决定在系统上查找相关的信息。

小王打开了失物招领系统，并使用了搜索功能。通过系统内的筛选功能，他设置了时间范围（当天的帖子），并选择了“贵重物品”分类。很快，他就看到了小李发布的求助帖子。帖子中的手机照片与他捡到的手机非常相似，描述也非常吻合。于是，小王决定与小李进行联系，确认物品的详细信息。

三、物品交流和确认失主

场景：

小王通过失物招领系统的内建消息功能，向小李发送了一个询问消息：“你好，我捡到一部手机，颜色和型号和你遗失的描述很像，能否确认一下手机上的某个特别标志或细节？”

小李快速回复，告诉小王手机的屏幕上有一处刮痕，是她上周不小心弄上的。看到这个特征后，小王确认了这就是小李丢失的手机。

四、物品归还

场景：

确认无误后，小王和小李约定了一个方便的时间和地点见面。第二天中午，他们在学校食堂门口顺利见面，小王将手机还给了小李。

小李非常感激，决定在系统中发布一条感谢帖，表扬小王的诚信和及时帮助。

五、管理员的审核与管理

场景：

管理员定期对系统中发布的帖子进行审核。为了确保系统中的信息真实有效，管理员对所有发布的招领与求助帖子进行内容审核，检查物品描述是否清晰、信息是否完整，及时清理过期的帖子，避免用户收到不相关的信息。

管理员也会定期检查用户的互动记录，防止恶意行为，确保失物招领系统的健康运行。

功能与用户需求的契合：

1. 物品分类与筛选：

系统的分类和筛选功能让小李能够迅速发布清晰的求助信息，而小王也能通过筛选迅速找到可能的失物，减少了信息匹配的时间成本。

2. 用户交流功能：

通过系统内的消息功能，小李与小王能够在平台上直接沟通，避免了不必要的误会和信息延误，加速了物品归还过程。

3. 管理员监管：

管理员的内容审核确保了平台的秩序，减少了虚假信息和欺诈行为的发生，提高了用户的信任感和平台的整体效率。

4. 高效的物品找回：

系统帮助小李和小王顺利找回失物，减少了时间和精力的浪费，提升了校园内的互帮互助氛围。

总结：
通过这个失物招领系统，用户能够在失去物品时轻松发布求助信息，并能通过筛选和分类功能快速找到相关的招领信息，促进了师生之间的互帮互助。同时，管理员的监督和审核确保了系统的有效运行，减少了虚假信息的干扰，让整个失物招领流程更加顺畅和高效。

功能分析的四个象限：

四象限模型：

• 象限一：重要且紧急（High Priority, High Impact）
• 象限二：重要但不紧急（High Priority, Low Impact）
• 象限三：不重要但紧急（Low Priority, High Impact）
• 象限四：不重要且不紧急（Low Priority, Low Impact）

象限一：重要且紧急（High Priority, High Impact）
这些功能对于系统的核心目标至关重要，直接影响到系统的核心用户体验和功能实现，是项目的基础功能，必须尽早实现。

用户管理：
用户注册与登录：这是任何系统的基础功能，用户需要注册账户才能参与失物招领，因此必须确保其安全性和稳定性。
密码找回功能：为用户提供重置密码的途径是提高用户体验的基本需求，必须有。
用户信息编辑：允许用户更新个人信息，确保信息准确并便于系统与用户互动。

物品登记与交流：
发布招领帖子：拾到物品的用户必须能够简单且快速地发布失物招领信息，包含物品照片、描述、拾获地点和时间。
发布求助帖子：遗失物品的用户也应能便捷地发布求助信息，帮助他人寻找物品。
交流功能：用户之间需要便于交流和确认物品细节，这项功能能提升失物招领的成功率。
系统安全与维护：

数据安全：为了保护用户隐私和信息安全，必须进行严格的数据保护，特别是与用户联系方式和物品相关的信息。
系统日志与监控：确保系统的稳定运行，快速响应用户的需求，并避免系统出现重大问题。

象限二：重要但不紧急（High Priority, Low Impact）
这些功能对系统的用户体验提升至关重要，但开发周期和实际需求可能相对较低，或者可以根据实际情况逐步优化。

定位与认领功能（初步开发不实现，但计划要实现）：

定位功能：通过地图标记物品发现地点可以帮助快速确认物品的位置，提升系统的可操作性。
认领确认功能：这是一项重要的功能，能够有效提高失主与拾取者之间的沟通效率，避免不必要的争议。虽然初期不实现，但这一功能可以在后期开发中逐步完善。
虚拟电话：保护用户隐私的功能，可以避免用户的电话号码泄露，但这项功能可以在系统稳定后再实现。
客服与存放（初步开发不实现，但有潜力）：

客服功能：处理用户在使用系统过程中遇到的问题和纠纷，确保用户体验。
物品存放服务：虽然目前不实现，但该功能可以提高用户的便捷性，尤其是对于贵重物品的处理非常重要。

象限三：不重要但紧急（Low Priority, High Impact）
这些功能在短期内可能会影响系统的使用，但对于整体功能和可持续发展来说，其优先级相对较低。通常这些功能可以优化，但不影响基本服务的提供。

系统容量与性能：
响应时间（<2秒）：虽然系统响应时间对用户体验影响较大，但相对其他功能来说，这个问题可以逐步优化，特别是初期用户量较小，性能要求可以在后期逐步提高。
处理5000条记录和1000活跃用户：初期用户量不大，但要为后期增长做准备，因此要设计好扩展性。虽然此项要求比较紧急，但在实际的产品迭代过程中可以逐步优化。

象限四：不重要且不紧急（Low Priority, Low Impact）
这些功能对于项目的核心价值影响较小，且当前阶段没有强烈需求，可以暂时忽略，待后续开发时再考虑实现。

增强功能（后期可选）：
客服功能（初步开发不实现）：尽管用户的需求可能会包含客服支持，但这一功能并非项目启动时的首要任务。
物品存放服务（初步开发不实现）：虽然可以提高物品归还的灵活性，但初期阶段可能难以实现这一功能。

分解WBS及相应的项目进度计划：

核心功能开发：用户登录注册；发帖寻主发帖求助功能；用户设置功能。（1周）

辅助功能开发：用户间聊天界面；数据库开发等。（1周）

增值功能开发：定位功能实现；客服功能实现。（1周）

测试：单元测试；集成测试；系统测试。（1周）

四、系统设计

系统框架

Spring框架是一个开源的Java应用程序框架，它被广泛用于构建企业级Java应用程序。它提供了一种轻量级的编程模型，通过依赖注入（Dependency Injection）和面向切面编程（Aspect-oriented Programming）等技术，使得开发者可以更加方便地开发可扩展、模块化和松耦合的应用程序，它允许开发者使用普通的Java对象进行开发，并集成了许多流行的第三方框架和技术，如Hibernate、MyBatis、JPA、RESTful服务等。此外，Spring框架还提供了强大的配置和管理机制，使得应用程序的配置更加简单灵活。

后端系统设计：将会是连接前端以及检索系统的重要部分，负责处理从用户处得到的信息，并将此类信息进行保存和编排之后发到界面之上，同时保证不同用户之间的信息的互通，在进行正常交流的时候可以相互告知自己所有的信息，达到失物者联系拾得者取回自己物品的目的。
为了达到我们的开发目的，同时基于大家都接触过java，我们选择使用java作为后端开发语言，并采用了Spring框架来实现我们的后端。

后端系统主要分成以下部分：
主站模块：用以具体的主界面信息提示，包括新发布的帖子以及各种功能选项。
用户模块：用以用户管理自己的信息，保证具体的使用。
帖子模块：具体的失物招领信息的发布，作为达成失物者寻找个人物品的主要渠道，可以了解到拾得者发布拾得物品的具体信息，以及发布失物的具体信息。
还有一个部分则是与搜索引擎的衔接，保证用户的信息能被正常搜索以及搜索。

分层结构设计

1. 表示层 (Presentation Layer)

目标： 负责与用户进行直接交互，呈现UI，获取用户的输入，并将业务数据展现给用户。

主要功能：

• 用户注册与登录：用户可以通过界面填写个人信息并进行注册，或者输入用户名和密码进行登录。
• 用户信息管理：用户可以查看和编辑个人资料，包括学号/工号、联系方式等。
• 物品管理：用户可以通过界面发布失物或招领信息，包括物品照片、描述、丢失或拾取地点和时间。
• 帖子查看与筛选：用户可以浏览所有失物招领帖子，并根据时间、物品类别等条件进行筛选。
• 交流功能：通过系统内的消息功能，与其他用户进行沟通交流。

前端技术：HTML, CSS, JavaScript

前后端交互图稿

2. 业务逻辑层 (Business Logic Layer)

目标： 处理应用程序的核心业务逻辑，保证系统功能的有效实现，处理用户请求并协调各层的交互。

主要功能：

• 用户管理：包括用户注册、登录、密码重置、信息编辑等功能的业务逻辑实现。
• 物品管理：处理用户发布招领帖子、求助帖子的业务逻辑，包括物品分类、筛选等。
• 帖子匹配与通知：当系统检测到用户发布的求助帖子可能与某个招领帖子匹配时，触发通知。
• 系统安全：对系统的安全进行逻辑控制，包括数据保护、访问控制、加密解密等。

后端技术：Java (Spring Boot),Node.js 等。
业务逻辑开发：根据需求设计各类服务类、控制器、以及逻辑处理方法。
3. 数据访问层 (Data Access Layer)

目标： 负责与数据库交互，实现数据的增删改查操作。

主要功能：

• 用户数据访问：存储和更新用户信息，包括学号、工号、联系方式、注册时间等。
• 物品信息存储：存储失物与招领信息，包括物品名称、照片、描述、拾取地点、丢失时间等。
• 帖子管理：存储所有求助和招领帖子的详细内容，并处理帖子的分类、筛选等。

数据库技术：关系型数据库MySQL

4. 数据库层 (Database Layer)

目标： 存储应用程序的数据，保证数据的持久化与高效检索。
数据库设计：

• 用户表 (Users)：存储用户基本信息，包括ID、姓名、学号/工号、联系方式、注册时间等。
• 帖子表 (Posts)：存储招领帖子与求助帖子的详细信息，包括帖子ID、物品ID、帖子类型（招领或求助）、状态、发布时间等。

技术实现：
数据库管理系统（DBMS）：使用MySQL关系型数据库来管理数据。
数据库设计原则：遵循规范化设计原则，保证数据的完整性和一致性。

数据库ER图

五、Alpha任务分配计划

我们将整个项目分为了九个模块：

• 系统设计（已完成）
• 用户登录模块
• 发帖模块
• 聊天模块
• 用户设置模块
• 数据库开发模块
• 测试计划
• 前端界面
• 需求说明书

任务分配人员计划

人员	头像
李建龙	Dr
龙杜冰	嗯哼
陈东阳	DY
方伟城	伟城
吴灿豪	Ra
李梓灏	Me
欧可贵	🐕

甘特图

六、测试计划

1.接口测试

• 选择测试工具：一般来说，一个功能对应一个控制层接口，使用Apifox对每一个功能进行接口测试。

• 执行测试：在测试过程中，需要记录测试结果，包括请求的状态码、返回数据的正确性和完整性等。

• 分析测试结果：对测试结果进行分析，确保测试结果与预期结果一致。如果测试结果与预期不符，需要分析原因并跟踪问题。这可能涉及查看服务器的日志、调试代码等。

• 编写测试报告：根据测试结果和分析结果，编写测试报告。测试报告应列出测试用例的结果、问题以及建议的解决方案。这有助于团队成员了解接口的测试情况，并采取相应的措施来解决问题。

2.性能测试

• 准备测试环境：搭建适合压力测试的环境，包括硬件设备、网络配置、测试环境部署等。确保测试环境的稳定性、一致性和负载能力。使用Jmeter 进行压力测试
• 执行测试：使用性能测试工具模拟并生成负载，对应用程序进行压力测试。可以逐步增加负载，直至达到预定的性能验收标准。在这个过程中，需要使用性能监控工具对应用程序的性能指标进行实时监测和记录。
• 收集和分析结果：根据测试期间的监控数据，收集和分析性能测试的结果。对性能问题和瓶颈进行归因分析，找出性能瓶颈所在的原因。
• 编写测试报告：根据分析结果，编写性能测试报告，总结测试的结果、得出结论，并提供可视化图表和建议。测试报告应该包括测试指标、测试环境、测试结果、发现的问题等。
• 提出改进建议：根据测试报告提供的性能问题和瓶颈，给出具体的改进建议，包括代码优化、配置调整、资源扩容等方面的优化建议。

3.测试完成标准
1.测试充分性

a.用例已全面覆盖需求：测试用例覆盖率要求达到100%。

b.原则上要求所有用例都100%执行，即优先级高、中、低的用例都必须100%执行。

c.工作投入充分性：项目测试工作要充分投入，保障测试投入的合理性。

2测试有效性

a.严重性以上程度的缺陷解决率必须达到100%。

b.缺陷密度达到一定的标准，Bug数呈正态分布。

c.相关责任部门认可测试结果,包括客户的试用、验收测试等。