软工第一次结对作业

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

这个作业属于哪个课程	https://edu.cnblogs.com/campus/fzu/202601SofwareEngineering
这个作业要求在哪里	https://edu.cnblogs.com/campus/fzu/202601SofwareEngineering/homework/16743
这个作业的目标	设计一个"校园失物招领小程序"，重点完成需求分析和原型设计
成员1	102401233郑志銮
成员2	102401212沈雷
原型链接	https://modao.cc/agent-py/workspace/6aba42f7b767a80220066cb5/campus-lost-found.html/home.html?render_html=true

一、作业之前：阅读《构建之法》

本次作业前，我们学习了《构建之法》中结对合作与需求分析两方面的知识。结对编程并非 "一人写、一人看"，而是两人分别担任驾驶员（负责实现）与领航员（负责审视与纠错）并定期互换角色，共同分析、设计、评审。需求分析方面，我们学会了通过问卷调查、用户访谈等方式获取需求，并用 NABCD 模型（需求、做法、好处、竞争、推广）把客户的一句话系统转成清晰的需求描述。这些方法直接指导了本次作业。

二、需求分析

2.1 用户分析

本软件主要面向校园学生，使用场景覆盖教学楼、食堂、图书馆、宿舍区、运动场等。学生既可能成为 "失主"（丢失校园卡、钥匙、水杯、雨伞等），也可能成为 "拾主"，因此软件需同时支持寻物与招领两类信息的发布与查看。

2.2 痛点分析

根据客户描述，当前失物信息主要通过班级群、宿舍群、朋友圈传播，存在三个问题：一是信息分散，失主与拾主难以互相发现；二是易被覆盖，历史信息很快被群聊消息淹没；三是触达率低，拾主只在 "小圈子" 发布，失主未必看到。软件主要解决 "信息集中、可搜索、易触达" 三个问题，提高失物找回与归还效率。

2.3 NABCD 分析

维度	分析
N（需求）	校园失物信息分散、易被淹没，失主与拾主难以匹配
A（做法）	集中平台 + 分类浏览 + 关键词搜索 + 一键发布
B（好处）	信息集中可查、随时可搜索，找回效率高、操作门槛低
C（竞争）	相比群聊 / 朋友圈：信息不被刷走、覆盖面广；相比二手平台：场景聚焦、流程简单
D（推广）	依托公众号、学生会、线下海报推广，小程序免安装、即用即走

2.4 主要功能

• 浏览失物 / 招领信息（支持分类筛选）

• 发布寻物信息、发布招领信息

• 按关键词搜索物品

• 查看物品详情（地点、时间、描述、发布者）

• 修改信息状态（标记已完成）与删除信息

三、原型设计

3.1 原型工具与链接

本次原型采用 HTML / CSS / JavaScript 制作的高保真可交互原型（手机端形态，效果与 Axure 导出的 HTML 原型一致），可直接在浏览器中点击演示。

原型在线链接：[https://modao.cc/agent-py/workspace/6aba42f7b767a80220066cb5/campus-lost-found.html/home.html?render_html=true]

3.2 页面设计

页面	主要设计
首页	顶部搜索栏 + 寻物 / 招领分类标签 + 常用物品直达 + 信息列表卡片
发布信息页	切换 "寻物 / 招领" + 表单（名称、类别、地点、时间、描述、联系方式）
搜索页	关键词实时搜索 + 热门搜索词 + 搜索结果列表
信息详情页	物品信息 + 发布者 + 联系发布者 / 标记已完成
发布成功页	发布成功反馈，可跳转我的发布或返回首页
我的发布页	发布统计 + 管理本人信息（标记完成、删除）

3.3 基本流程演示

原型可完整演示三条流程：

• 查看信息：进入首页 → 浏览信息 → 点击卡片查看详情 → 联系发布者；

• 发布信息：点击底部 "＋" → 填写物品信息 → 立即发布 → 发布成功；

• 搜索物品：输入关键词 → 查看搜索结果 → 点击查看详情。

四、用户使用流程图

进入首页 ↓ 浏览或搜索信息 ↓ 查看物品详情 ↓ 联系发布者

进入发布页面 ↓ 填写物品信息 ↓ 点击发布 ↓ 发布成功

五、PSP 表格

阶段	预估耗时（分钟）	实际耗时（分钟）
计划：明确需求、划分任务	30	25
阅读《构建之法》相关章节	60	70
需求分析（用户分析、NABCD、功能列表）	60	50
绘制流程图	40	35
原型设计（页面结构、交互）	120	150
原型测试与修改	40	30
撰写博客	60	50
合计	410	410

六、结对过程记录

两人共同阅读客户描述，梳理出 "信息分散、易淹没、难匹配" 三个痛点，确定功能范围（不含后台管理、实名认证、即时聊天、地图定位等复杂功能，便于后续实现）。随后一人绘制流程图初稿、一人补充完善，确定 "查看 / 搜索" 与 "发布" 两条主线；原型制作阶段一人负责页面结构与视觉，一人负责交互逻辑与流程校验，并通过在线链接反复测试。【此处插入讨论需求、绘制流程图、制作原型的照片或截图】

后续第二次结对作业将基于本原型进行代码实现，我们计划提前熟悉 GitHub 的基本使用方法（创建仓库、clone、commit、pull request），在 GitHub 上协作开发。

七、个人总结

这次结对让我体会到 "1+1>2"：两人讨论时，很多一个人想不到的边界情况（如发布表单的必填校验、信息状态如何修改）能被及时发现。我主要负责原型交互部分，起初页面跳转逻辑较乱，用 "页面 - 流程对照表" 梳理后才理顺。收获是学会了用简洁界面表达完整流程，并提前熟悉了 GitHub 协作的准备工作，期待下一次结对编程实践。