2026秋软工第一次结对作业

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

这个作业属于哪个课程	2026秋软件工程（福州大学）
这个作业要求在哪里	2026秋软工第一次结对作业
这个作业的目标	校园失物招领小程序的需求分析与原型设计
结对成员	102401416 唐捷、102401414 许书凯
本篇作者	唐捷（102401416）
原型开发工具	墨刀（Modao），初版原型由墨刀 AI 生成后人工核对调整
原型在线链接	https://modao.cc/ai/design/spmukvqz0fp4xvig/6aba0f7bb767a80220066a3c

一、项目背景与问题定义

在校园里，校园卡、钥匙、水杯、雨伞、耳机、书籍等物品遗失很常见。目前大家主要靠班级群、宿舍群、朋友圈发布寻物或招领信息：信息分散在多个渠道，还会不断被新消息覆盖；捡到东西的同学和失主往往不在同一个群里，消息无法对应；物品已经归还，旧消息却没更新，又会造成重复联系。

“校园寻物站”小程序把寻物、招领信息集中到一个入口，支持按物品名称等关键词搜索，并维护信息状态，让同学们少翻群聊、更快找到线索。

二、用户与需求分析

用户	典型场景	核心需求
失主	在图书馆遗失水杯	搜索招领、发布寻物、找回后更新状态
拾获者	在食堂捡到钥匙	描述特征、留下联系方式、归还后标记完成
浏览者	浏览近期失物信息	快速查看、按名称搜索、提供线索

P0（必须）：浏览、发布寻物、发布招领、搜索、查看详情、修改状态。
P1（辅助）：类型筛选、图片选填、我的发布入口。
暂不做：即时聊天、地图定位、实名认证、后台管理——作业不要求这些功能，控制范围也便于第二次结对作业的代码实现。

隐私与安全：联系方式点击后查看，并附站外联系风险提示；图片选填，不展示完整证件号；认领前核对物品特征；线下交接建议选在图书馆、食堂等公共区域。

三、主要功能

• 浏览信息：按发布时间倒序展示，支持全部、寻物、招领筛选。
• 发布寻物：填写名称、丢失日期、地点、特征、联系方式，图片选填。
• 发布招领：同一表单，日期与地点标注为拾获信息。
• 搜索物品：按名称等关键词匹配结果，无结果时提示更换关键词。
• 查看详情：展示完整资料与联系方式入口，通过站外渠道沟通。
• 修改状态：寻物“寻找中→已找回”，招领“待认领→已归还”，仅本人可操作。

四、用户使用流程

流程1：查看信息 → 查看详情

进入首页 → 浏览信息卡片 → 点击信息 → 查看详情 → 查看联系方式

流程2：发布信息 → 发布成功

进入发布页 → 选择寻物/招领 → 填写资料 → 必填检查 → 发布成功
                                          ↓ 缺失
                                     保留内容并提示补填

流程3：搜索物品 → 查看搜索结果

输入「水杯」 → 点击搜索 → 查看结果 → 进入详情
                          ↓ 无结果
                    更换关键词或去发布

五、原型设计

原型采用墨刀制作，初版由墨刀 AI 生成后人工核对调整。画布为移动端 402×874，深绿主色 #0f7350 搭配白底卡片与浅灰底 #f6f8f7，底部导航为「首页 / 发布 / 我的发布」。数据为本地模拟（当前用户「我（林小满）」），不含登录、聊天、地图与后台。

页面	主要内容	对应流程
首页	搜索入口、全部/寻物/招领筛选、信息卡片、底部导航	流程1、3
发布信息页	寻物/招领类型切换、必填表单、校验提示	流程2
发布成功页	成功提示、查看详情、返回首页、我的发布	流程2
搜索页	关键词实时筛选、结果列表、空状态	流程3
信息详情页	特征、地点、日期、状态、查看联系方式	流程1、3
我的发布	本人信息列表、标记已找回/已归还	状态维护

三条演示链路与作业要求的三条基本流程一一对应：①查看信息→查看详情：首页卡片按 id 进入详情，展示名称、特征、地点、日期、状态与联系方式入口；②发布信息→发布成功：必填校验失败时保留已填内容并提示，成功后可查看详情、返回首页或去「我的发布」，新信息同步进入首页信息流；③搜索物品→查看搜索结果：搜索「水杯」实时命中「蓝色水杯」，无匹配时显示空状态与发布入口。示例数据含蓝色水杯（招领·图书馆二楼·待认领）、黑色雨伞（寻物·第一食堂·寻找中）、银色钥匙（招领·教学楼·待认领）等 5 条。

原型在线链接：https://modao.cc/ai/design/spmukvqz0fp4xvig/6aba0f7bb767a80220066a3c

六、《构建之法》第3章、第8章学习成果

第3章「软件工程师的成长」强调对工作进行量化估计与复盘改进（如 PSP），我们因此用 PSP 表格记录预估与实际耗时、对比偏差。第8章「需求分析」讲获取需求的步骤、需求优先级与 NABCD 等竞争性需求分析框架，我们据此先梳理用户场景与痛点、再确定功能并裁剪范围，避免“解决方案先行”。

七、PSP表格

单位：个人投入分钟。

阶段	预估耗时（分钟）	实际耗时（分钟）
阅读与任务规划	20	20
用户场景与需求分析	60	65
功能范围与流程图	50	60
页面结构讨论	30	30
原型结对制作	50	50
流程检查与修改	30	30
博客与截图整理	40	30
总结与提交检查	20	20
合计	300	305

八、结对过程记录

1. 需求讨论：唐捷梳理用户场景，许书凯核对信息字段是否充分。
2. 流程整理：共同确定浏览、发布、搜索三条主线，检查每条流程的返回入口。
3. 原型制作：许书凯负责页面与交互，唐捷对照需求检查，中途交换角色。
4. 检查复盘：推演漏填联系方式、搜索无结果、归还后状态变化等异常情况。

两人已提前熟悉 GitHub 基本操作，为第二次结对作业的代码协作做准备。

九、个人总结

唐捷（102401416）：本次作业我主要负责需求分析与功能边界。最大的收获是认识到需求分析要回答“功能如何解决问题”：名称搜索对应查找困难，状态更新对应信息过期。遇到的问题是对功能范围把握不准，聊天、地图虽方便但超出本次范围，反复讨论后才收敛到六项核心功能。后续实现时我会优先检查必填缺失、搜索无结果和状态变更等异常流程，而不是只走通正常流程。

许书凯（102401414）：本次作业我主要负责页面与交互设计。最大的收获是“界面要解释操作结果”：发布成功后要给出查看详情、返回首页等去向，搜索无结果也要给出空状态和出口，否则流程会中断。遇到的问题是页面状态一致性，同一信息在首页、详情、我的发布中的名称与状态必须一致，我先统一字段与状态规则再连接页面。后续实现应先保证流程完整，再优化视觉细节。

---

**参考资料：公开案例 Kalyn《寻物森林》、PMAI 校园失物招领原型参考 仅供设计参考，非本组成果。