2026秋软件工程结对作业（第一次）

2026 秋软件工程个人作业（第三次）——“校园拾光”需求分析与原型设计

项目	内容
这个作业属于哪个课程	H202601软件工程与软件工程实践
这个作业要求在哪里	2026秋软件工程个人作业(第三次)
这个作业的目标	完成校园失物招领小程序原型开发，学习结对合作、需求分析与原型设计，实现物品发布、详情查看、地图检索标记等功能，掌握墨刀原型制作与流程图绘制方法
结对成员	102402103吴雅晴；102402101章玲
原型设计链接（墨刀）	校园拾光在线原型

《构建之法》读后感

通过两章节的学习，我建立了标准化的软件工程前期开发思维。结对合作解决了“团队如何高效协作”的问题，让我明白软件开发是团队协作的产物，沟通与互补是项目高效推进的关键；需求分析与原型设计解决了“软件为何开发、如何设计”的问题，让我摒弃了盲目开发的误区，养成了先调研、再分析、后设计的规范化开发习惯。

一、项目背景与需求分析

校园卡、钥匙、耳机等物品丢失后，相关消息常散落在班级群、宿舍群或朋友圈中，容易被新消息覆盖，失主与拾获者也可能处于不同的信息圈。我们因此设计“校园拾光”校园失物招领小程序，把寻物、招领、浏览和搜索集中到统一入口。

平台面向三类用户：失主需要快速发布物品名称、遗失地点、时间、描述和图片，并搜索招领信息；拾获者需要发布拾取地点、时间和联系方式；普通浏览者需要查看最新信息，并按关键词或类别筛选。三类用户的共同诉求是入口清楚、填写简单、反馈及时。

考虑到下一次作业要真正实现小程序，本次不加入地图定位、实名认证、即时聊天和 AI 推荐，只保留前端页面与基础数据增删改查能够完成的功能。

二、功能与原型设计

原型包括六个页面：首页展示分类和最新信息；发布页选择“寻物/招领”，填写名称、地点、时间、描述和图片；搜索页提供关键词输入与结果列表；详情页展示完整信息；发布成功页给予反馈；“我的发布”用于查看个人记录。搜索既可由首页搜索入口进入，也可作为后续编码时的独立功能模块。

使用简单流程图描述用户使用软件的基本过程：

从主页进入发布页面 → 选择丢失/拾取类型 → 填写物品信息 → 点击发布，发布成功

此外，还有搜索页面和我的发布页面：

三、结对分工与协作

我负责墨刀页面搭建、视觉规范、卡片与表单设计；章玲负责需求分析、功能边界、流程图、交互检查和博客整合。完成初稿后，两人交叉评审：我检查流程是否闭环，吴雅晴检查布局、字号和样式是否统一，问题确认后共同修改并复测。这种“各自主责—交换检查—共同定稿”的方式兼顾了个人能力与团队协作。

以下是我们讨论需求、绘制流程图、制作原型时的照片：

五、PSP 表

PSP 阶段	我预计/实际（分钟）	吴雅晴预计/实际（分钟）
计划与需求理解	35 / 40	35 / 40
需求或视觉设计	70 / 85	80 / 95
流程或页面搭建	90 / 110	170 / 210
交互检查与统一修改	70 / 95	70 / 90
博客、截图与材料整理	80 / 95	50 / 60
结对讨论与复盘	45 / 55	45 / 55
合计	390 / 480	450 / 550

六、个人总结

本次结对项目是校园失物招领小程序，我主要负责PSP 表格、视觉规范、卡片与表单设计以及墨刀原型制作。我结合《构建之法》用户故事思想梳理功能需求，使用墨刀搭建包含地图检索功能的交互原型，完成页面布局与跳转交互。过程中遇到需求边界不清晰、墨刀导航组件交互难以设置、前期时间预估偏差等问题，通过和搭档沟通逐步解决。本次实践让我掌握原型设计与需求分析方法，体会 PSP 对时间管理的作用，理解结对合作的意义，也认识到前期设计能够提前规避开发问题。

七、后续实现

下一次编码将优先实现信息列表、发布表单、关键词搜索、详情查看和状态修改，数据字段直接沿用本次原型；图片先采用小程序云存储或临时图片方案，联系方式使用文本展示。代码协作计划使用 GitHub 功能分支、Pull Request 和交叉测试，减少合并冲突。