软件工程第三次作业

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

项目内容
这个作业属于哪个课程	202601 软件工程
这个作业要求在哪里	2026秋软件工程结对作业（第一次之需求分析和原型设计）
这个作业的目标	分析校园失物招领需求，制作能演示浏览、发布、搜索流程的原型
结对成员（学号、姓名）	292400336 吴涵彬；182400143 张宇天
本文提交人	182400143 张宇天
原型工具与在线展示	Pencil Project 3.1.1；打开七页在线原型
原型源文件	校园失物招领-Pencil原型.epgz，随提交材料提供

一、问题与目标用户

校园卡、钥匙、雨伞等失物消息分散在班级群和朋友圈，容易被新消息覆盖，失主未必看见拾取者发布的信息。方案面向失主、拾取者及线索提供者，目标是集中发布、浏览和搜索，并通过名称、地点等线索联系对方。

二、需求分析与功能取舍

从“教学楼丢卡”和“图书馆捡伞”两个场景出发，首版提供浏览、搜索、详情、发布寻物与招领，并在“我的发布”更新完成状态。失主可先搜索；无匹配时再发布寻物。拾取者发布招领时，需要说明拾取时间、地点及暂存情况，便于失主判断是否相关。

发布须填写名称、类别、日期、地点、特征和联系方式，照片选填；搜索覆盖名称、类别、地点，空关键词或无结果时给出提示。卡证类物品不公开完整学号或证件号，认领时核对未公开特征。已完成的信息保留状态，减少重复联系。

《构建之法》第3章关于个人能力度量的内容对应下面的PSP记录；第8章的需求获取与优先级方法帮助我们从用户任务确定首版功能，快速原型用于展示方案并准备后续反馈。结对协作还参考第4章。实名认证、即时聊天、地图定位和复杂后台暂不纳入，便于下一次作业按原型逐步实现。

三、七页原型与使用流程

原型有首页、搜索、搜索结果、发布信息、发布成功、信息详情和我的发布七页。首页卡片标明寻物或招领及当前状态，列表不直接显示联系方式；搜索结果可进入详情，详情提供联系入口及认领核对提醒。两类发布共用一张表单，填完必填项后进入独立成功页，“我的发布”提供状态更新入口。

浏览与搜索

发布与状态更新

三条主流程：首页 → 信息详情 → 联系发布者；搜索物品 → 搜索结果 → 信息详情；发布信息 → 必填检查 → 发布成功。发布者还可在“我的发布”将寻物标为“已找回”，或将招领标为“已归还”。走查时需检查空搜索、无结果、漏填地点、完成状态等情况。以上是线框原型，文字框与按钮只展示交互路径，不保存真实数据。

四、结对分工与过程

本次结对按下表分工，同时共同检查三条主流程是否连贯、详情是否泄露敏感信息，以及提交材料是否满足作业要求。

成员	主要负责	共同检查
吴涵彬（292400336）	整理用户场景、首版范围、博客文字与PSP	主流程、隐私提示、作业要求
张宇天（182400143）	整理页面结构与流程图，检查页面跳转和原型展示材料	主流程、页面易读性、作业要求

两张结对讨论截图记录了首页卡片信息、搜索结果、共用发布表单、校园卡认领核对和“我的发布”状态管理等议题。讨论形成的方案均已体现在上文原型中。

讨论从失物信息分散的问题出发，先确定首页和搜索入口，再检查发布与认领细节。两人还确定用“首页到详情、搜索到结果、发布到成功”三条路径走查页面衔接，重点检查无结果提示、必填字段和状态变化。

五、PSP记录（分钟）

以下耗时由两人根据待核稿确认，分别列出预估与实际，单位均为分钟。

张宇天

工作项	预估	实际
阅读教材、核对要求	40	45
用户场景与需求取舍	45	55
流程、页面讨论	55	65
原型制作与走查	145	170
写作与排版检查	65	75
合计	350	410

吴涵彬

工作项	预估	实际
阅读教材、核对要求	40	45
用户场景与需求取舍	55	65
流程、页面讨论	45	50
原型制作与走查	130	150
写作与排版检查	70	85
合计	340	395

六、个人总结

我在整理页面与流程时遇到的主要问题是：单个页面看起来完整，串起来却可能让用户卡住。例如搜索后需要结果页，发布后需要明确的成功反馈，找回或归还后也要更新状态。用“丢校园卡”和“捡雨伞”的任务逐步检查，比只看页面布局更容易发现遗漏。校园卡认领还涉及冒领风险，因此详情中加入核对未公开特征的提醒。这次作业让我认识到，原型要围绕用户任务设计，并用完整流程检验。下一次实现可先按七页原型和三条主流程拆任务，再用GitHub管理与检查改动。