软工第一次结对作业

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

**学号：102401404　　姓名：孟维涛
**学号：102401418　　姓名：王宇航
课程：软件工程　　作业类型：结对作业（2 人）

---

一、选题与背景

校园里丢东西太常见：校园卡、钥匙、水杯、雨伞、耳机、书本。现在大家习惯在班级群、宿舍群、朋友圈发消息，但信息分散、一刷就沉——捡到校园卡的同学发在自己班上，丢卡的同学却看不到。我们想给全校的寻物与招领信息一个集中入口：能发、能搜、能看详情，让丢的人和捡的人在同一个页面遇上。

---

二、主要用户与需求分析

《构建之法》第 8 章强调需求分析要从典型用户和典型场景出发。我们按身份把用户分为三类：

典型用户	主要需求	使用频率
失主（学生）	发布寻物信息、搜索物品、查看详情、联系拾得者	偶发，但很着急
拾得者（学生）	发布招领信息、被失主找到、完成归还	偶发
楼管 / 值班室老师（扩展）	代收物品并登记存放位置	较频繁

核心用户是学生，而且同一个人会以两种身份出现：今天丢了耳机是失主，明天捡到校园卡就是拾得者。所以首页必须同时容纳寻物和招领，用标签区分。

典型场景 A：同学在教学楼丢了耳机，搜索「耳机」后翻到一条招领信息，点进详情核对特征，联系发布者约在值班室取回。

典型场景 B：同学在图书馆捡到校园卡，点「发布」并选择「发布招领」，拍照、选分类、填地点，一分钟完成发布。

要解决的问题：把分散在群聊里的信息集中成可搜索的列表，降低双方互相找到的成本。

---

三、用 NABCD 模型梳理需求

• N（需求）：校园失物信息分散、易被刷屏、无法检索，失主与拾得者难以互相发现。
• A（做法）：用小程序把「发布—搜索—详情—联系」串成一条线。
• B（好处）：失主从「翻十几个群」变成「搜一个词」；拾得者不必四处转发，失主会主动找来。
• C（竞争）：替代方案是班级群与表白墙，优势是无需安装、传播快，劣势是不能检索、信息生命周期极短。
• D（推广）：在图书馆、食堂张贴小程序码，与值班室合作录入代收物品。

---

四、从用户需求到软件需求：我们主动砍掉了什么

《构建之法》第 8 章提醒我们：用户的需求不等于软件的需求，需求分析一半在做减法。

不做复杂的实名认证：只在「我的」页放一个「已实名」标记，不接入学校统一认证，也不要求上传证件。

不做即时聊天：自建聊天要处理推送、会话存储和内容审核，成本远超收益。改成「留言 + 服务通知」的异步沟通，每条留言自动带上对应的物品卡片。

不做地图定位：校园地点是有限集合，写「第三教学楼 A203」比在地图上拖点更快，也便于按地点检索。

不做复杂后台：只保留 30 天自动到期和发布者自行下架，管理端留到二期。

砍掉四项后，核心收敛成一句话：能发、能搜、能看、能联系。

---

五、软件主要功能

1. 浏览信息：首页用 8 个分类图标做快捷入口，信息流按「全部 / 寻物 / 招领」切换。
2. 发布寻物：选「我丢了东西」，填名称、类别、地点、时间和描述，传照片（最多 3 张）。
3. 发布招领：选「我捡到东西」，与寻物共用同一张表单。
4. 搜索物品：同时匹配名称、描述文字和地点，带搜索历史与热词。
5. 筛选结果：结果页先给命中条数，再按「全部 / 招领 / 寻物 / 未归还」筛。
6. 查看详情：展示图片、状态标签、类别、拾获地点与时间、物品特征和说明。
7. 联系发布者：通过「联系 TA」或「我要留言」发起联系，有留言时收到通知。
8. 修改状态：在「我的发布」把信息标记为已归还，或修改、下架。
9. 消息通知：留言与系统通知分组展示，每条留言关联对应物品。

---

六、原型设计

原型开发工具：墨刀（Modao），原型在线链接：https://5mkcspcj.site.modao.ink/index.html（导入后填写）

原型共 9 个页面，尺寸 375 × 667。配色刻意保持克制：暖白底配深墨蓝文字，橙色只用于「寻物」和发布动作，绿色只用于「招领」和已完成状态，用户扫一眼就能分清信息的性质。底部固定三个 Tab：首页、消息、我的。

页面	设计说明
首页	顶部是搜索入口和「已帮助 1,286 件物品回到主人身边」的数据反馈；中间 8 个分类图标（校园卡、钥匙、水杯、雨伞、耳机、书籍、其他、去发布）让用户一眼定位；下方是「全部 / 寻物 / 招领」切换和最新信息流；右下角橙色「发布信息」悬浮按钮随时可发
搜索页	搜索框下方放「搜索历史」和「大家都在找」排行榜，点一下就搜；底部说明搜索会同时匹配名称、描述、地点三类内容
搜索结果	先给命中条数，再用「全部 / 招领 / 寻物 / 未归还」筛一遍；列表卡片统一为缩略图、标题、状态标签、摘要和地点时间
搜索无结果	空状态不是写一句「没有结果」就结束，而是给出「换个说法试试」的备选词，并直接引导发布寻物信息
信息详情	大图 + 状态标签 + 信息卡（类别、拾获地点、时间、物品特征）+ 详细说明；底部固定「联系 TA」和「我要留言」两个出口
发布信息	先选类型：「我丢了东西」还是「我捡到东西」，选中态有边框和对勾；下面依次是照片、名称、类别、地点等必填项，一屏填完
发布成功	明确告诉用户「已通过内容审核，无需等待」「信息展示 30 天，到期可一键续期」，消除「发了会不会没人看到」的顾虑
消息	「留言 / 系统通知」两个分组；每条留言都带上对应的物品卡片，用户不用回去翻上下文
我的	个人信息 + 数据统计（我的寻物、成功归还、我的收藏）+ 发布管理入口，发布者随时能改状态或标记已归还

七、用户使用软件的基本流程

流程一（找东西）：进入首页 → 用分类图标或搜索框找信息 → 点击搜索结果卡片 → 查看物品详情 → 判断是不是自己要找的东西（不是就换关键词，或自己发一条）→ 联系 TA 或留言 → 线下核对并当面交接 → 在「我的发布」标记已归还。

流程二（发信息）：点击「发布信息」→ 选择「我丢了东西」或「我捡到东西」→ 填写信息并上传照片 → 点击「立即发布」→ 发布成功 → 在「我的发布」查看或修改状态。

---

八、PSP 表格

PSP 阶段	预估耗时（分钟）	实际耗时（分钟）	说明
计划（需求讨论、确定范围）	30	35	对照客户描述逐条确认要解决什么
需求分析（典型用户与场景）	40	45	用 NABCD 梳理，明确砍掉的功能
原型设计（绘制 9 个页面）	120	180	首页和搜索结果页各改了 3 版
流程图绘制	30	25	两张流程图
文档撰写与排版	40	45	博客撰写、图片上传
结对评审与修改	20	30	互相试用原型并提出修改意见
合计	280	360

---

九、结对完成过程记录

《构建之法》第 3 章讲两人合作时提到，结对是两人轮流当驾驶员和领航员，而不是一人写、一人看，全程两人同时在场。

讨论需求（35 分钟）：把客户描述里的物品和场所列在白纸上，在「校园卡要不要特殊处理」上产生分歧，最后决定把处置建议写进详情页的「详细说明」，让失主知道可以直接去值班室认领。

确定范围（45 分钟）：列出全部功能，逐条判断「必须有」还是「二期再说」。

画流程图（25 分钟）：先画线性的发布流程，再画带判断分支的浏览搜索流程。

制作原型（180 分钟）：同伴负责首页、信息详情和我的，我负责搜索流程和发布流程。第一版首页把搜索、分类、筛选全叠在一起，同伴试用后提出「我只想快点找到东西」，于是把 8 个分类图标提到最上层，筛选收进信息流上方，页面才清爽下来。

---

十、个人总结

王宇航（负责原型设计）：

我负责首页、信息详情和「我的」。第一次做原型时我没有「尺寸感」，把首页堆得很满，看着内容丰富，在手机上却十分拥挤。同伴扮演用户试用后指出了这一点，我才意识到原型要让人一眼看懂主流程，而不是展示所有功能。第二版把 8 个分类图标提到最上层、把搜索框和筛选条分层，页面立刻清爽了。自己看自己的设计容易改不下去，结对的好处就是有人站在使用者角度毫不客气地提问。

---

十一、后续计划

第二次结对作业将基于本次原型实现代码：先做「首页信息流 + 发布信息 + 搜索与结果」三个核心功能，数据先用本地模拟，使用 GitHub 协作，提交前互相 review。