软件工程第一次结对作业

项目	内容
这个作业属于哪个课程	202601 软件工程
这个作业要求在哪里	2026秋软件工程结对作业（第一次之需求分析和原型设计）
这个作业的目标	分析校园失物招领需求，制作能演示浏览、发布、搜索流程的原型
结对成员（学号、姓名）	162404103 蔡信坡；162404109 杜玉鹤
原型工具与在线展示	墨刀；打开“拾光 · 校园失物招领”在线原型

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

一、问题与用户

校园卡、钥匙等物品遗失后，同学们通常在群聊或朋友圈发布消息，消息容易被覆盖，失主也难以逐个查找。因此我们设计了校园失物招领小程序“拾光”，将发布、浏览和搜索集中到一个入口。

需求分析以作业给定的校园场景为依据。主要用户是失主和拾获者，同一学生可兼两种角色：失主搜索线索、发布寻物；拾获者说明物品特征、时间和地点，便于核对后归还。

二、需求与功能

以丢失校园卡为例，用户先搜索“校园卡”，根据时间、地点和描述核对物品，找到线索后查看联系方式；没有线索时发布寻物信息。

功能	设计内容
浏览	卡片展示物品名称、地点、时间和状态
发布	区分寻物与招领，设置名称、时间、地点、描述和联系方式
搜索	按物品名称查找，结果关联对应详情
详情	展示物品特征，提供查看联系方式的入口
状态	在“我的发布”中把信息标记为已找到

参照《构建之法》第 8 章的需求分析方法，我们先判断这件事值不值得做：校园信息分散、失主找不到招领是需求；把发布和检索收进同一个小程序是做法；按物品名直接检索、不受群消息刷屏影响是好处；相比群聊与朋友圈，信息不会沉底是优势。据此把浏览、发布、搜索、详情列为必需功能，“我的发布”用于修改信息状态，真实数据存储留到后续开发。

三、已完成的原型与流程

“拾光”的八页墨刀交互原型已完成，包括首页、发布寻物、发布成功、搜索、搜索结果、校园卡详情、联系方式和我的发布，覆盖作业要求的四类基本页面。

原型展示链接：拾光 · 校园失物招领（墨刀演示）

页面采用绿色与米白色搭配：首页展示识别物品所需信息，详情补充描述，发布成功页给出操作反馈。

原型围绕三条核心流程组织：

1. 浏览：首页 → 校园卡详情 → 查看联系方式。
2. 发布：发布寻物 → 核对示例信息 → 点击发布 → 发布成功。
3. 搜索：搜索页面 → 校园卡示例 → 搜索结果 → 对应详情。

演示使用固定样例，表单为预填值，结果为预设页面。

四、阅读与结对过程

本次分工如下：

成员	主要工作
杜玉鹤	用户需求、字段整理、墨刀页面搭建和发布流程
蔡信坡	流程梳理、搜索与详情连线、交互检查和配图整理
共同参与	范围讨论、页面复核、博客整理与总结

制作中把八个画面分别建为独立页面，再设置点击区域和跳转目标，这样可以沿浏览、发布、搜索逐项检查，减少遗漏入口和结果页。

结合《构建之法》第 3 章关于两人合作的讨论，我认为原型制作也适合让操作与检查相互配合：操作时关注页面搭建，检查时从用户入口追踪结果，并交换视角。第 8 章的需求分析则提醒我们先定优先级，必需路径能演示之后再考虑辅助功能。

五、PSP

单位：分钟。“实际”栏按工作量估算，非逐项计时。

阶段	预估	实际（估算）
计划	20	20
阅读与讨论	35	40
需求分析	40	40
流程与页面设计	35	45
墨刀原型与交互	80	90
互审与修改	40	50
博客整理	30	35
总结与提交	20	20
合计	300	340

估算投入比原计划多 40 分钟，主要增加在页面设计、连线和复核。

六、个人总结

这次作业让我更关注用户能否顺着页面完成一件事。搜索结果应对应同一物品，详情需要给出联系入口，发布后也应有明确反馈。过程中也遇到问题：第一次连线时漏设了搜索结果到详情的跳转，复查时才补上，这说明对照三条流程检查比只看单张页面更容易发现缺漏。后续开发中，我会把这些路径整理成检查用例，与搭档通过 GitHub 互审，补充空关键词、无结果和必填项缺失等情况。