2026秋软件工程个人作业（第三次）——校园失物招领小程序（结对设计）

2026秋软件工程个人作业（第三次）——校园失物招领小程序（结对设计）

项目	内容
这个作业属于哪个课程	H202601 软件工程与软件工程实践（福州大学·计算机与大数据学院）
这个作业要求在哪里	2026 秋软件工程个人作业（第三次）
结对成员	学号 032401135（沈文驰）、学号 052405110（陈佳慧）
本次作业目标	完成「校园失物招领小程序」的需求分析与原型设计
原型在线链接（墨刀）	https://modao.cc/proto/xjaLmUGZtlzinzv3TOmKL5/sharing?view_mode=read_only&screen=rbpVWLy9XNUGPgvBq
原型在线链接（HTML 可点击版）	https://zzzoe116.github.io/lost-found/
项目仓库	https://github.com/zzzoe116/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/zzzoe116/lost-found

另外附一份同款的 HTML 可点击原型作为补充：同一套界面用 HTML + CSS + JavaScript 实现（借助 Trae 辅助生成），在浏览器里打开可以直接输入关键词、填写表单，交互比图片热区更真实。

• HTML 版在线原型：https://zzzoe116.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

实际耗时比预估少一些，主要是因为需求分析阶段把「要哪些功能」先定死了，做原型时基本没有返工；超出预估的部分是原型制作——原以为只是画页面，实际把筛选、表单校验、状态切换等交互补齐花了更多时间。

六、个人总结

学号 052405110（陈佳慧）：
本次结对作业让我对软件工程的需求分析与原型设计有了完全不同的体会，也让我更清楚地看到自己的不足。

1. 需求分析：砍功能比加功能更难

以前总觉得写代码才是软件开发的“正事”，但这次我们花了大量时间争论“不做什么”。刚开始我和搭档分歧很大——我想加后台管理、实名认证、地图定位，觉得功能越多越像个“平台”；搭档则认为客户抱怨的只有三件事：信息分散在不同群里看不见、被新消息刷掉翻不到、只能靠聊天记录搜。争论到最后，我们按这三个困扰倒推功能：既然问题是“分散”，核心就应该是把寻物和招领放进同一个信息池。于是功能被砍到只剩浏览、发布、搜索、详情、状态修改五项。这件事让我明白：需求分析的本质是聚焦，而不是堆功能。前期把“不做什么”定死，后面反而几乎没有返工。

2. 原型设计：从踩坑到熟练

画流程图时，口头描述觉得顺理成章，一画图就发现漏洞。流程一最初漏了“物品归还后要改状态”这一环，否则信息会永远挂在列表里。用墨刀做原型更是第一次：热区坐标老对不准、发布页比其他页面高出一截、首页好几条信息却只做了一张详情页……这些问题都是通过和搭档互审才暴露出来的。我们约定每人把三条流程完整走一遍，专挑“点不通”和“点通了但不合理”的地方。改掉之后，体验顺畅了很多。从 PSP 表也能看出，我在原型制作上超时了 0.5 小时，说明对工具还不够熟练。

3. 结对编程：互相检查比单打独斗更靠谱

这次最大的收获是体会到结对的价值。一个人闷头做，容易陷入“自认为没问题”的盲区；两个人交换体验、互审修改，很多坑根本藏不住。比如发布成功页原本只有一句提示，是个死胡同，搭档一眼就看出问题，补上了“查看详情 / 继续发布 / 返回首页”三个出口。详情页默认显示联系方式也是搭档提醒后才改成“联系 TA”才展开，并加了防诈骗提示。这些细节靠一个人很难想全。

4. 不足与改进

• 工具熟练度不够：墨刀热区、页面高度设置等基础操作花了太多时间，下次应提前看教程或做小练习。
• 流程设计经验不足：画图时容易漏掉异常分支和状态清理，以后可以先用“用户旅程地图”把每一步想全再动手。
• 时间分配可以更合理：原型制作超时，说明预留时间偏少，下次应把交互细节单独列出来估时。

总体来说，这次作业让我真正把《构建之法》里“先搞清楚问题再动手”的思路用上了。今后我会更注意需求聚焦、工具熟练度和结对互审，争取下一次做得更快更好。