软件工程结对作业1

这个作业属于哪个课程 前往班级
这个作业要求在哪里 前往查看
这个作业的目标 完成校园失物招领小程序的需求分析与原型设计
队员1学号姓名 102401309 叶凯乐
队员2学号姓名 102401234 黄俊凡
原型在线链接 前往查看

一、结对分工

角色 任务
叶凯乐 需求分析、用户角色与场景、功能列表、流程图绘制
黄俊凡 原型设计、Figma页面制作、交互链接、截图
协同 需求讨论、确定功能边界、互审原型、撰写博客主体、PSP

二、需求分析

2.1 用户角色

角色 特征 核心需求
失主 丢失物品的同学,可能在教学楼、食堂、图书馆等场所遗落 发布寻物信息、搜索招领信息、快速联系拾获者
拾获者 捡到物品的同学,希望尽快找到失主 发布招领信息、接收失主联系、归还后更新状态

2.2 痛点分析

  • 信息分散: 拾获者与失主往往不在同一个群,消息难以互相触达
  • 信息沉没: 群聊消息不断更新,之前发布的信息很快被覆盖,事后查找不便
  • 触达受限: 发布范围受社交圈限制——在教学楼捡到校园卡的同学只能发在自己的班级群,失主很可能根本看不到

2.3 核心功能列表

功能 说明
浏览失物和招领信息 首页信息流,支持“全部/寻物/招领”分类筛选
发布寻物信息 填写物品名称、地点、时间、描述、联系方式后发布
发布招领信息 同上,信息类型选择“招领”
搜索物品 按关键词匹配标题、地点、描述
查看物品详情 展示完整信息与联系方式
修改信息状态 在“我的发布”中标记为已解决
我的发布 集中管理自己发布的信息

聊天、地图定位、实名认证、后台管理不纳入本次原型

三、流程图涉及

流程一:浏览信息—查看详情

flowchart TD A[进入首页] --> B{选择查找方式} B -->|直接浏览| C[浏览寻物或招领列表] B -->|关键词搜索| D[进入搜索页面] D --> E[输入关键词并搜索] E --> F[查看搜索结果] C --> G[点击物品卡片] F --> G G --> H[查看物品详情] H --> I[查看发布者联系方式]

流程二:发布信息—发布成功

flowchart TD A[进入发布页面] --> B[选择寻物或招领] B --> C[填写物品资料] C --> D{必填项是否完整} D -->|否| E[提示补充信息] E --> C D -->|是| F[点击立即发布] F --> G[发布成功] G --> H{选择后续操作} H -->|返回首页| I[继续浏览] H -->|查看我的发布| J[管理发布记录]

流程三:搜索物品—查看搜索结果

flowchart TD A[进入搜索页面] --> B[输入物品关键词] B --> C[点击搜索] C --> D{是否有匹配结果} D -->|有| E[展示搜索结果列表] E --> F[点击物品卡片] F --> G[查看物品详情] D -->|无| H[提示无匹配结果] H --> I[更换关键词] I --> B

流程四:我的发布—查看与修改信息

flowchart TD A[进入我的发布] --> B{选择操作} B -->|修改状态| C[标记已找回或已归还] C --> D[更新物品状态] B -->|查看信息| E[点击物品卡片] E --> F[查看我的发布详情] F --> G[点击编辑信息] G --> H[修改物品资料] H --> I{用户操作} I -->|保存修改| J[确认保存] J -->|取消| H J -->|确认| K[保存成功] K --> F I -->|返回| L{是否有未保存修改} L -->|否| F L -->|是| M[显示未保存提醒] M -->|继续编辑| H M -->|放弃修改| F M -->|保存并离开| J

四、流程展示

在信息浏览流程中,用户可以通过首页分类或关键词搜索查找物品,进入详情页查看地点、时间、物品描述及发布者联系方式。

{8B5E0245-5DFC-4B66-8621-3AB79C9384AE}

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

image

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

{7CA27859-6DEC-401C-B660-920A9FAEEE94}

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

{06B2A6B3-FFBA-4A75-BC7A-0E3087203F38}

五、原型设计

5.1 原型工具与在线链接

本次作业采用 Figma 进行原型设计,使用 Figma Agent 辅助生成初始界面,并通过人工调整、组件设计和 Prototype 交互连接完善原型。

Figma 支持多人在线协作,便于两名成员共同修改、检查设计。同时,原型可通过在线链接展示,无须编写程序即可模拟用户操作。

原型展示链接: 校园失物招领小程序原型

5.2 页面说明与截图

根据需求分析,我们设计了首页、发布信息、发布成功、搜索、搜索结果、信息详情及我的发布等主要页面,整体采用统一的蓝白配色和卡片式布局。

主要页面功能如下:

页面 主要功能
首页 浏览寻物与招领信息,进入搜索或发布页面
发布信息 填写物品名称、分类、地点、时间、描述及联系方式
发布成功 展示发布结果,支持返回首页或查看个人发布
搜索及搜索结果 根据关键词查找相关物品信息
信息详情 展示物品完整信息及发布者联系方式
我的发布 查看个人发布的信息,修改物品状态
我的发布详情与编辑 查看、修改已发布的物品信息,并保存

主要功能页面总览

主要功能页面总览

{A06892C7-F3AF-49FD-A0A3-BEDC8A0443C3}

5.3 走查与修改

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

页面布局的检查
image

在状态修改功能的走查中,我们发现:最初采用多个完整页面模拟“寻找中”“已找回”等状态,切换寻物与招领页面后,可能重新显示修改前的信息。

针对这一问题,我们将蓝牙耳机和水杯设计为交互组件,利用不同变体表示物品状态,通过 Change to 实现卡片内部状态切换,将物品状态变化与页面导航分离。

初期使用完整页面模拟状态变化

原先的状态页面

改进后的组件变体设计

组件化状态管理

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

{7EC0406A-9ED0-46EA-9D17-D48CC7139C4A}

我们补充了个人发布信息的查看与编辑页面,并设计了保存确认、未保存离开提醒等交互状态。

最后通过 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上原型的构建。做主页面的时间没花多少,调整一些按键的动作以及卡片的状态反而占了大头。作为原型,我们只保留了最简要的演示功能,其它的部分没有严格自洽,如只制作了一部分物品的卡片供演示,而其它没用到的卡片没设置他们的功能;又如想添加一个快捷联系到失主、拾物者的按键,分析了一下,发现可能还需要连带添加通信的需求,进一步,还需要个人账户的注册、登录,可能还需要能应用内聊天、添加联系人等,于是我们只提供了联系方式,其它后续就没在原型中实现,只作为一个可行的想法留存在大脑中。

原型的制作让我初步感受到了软件阶段需求的意义,以及深化了对课堂内容的理解:不要一开始就把完备的功能作为自己的目标,否则开发过程可能会无比冗长,让手里做的事变得毫无兴致。万丈高楼平地起,原型虽然没那么复杂,但是基本的逻辑也不能出错,否则会出现返工的情况,因此也不能轻视,最好先理清楚流程再进行原型的构建。

posted @ 2026-09-26 17:52  JFanH  阅读(29)  评论(1)    收藏  举报