软件工程第三次作业-第一次结对作业

结对作业（第一次）：校园失物招领小程序 —— 需求分析与原型设计

项目	内容
这个作业属于哪个课程	H202601软件工程与软件工程实践
这个作业要求在哪里	2026秋软件工程个人作业(第三次)
这个作业的目标	是用一个贴近校园生活的小场景，让你在不写代码的情况下，练习如何把模糊的现实问题，转化为清晰、可沟通、可实现、可协作的软件方案。
学号	姓名
102402113	吴佳仪
102402114	谢慧彬
102402115	张润

---

一、阅读《构建之法》的学习成果

阅读《构建之法》第3章后，我们认识到结对合作的关键在于“驾驶员”和“领航员”的角色轮换——编码者专注实现，审核者专注纠错。本次作业虽然不写代码，但我们三人也套用了这个思路：一人主要负责需求分析与流程图，一人主要负责原型页面制作，一人主要负责原型评审与文档整理；每做完一个页面就交叉检查，确保功能确实必要、界面容易看懂。

第8章帮我们理清了需求分析的方法。书中“秋千图”的比喻让我们印象很深：用户想要的、团队理解的、最后做出来的，往往对不上号，需求分析就是为了缩短这条传递链上的损耗。我们据此用NABCD模型分析了本小程序——N（需求）是群聊信息太分散、没法搜索；A（做法）是做一个能集中发布和搜索的小程序；B（好处）是提高失物归还效率；C（竞争）是相比群聊，优势在于“集中”和“可搜索”；D（推广）是先在本班级试用。

二、问题：校园失物信息为什么失效

校园里丢东西很常见，丢了之后大家的第一反应是发到班级群、宿舍群或朋友圈。但这种方式毛病明显：信息分散，十几个群各发各的；容易被淹没，一条信息半小时就被聊天记录顶没了；供需不对称，在教学楼捡到校园卡的同学只能发在自己班群，失主很可能不在。结果是捡到的人在等、丢的人在找，两边在同一校园却碰不上。

三、用户与需求：失主和拾得者要什么

目标用户很集中：在校学生，分失主和拾得者两类。两者诉求相反，但要做的是同一件事：找到对得上的那条信息，再联系对方。由此得出四个核心需求：看得到、发得快（一两分钟发完）、搜得到（记得物品名就能搜）、联系得上（看完详情能加到人）。

不做的范围同样明确：后台管理、实名认证、站内聊天、地图定位都不做。尤其是聊天——双方认识后自然会在微信里沟通，硬做聊天反而要求用户在陌生系统重建社交关系。

四、方案与功能

一句话概括：把散落在各个群聊里、转瞬即逝的失物信息，集中到一个可分类、可搜索的入口。

主要功能：

• 浏览与筛选：首页信息流可按"全部 / 寻物 / 招领"三个标签筛选，按"最新发布 / 失物较多"排序；
• 发布信息：填写类型（寻物/招领）、物品名称、物品分类（证件卡类/钥匙/雨伞/水杯/耳机/图书）、地点与时间、详细描述、联系方式（仅详情页可见），可上传物品照片；必填项为空时红框提示校验失败；
• 搜索物品：支持搜索历史与热门搜索，结果按关键词高亮，无结果时给出空状态提示；
• 查看详情与联系：展示地点、时间与物品描述，附"防冒领"温馨提示，可收藏、分享、一键"联系 TA"；
• 我的发布：统计"我发布的 / 已解决 / 我的收藏"，可筛选查看，标记"已解决"后自动下架。

五、原型设计

小程序取名 「拾回」，取"失而复得"之意，主色用绿色象征希望与归还。

原型工具选用墨刀（国内在线原型设计工具，免费注册、国内直连、无需安装），把页面图导入后逐个加上点击热区，即可在线点击演示；分享链接设为公开后，查看者无需注册账号。

🔗 原型在线链接：[【墨刀分享链接】](https://modao.cc/proto/TmD18VeOtm1ydlK5lvtWi8/sharing?view_mode=device&screen=rbpVWQtAfbSClevVI&canvasId=rcVWQxO9VWQxTCpuvIBdZp #未命名原型副本-分享)

原型共 12 个页面：7 个主页面 + 5 个状态/筛选变体，覆盖三条主干流程与关键边界情况。

• 7 个主页面：首页、发布信息、发布成功、搜索页、搜索结果、信息详情、我的发布；
• 5 个变体：搜索无结果（空状态）、发布校验失败、信息详情（寻物）、首页（寻物筛选）、首页（招领筛选）。

流程图

原型总览

以下是选取的两个功能展示

功能一：个人发布丢寻信息

功能二：搜索页面，对于搜寻结果进行边界处理

页面描述
首先分为如下三个页面
首页、寻物、招领

然后是发布信息、发布信息——校验失败、发布成功页面、个人发布主页

搜索页搜索成功页面搜索结果—无结果

最后是信息详情—寻物页。这里也考虑了边界情况，可能物品并不存在

六、基本使用流程

三条主干流程：

1. 查看信息 → 查看详情：首页 → 信息详情 → 联系发布者；
2. 发布信息 → 发布成功：填写表单 → 立即发布 → 发布成功 → 我的发布；
3. 搜索物品 → 查看搜索结果：输入关键词 → 结果列表（关键词高亮）→ 详情。

除主干外，原型还覆盖了几类关键边界情况：

• 筛选切换：首页在"全部 / 寻物 / 招领"间切换，列表随之过滤；
• 发布校验失败：物品名称、联系方式等必填项为空时，输入框红框并提示"请填写××"；
• 搜索无结果：搜不到时展示空状态，引导"换个关键词试试"。

流程上还有一条闭环：发布者可将信息标记为"已解决"，标记后自动下架，避免已归还的物品继续占用别人的注意力。

七、结对过程

我们讨论了四次。第一次拆解问题，各自写下"最难受的一点"再合并，两个角度最后归一为"供需不对称"。第二次确定功能与页面，最大分歧是"联系发布者"要不要做站内留言，讨论后采纳队友意见改为展示微信号。

第三次原型评审，我们发现原型没有考虑“特殊状态”搜索没结果、首页没数据的时候，页面是空的，于是补充了无结果页面。
一部分讨论过程

后台制作原型过程

八、PSP 表格

PSP 阶段	预估(分钟)	实际(分钟)
计划 Planning	20	25
需求分析 Analysis	60	75
设计 Design	90	105
原型制作 Prototype	120	150
文档与博客	110	120
评审 Review	30	35
合计	430	510

超时主要集中在需求分析与原型制作。需求分析阶段，我们三人起初只依据客户描述列出 3 个痛点，经过进一步讨论和补充访谈后，才意识到“信息格式不统一”同样关键，反复对齐增加了不少耗时；原型制作阶段，三人分头负责不同页面，前期没有统一颜色、字号和圆角等规范，导致 7 个页面风格不一致，最后不得不返工调整。后来我们先花时间确定设计规范再分工，效率才明显提升。

九、个人总结

本次结对作业中，我主要负责需求分析和流程图绘制。起初我以为把客户描述转成功能列表就行，但真正动手才发现没那么简单。比如丢东西和捡东西的同学需求并不一样，不能混在一起写。画流程图时我也走过弯路，一开始想把每个页面关系都画清楚，结果越画越乱。后来和队友商量，只保留查看、发布、搜索三条主流程，图才清爽起来。这次作业让我明白，需求分析不是照抄客户的话，而是要把问题整理成清楚的解决路径，也让我体会到和队友反复沟通的重要性。。