软件工程第三次作业——校园失物招领小程序「福大拾光」——需求分析与原型设计

项目	内容
这个作业属于哪个课程	H202601软件工程与软件工程实践
这个作业要求在哪里	软件工程第三次作业
这个作业的目标	分析校园失物招领需求，使用原型呈现主要页面和流程，并通过结对协作完成需求分析与设计
学号与姓名	102402112 松格拉；102402110 姜思源
结对同伴的博文链接	102402112 松格拉 结对作业博文

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

一、学习准备

动手前我们研读《构建之法》第3章与第8章：

• 第3章：理解结对编程驾驶员—领航员协作模式，核心是持续沟通协作，而非各自完成一半再简单拼接；
• 第8章：采用 NABCD模型 作为本次需求分析的核心框架。

二、需求分析：NABCD模型拆解

核心痛点：失主的需求不是单纯浏览物品信息列表，而是快速定位遗失物品；拾获者顾虑物品被他人冒领，缺少可靠的身份核验手段。

NABCD	内容
N 需求	失主：希望系统主动提醒物品位置，不用手动翻找海量信息； 拾获者：需要一套验证机制，防止物品被冒领。
A 做法	失物本质：人与物品在同一时间、同一地点产生交集。 不使用传统物品分类检索，采用「地点 × 时间」时空索引；地图承载地点信息，时间轴实现时间回溯，系统主动做时空匹配，向用户推送疑似丢失物品。
B 好处	失主：不再盲目翻帖子，直接查看自己去过地点的失物标记； 防冒领：发布者自定义两道验证题目，答错2次锁定24小时，降低冒领风险。
C 竞争	QQ群、表白墙：传播快，但信息极易被刷屏淹没，无法检索； 学校线下招领处：官方权威，但无法覆盖教学楼、操场等零散遗失场景。 差异化：不比拼信息传播速度，主打时空主动匹配，区别于普通信息列表类招领平台。
D 交付	优先从校园卡这类高频遗失物品切入；7天无人认领的物品自动移交校方失物招领处，对接现有线下流程，不替代原有招领体系。 功能优先级：地图浏览与时空匹配 ＞ 打点发布 ＞ 认领验证 ＞ 状态管理 本次原型不实现：实名认证、即时聊天。

三、功能列表

功能	说明
失物地图	首页展示福大校园地图，失物落点标记；红色=寻物，绿色=招领
时间轴回溯	支持今天/昨天/近三天/更早，按时间维度回溯查找遗失信息
时空匹配	「你可能丢了它」：根据用户到访地点、离开时间，系统自动推断疑似丢失物品
发布·地图打点	在地图选定位置，填写遗失/拾取时间，自定义认领验证问题
认领验证	必须答对发布者设置的两道验证题，才可查看联系方式，防范冒领
状态管理	「我的」页面跟踪认领进度；7天无人认领物品移交校方失物招领处

四、原型设计与工具

• 原型工具：墨刀（modao.cc）
• 制作流程：先用HTML还原8页视觉稿，再将页面导入墨刀生成可编辑元件，配置页面交互跳转；底部导航封装为母版复用，减少重复工作量。
• 产品命名：福大拾光 ——「拾」代表拾获物品，「光」代表回溯丢失的时间。
• 主题色：采用校徽红 #C62828

墨刀原型在线链接：【 https://modao.cc/proto/z8HlUKYntm0wn2lrz2Q7YO/sharing 】

页面清单（共8页）

失物地图（首页）、时空匹配、认领验证、发布打点、发布成功、我的、查找、空结果引导

三条可完整走通核心业务流程

1. 首页点地图圆点 → 时空匹配 → 认领验证 → 答题通过展示联系方式
2. 底部「+」发布按钮 → 地图打点 → 发布到地图 → 发布成功提示
3. 查找页 → 按时间、地点回溯筛选 → 展示结果 / 空结果引导

和普通失物招领方案的核心差异

1. 首页主体为地图，而非传统信息流列表
2. 依靠时空条件主动匹配，不是用户手动翻阅信息
3. 使用答题验证防冒领，替代直接暴露联系方式的自证方式
4. 空结果页面提供引导，支持放宽时间范围继续检索

五、原型页面展示

• 首页 · 失物地图：红绿点位标记 + 时间轴 +「你可能丢了它」匹配入口

• 时空匹配：示例：你15:20离开西二教学楼，15:30该地点有人捡到一卡通

• 认领验证：答对两道自定义题目，才可查看发布者联系方式

• 发布打点 & 发布成功：地图选点填写信息，发布后提示「已钉在地图上

• 我的——界面：
  

• 查找 & 空结果：按时间回溯，勾选曾经到访地点进行检索

六、使用流程图

物品找回流程：查看地图 → 时间回溯/时空匹配 → 认领答题验证 → 线下取回物品
物品送交流程：点击底部「+」打点发布 → 信息钉入地图 → 失主时空匹配后查看

七、PSP 表格

PSP 阶段	预估耗时（h）	实际耗时（h）
计划与需求分析	1.0	1.5
原型设计（8 个页面）	3.0	3.5
流程图绘制	0.5	0.5
博客撰写与排版	1.5	2.0
合计	6.0	7.5

八、结对过程记录

我们在宿舍面对面开展结对开发：

1. 共同讨论，挖掘失物招领场景下真实痛点，使用NABCD模型完成需求拆解；
2. 我负责绘制地图草图、业务流程图，姜思源逐页评审、提出疑问；
3. 两人协同导入原型素材，配置页面交互，完整走查三条核心业务流程。

讨论需求、绘制流程图、制作原型时的照片

九、个人总结

102402112 松格拉 心得：

本次结对作业让我对软件需求挖掘与原型取舍有了很直观的体会。
在项目初期，我们很容易惯性地搭建一套常规失物招领平台：发布、搜索、物品详情，功能看着齐全，但没有解决真实场景痛点。重读《构建之法》后我意识到：需求分析不是简单收集用户表面诉求，而是挖掘诉求背后的真实目标。丢东西的用户并不想要更多信息卡片，而是希望快速找到自己遗失的物品，这个想法才催生了地图与时空匹配的核心设计。

结对协作的价值在本次项目中体现得十分明显。驾驶员与领航员的角色分工，让我们全程保持同步思考，减少独自埋头开发带来的思路盲区。在草图讨论阶段，我们突然想到，“如何确认认领人就是物主？” 这个问题，促使我们设计出答题验证的防冒领方案；而我提出首页以地图为核心的想法，也在队友的提醒下补充了时间轴与引导模块，降低新用户的理解成本。产品方案正是在这样持续的互相提问、思辨中逐步完善的。
同时我也学会了做产品要懂得做减法。原型的目标是验证核心创意，不是堆砌全部想到的功能。像实名认证、即时聊天这类锦上添花的功能，全部暂时舍弃，集中精力验证「时空匹配+答题防冒领」这套核心方案。这种取舍思维，也是软件工程实践里非常重要的一课。

102402110 姜思源 心得：

本次结对作业，让我切身理解了结对编程 “驾驶员 + 领航员” 模式的意义，也实践了 NABCD 模型从痛点挖掘到产品交付的完整需求分析流程。
最开始我们打算做一个传统的校园失物招领信息发布平台，罗列物品信息供用户浏览检索。在结对讨论过程中，我们一起复盘校园真实场景：表白墙信息刷屏、线下招领地点固定，丢东西的同学很难高效检索，拾获者又担心物品被冒领。我们跳出 “信息发布板” 的固有思路，确定了地图 + 时空匹配作为产品核心亮点。在原型制作阶段，我负责页面交互校验、走查业务流程，反复测试三条核心链路，同时提出空结果页面引导、答题次数限制等细节优化，完善产品边界场景。

需求设计中很重要的一点是区分刚需和锦上添花功能。按照 NABCD 里交付 D 的要求，我们确定功能优先级，主动砍掉实名认证、即时聊天等非核心功能，聚焦验证时空匹配与防冒领机制。原型只用来验证核心业务想法，而不是一次性完成全部功能，这也是《构建之法》里强调的产品迭代思维。

结对协作和独自完成作业差别很大。两个人互相质疑、评审设计，可以提前发现很多设计漏洞。比如在认领验证模块，我们一起讨论答题失败后的锁定机制，避免冒领风险；在原型走查时，互相模拟普通学生用户操作，优化页面导航逻辑。这次实践也让我意识到，软件设计不只是画页面，而是始终围绕用户真实痛点去做取舍与设计。