软件工程第一次结对作业

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

项目	内容
这个作业要求在哪	2026 秋软件工程个人作业（第三次）
这个作业属于哪个课程	H202601 软件工程与软件工程实践
原型设计工具	Figma
设计主题	校园失物招领小程序
结对成员	102402141 叶思铖；102402142 叶腾骏
原型在线链接	校园失物招领原型

一、阅读《构建之法》的收获

第 3 章让我明白，结对不是各做各的——两人得持续交流，才能及时发现遗漏。第 8 章更直接：需求分析要从用户的实际困难出发，先弄清用户是谁、遇到什么问题，再决定做什么；原型是拿来验证流程的，不是拿来好看的。

二、用户与需求分析

校园里丢校园卡、钥匙、水杯、雨伞是常事，目前主要靠班级群、宿舍群、朋友圈发布，问题是群与群之间不互通、消息很快被刷走、格式不统一、没有搜索入口。

归结起来是四类用户：

用户角色	主要需求	对应痛点
丢失物品的学生	发布寻物、搜索招领信息	信息分散，翻不到
捡到物品的学生	发布招领，让失主看到	只能发在自己群里
普通浏览者	浏览信息、帮忙转达	没有统一入口
信息发布者	更新物品状态	找回后信息仍被误认为有效

三、主要功能

功能	优先级
浏览寻物／招领信息	P0
按"寻物／全部／招领"分类筛选	P0
按物品名称或地点搜索	P0
发布寻物 / 发布招领	P0
查看信息详情与联系方式	P0
管理个人发布、更新物品状态	P0
上传物品图片	P1

寻物和招领共用一套表单，只改文案（"丢失"与"拾取"）；状态上寻物初始为"寻找中"，招领初始为"待认领"。即时聊天、地图定位、消息推送和后台审核本次不做，先把主流程做扎实，也便于后续实现。

四、用户使用流程

进入首页可以浏览或搜索信息，点卡片看详情和联系方式；点底部"发布"选择寻物或招领，填完提交，系统检查必填项后完成发布；在"我的"里能查看、编辑自己的发布，或把状态改成"已找回／已归还"。

五、原型设计

原型用 Figma 制作，共 7 个页面：首页、搜索结果、发布类型、发布寻物、发布招领、信息详情、个人主页。发布寻物和招领共用一套表单结构，字段只区分"丢失"与"拾取"。

原型可以演示三条基本流程：查看信息 → 查看详情，发布信息 → 发布成功，搜索物品 → 查看搜索结果。

六、结对过程

我们先把客户描述逐条拆成"用户—场景—痛点"，定下要做的页面范围（要求 4 个，我们加到 7 个）；再在白纸上从首页出发梳理流程，把"发布成功后回首页还是进详情页"这类分歧当场定下来。

原型第一版做出来自己都觉得太素——白底加表格，伙伴说"画出来像老年模式一样"，商量后加了柔和的图片作为模块底图；最后按需求逐条核对，发现"发布招领"页字段还写着"丢失时间／地点"，改成了"拾取"。

七、PSP 时间记录

阶段	预估/min	实际/min
阅读作业要求和教材	60	50
需求分析	60	60
页面规划和流程图	60	60
Figma 原型制作	180	240
原型检查与修改	30	30
博客整理	30	30
合计	420	470

八、个人总结

102402142 叶腾骏

这次结对最大的收获是一个人看不出自己的问题。伙伴做完第一版原型觉得还行，发给我看却觉得太素，像没上色的线稿；加了柔和图片做底图之后才像样。
在制作过程中，还遇到了原型和需求容易脱节等问题，对着需求逐条核对，才发现"发布招领"页的字段还写着"丢失时间／地点"，是从发布寻物页复制时忘了改。我也体会到了在原型阶段发现问题，远比写完代码再发现便宜得多。