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

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

问题与需求

群聊里的寻物、招领消息比较分散，消息一多就容易被刷走。李嘉星曾花了约两周寻找遗失的笔盒，我们也访谈了一名大三同学，了解他大二时寻找华为手写笔的经历。结合这些经历，我们希望同学能先搜到可能匹配的物品，再看描述、联系发布者核对。

对失主来说，搜索和详情页能帮助他们查找物品，核对时间、地点和特征；对拾获者来说，招领表单方便他们说明捡到了什么、留下联系方式。物品找回或归还后，发布者可以在“我的发布”中更新状态，减少重复联系。

参考《构建之法》第 8 章，我们先确定最需要的功能：浏览、搜索、查看详情和发布信息，再补上状态修改。聊天、地图和后台管理暂时不做。

流程与原型

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

图 1：主要使用流程。

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

首页	搜索结果

信息详情	发布信息

发布成功	我的发布

走查与修改

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

一位组外同学操作原型后问：“已找回的话搜索的时候放到底下或者直接删去？”我们决定保留历史记录，让进行中的信息排前面、已结束的排后面，并淡化后者。复测首页，已找回的雨伞排在进行中信息后。后续正式开发的时候，公开区域将设置24小时课件，我的页面则永久保留。

结对过程与 PSP

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

图 2：讨论同学需要什么、这次要做哪些功能。

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

图 4：讨论联系方式应该怎样展示。

图 5：调整卡片上图片、地点和日期的位置。

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

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

个人总结

李嘉星：这次我主要整理需求、画流程图和制作原型。一开始我比较关注页面是否齐全、按钮能不能点等等，对物品找回后该怎么展示考虑得不多。后来有同学问，已找回的信息是不是应该删掉，我才发现这个问题还没想清楚。讨论后，我们决定保留记录，但把已结束的信息放到后面。这次让我觉得，请别人实际操作一遍很有必要，自己反复看，还是容易漏掉一些问题。