| 这个作业属于哪个课程 | Click |
|---|---|
| 这个作业要求在哪里 | Click |
| 这个作业的目标 | 完成“失物招领”小程序的需求分析和原型设计 |
| 参与人员1 | 102401607梁倩 |
| 参与人员2 | 112400810雷葭雨 |
CHAPTER 01
需求分析
一、根据在校园失物招领事件中扮演的角色，可分为三类用户：
🔍 失主
丢失物品的同学。希望快速发布寻物信息让更多人看到，并能搜索别人发布的招领信息，尽快找回失物。
✓ 拾获者
捡到物品的同学。希望方便地发布招领信息、找到失主，让信息被真正的失主看到。
🔎 热心同学
浏览身边的失物招领信息，帮忙辨认、转告、提供线索，是信息传播的放大器。
二、 为此列出如下的功能清单
| 模块 | 功能点 | 功能描述 |
|---|---|---|
| 浏览信息 | 信息列表 | 以卡片形式展示所有寻物、招领信息，含缩略图、名称、地点、时间、状态 |
| 类型筛选 | 通过「全部 / 寻物启事 / 失物招领」分段控件快速切换，并显示各类数量 | |
| 校园地图 | 查看福州大学旗山校区导览图，支持放大查看，并按高频遗失地点（图书馆、食堂、田径场、快递中心等）快速检索 | |
| 发布信息 | 发布寻物启事 | 失主填写物品名称、分类、丢失地点/时间、描述、联系方式、图片后发布 |
| 发布失物招领 | 拾获者填写捡到物品的相关信息后发布，寻找失主 | |
| 搜索信息 | 关键词搜索 | 按物品名称、分类、地点、描述关键词检索，结果关键词高亮 |
| 搜索历史 / 热门搜索 | 记录搜索历史（可清空），提供热门搜索词和排行，点击即搜 | |
| 查看详情 | 物品详情 | 查看物品大图、基本信息、详细描述、发布者信息，并可联系对方 |
| 我的发布 | 我的发布列表 | 查看自己发布的全部信息及统计数据，支持按状态筛选 |
| 修改信息状态 | 物品找回或归还后，将信息由「进行中」标记为「已完成」 | |
| 消息中心 | 互动 / 系统通知 | 接收他人联系、状态变更、相关招领推荐等通知，点击可直达对应详情 |
此外，还存在一些隐含的非功能需求
- 简单，面向学生使用，操作不能复杂。
- 信息集中管理，不会像微信群那样消息被覆盖。
- 信息是公开给校内同学浏览（一般不用做严格身份认证）。
三、业务流程
①失主视角
发现物品丢失
回忆丢失地点、时间及可能路线 ↓
发布寻物 / 搜索招领
发布寻物信息或查找已有招领信息 ↓
获得线索并联系
电话 / 站内联系，核对物品特征 ↓
找回物品
确认物品无误，标记为「已找到」 |
②拾获者视角
捡到物品
妥善保管捡到的物品 ↓
发布失物招领
填写物品信息、捡到地点与时间 ↓
失主联系核验
核对物品名称、外观及其他特征 ↓
归还物品
完成归还，标记为「已归还」 |
CHAPTER 02
原型设计
原型主要采用Figma实现，共 5 个核心页面，流程清晰、易于理解和操作。
软件主要功能
- 发布功能
- 选择类型：【寻物启事】 / 【失物招领】二选一。
- 填写物品名称、物品分类、丢失 / 捡到地点、丢失 / 捡到时间、详细描述（可选）、联系信息、上传图片（可选）。
|
|
🏖️你有没有为放假苹果命
- 信息列表展示：首页快速入口 / 最新消息（可只看招领 / 只看寻物）；信息页全部展示。
- 搜索 and 详情：根据物品名称做关键词检索，匹配出相关帖子；点进去查看完整的物品信息。
- 信息状态：比如找到之后，可以标记为【已找到 / 已归还】，这条信息就不再作为待匹配信息展示。
以上主要功能解决了校园寻物、招领信息分散在各个微信群，信息零散、传播有限、查找麻烦、过期信息持续干扰的问题。
CHAPTER 03
PSP表格
| 任务 | 预估耗时（小时） | 实际耗时（小时） | 差异（小时） |
|---|---|---|---|
| 阅读准备 | 1 | 1.5 | +0.5 |
| 需求分析 | 2 | 2 | 0 |
| 原型设计（工具选型 + 页面构思） | 1.5 | 2 | +0.5 |
| 原型图绘制 | 2 | 5 | +3 |
| 流程图绘制 | 1 | 0.5 | -0.5 |
| 测试与修改 | 2 | 2.5 | +0.5 |
| 博客撰写 | 2 | 1.5 | -0.5 |
| 合计 | 11.5 | 15 | +3.5 |
本次任务预估总耗时 11.5 小时，实际耗时 15 小时，总耗时超出预估 3.5 小时。时间偏差主要来自原型图绘制。本次为结对项目，需要持续开展线上线下讨论，两人不断沟通需求、协商页面布局、统一设计思路，沟通协调本身占用不少时间。同时因为初次接触原型工具，不熟悉各类组件与交互设置，页面效果需要多次调整打磨，这两项叠加，使得原型绘制耗时远高于预期。流程图业务逻辑简单，双方很快达成共识，博客内容提前梳理好了大纲，这两项的实际用时少于预估。在测试与修改阶段，结对互查原型，从不同视角找出界面缺陷，也带来少量额外修改时间。通过本次 PSP 记录我认识到，结对开发不能只算动手制作的时间，需要把成员之间沟通讨论、意见协商的成本纳入工作量预估，后续估算任务时长时，要充分考虑这部分开销，同时预留原型迭代调试的时间。
个人总结
1. 从功能实现到需求驱动
以前完成程序设计任务时，更多考虑的是如何把功能实现出来；而在本次结对作业中，我们开始尝试从用户需求出发，经历需求分析、功能取舍、原型设计、结对讨论和修改完善等过程。
原型并不等同于最终的软件界面，它更像是开发之前的一次低成本验证。通过原型，可以提前展示页面结构、功能入口、页面之间的跳转关系以及用户完成任务的基本流程。
2. 原型设计中的问题与反思
在完成本次任务的过程中，也遇到了一些问题。刚开始设计页面时，我会比较在意颜色、布局和页面是否美观，但后来发现，原型阶段更重要的是信息结构和交互流程。
只有先确定页面中需要包含哪些内容、按钮之间如何跳转以及用户怎样完成核心任务，后续的视觉优化才有意义。
3. 对结对合作的认识
本次结对作业让我更加直观地体会到了两个人共同完成项目与个人独立完成作业之间的区别。
在需求分析和原型设计过程中，一个人完成内容后，另一个人从不同角度重新查看，往往能够发现一些原本没有注意到的问题。
“1+1”并不一定天然大于 2，只有建立在充分沟通、明确分工和相互复审的基础上，结对合作才能真正发挥作用。
浙公网安备 33010602011771号