软工第三次作业

校园失物招领小程序 —— 需求分析与原型设计

结对成员：学号 102401510　姓名 林富强
作业：2026 秋 软件工程 个人作业（第三次）· 结对合作
原型工具：HTML + CSS + JavaScript 手写高保真原型，GitHub Pages 在线发布
在线体验：https://chirp77.github.io/lost-found/　源码仓库：https://github.com/chirp77/lost-found

---

一、我们要解决什么问题

校园里丢东西是高频事件：校园卡、钥匙、水杯、雨伞、耳机、课本。目前大家习惯在班级群、宿舍群、朋友圈各发一遍，这套做法有三个绕不开的毛病：

1. 信息分散——捡到校园卡的同学，和丢了校园卡的同学，很可能根本不在同一个群里。
2. 信息被淹没——群聊每天几百条消息，一条寻物信息几小时后就被顶得看不见了。
3. 信息无法检索——想知道"有没有人捡到一把黑色雨伞"，只能人工翻聊天记录。

这个软件要做的，是把"在群聊里碰运气"变成"一个集中的公告板 + 一个搜索框"，只追求三件事：发得快、搜得到、联系得上。

二、用户角色与需求分析

用户角色	典型场景	核心诉求
失主	在图书馆自习，回宿舍后发现耳机少了一只	三步之内发出寻物信息；能搜到别人发的招领信息
拾得者	在三教 302 教室捡到一张校园卡	发布流程尽量短；不必暴露手机号；东西尽快被领走
顺路浏览者	睡前随手刷一刷	一眼看清是寻物还是招领、在哪捡的、什么时候

据此我们划定了本期边界：做集中发布、分类浏览、关键词搜索、查看详情、展示联系方式、标记归还状态；不做即时聊天、地图定位、实名认证、后台管理。砍掉后四项，是因为它们显著抬高实现成本，却对"让东西回到主人手里"帮助有限——留一个微信号比做聊天系统直接得多，也为第二次结对作业的代码实现留出余地。

三、主要功能清单

编号	功能	说明
F1	浏览失物与招领信息	首页按"全部 / 寻物 / 招领"筛选，卡片展示分类图标、标题、地点、时间
F2	分类快捷入口	校园卡、钥匙、水杯、雨伞、耳机、书籍等，点击直接跳转搜索
F3	发布寻物信息	填名称、分类、丢失地点、时间、描述、联系方式
F4	发布招领信息	表单项自动切换为"拾获地点 / 拾获时间"
F5	关键词搜索	在标题、分类、地点、描述中匹配，命中词高亮
F6	查看物品详情	大图、状态标签、地点时间、详细描述、发布者、安全提示
F7	联系发布者	底部"联系 TA"唤起联系卡片，一键复制联系方式
F8	修改信息状态	在"我的发布"中标记为"寻找中 / 已归还"
F9	我的发布管理	按"全部 / 我丢的 / 我捡的"查看自己发布的信息

四、使用流程

整体流程是"进入首页 → 浏览或搜索 → 查看详情 → 联系发布者"：

flowchart TD A[打开小程序] --> B[首页信息流] B --> C{找到相关物品?} C -- 没有 --> D[发布寻物信息] D --> E[填写物品信息] E --> F[点击发布] F --> G[发布成功] G --> B C -- 有 --> H[进入物品详情] H --> I[查看联系方式] I --> J[线下联系、当面归还] J --> K[回到我的发布] K --> L[把状态改为已归还]

发布流程单独展开：

flowchart LR A[点击底部发布按钮] --> B{我丢了 / 我捡到} B --> C[上传照片] C --> D[填写名称与分类] D --> E[填写地点与时间] E --> F[填写描述与联系方式] F --> G{校验是否通过} G -- 不通过 --> H[高亮缺失项并定位] H --> F G -- 通过 --> I[发布成功页] I --> J[查看我的发布]

五、原型页面说明

原型共 6 个页面，覆盖作业要求的全部页面，并额外增加了"我的发布"。

页面	关键元素
首页	顶部搜索入口、在列信息数与已归还数、8 个分类入口、全部/寻物/招领切换、信息卡片流
搜索页	搜索框、热门搜索词、搜索历史（可清空）、结果统计、寻物/招领二次筛选、关键词高亮、空结果引导
详情页	物品大图与类型标签、当前状态、分类/地点/时间信息行、详细描述、发布者卡片、安全提示、底部"收藏 + 联系 TA"
发布页	"我丢了 / 我捡到"分段切换、图片上传（最多 3 张）、名称、分类、地点、时间、描述（带字数统计）、联系方式、必填校验
发布成功页	成功动画、信息预览卡片、"查看我的发布 / 返回首页"两个出口、"找回后记得改状态"提示
我的发布	用户信息与统计、"全部 / 我丢的 / 我捡的"筛选、卡片右上角"改状态"入口

六、原型可演示的三条流程

1. 查看信息 → 查看详情：首页点任意卡片进详情 → 点"联系 TA"唤起联系方式弹层 → 复制联系方式。
2. 发布信息 → 发布成功：点底部"+" → 选"我丢了东西 / 我捡到东西" → 填写信息 → 点"发布" → 成功动画 → 在"我的发布"中可见。
3. 搜索物品 → 查看搜索结果：首页点搜索框 → 输入"校园卡"（或点热门词）→ 实时返回结果并高亮关键词 → 点结果进详情页。

七、PSP 表格

| PSP 阶段 | 预估耗时（分钟） | 实际耗时（分钟） |
| 计划 |
| 需求理解 | 20 |20 |
| 开发
| 用户与需求分析 | 40 |40 |
| 功能清单与流程设计 | 35 | 30|
| 原型页面设计 | 60 |55 |
| 原型交互实现 | 120 | 125|
| 联调与走查 | 30 |30 |
| 报告 |
| 博客撰写 | 50 |50 |
| 截图与排版 | 20 |25 |
| 个人总结 | 20 |25 |
| 合计 | 395 | 395|

九、个人总结

这次最大的收获是意识到"不做"比"做"更难，也更值钱。我最初列功能清单时把聊天、地图、实名认证都写了进去，觉得功能越多越完整。搭档反问："如果只保留三个，你留哪三个？"删到只剩发布、浏览、搜索之后，流程反而一下子清楚了——需求分析的核心不是罗列，而是判断什么不该做。

遇到的问题主要是页面间的状态没想清楚。第一版原型里，从搜索结果点进详情页，返回后关键词就丢了。后来把"当前关键词"单独存下来、返回时再恢复才解决。这让我第一次具体理解了"状态"——它不是抽象概念，而是用户实实在在会遇到的麻烦。

发布页和搜索页，最深的体会是表单的容错设计比表单本身重要得多。我最初是点"发布"后统一校验、把所有错误一次性列出来，搭档试用的第一句话是"我知道错了，但不知道错在哪"。于是改成：哪一项没填就高亮哪一项、滚动到那一项并用一句话提示。改动不大，体验完全不同。

另一个问题是搜索范围。我一开始只匹配标题，搜"图书馆"什么都搜不到——因为它是地点不是标题。后来扩大到"标题 + 分类 + 地点 + 描述"四个字段，命中率明显提高，再给命中词加高亮，用户就能一眼看到这条为什么会被搜出来。