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

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

项目	内容
姓名	章玲
学号	102402101
结对同学	吴雅晴（102402103）
原型工具	墨刀
课程链接	H202601软件工程与软件工程实践
作业要求链接	2026 秋软件工程个人作业（第三次）
在线原型	校园拾光在线原型

《构建之法》读后感

读完《构建之法》的第3章和第8章，我对软件工程有了更务实的认识。以前总觉得开发软件的核心就是敲代码，只要功能实现就行。但这两章让我意识到，结对合作、需求分析和原型设计才是决定项目能否顺利推进的基础。以下是我对这三个方面基本方法的学习体会。

首先是结对合作。它的基本方法并不是把任务简单拆成两半各自去写，而是两人共用一台电脑，交替扮演“驾驶员”和“领航员”的角色。驾驶员专注于具体的代码输入和实现，领航员则负责观察整体思路、检查代码规范以及寻找潜在的逻辑漏洞。两人定期交换角色，通过这种持续的复审机制，很多低级错误在编码阶段就能被发现。这种方法不仅能有效减少个人的思维盲区，还能促进团队成员之间的知识共享，让代码成为团队共同维护的资产。

其次是需求分析。这部分让我学到了不能只做用户需求的“传声筒”。用户提出来的要求往往只是表面的解决方案，并不等同于他们真实的痛点。需求分析的基本方法要求我们跳出文档，通过访谈、问卷、实地观察等手段，去了解用户的实际使用场景。同时，还要识别不同利益相关者的诉求，对收集到的信息进行整理和判断，最终确定功能的优先级。只有弄清楚了“做什么”和“为什么做”，后续的开发才不会跑偏。

最后是原型设计。它是连接需求与开发的桥梁，其基本方法是在正式写代码之前，利用草图、线框图或简单的静态页面等低成本方式，将抽象的想法具象化。原型不需要多精细，核心目的是让用户能够直观地“看到”和“试用”。通过这种方式，我们可以尽早验证设计思路是否合理，发现需求理解上的偏差。因为在原型阶段修改，成本远低于系统开发完成后再返工。

总的来说，这两章让我明白了软件开发是一个不断沟通和验证的过程。在接下来的作业中，我会尝试运用这些基本方法：先与搭档明确合作方式，做足需求分析，用简单的原型确认方向，然后再开始编写代码。把这些前期基础工作做扎实，后续的开发才会更加顺畅。

一、项目背景与需求分析

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

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

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

二、功能与原型设计

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

1. 首页

首页包含品牌标题、搜索入口、寻物/招领分类、最新信息卡片和底部导航。用户打开小程序后可以直接浏览信息，也可以按类型筛选。

图 1　首页原型

2. 发布信息页

发布页支持选择“丢失物品”或“拾到物品”，填写名称、地点、时间和详细描述，并可上传图片。点击“提交发布”后进入成功反馈页。

图 2　发布信息页原型

3. 搜索页面

搜索页提供“物品名称/地点”关键词输入框和结果列表，点击“钥匙”等结果卡片可继续进入物品详情。

图 3　搜索页面原型

4. 物品详情页

详情页集中展示物品图片、类别、地点、时间、描述、发布者及联系入口，并提供“标记已认领”操作，使查看信息的流程形成闭环。

图 4　物品详情页原型

5. 发布成功页

提交后显示明确的“发布成功”反馈，并提供返回首页入口，使发布任务有清楚的结果提示。

图 5　发布成功页原型

6. 我的发布

“我的发布”集中展示本人发布的寻物与招领记录，后续实现时可继续扩展修改状态和删除功能。

图 6　我的发布页面原型

三、用户使用流程和流程图示例

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

流程图：

四、结对分工与协作

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

图 8　结对成员讨论原型问题与修改方案

图 9　墨刀团队邀请及在线原型分享记录

五、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

六、个人总结

这次作业让我认识到，需求分析不能停留在“需要哪些页面”，还要落实到字段、状态、入口和跳转。检查原型时，我发现页面已经画出来并不代表流程真正闭环，例如提交按钮缺少反馈、导航名称与目标不一致都会影响使用。最大的困难是控制功能边界：既要满足真实场景，又要保证下一次可以编码实现。通过与队友交叉评审，我学会了用用户任务检验设计，并在需求完整性和开发成本之间做取舍。

七、后续实现

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