# 2026 秋软件工程个人作业（第三次）：失物有迹——校园失物招领小程序需求分析与原型设计

项目	内容
这个作业属于哪个课程	H202601软件工程与软件工程实践
这个作业要求在哪里	2026 秋软件工程个人作业（第三次）
学生	吴欣键（102401216）
原型名称	失物有迹
原型工具	墨刀（HTML 转墨刀）
原型在线链接	失物有迹｜校园失物招领原型

一、需求分析

校园卡、钥匙、雨伞、水杯和耳机等物品在校园中常被遗失。当前同学多在班级群、宿舍群或朋友圈发布信息，但消息分散、刷新快，失主和拾获者往往不在同一个群里。因此，本设计希望将寻物与招领线索集中展示，并通过关键词搜索和状态管理提高找回效率。

主要用户包含失主和拾获者。失主需要浏览近期招领、按名称搜索，并通过地点、时间和特征判断物品是否属于自己；没有线索时可发布寻物。拾获者需要用简短表单发布招领，并在归还后关闭信息。页面应优先呈现信息类型、地点、时间和当前状态。

“失物有迹”解决的是信息被群消息淹没、难以检索和过期信息持续干扰的问题。本次原型只实现浏览、发布、搜索、详情与状态更新五项核心能力；不加入实名认证、即时聊天、地图定位和后台管理。校园卡仅展示卡套或非敏感特征，完整信息留给线下核验，降低冒领风险。

二、主要功能与页面设计

1. 首页／线索墙：按时间展示寻物和招领卡片，可按“全部、寻物、招领”筛选；卡片直接显示类型、状态、地点和时间。
2. 发布信息：用户选择寻物或招领，填写物品名称、时间、地点、特征和联系方式。其中名称、时间、地点和联系方式为必填项。
3. 搜索：输入物品名称关键词后展示匹配结果；无结果时，引导用户发布寻物信息，而不是留下空白页面。
4. 信息详情：补充物品特征、交接建议和联系入口，并提醒失主先说出可核验信息。
5. 状态管理：发布者在物品找回或归还后，将信息标记为完成，减少无效联系。

原型包含首页、发布、搜索结果、详情和发布成功五个页面。蓝色作为主色，橙色区分寻物、绿色区分招领；状态标签放在卡片顶部，减少用户反复进入详情的次数。

三、原型界面截图

图 1 首页：集中展示校园寻物与招领线索，支持按信息类型浏览。

图 2 发布信息页：用户填写物品名称、时间、地点、特征和联系方式后发布寻物或招领信息。

图 3 搜索结果页：输入“校园卡”等关键词后，展示匹配线索并引导用户进入详情核对。

图 4 信息详情页：突出物品特征、拾取地点、当前状态和交接建议，帮助失主安全认领。

四、基本流程

查看信息：进入首页 → 浏览线索卡 → 查看详情 → 核对特征 → 联系发布者。

发布信息：进入发布页 → 选择寻物／招领 → 填写必填信息 → 确认发布 → 显示发布成功。

搜索物品：进入搜索页 → 输入关键词 → 查看搜索结果 → 打开详情并核对。

flowchart TD A[进入首页] --> B{浏览或搜索} B -->|浏览| C[点击信息卡片] B -->|搜索| D[输入物品关键词] D --> E[查看搜索结果] E --> C C --> F[查看详情与核对特征] F --> G[联系发布者] A --> H[进入发布页] H --> I[填写物品信息] I --> J[确认发布] J --> K[发布成功]

五、PSP 记录

PSP 阶段	预估耗时（小时）	实际耗时（小时）
阅读任务并分析需求	0.8	0.7
设计功能与流程	1.0	1.0
制作原型页面与交互	2.5	2.7
走查、修改与截图	0.8	0.7
整理博客	0.9	0.9
合计	6.0	6.0

六、个人总结

这次作业让我认识到，需求分析不是罗列“发布、搜索”等功能，而是先找到用户受阻的环节，再把它变成明确操作。只有物品名称不足以确认线索，所以卡片还需要地点、时间和状态；校园卡也不能公开完整信息，应在线下核验。制作原型时，我重点检查了首页到详情、发布到成功、搜索到详情三条路径。最难的是控制范围：聊天、定位虽然有用，却会显著增加后续实现难度。原型的价值不仅是界面好看，更是尽早发现流程断点。

发布前检查：插入四个页面截图。