校园失物招领小程序 —— 需求分析与原型设计
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | [H202601软件工程与软件工程实践]( https://edu.cnblogs.com/campus/fzu/2026-01SoftwareEngineeringandSoftwareEngineeringPractice ） |
| 这个作业的要求在哪里 | 2026秋软件工程个人作业（第三次) |
| 姓名 | 刘怀正 · 丁维彤 |
| 学号 | 052404147 · 102402123 |
| 作业目标 | 分析校园失物招领需求，使用原型工具完成小程序原型设计 |
| 原型工具 | 墨刀（Modao） |
| 原型链接 | 校园失物招领小程序原型 |
一、用户与需求分析
主要用户：在校学生，分为两类——失主（物品遗失，希望找回）和拾获者（捡到物品，希望归还）。
存在的问题：目前同学们主要通过班级群、宿舍群、朋友圈发布寻物或招领信息，但这类信息高度分散，且会被不断刷新的群消息淹没；一个同学在教学楼捡到校园卡，可能只能在有限的圈子里发布，而真正遗失校园卡的同学未必能看到。
本软件要解决的问题：提供一个集中、可搜索、不被刷掉的失物招领信息平台，让失主和拾获者都能快速发布、浏览、搜索信息，从而提高物品找回与归还的效率。
设计原则：功能简单、流程清晰、贴近小程序使用习惯，便于后续编码实现（本作业不做实名认证、即时聊天、地图定位等复杂功能）。
二、主要功能
| 功能 | 说明 |
|---|---|
| 浏览失物/招领信息 | 首页卡片流展示，可切换"寻物/招领"标签 |
| 发布寻物信息 | 填写物品名称、分类、丢失地点时间、描述、联系方式 |
| 发布招领信息 | 同上，标明"我捡到" |
| 搜索物品 | 按名称/地点关键词搜索，含热门搜索与历史记录 |
| 查看物品详情 | 展示物品信息、发布者联系方式 |
| 修改信息状态 | 已归还 / 进行中 / 暂停展示 |
| （扩展）消息通知 | 认领、浏览、状态变更提醒 |
| （扩展）我的发布 | 个人发布与认领记录统计 |
三、原型设计（工具：墨刀）
本次使用 墨刀 完成原型设计。原型共 12 个页面，覆盖作业要求的基础页面（首页、发布、搜索、详情、我的发布）并适当扩展，按底部导航分为三个 Tab：
-
首页 Tab：首页、分类浏览、搜索、信息详情、联系发布者、全部信息、消息通知
-
发布 Tab：发布信息、发布成功
-
我的 Tab：我的发布、修改状态、修改成功
页面截图如下：
（首页）
（分类浏览 / 搜索）
（信息详情 / 联系发布者）
（全部信息 / 消息通知）
（发布信息 / 发布成功）
（我的发布 / 修改状态 / 修改成功）
以上截图可直接在线查看交互效果：点击打开原型
四、使用流程图
流程一：查看信息 → 查看详情 → 联系发布者
进入首页 → 浏览/搜索信息 → 点击信息卡片 → 查看物品详情 → 联系发布者（复制/拨打）
流程二：发布信息 → 发布成功
点击"＋"发布 → 选择寻物/招领 → 填写物品信息 → 点击发布 → 发布成功 → 查看我的发布
流程三：搜索物品 → 查看搜索结果
首页搜索框 → 输入关键词 → 查看搜索结果 → 进入详情
五、结对过程
分工如下：
| 成员 | 主要工作 |
|---|---|
| 刘怀正（052404147） | 需求分析、功能清单、流程图设计、博客整合 |
| 丁维彤（102402123） | 墨刀原型绘制、页面布局、交互连线 |
我们首先一起讨论需求，确定"失主/拾获者"两类用户和核心功能范围；随后由刘怀正整理功能清单和流程图，丁维彤在此基础上用墨刀完成页面绘制与交互。过程中通过微信随时同步进展，多次核对页面跳转是否顺畅。
六、PSP 表格
| 任务 | 预估耗时（小时） | 实际耗时（小时） | 差异（小时） |
|---|---|---|---|
| 需求分析 | 1.5 | 1.0 | -0.5 |
| 原型设计（页面绘制） | 3.0 | 3.5 | +0.5 |
| 交互连线 | 1.0 | 1.5 | +0.5 |
| 流程图与功能整理 | 0.5 | 0.5 | 0 |
| 博客撰写 | 1.5 | 1.5 | 0 |
| 合计 | 7.5 | 8.0 | +0.5 |
七、个人总结（刘怀正）
本次结对作业中，我主要负责需求分析与整体设计。我最大的收获是理解了需求分析的价值：客户描述看似简单，但拆解出"失主/拾获者"两类用户、明确"信息分散且被淹没"的核心痛点后，功能范围一下就清晰了，避免了盲目堆功能。在梳理功能清单和流程图的过程中，我也体会到**"简单、可落地"比"花哨"更重要**——本次设计主动排除了聊天、地图等复杂功能，为后续编码实现留出了空间。遇到的困难主要是与搭档在设计细节上需要反复对齐，比如状态如何流转、页面如何分组，最终通过多次沟通和画线稿统一了认识。
