软件工程第三次作业
校园失物招领小程序：需求分析与原型设计
结对成员：102302152 戴锴斌、072308214 周兴宇。
目标和范围
主要用户为在校学生，包括丢失物品的人和捡到物品的人，同一学生可使用两种发布类型。信息统一展示，按物品名称搜索，详情展示地点、时间、特征和联系方式，帮助双方在线下核对、归还物品。
本次交付为 Figma 可点击原型、基本流程图及博客草稿。不开发小程序代码；不设计实名认证、即时聊天、地图定位、后台管理或支付功能。图书馆、第一教学楼、第一食堂为场景示例，联系方式为虚构演示值。
主要需求与验收
| 功能 | 用户需要 | 可观察的验收结果 |
|---|---|---|
| 浏览信息 | 集中查看寻物、招领消息 | 首页切换寻物/招领；默认只展示未结束信息，按发布时间倒序 |
| 发布寻物 | 描述遗失物品并留下联系方式 | 填写必填项后进入发布成功页，可进入我的发布 |
| 发布招领 | 告诉失主捡到了什么 | 切换招领类型，时间、地点的标签相应变化 |
| 搜索物品 | 不翻群聊，直接按名称查找 | 输入关键词后展示匹配信息；无结果可修改关键词或发布 |
| 查看详情 | 判断是否是自己的物品并联系对方 | 展示类型、状态、名称、时间、地点、描述与联系方式 |
| 修改状态 | 找回或归还后停止无效联系 | 仅在我的发布中操作；二次确认后显示已找回/已归还 |
表单和搜索规则
必填：信息类型、物品名称、丢失/捡到地点、丢失/捡到时间、微信或电话。描述选填。本次不要求上传照片，减少首版设计和后续实现工作量。实际实现中应去除首尾空格、阻止空名称和空联系方式，时间不得晚于当前时间。
搜索范围为未结束的寻物和招领信息，采用物品名称包含关键词的简单匹配；不设计全文检索、拼音纠错或智能推荐。空关键词不提交并提示输入名称。首页和搜索结果同样按发布时间倒序。
状态：寻物“寻找中→已找回”，招领“待认领→已归还”。状态修改前确认，取消不改变信息，结束后在“我的发布”保留记录。
原型演示脚本
原型链接与演示方法
三条必需流程
- 查看信息：首页点击第一张“校园卡”卡片，再点击“查看联系方式”。
- 发布信息：首页底部点“发布”，点击“物品名称”框演示填写，再点“确认发布”，进入发布成功页。
- 搜索物品：首页点搜索栏，点击“校园卡”关键词，查看搜索结果并点击结果卡片。
其他演示
- 首页可切换寻物/招领；寻物列表第一张为蓝色水杯。
- 发布页点“我要招领”，演示招领表单与发布成功。
- 搜索页点“耳机”，展示无结果提示。
- 我的发布中可点“标记已找回”，确认后查看已找回状态；校园卡可走“已归还”分支。
- 浏览：从首页开始 → 校园卡卡片 → 查看联系方式。
- 发布：底部“发布” → 点击物品名称演示填写 → 确认发布 → 发布成功 → 查看我的发布。
- 招领：底部“发布” → 我要招领 → 确认发布 → 发布成功。
- 搜索：首页搜索栏 → 常见物品“校园卡” → 结果卡片 → 详情。
- 无结果：搜索页点击“耳机” → 暂无相关信息 → 修改关键词或发布寻物。
- 修改状态：我的 → 蓝色水杯“标记已找回” → 确认找回 → 已找回；校园卡可演示已归还。
- 必填提示：未填写的发布页 → 确认发布 → 补充联系方式 → 返回完整表单。
制作记录
| 阶段 | 戴锴斌预计/分钟 | 戴锴斌实际/分钟 | 周兴宇预计/分钟 | 周兴宇实际/分钟 |
|---|---|---|---|---|
| 阅读教材与任务规划 | 25 | 20 | 25 | 20 |
| 需求分析与讨论 | 35 | 30 | 25 | 20 |
| 流程设计 | 25 | 15 | 20 | 20 |
| 原型制作与修改 | 35 | 35 | 65 | 50 |
| 交互检查 | 25 | 25 | 25 | 25 |
| 博客整理与个人总结 | 35 | 30 | 20 | 25 |
| 合计 | 180 | 155 | 180 | 160 |
分工与制作记录
分工安排
- 戴锴斌：需求、流程与博客整理。
- 周兴宇：页面、交互与演示检查。
已有制作记录
一、需求分析
校园卡丢了以后，常见做法是翻班级群、宿舍群，再发一条寻物消息。但捡到物品的人未必和失主在同一个群，消息也容易被后续聊天覆盖。本次设计希望把这些信息放在一起，让同学能按物品名称查找。
主要用户有两类：失主需要搜索招领消息、发布寻物信息；拾物者需要描述物品、留下联系方式，归还后更新状态。同一名学生可以使用两类功能，无须选择固定身份。
结合《构建之法》中需求分析的思路，功能应从具体场景出发。例如，丢失校园卡的同学需要的是尽快找到相关消息，因此首版优先保留浏览、发布、搜索和联系，暂不加入聊天、地图与实名认证。
二、功能与页面
原型工具采用 Figma，界面使用蓝白配色，底部设置“首页、发布、我的”三个入口。
原型展示：点击体验校园失物招领原型。
| 页面 | 主要内容 |
|---|---|
| 首页 | 切换寻物、招领，按发布时间浏览信息 |
| 发布页 | 选择类型，填写名称、地点、时间和联系方式 |
| 搜索页 | 按物品名称查找，显示结果或无结果提示 |
| 详情页 | 查看物品特征、状态及发布者联系方式 |
| 我的发布 | 查看本人信息，标记已找回或已归还 |
)
发布时，名称、地点、时间及联系方式必填，描述选填。
搜索同时查找两类未结束信息。没有结果时，可更换关键词或直接发布寻物消息。详情页提醒双方核对物品特征，再通过微信或电话联系。归还完成后，由发布者确认修改状态，避免其他同学继续联系。
三、基本流程
）
流程见上图。原型用预设信息模拟输入和跳转，不保存真实数据。
四、分工与制作记录
分工安排：戴锴斌侧重需求、流程和博客整理，周兴宇侧重页面、交互和演示检查。检查时应交换操作与核对角色，避免只熟悉各自负责的部分。
原型制作先确定表单字段，再统一页面布局，最后连接跳转。连线检查中出现过同一页面不能跳转到自身的问题，取消这类无效连接后，浏览、发布和搜索流程均能走通。“我的发布”另外加入确认步骤，防止误点后直接结束信息。
)
)
| 阶段 | 预计 | 实际 |
|---|---|---|
| 阅读与规划 | 25 | 10 |
| 需求分析 | 25 | 10 |
| 流程设计 | 20 | 30 |
| 原型制作与修改 | 65 | 80 |
| 交互检查 | 25 | 5 |
| 博客与总结 | 20 | 30 |
| 合计 | 180 | 165 |
五、个人总结
本次结对作业围绕“校园失物招领小程序”完成了需求分析与 Figma 原型设计。交付物包括可点击原型、基本流程图和博客记录，不涉及代码实现。从结果看，三条主流程（浏览、发布、搜索）均可走通，异常分支（无结果、必填校验、状态二次确认）也已覆盖。以下从几个方面做客观回顾。
一、需求范围的界定
需求分析的起点是具体场景：失主翻群聊找校园卡，信息易被覆盖；拾物者与失主未必同群。基于此，核心需求被收敛为“集中展示、按名称搜索、线下联系”三项。首版明确排除了实名认证、即时聊天、地图定位、后台管理和支付功能。这一取舍的依据是：首版目标是验证信息聚合与检索流程是否成立，而非构建完整社交或交易闭环。从工程角度看，范围控制是本次作业中判断最明确的一步。
二、表单与搜索规则的约束
在表单设计上，必填项限定为信息类型、物品名称、地点、时间、联系方式，描述选填，且不要求上传照片。搜索采用物品名称包含关键词的简单匹配，不做全文检索、拼音纠错或智能推荐。这些约束降低了原型复杂度和后续实现成本。同时，规则中明确了去空格、阻止空名称与空联系方式、时间不得晚于当前时间等校验逻辑，报错时保留已填内容。这些细节说明，需求文档中的“不做什么”和“做什么”同样重要。
三、原型制作与交互检查
原型使用 Figma 制作，页面结构为首页、发布页、搜索页、详情页和“我的发布”。制作过程中出现的问题主要有两类：一是连线时存在同一页面跳转自身的无效连接；二是“我的发布”中修改状态缺少二次确认，易导致误操作。前者通过取消无效连接解决，后者通过增加确认步骤解决。交互检查阶段确认了浏览、发布、搜索三条路径均可走通，并补充了无结果提示和必填报错分支。这说明原型的价值不在于视觉完整度，而在于路径是否闭合、异常是否可演示。
四、结论
本次作业验证了一个基本判断：在原型阶段，把需求收敛为可验收的条目、把流程闭合为可演示的路径，比追求功能数量更重要。后续如果进入实现阶段，表单校验规则、搜索匹配逻辑和状态流转是三个需要优先固化的点。时间预估方面，应给界面细节和连线调试留出更大余量。整体来看，这次作业完成度符合预期，过程记录也为后续迭代提供了可参考的依据。
浙公网安备 33010602011771号