2026秋软件工程个人作业（第三次）
校园失物招领小程序：需求分析与原型设计
结对成员：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号