软件工程结对作业1
| 这个作业属于哪个课程 | 前往班级 |
|---|---|
| 这个作业要求在哪里 | 前往查看 |
| 这个作业的目标 | 完成校园失物招领小程序的需求分析与原型设计 |
| 队员1学号姓名 | 102401309 叶凯乐 |
| 队员2学号姓名 | 102401234 黄俊凡 |
| 原型在线链接 | 前往查看 |
一、结对分工
| 角色 | 任务 |
|---|---|
| 叶凯乐 | 需求分析、用户角色与场景、功能列表、流程图绘制 |
| 黄俊凡 | 原型设计、Figma页面制作、交互链接、截图 |
| 协同 | 需求讨论、确定功能边界、互审原型、撰写博客主体、PSP |
二、需求分析
2.1 用户角色
| 角色 | 特征 | 核心需求 |
|---|---|---|
| 失主 | 丢失物品的同学,可能在教学楼、食堂、图书馆等场所遗落 | 发布寻物信息、搜索招领信息、快速联系拾获者 |
| 拾获者 | 捡到物品的同学,希望尽快找到失主 | 发布招领信息、接收失主联系、归还后更新状态 |
2.2 痛点分析
- 信息分散: 拾获者与失主往往不在同一个群,消息难以互相触达
- 信息沉没: 群聊消息不断更新,之前发布的信息很快被覆盖,事后查找不便
- 触达受限: 发布范围受社交圈限制——在教学楼捡到校园卡的同学只能发在自己的班级群,失主很可能根本看不到
2.3 核心功能列表
| 功能 | 说明 |
|---|---|
| 浏览失物和招领信息 | 首页信息流,支持“全部/寻物/招领”分类筛选 |
| 发布寻物信息 | 填写物品名称、地点、时间、描述、联系方式后发布 |
| 发布招领信息 | 同上,信息类型选择“招领” |
| 搜索物品 | 按关键词匹配标题、地点、描述 |
| 查看物品详情 | 展示完整信息与联系方式 |
| 修改信息状态 | 在“我的发布”中标记为已解决 |
| 我的发布 | 集中管理自己发布的信息 |
聊天、地图定位、实名认证、后台管理不纳入本次原型
三、流程图涉及
流程一:浏览信息—查看详情
流程二:发布信息—发布成功
流程三:搜索物品—查看搜索结果
流程四:我的发布—查看与修改信息
四、流程展示
在信息浏览流程中,用户可以通过首页分类或关键词搜索查找物品,进入详情页查看地点、时间、物品描述及发布者联系方式。

在信息发布流程中,用户选择寻物或招领类型,填写物品资料后进入发布成功页面,并可返回首页或查看个人发布记录。

在搜索流程中,以“校园卡”为例,原型展示了从关键词搜索、结果列表到信息详情的操作过程。

此外,我们进一步补充了个人发布信息的查看与编辑流程,设计了保存确认、保存成功及未保存离开提醒等交互状态,使原型能够更完整地表达发布后的信息管理需求。

五、原型设计
5.1 原型工具与在线链接
本次作业采用 Figma 进行原型设计,使用 Figma Agent 辅助生成初始界面,并通过人工调整、组件设计和 Prototype 交互连接完善原型。
Figma 支持多人在线协作,便于两名成员共同修改、检查设计。同时,原型可通过在线链接展示,无须编写程序即可模拟用户操作。
原型展示链接: 校园失物招领小程序原型
5.2 页面说明与截图
根据需求分析,我们设计了首页、发布信息、发布成功、搜索、搜索结果、信息详情及我的发布等主要页面,整体采用统一的蓝白配色和卡片式布局。
主要页面功能如下:
| 页面 | 主要功能 |
|---|---|
| 首页 | 浏览寻物与招领信息,进入搜索或发布页面 |
| 发布信息 | 填写物品名称、分类、地点、时间、描述及联系方式 |
| 发布成功 | 展示发布结果,支持返回首页或查看个人发布 |
| 搜索及搜索结果 | 根据关键词查找相关物品信息 |
| 信息详情 | 展示物品完整信息及发布者联系方式 |
| 我的发布 | 查看个人发布的信息,修改物品状态 |
| 我的发布详情与编辑 | 查看、修改已发布的物品信息,并保存 |
主要功能页面总览


5.3 走查与修改
构建主要的几个页面(首页、搜索、发布)后,我们人工检查页面布局、字段完整性及交互流程,并补充了“我的发布”等功能。
页面布局的检查

在状态修改功能的走查中,我们发现:最初采用多个完整页面模拟“寻找中”“已找回”等状态,切换寻物与招领页面后,可能重新显示修改前的信息。
针对这一问题,我们将蓝牙耳机和水杯设计为交互组件,利用不同变体表示物品状态,通过 Change to 实现卡片内部状态切换,将物品状态变化与页面导航分离。
初期使用完整页面模拟状态变化

改进后的组件变体设计

与同伴检查沟通过后,我们决定添加修改信息的功能。原型中在发布页面可点击相应的物品卡片,修改自己的失物与待招领物品信息

我们补充了个人发布信息的查看与编辑页面,并设计了保存确认、未保存离开提醒等交互状态。
最后通过 Prototype 连接页面,在演示模式中检查信息浏览、发布、搜索、状态修改及返回等基本流程。

通过本次走查,我们认识到原型设计不仅需要关注界面外观,还应考虑操作逻辑、状态一致性和后续实现的可行性。
六、PSP表格
| 任务 | 预估耗时(h) | 实际耗时(h) | 差异(h) |
|---|---|---|---|
| 阅读《构建之法》第3、8章 | 1 | 0.5 | -0.5 |
| 需求分析 | 1 | 1 | 0 |
| 流程图绘制 | 2 | 1 | -1 |
| Figma原型制作 | 4 | 3.5 | -0.5 |
| 走查与修正 | 1 | 2 | 1 |
| 博客撰写 | 1 | 1 | 0 |
| 合计 | 10 | 9 | -1 |
注:差异 = 实际耗时 − 预估耗时。
七、个人总结
本次作业我主要负责figma上原型的构建。做主页面的时间没花多少,调整一些按键的动作以及卡片的状态反而占了大头。作为原型,我们只保留了最简要的演示功能,其它的部分没有严格自洽,如只制作了一部分物品的卡片供演示,而其它没用到的卡片没设置他们的功能;又如想添加一个快捷联系到失主、拾物者的按键,分析了一下,发现可能还需要连带添加通信的需求,进一步,还需要个人账户的注册、登录,可能还需要能应用内聊天、添加联系人等,于是我们只提供了联系方式,其它后续就没在原型中实现,只作为一个可行的想法留存在大脑中。
原型的制作让我初步感受到了软件阶段需求的意义,以及深化了对课堂内容的理解:不要一开始就把完备的功能作为自己的目标,否则开发过程可能会无比冗长,让手里做的事变得毫无兴致。万丈高楼平地起,原型虽然没那么复杂,但是基本的逻辑也不能出错,否则会出现返工的情况,因此也不能轻视,最好先理清楚流程再进行原型的构建。

浙公网安备 33010602011771号