2026秋软件工程结对作业

软件工程第三次结对作业——校园失物招领小程序

项目	内容
课程	202601 软件工程
作业要求	第三次结对作业
作业目标	完成校园失物招领小程序的需求分析、流程图和交互原型
结对成员	102400412 龚巍斌 / 102401111 郑瀚
原型工具	墨刀（Modao）
在线原型	寻物系统原型

一、需求分析

《构建之法》第 3 章提醒我们复盘实际成果；第 8 章强调从用户场景分析需求、确定功能优先级。我们先讨论“丢东西”和“捡到东西”两种情境，再确定页面，并在分工制作后互相走查。

1. 用户痛点

校园卡、钥匙和雨伞等物品经常遗失在食堂、教学楼或图书馆。假如同学在食堂捡到校园卡，只发在自己的班级群或朋友圈，失主未必看得到；即使双方在同一个群，信息也会随着新消息滚动而被覆盖。现有渠道分散，又难按物品名称回查，导致找物和归还都要反复询问、转发。我们希望把寻物与招领集中到同一入口，并用关键词缩短查找时间。

2. NABCD 需求分析

维度	分析
N（需求）	失主需要快速查到招领线索，拾主需要让失主看到消息；现有群聊分散，且旧消息难以回查。双方都需要一个集中的信息入口。
A（方案）	首页汇总寻物与招领信息，发布时记录名称、类别、时间、地点、特征和联系方式；用户可按关键词搜索、进入详情核对，并在物品找回后更新状态。
B（收益）	失主不必反复翻找多个群，拾主也不必重复转发。状态更新能让已解决的信息退出首页，减少无效联系。
C（竞争）	班级群和朋友圈发布方便，但覆盖范围取决于社交关系且消息易下沉；线下失物招领处可信，却需要到场询问。本方案提供可持续查看和搜索的线上补充渠道。
D（交付）	本次先交付墨刀在线原型、页面说明与流程图，供同学体验和反馈；下一次结对作业沿用这些页面和字段开展代码实现。

3. 主要用户及需求

用户	主要需求
失主	浏览或搜索招领信息；找不到时发布寻物信息；找回后更新状态
拾主	浏览寻物信息；发布招领信息；归还后更新状态
线索提供者	浏览相关启事，发现线索后转告当事同学

二、软件功能

• 浏览信息：首页展示最新启事，支持“全部、寻物、招领”筛选。
• 发布寻物或招领：选择类型，填写名称、类别、时间、地点、描述和联系方式；图片可选，必填项不完整时提示补充。
• 搜索与详情：按关键词检索，空结果给出提示；详情展示完整信息和联系方式。
• 管理发布：在“我的发布”查看记录，将已找回或已归还的物品更新为结束状态。

三、原型设计

1. 原型工具

我们用墨刀串联移动端页面并分享在线原型，方便双方检查页面跳转。设计时统一卡片、标签和按钮样式，重点走查浏览到详情、发布到成功、搜索到结果三条路径。另保留 HTML 总览和独立页面，以下截图来自独立页面。

2. 页面说明

原型包含首页、搜索页、发布页、信息详情页、发布成功页、我的发布页和状态更新页，共七个页面。用户可浏览与搜索启事、发布寻物或招领信息、查看联系方式，并管理自己发布的状态。界面采用浅蓝、浅绿配色和卡片布局；首页、搜索、发布、我的四个入口放在底部导航中。

首页：顶部提供搜索入口，以及“我丢了东西”“我捡到东西”两个发布入口。下方按最新时间展示信息卡片，可切换全部、寻物、招领；卡片显示物品名称、地点、时间和状态，点击后进入详情。

搜索页面：输入物品名称等关键词，或点击校园卡、钥匙、雨伞、耳机等常用词发起检索。页面显示匹配数量和结果卡片，点击结果可看详情；没有匹配内容时给出更换关键词的提示。

发布页面：先切换寻物或招领类型，再填写物品名称、类别、丢失或拾取时间、地点、特征描述和联系方式；图片为可选项。必填内容缺失时提示补充，填写完整后才能进入发布成功页。

信息详情页面：集中展示物品名称、类别、寻物或招领类型、当前状态、时间、地点和文字描述。用户先核对外观特征，再查看联系方式并联系发布者，避免只凭名称误认物品。

发布成功页面：用明确的成功提示确认提交结果，同时展示刚发布物品的名称与地点。用户可以返回首页核对新信息，也可以直接进入“我的发布”继续管理。

我的发布页面：汇总本人发布的寻物与招领信息，显示发布总数、进行中和已结束数量。用户可按状态筛选记录，并对单条信息查看详情、更新状态或删除。

状态更新页面：先显示物品名称和当前状态，再让发布者选择“已找到”“已归还”或保持原状态。确认结束后，该启事不再出现在首页的有效信息列表中。

四、基本使用流程

1. 典型场景：寻找失物

例如在图书馆丢失雨伞，失主先搜索“雨伞”。有招领信息时，进入详情核对时间、地点和特征，再联系发布者线下确认；没有结果时，发布寻物信息并留下联系方式，等待线索。找回后到“我的发布”标为已找到，避免继续接受联系。这一场景串起了搜索、详情、发布和状态维护。

2. 分项流程

浏览与两类信息发布的操作路径如下：

浏览信息 → 查看详情	发布寻物 → 发布成功	发布招领 → 发布成功
从首页浏览或筛选卡片，点击后查看物品详情与联系方式。	填写丢失时间、地点等必填信息；不完整时补充，提交后显示发布成功。	填写拾取时间、地点和物品特征；检查必填项后发布招领。

搜索、查看个人记录及更新状态的路径如下：

搜索物品 → 查看结果	我的发布 → 查看详情	更新物品状态
输入关键词并查看结果；找到相关信息后进入详情，无结果时调整关键词。	进入“我的发布”，选择一条寻物或招领记录查看详情。	物品找回或归还后，选择对应记录，修改为“已找到”或“已归还”。

五、PSP 表格

工作阶段	预估（小时）	实际（小时）	差值（小时）
阅读资料、讨论需求	0.7	0.6	-0.1
分析用户、确定功能	0.5	0.6	+0.1
绘制流程图	0.9	0.7	-0.2
制作原型页面	1.7	1.5	-0.2
联调与互相走查	0.6	0.7	+0.1
撰写、排版博客	0.6	0.4	-0.2
合计	5.0	4.5	-0.5

六、结对过程

我们两人分工如下：

• 龚巍斌（102400412）：负责首页、搜索页和详情页，串联查找信息的流程。
• 郑瀚（102401111）：负责发布页、发布成功页、我的发布页和状态更新页，串联发布与管理流程。

（1）讨论需求与功能范围：分析信息分散、易被覆盖和供需难匹配的问题，确定浏览、搜索、发布、详情与状态更新功能。

（2）梳理流程并确定分工：确定“先查找，找不到再发布”的顺序，再按查找与发布管理两条链路分工。

（3）调整页面与交互：走查初版，调整发布入口的醒目程度，以及“我的发布”的统计、筛选与按钮。

（4）按场景验收原型：按失主和拾主场景检查页面跳转与状态更新，确认主要路径连贯。

七、个人小结

大概做了什么：先跟同伴一起讨论了整体需求，确定功能范围后开始分工。我这边从发布页入手，把表单字段分成必填和选填两类，再往后做发布成功反馈页、个人发布记录页和状态更新页。做完初版后两人互相走查，根据反馈调整了发布入口的醒目程度和"我的发布"里的统计展示，最后按场景把整条流程跑通确认没有问题。

遇到什么困难：一是发布页字段设计上拿不准分寸，信息太少怕对不上号、太多又怕用户嫌烦，最后参考了几个现有失物招领平台的表单，定了必填加选填的组合；二是状态更新功能一开始想做得比较细，后来发现跟整体"简单清晰"的定位冲突，果断砍掉了多余选项，只保留"已找到"和"已归还"两个状态；三是初版原型里发布成功页只有一句"提交成功"，走查时被指出反馈太弱，后来补了跳转按钮和提示文字。

学会了什么：第一次正经用墨刀做移动端原型，熟悉了页面跳转、组件复用和弹窗提示这些基本操作；对原型设计的理解也从"把页面画出来"变成了"每一步都要想清楚用户为什么要点这里、点了之后去哪、如果操作失败怎么办"；另外PSP表让我第一次认真记录预估和实际耗时的差距，发现写博客比想象中快但联调走查比预估花时间。

体会：自己画原型的时候总觉得逻辑没问题，但别人一走查就能挑出你没注意到的细节——比如按钮不够显眼、空状态没处理、流程断了一截。结对最大的价值不是分工省力，而是有人帮你挑刺。下次写代码实现的时候，这次原型里确定的字段和流程应该能直接搬过去，不用再纠结一遍。