软件工程第三次作业

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

成员一：032401339 沈冠宇
成员二：052402234 郭泽强

项目	内容
所属课程	2026秋软件工程与软件工程实践
作业要求	第三次作业
作业目标	结对完成校园失物招领小程序的需求分析与原型设计
原型工具与在线链接	Figma：点击体验校园拾光

一、教材学习与应用

《构建之法》第3章启发我关注交付质量：页面画完还要检查文字和流程。我们分解任务，用PSP记录时间。第3章资料

第8章强调分析用户问题、确定优先级并验证需求。我们聚焦发布、搜索、详情和状态修改，用Figma检查基本流程及异常反馈。第8章资料

作者的两人合作讲义强调交流与复核；实际结对过程见后文。

二、需求分析

校园失物信息散落在群聊中，容易被覆盖。“校园拾光”集中展示寻物与招领线索，并保留完成状态。

失主搜索招领或发布寻物；拾得者描述物品并留下联系方式；热心同学浏览、转告线索。完成交接后更新状态。

三、功能与原型设计

功能	原型中的做法
浏览与搜索	首页按寻物/招领筛选；输入关键词后查看结果或空结果提示
发布信息	分别填写寻物、招领；名称、地点、时间、描述、联系方式等为必填，图片选填
查看详情	展示物品特征、地点、时间、状态，并提示联系前核实信息
修改状态	在“我的发布”中确认后标记为“已找回”或“已归还”

Figma原型覆盖首页、发布、搜索、详情和“我的发布”；用固定样例演示必填提示、空结果及状态确认。

首页集中展示招领线索，并提供分类、搜索和发布入口。

四、操作流程

失主：丢失物品后，可以先通过搜索功能寻找已有招领信息；如果没有匹配结果，则可以发布寻物信息。找到物品后，用户可以修改状态，避免其他同学重复联系。

拾得者：拾到物品后，可以填写物品信息发布招领；失主联系后双方核实物品特征，完成归还后更新状态。

（1）整体操作流程

下图展示了校园拾光中失主和拾得者两类用户的主要操作流程，包括信息发布、搜索匹配、联系确认以及状态更新等步骤。

（2）查看招领信息

用户可以在首页浏览物品信息，并进入详情页面查看物品名称、图片、丢失地点、时间以及描述等关键内容，帮助用户判断是否为自己的物品。

（3）发布寻物信息

当用户未搜索到相关招领信息时，可以进入发布页面填写寻物信息。页面要求填写物品名称、丢失地点、时间、物品描述和联系方式等内容，保证信息完整。

（4）发布结果反馈

提交信息后，系统显示发布成功提示，并返回相关页面，使用户确认信息已经成功提交。

（5）搜索匹配

用户可以通过关键词搜索物品，例如输入“水杯”，系统展示匹配的失物或招领信息，帮助用户快速定位相关线索。

当搜索关键词没有对应信息时，例如搜索“紫色围巾”，系统提示暂无相关结果，并提供重新搜索或发布寻物信息的入口，避免用户无法继续操作。

（6）物品状态管理

为避免物品已经找回后仍被其他用户联系，系统提供状态修改功能。用户确认完成交接后，可以将寻物信息修改为“已找回”，将招领信息修改为“已归还”。

五、结对过程

本次分工确定为：我负责Figma页面与交互、流程图和博客整理；郭泽强负责用户需求、发布字段、状态规则、搜索边界及体验检查。双方共同讨论并交叉检查。

郭泽强指出交接后不更新状态会导致重复联系，建议加入“已找回/已归还”与修改前确认；发布须写明地点、时间和特征。我用“水杯”“紫色围巾”演示搜索结果，他建议保留重新搜索或发布寻物入口，以及“联系前核实”“交接后更新”。截图记录讨论；页面字段与三条跳转的最终复核仍待完成。

六、PSP与时间分析

单位为分钟，按本人投入统计。下列为参考估算，不是实测记录；实际耗时须本人核实后提交，不按作业开放天数折算。

PSP阶段	预估耗时	实际耗时（参考估算，待确认）
计划与任务分解	30	40
教材阅读与工具学习	60	80
需求分析	60	75
功能与流程设计	50	60
原型页面制作	150	185
交互配置与检查	70	95
博客整理与总结	60	65
合计	480	600

参考投入比计划多120分钟，差额主要分配给页面与交互检查。真实偏差待核实。

七、个人总结

本次作业中，我主要负责用户需求分析、功能规则设计和原型体验检查。在开始设计之前，我和队友先结合校园失物招领的实际场景分析用户需求，思考失主、拾得者以及普通浏览用户在使用过程中分别需要什么功能。在此基础上，我参与确定了发布信息需要填写的物品名称、地点、时间、描述和联系方式等内容，并对搜索、信息发布和物品状态修改等功能进行了梳理。

在原型讨论过程中，我比较关注用户操作是否完整以及不同情况下系统应该如何反馈。例如，用户搜索“水杯”时可以直接查看相关结果，而搜索“紫色围巾”没有结果时，也应该给用户提供重新搜索或发布寻物信息的选择，不能让用户停留在一个无法继续操作的页面。另外，在物品完成交接后，需要将信息修改为“已找回”或“已归还”，这样既可以及时更新信息，也可以减少其他用户重复联系的情况。通过这些细节的讨论，我认识到需求分析不仅是确定软件“有什么功能”，还需要考虑用户在实际使用过程中可能遇到的各种情况。

在与队友合作的过程中，我主要从功能需求和用户体验的角度提出修改意见，队友则负责将这些需求落实到Figma原型中。我们通过不断讨论和检查，对页面内容、操作流程和反馈方式进行调整。这个过程让我体会到，结对开发并不是简单地把任务分成两部分完成，而是需要双方不断沟通和相互检查，才能让最终的设计更加完整。

通过本次作业，我对需求分析、原型设计和软件工程中的用户思维有了更加具体的认识。以前在设计功能时容易只关注功能本身能不能实现，而这次作业让我开始更多考虑用户为什么需要这个功能、操作过程中可能遇到什么问题以及系统应该给予什么反馈。同时，我也认识到前期需求分析做得越清楚，后续的页面设计和开发就越容易进行。这次结对作业也提高了我的沟通、分析和发现问题的能力，为之后参与完整的软件开发项目积累了一定经验。