软件工程第三次作业：校园失物招领小程序需求分析与原型设计

软件工程第三次作业：校园失物招领小程序需求分析与原型设计

《校园拾物》：校园失物招领小程序需求分析与原型设计

项目	内容
这个作业属于哪个课程	H202601软件工程与软件工程实践
这个作业要求在哪里	2026秋软件工程个人作业(第三次)
这个作业的目标	结对完成校园失物招领小程序的需求分析与原型设计，使用墨刀绘制原型，梳理用户流程
成员1	102402109 陈薇薇
成员2	102402111 李青容
原型工具	墨刀
原型链接	小程序入口

一、项目展示

《校园拾光》是一款面向校园学生的失物招领小程序原型。针对目前校园失物信息分散在班级群、宿舍群、朋友圈，容易被新消息覆盖的问题，我们希望提供一个集中发布、浏览和搜索寻物/招领信息的入口。

原型包含欢迎页、首页、搜索页、发布信息页、信息详情页、我的页面，覆盖了从进入小程序到发布、搜索、查看详情、标记归还的完整流程。

1. 欢迎页

欢迎页展示小程序名称“校园拾光”和英文名“Campus Lost & Found”，下方是标语“每一次遗失，都值得被找回”，中间是“开始寻找”按钮，底部注明“校园失物招领服务平台”。

2. 首页

首页顶部是“返回”和“校园拾光”标题，下面显示“你好，王同学”和“今天也有新的失物信息”。搜索框提示“搜索丢失物品，如耳机，一卡通”。下方有两个快捷入口：“我丢东西”和“我捡到了”。

再往下是“最新失物信息”列表，顶部有“全部 / 寻物 / 招领”三个筛选标签。信息卡片显示物品图片、名称、地点、发布时间和类型标签，例如“白色碎花钱包 / 图书馆三楼 / 今天14:20发布 / 招领”“AirPods耳机 / 教学楼A区 / 今天13:10发布 / 寻物”。底部导航为“首页 / 发布 / 我的”。

3. 搜索页

搜索页顶部是“返回”和“搜索物品”标题，搜索框提示“输入丢失物品，例如：钱包”，右侧是“去搜索”按钮。下方是“大家都在找”标签，包含“钱包 / 耳机 / 一卡通 / 手机 / 水杯”。再往下是搜索结果，显示“找到15条搜索结果”，每条结果展示物品图片、名称、地点、时间和类型标签。

4. 发布信息页

发布页顶部是“返回”和“发布信息”标题，下方是“我丢东西”和“我捡东西了”两个切换按钮。表单依次为：物品类型、物品名称、丢失/找到时间、丢失/找到地点、联系方式、物品描述，以及“请上传图片（最多三张）”。底部是“发布！”按钮。点击发布后弹出“发布成功！”提示。

5. 信息详情页

详情页顶部是“返回”和“物品详细”标题，右上角是分享和收藏图标。下方是物品大图，接着是信息类型、物品类型、物品信息、拾取时间、拾取地点、发布者等字段。再往下是“物品描述”，最后是“标记为已解决”和“联系发布人”两个按钮。

点击“联系发布人”后弹出浮层，提示“请提前说明认领的物品细节，防止误领”，并提供“拨打电话”和“线下认领点（学生中心1楼失物招领处）”两个选项。点击“标记为已解决”后弹出“归还标记成功！”提示。

6. 我的页面

我的页面顶部展示用户头像、姓名“王一一”、学院“计算机与大数据学院 大数据专业”、学号“102402100”，以及“我的发布 7 / 寻物信息 4 / 招领信息 3”三个统计数字。

下方是“我的发布”列表，展示已发布的信息，例如“白色碎花钱包 / 图书馆三楼 / 今天14:20发布 / 招领 / 待认领”和“黑色皮质钱包 / 操场中央 / 昨天19:30发布 / 招领 / 已归还”，右上角有“+发布新消息”入口。再往下是“消息通知 / 浏览记录 / 搜索”快捷入口，以及“默认联系方式”“消息通知”“问题与反馈”等设置项。

二、项目介绍

1. 用户需求分析

主要用户分为三类：

• 丢失物品的学生：希望快速发布寻物信息，并通过关键词搜索是否已有人拾到。
• 捡到物品的学生：希望快速发布招领信息，让失主联系到自己。
• 普通浏览者：没有明确发布需求，但会随手浏览，看到相关信息时进行联系。

核心痛点：信息碎片化、容易被群消息覆盖、捡到物品的人和丢失物品的人未必在同一个群。因此本软件主要解决信息集中、便于检索、流程清晰三个问题。

2. 主要功能

• 浏览失物和招领信息
• 发布寻物信息
• 发布招领信息
• 搜索物品
• 查看物品详情
• 联系发布者
• 标记为已解决
• 我的发布

3. 界面设计

整体采用浅蓝渐变风格，搭配白色卡片，信息层级清楚。首页突出搜索框和快捷发布入口，发布页突出寻物/招领二选一，详情页突出物品大图和联系入口，降低用户理解成本。

三、开发环境

项目	环境
原型工具	墨刀
文档工具	博客园 Markdown
流程图工具	Mermaid

四、实现思路

1. 总体功能结构

flowchart TD A[校园失物招领小程序] --> B[首页] A --> C[发布信息] A --> D[搜索] A --> E[信息详情] A --> F[我的] B --> B1[浏览寻物/招领列表] B --> B2[按时间倒序展示] B --> B3[状态标签：待认领/已归还] C --> C1[我丢东西了-发布寻物] C --> C2[我捡东西了-发布招领] C1 --> C3[填写物品描述/地点/时间/图片] C2 --> C3 C3 --> C4[点击发布] D --> D1[输入物品名称关键词] D1 --> D2[展示搜索结果列表] D2 --> E E --> E1[查看物品类型/地点/描述] E --> E2[联系发布者] E --> E3[标记为已解决] F --> F1[查看我的发布] F --> F2[发布新消息]

2. 查看信息流程

流程说明： 进入首页 → 浏览信息列表 → 点击信息卡片 → 查看物品详情 → 联系发布者 → 线下认领/归还 → 标记为已解决。

流程图：

flowchart LR A[进入首页] --> B[浏览信息列表] B --> C{是否找到相关物品} C -- 否 --> D[使用搜索或继续浏览] D --> B C -- 是 --> E[点击信息卡片] E --> F[查看物品详情] F --> G[联系发布者] G --> H[线下认领/归还] H --> I[标记为已解决]

关键页面：

• 首页：浏览“最新失物信息”列表，可按“全部 / 寻物 / 招领”筛选。
• 详情页：查看物品大图、物品类型、拾取地点、发布者、物品描述。
• 联系发布者：弹出浮层，显示拨打电话和线下认领点，并提示“请提前说明认领的物品细节，防止误领”。
• 标记为已解决：点击后弹出“归还标记成功！”提示，状态更新为“已归还”。

3. 发布信息流程

流程说明： 进入发布页 → 选择寻物/招领 → 填写物品信息并上传图片 → 点击发布 → 发布成功 → 返回首页刷新列表。

流程图：

flowchart TD A[进入发布页面] --> B{选择信息类型} B -- 我丢东西了 --> C[填写寻物信息] B -- 我捡东西了 --> D[填写招领信息] C --> E[填写物品描述、地点、时间] D --> E E --> F[上传图片 最多三张] F --> G{信息是否完整} G -- 否 --> E G -- 是 --> H[点击发布] H --> I[发布成功] I --> J[返回首页并刷新列表]

关键页面：

• 发布页：顶部切换“我丢东西 / 我捡东西了”，表单包含物品类型、物品名称、丢失/找到时间、丢失/找到地点、联系方式、物品描述、上传图片。
• 发布成功：点击“发布！”后弹出“发布成功！”提示。

4. 搜索流程

流程说明： 进入搜索页 → 输入关键词 → 查看搜索结果 → 点击结果查看详情。

流程图：

flowchart LR A[进入搜索页] --> B[输入物品名称关键词] B --> C{是否有匹配结果} C -- 否 --> D[提示暂无结果，建议更换关键词] D --> B C -- 是 --> E[展示搜索结果列表] E --> F[点击某条结果] F --> G[查看物品详情]

关键页面：

• 搜索页：输入框提示“输入丢失物品，例如：钱包”，下方提供“大家都在找”标签。
• 搜索结果：显示“找到15条搜索结果”，每条结果展示物品图片、名称、地点、时间和类型标签。

五、结对合作过程

本次结对作业我们采用线下面对面交流的方式完成，两人约定在图书馆讨论区集中讨论，从阅读教材、分析需求，到画流程图、做原型，全程一起推进。

1. 阅读教材，统一认识

我们先一起阅读《构建之法》第3章和第8章，重点讨论了结对合作中“驾驶员”和“领航员”的分工，以及需求分析要区分“用户表面需求”和“真实痛点”。读完以后，我们约定：一人负责操作，另一人负责检查和提问，两人共同对结果负责。

2. 讨论需求，确定主线

我们用纸笔列出“丢东西的人”和“捡东西的人”两条主线，再补充“浏览者”的搜索路径。讨论中发现，丢东西的人最需要“搜索”和“联系发布者”，捡东西的人最需要“快速发布”和“不被误领”。这个结论直接影响了后面详情页的设计，也让我们决定在详情页加上“请提前说明认领的物品细节，防止误领”的提示。

3. 绘制流程图，检查每一步

我们把三条主要流程（查看信息、发布信息、搜索）画在纸上，互相检查每一步是否有对应的页面。比如原本“发布成功”之后没有明确去向，讨论后决定加一个成功提示，并返回首页刷新列表，让用户立刻看到自己发布的信息。

4. 制作原型，边做边改

进入墨刀原型制作阶段后，我们使用墨刀的团队协作模式。一人操作拖拽页面，另一人对照需求清单检查流程。遇到分歧就当场讨论、当场修改。线下交流的好处是反馈即时，一个问题不用来回发消息，直接指着屏幕就能说清楚。最终我们完成了欢迎页、首页、搜索页、发布信息页、信息详情页和我的页面。

六、测试与检查

编号	测试内容	预期结果	实际结果	是否通过
T01	首页能否正常展示信息列表	按时间倒序展示	正常展示	通过
T02	发布寻物信息	发布成功并返回首页	发布成功	通过
T03	发布招领信息	发布成功并返回首页	发布成功	通过
T04	点击信息卡片	进入详情页	正常进入	通过

七、PSP 表格

任务	预估耗时（分钟）	实际耗时（分钟）	差异（分钟）
阅读《构建之法》第3、8章	40	45	+5
讨论用户需求	30	35	+5
绘制流程图	25	30	+5
墨刀原型设计	300	360	+60
撰写博客	40	50	+10
合计	435	520	+85

八、心得体会

陈薇薇

本次结对作业是我第一次系统地做需求分析和原型设计。以前我总觉得“画原型”就是把页面摆好看，但真正动手后才发现，原型最重要的是把流程讲清楚。比如在首页信息卡片的设计上，我一开始只放了物品名称和地点，李青容提醒我：用户最关心的是“什么时候发的”和“有没有被认领”，于是我们补充了发布时间和状态标签。这个细节让我明白，界面元素不是随便放的，每一个都要对应一个用户需求。

在结对过程中，我们采用了“驾驶员—领航员”模式。我负责操作墨刀拖拽页面，李青容负责对照需求清单检查流程。我们约定：先把流程图走通，再美化界面。这个顺序调整后，效率明显提高。

我遇到的最大问题是“发布成功”后的跳转逻辑。我原本只做了一个弹窗提示，但弹窗关闭后用户还停在发布页，容易以为没发出去。我们最终改成：弹窗提示“发布成功”后，点击“发布成功”后，自动返回首页。

通过阅读《构建之法》第8章，我还学会了区分“必要功能”和“锦上添花功能”。我们主动砍掉了即时聊天、地图定位、实名认证等复杂功能，只保留发布、搜索、详情、状态修改。这次作业让我体会到，好的设计不是功能多，而是流程清楚、用户容易理解。

李青容

我在本次结对作业中主要负责需求梳理、流程检查和文档撰写。通过阅读《构建之法》第3章，我理解了结对合作不是“一人做一半”，而是两人共同对结果负责。驾驶员关注当前操作，领航员关注整体方向和潜在问题，这种分工能有效减少遗漏。

在需求分析阶段，我们先把用户分成三类：丢失物品的学生、捡到物品的学生、普通浏览者。然后针对每一类用户追问“他们最想做什么”。结果发现，丢失物品的学生最需要的是“搜索”和“联系发布者”，捡到物品的学生最需要的是“快速发布”和“不被误领”。基于这个发现，我们在详情页增加了“请提前说明认领的物品细节，防止误领”的提示，并设计了“线下认领点”信息。这个细节让我意识到，需求分析要深入到具体场景，而不是停留在功能列表。

我遇到的最大困难是流程图和原型页面之间的对应关系。一开始我画的流程图有“联系发布者”这一步，但原型里没有对应的页面或按钮，检查时才发现漏了。后来我们约定：流程图上的每一个节点，都必须在原型中找到对应界面。这个检查方法帮我们补上了“标记为已解决”和“我的页面”两个页面。

另外，我们在“联系发布者”的实现方式上有过分歧。我一开始想设计成站内聊天，但考虑到作业不要求即时聊天，而且实现难度相对较大，最终决定只展示发布者信息，由用户线下联系。这个取舍让我明白，设计要服务于后续实现，不能只追求理想效果。

通过这次作业，我最大的收获是学会了用流程图梳理逻辑、用原型验证流程。结对合作让我看到，两个人互相检查、互相提醒，确实能发现一个人容易忽略的问题。