2026秋软件工程个人作业（第三次）
2026秋软件工程个人作业（第三次）——校园失物招领小程序（结对设计）
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | H202601 软件工程与软件工程实践（福州大学·计算机与大数据学院） |
| 这个作业要求在哪里 | 2026 秋软件工程个人作业（第三次） |
| 结对成员 | 学号 032401135（姓名 沈文驰）、学号 052405110（姓名 陈佳慧） |
| 本次作业目标 | 完成「校园失物招领小程序」的需求分析与原型设计 |
| 原型在线链接（墨刀） | https://modao.cc/proto/xjaLmUGZtlzinzv3TOmKL5/sharing?view_mode=read_only&screen=rbpVWLy9XNUGPgvBq |
| 原型在线链接（HTML 可点击版） | https://otonash1.github.io/lost-found/ |
| 项目仓库 | https://github.com/otonash1/lost-found |
一、需求分析
1.1 主要用户与使用场景
软件面向校园里的三类使用者：丢了东西的同学（失主）、捡到东西的同学（拾获者）、以及帮忙留意信息的其他同学。使用场景集中在教室、食堂、图书馆、宿舍区、运动场等场所，涉及的物品多为校园卡、钥匙、水杯、雨伞、耳机、书籍等。
| 用户 | 需求 |
|---|---|
| 失主 | 尽快把自己的寻物信息发出去，并能在别人发的招领信息里找到自己的东西 |
| 拾获者 | 用尽量少的文字把物品信息发出来，等失主联系自己 |
| 其他同学 | 随手翻一翻、搜一搜，看到认识的东西可以告知同学 |
1.2 软件要解决的问题
现在大家主要靠班级群、宿舍群、朋友圈发布寻物招领信息，问题是：信息分散在不同群里（跨群看不见）、会被新消息刷屏覆盖（翻不到）、只能靠关键词在聊天记录里翻找（搜不到）。例如在教学楼捡到一张校园卡，只能在班级群或朋友圈发一条招领，丢卡的同学未必看得到。
所以这个小程序的核心思路是：把寻物和招领信息集中到同一个信息池里，用统一的列表浏览、用物品关键词搜索，让「丢的人」和「捡到的人」能对上。
1.3 主要功能
| 功能 | 说明 |
|---|---|
| 浏览失物 / 招领信息 | 首页列表按时间倒序展示，可用「全部 / 寻物 / 招领」筛选 |
| 发布寻物信息 | 填写物品名称、类别、丢失地点与时间、联系方式 |
| 发布招领信息 | 填写物品名称、类别、拾获地点与时间、联系方式 |
| 搜索物品 | 按物品名称、类别、地点、描述做关键词匹配，并提示命中条数 |
| 查看物品详情 | 查看物品描述、地点时间、物品类别、发布者信息，并联系发布者 |
| 修改信息状态 | 在「我的发布」里把信息标记为「已完成」（物品已归还/已领回） |
二、原型设计
2.1 原型开发工具与在线链接
原型使用墨刀（https://modao.cc）制作：按微信小程序 375×720 的页面尺寸（发布页 375×940）设计了 7 个页面，每个可点击元素都加上了跳转热区，打开分享链接即可点击体验「浏览信息 → 查看详情」「发布信息 → 发布成功」「搜索物品 → 查看搜索结果」三条完整流程。
- 墨刀在线原型链接：https://modao.cc/proto/xjaLmUGZtlzinzv3TOmKL5/sharing?view_mode=read_only&screen=rbpVWLy9XNUGPgvBq
- 项目仓库：https://github.com/otonash1/lost-found
另外附一份同款的 HTML 可点击原型作为补充：同一套界面用 HTML + CSS + JavaScript 实现（借助 Trae 辅助生成），在浏览器里打开可以直接输入关键词、填写表单，交互比图片热区更真实。
- HTML 版在线原型：https://otonash1.github.io/lost-found/
2.2 页面清单
| 页面 | 主要内容 |
|---|---|
| 首页 | 顶部搜索栏、发布寻物 / 发布招领两个入口、信息列表与筛选 |
| 发布信息页 | 类型切换、物品名称、类别、地点、时间、补充描述、照片、联系方式 |
| 发布成功页 | 成功提示与「查看详情 / 继续发布 / 返回首页」三个去向 |
| 搜索页 | 搜索框、热门搜索与快捷筛选、搜索结果列表与二次筛选 |
| 信息详情页 | 物品描述、地点时间、物品类别、信息编号、发布者与联系方式 |
| 我的发布 | 我发布的信息，支持修改状态、编辑、删除 |
首页（浏览信息）与信息详情页：
发布信息页、发布成功页与搜索页：
「我的发布」页面：
2.3 界面与交互设计要点
- 两类信息一眼可分：寻物用橙色标签、招领用青色标签，列表卡片只放图标、名称、地点、时间和描述摘要，扫一眼就能判断要不要点进去；
- 列表页就能完成大部分判断：描述摘要做了截断，避免卡片高度参差不齐；
- 搜索粒度细：关键词会在名称、类别、地点、描述四个字段里匹配，「校园卡」可以同时搜出寻物和招领两条信息，正好体现"同一个池子"的价值；
- 隐私保护：详情页默认隐藏联系方式，需要点击「联系 TA」才展示，并在页面下方提示谨防冒领与诈骗；
- 发布有校验、成功有出口：必填项缺失时逐项提示，发布成功后给出「查看详情 / 继续发布 / 返回首页」三条路径，不让用户停在死胡同。
三、基本使用流程
流程一：查看信息 → 查看详情 → 联系发布者
流程二：发布信息 → 发布成功
流程三：搜索物品 → 查看搜索结果
三条流程的共同点是：任何一个页面最多两步就能回到首页或搜索，用户不会迷路。
另外，本次原型只保留核心功能，没有做后台管理、实名认证、即时聊天、地图定位等复杂功能：每一条信息就是一条记录（物品名称、类别、地点、时间、描述、联系方式、状态），列表、搜索、发布都围绕这一条记录展开，页面之间的跳转关系也只有上面三条主线，方便第二次结对作业直接用代码实现。
四、结对完成过程
分工上，两人都全程参与，但各有侧重：一人主要负责需求梳理、流程与交互设计，另一人主要负责原型搭建与截图输出，每个阶段结束后交换检查。
第一步：先把「要解决什么问题」吵清楚。 各自读完《构建之法》第 3、8 章和客户描述后碰头，一开始的分歧不小——一人想做成「全校园失物招领平台」，加后台管理、实名认证、地图定位；另一人认为一次作业做不完这些，也不该做，因为客户抱怨的只有三件事：信息分散在不同群里看不见、被新消息刷掉翻不到、只能靠聊天记录搜。争论的结果是按这三个困扰倒推：既然问题是「分散」，那核心就应该是把寻物和招领放进同一个信息池，让搜索和列表都能同时命中两类信息。功能因此被砍到只剩浏览、发布、搜索、详情、状态修改五项，后台管理、聊天、定位全部不做。这一步定死了「不做什么」，后面才没有返工。
第二步：把口头流程画成能检查的图。 两个人对着白板口述流程时都觉得没问题，画成图才发现有漏洞。比如流程一最初画成了「点开卡片 → 联系发布者」，漏了「怎么判断这东西是不是我的」这一环，补上判断分支后，又发现结尾缺了「物品归还后把状态改成已完成」，否则信息会一直挂在列表里没人清理。三条流程都改完，才用 Mermaid 落成正式图（见第三节）。
第三步：在墨刀里把流程图变成能点的原型。 先按五个页面拉骨架，铺的时候发现问题：搜索是独立入口，搜完之后不能再退回首页列表里翻，结果必须有自己的承载页，于是拆成 7 个页面。做交互时又踩了两个坑：一是详情页只做了一张，但首页有雨伞、校园卡好几条信息，点校园卡卡片进去看到的却是雨伞的详情，一眼就穿帮，只能再补一张校园卡招领的详情页；二是发布页表单长，比其他页面高，页面高度得单独设成 940，否则底部按钮会被截掉。热区坐标也是返工最多的地方——图没贴到 (0,0) 时，热区就会整体偏移。
第四步：交换体验、互审修改。 两人约定各自把三条流程完整走一遍，专门挑「点不通」和「点通了但不合理」的地方。改掉的问题包括：发布成功页原本只有一句提示，是个死胡同，补上了「查看详情 / 继续发布 / 返回首页」三个出口；详情页原本直接显示联系方式，改成默认隐藏、点「联系 TA」才展开，并在下方提示谨防冒领诈骗；列表卡片的描述文字做了截断，避免长短不一导致卡片高度参差。
五、PSP 表格
| 任务 | 预估耗时（小时） | 实际耗时（小时） | 差异（小时） |
|---|---|---|---|
| 阅读作业要求与《构建之法》相关章节 | 0.5 | 0.4 | -0.1 |
| 需求分析（用户角色、功能列表） | 1.0 | 0.8 | -0.2 |
| 页面结构与交互流程设计 | 1.5 | 1.2 | -0.3 |
| 原型制作（墨刀 7 个页面 + 热区） | 2.0 | 2.5 | +0.5 |
| 流程图绘制（3 张） | 1.0 | 0.6 | -0.4 |
| 结对讨论与互审修改 | 1.0 | 0.8 | -0.2 |
| 原型截图与博客撰写 | 1.0 | 1.0 | 0 |
| 合计 | 8.0 | 7.3 | -0.7 |
实际耗时比预估少一些，主要是因为需求分析阶段把「要哪些功能」先定死了，做原型时基本没有返工；超出预估的部分是原型制作——原以为只是画页面，实际把筛选、表单校验、状态切换等交互补齐花了更多时间。
六、个人总结
学号 032401135（姓名 沈文驰）：
这次作业做完，我最大的感受是：做需求的时候，少加功能反而更难。我一开始特别自然地就想往里塞东西——后台管理、实名认证、地图定位，总觉得功能多才拿得出手。结果跟搭档把客户抱怨的三件事摊开一对（信息散在各个群里看不见、一发新消息就被刷没了、想找只能翻聊天记录），发现我加的那些功能一个都不解决这些问题，纯属想当然。最后砍到只剩浏览、发布、搜索、详情、改状态这五样，后面做原型基本没返工。这个取舍算是这次最大的收获。
动手这块主要是我来搭原型。用墨刀之前我真以为做原型就是画几张图，上手才知道交互得一条条试。比如详情页我只做了一张，结果首页好几条信息点进去看到的都是同一件东西，一眼就露馅，只好再补一张校园卡的详情页；发布页的表单比别的页面长，页面高度不单独改成 940，底下那个按钮直接就被裁没了；热区坐标还得跟图片卡得死死的，图没贴到左上角，热区就整体偏。这些问题都是我自己一遍遍点流程点出来的，真不是画完就完事。
两个人做比一个人做确实慢，像画流程图那会儿，我俩对着说都觉得没问题，一画出来才发现漏了「怎么判断这东西是不是我的」这一步。但也正是这个慢，让坑在写代码之前就露出来了，不至于拖到第二次结对作业才返工，想想还挺值。
当然也有做得糙的地方。墨刀的热区和交互我玩得还比较浅，「已完成」这种状态切换我就只摆了个静态样子，没做出动态效果；PSP 里原型制作实际比预估多花了半小时，说明我对「做原型」到底要多久，估计得还是太乐观了。
浙公网安备 33010602011771号