2026秋软件工程结对作业（第一次之需求分析和原型设计）：校园失物招领小程序原型

成员：李嘉星（102401128）、李莹莹（102401104）

问题与需求

群聊里的寻物、招领消息分散且容易被覆盖，失主未必能看到拾获者所在群的消息。我们面向失主、拾获者和发布者，设计集中浏览、发布、搜索及更新状态的入口。需求依据题目场景和李嘉星寻找遗失笔盒约两周的经历，做正式访谈了解大三同学描述大二时找寻华为手写笔时的难点。

参考《构建之法》第 8 章的需求获取、分析与验证方法，我们列出用户任务并确定优先级：浏览、分类、搜索、详情和寻物/招领发布为 P0；状态更新为 P1。聊天、地图、实名认证和后台不纳入本次原型。

流程与原型

我们用 Figma Make 制作可点击原型。浏览流程为“首页浏览或搜索→详情→查看联系方式”；发布流程为“填写信息→点击发布→校验必填项→发布成功→管理状态”，缺项时提示补填。发布需填写物品、地点、日期、时间和联系方式，描述、图片可选。演示物品为虚构数据，不展示校园卡卡主姓名或卡号。
图 1：主要使用流程。

在线预览：拾见原型（Figma Make）。原型以类型、状态标签和统一卡片呈现信息；搜索按物品名称或描述匹配关键词。可从首页体验浏览到详情、发布到成功、搜索到结果三条流程。登录与数据变更仅用于原型演示。

首页	搜索结果

信息详情	发布信息

发布成功	我的发布

走查与修改

组内走查了搜索“耳机”→详情→查看联系方式、无结果后换词、漏填提示→发布成功→更新状态。第一轮发现卡片信息不够直观，便补上缩略图，分开标注类型与状态，并调整日期和联系方式提示。复测时，从详情返回仍保留搜索词；雨伞改为“已找回”后，首页也同步更新。

一位组外同学通过Figma分享操作原型后问：“已找回的话搜索的时候放到底下或者直接删去？”我们决定保留历史记录，让进行中的信息排前面、已结束的排后面，并淡化后者。复测首页及“东3”搜索，已找回的雨伞均排在进行中信息后。后续实现计划让已结束信息在状态更新 24 小时后从公开列表隐藏，“我的发布”仍保留；当前原型只演示排序。

结对过程与 PSP

读完《构建之法》第 3 章后，我们在合作中注意把问题放到具体页面上讨论。李嘉星整理需求、流程图和原型，检查搜索到详情的操作；李莹莹检查发布到状态更新的操作，并提出页面建议。两人讨论后，把联系方式放在详情页，点击后再展示；地点和日期则放在卡片下方，方便浏览时查看。

图 2：讨论用户任务与功能范围。

图 3：核对流程图、页面与演示登录。

图 4：讨论联系方式的隐私边界。

图 5：调整列表卡片的信息层级。

PSP 单位为分钟，实际耗时已由两人核实。最初每人估了 645 分钟，没有充分考虑 AI 对原型制作和文稿整理的帮助。做完后回看，我们认为下次类似作业可先按每人 300 分钟安排，给讨论、修改和检查留出时间。表中列的是这次复盘后的修订估算。

阶段	原预估/人	李嘉星实际	李莹莹实际
作业要求梳理	45	20	20
需求素材与访谈提纲	60	8	10
需求分析和优先级	60	10	10
流程图与低保真线框	60	10	5
高保真原型与交互	180	35	30
内部走查与记录	60	10	15
修改与复核	60	15	20
博客草稿与流程图整理	90	15	10
链接与提交前检查	30	10	10
合计	645	133	130

个人总结

李莹莹：这次我主要检查发布信息和修改状态的流程，也和搭档讨论了页面上的提示。我比较在意的是，用户发完信息后，能不能知道去哪里查看和修改。所以检查时，我从填写信息开始，一直操作到“我的发布”里更新状态，也试了漏填内容时会有什么提示。这样一步步试下来，比单独看截图更容易发现不清楚的地方。