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

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

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

一、教材学习与应用

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

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

二、需求分析

群聊中的失物信息容易被覆盖。“校园拾光”集中展示线索和完成状态。

失主搜索或发布寻物；拾得者发布招领；其他同学可浏览、转告。交接后更新状态。

三、功能与原型设计

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

Figma以固定样例演示上述功能。

四、操作流程

失主：丢失→搜索或发布寻物→核实信息→找回后更新状态。

拾得者：拾到物品→发布招领→联系核实→归还后更新状态。

可点击演示：首页→详情、发布→成功、搜索→结果；详情提示核对特征。

“紫色围巾”无结果时，可重搜或发布寻物。

五、结对过程

分工：我负责Figma页面与交互、流程图、博客；郭泽强负责需求、字段、状态、搜索及体验检查。两人共同讨论。

郭泽强提出“已找回/已归还”及确认操作，避免交接后重复联系；发布须写明地点、时间、特征。我演示“水杯”有结果、“紫色围巾”无结果，他建议保留重搜、发布入口及“联系前核实”“交接后更新”。下图记录讨论；最终复核仍待完成。

六、PSP与时间分析

单位：分钟。实际耗时为参考估算，提交前须核实。

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

参考估算比计划多120分钟，主要用于原型与交互检查。

七、个人总结

这次作业重在需求分析和原型设计。我起初觉得功能越多越好，梳理失主和拾得者的需求后，才发现信息易找、字段清楚、交接后更新状态更重要。于是我们保留浏览、搜索、发布、详情和状态管理，没有加入聊天、定位等复杂功能。
我负责Figma页面、交互和流程图。制作时遇到中文字体显示不一致，我逐页调整；有些页面单独看没问题，连成流程才发现缺少反馈。比如漏填发布信息应提示，搜索“紫色围巾”无结果应给下一步入口，修改状态前应确认。我借助AI工具把问题整理成检查点，再补充相应画面，沿“首页→详情”“发布→成功”“搜索→结果”逐项点击核对。郭泽强提醒我联系前核实物品特征、交接后更新状态，让流程覆盖处理结果。
我以前更在意界面能不能画出来，这次开始关注用户是否知道下一步。《构建之法》第3章让我意识到检查与修改也要计入估时，第8章提醒我先抓核心需求。不足是前期没列全异常情况，后来才补页面。以后我会先画用户路径，再做原型并留时间检查。