软工第三次作业：校园失物招领小程序——需求分析与原型设计
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 软件工程 |
| 这个作业要求在哪里 | 软工第三次作业 |
| 这个这作业的目标 | 设计一个简单的“校园失物招领小程序” |
| 成员一 | 102402147郑宇嘉 |
| 成员二 | 102402146郑仕廷 |
一、阅读学习
本次作业前，我们阅读了《构建之法》第3章和第8章的相关内容。第3章强调软件工程师需要具备有效交流、与人合作的能力，结对合作有助于提高效率、相互学习。第8章介绍了NABCD需求分析模型和快速原型调研方法，提醒我们应基于“用户是谁、什么场景、什么问题”来确定功能范围。这为本次“先理清需求、再画原型”的协作思路提供了方法指导。
二、用户需求分析
在校园日常生活中，物品遗失是高频事件。校园卡、钥匙、水杯、雨伞、耳机、书籍等物品在图书馆、食堂、教学楼、运动场等地频繁丢失。然而，目前的失物招领信息主要依赖于班级群、宿舍群、朋友圈等社交渠道发布，存在几个极为明显的痛点：
- 信息高度分散：拾获者与失主往往不在同一个群聊中，信息难以跨群触达。例如，一名同学在图书馆捡到校园卡，发在班级群里，但失主可能是另一个学院的学生，根本看不到这条消息。
- 信息极易沉没：群聊消息更新频繁，寻物或招领信息很容易被后续的聊天内容覆盖，导致需要的人看不到，事后查找更是如同大海捞针。
- 缺乏检索手段：社交群聊是线性的信息流，无法按物品名称、丢失地点、时间等维度进行搜索和分类筛选，导致寻找效率极低。
本软件主要面向两类核心用户：
- 失主（寻物者）：需求是快速发布丢失信息（如物品名称、丢失时间、地点），并能通过关键词搜索，看看是否有好心人已经发布了招领信息，最后能通过留下的联系方式迅速找回物品。
- 拾获者（招领者）：需求是能够便捷地发布捡到的物品信息，并希望通过平台能让失主准确看到，避免“好心办坏事”或者嫌麻烦而放弃发布。
此外，还有大量潜在浏览者，他们平时会习惯性地浏览信息，防患于未然，或者确认是否有自己遗失但尚未察觉的物品。
本软件主要解决的问题：将原本碎片化、私域化的社交群聊信息，集中到一个公开、透明、可检索的校园平台上。它打破了班级和宿舍的物理界限，将信息传递范围扩大到全校；同时，通过结构化的字段设计（类别、地点、时间、关键词）和搜索功能，让“找东西”从“碰运气刷屏”变成“精准搜索匹配”，极大提升校园失物寻找和归还的效率。为了确保后续结对编程能顺利实现，本软件不追求复杂功能，只聚焦于最核心的“发布、浏览、搜索、详情”闭环。
三、主要功能
- 浏览失物和招领信息——首页按“全部/寻物/招领”分类查看；
- 发布寻物信息——填写物品名称、地点、时间、联系方式；
- 发布招领信息——与寻物共用发布流程，通过类型切换；
- 按关键词搜索物品；
- 查看物品详情——展示完整信息与联系方式；
- 在“我的发布”中修改状态，如“已找到/已归还”。
暂不实现即时聊天、地图定位、实名认证和复杂后台管理，保证后续结对编程容易实现。
四、原型开发工具与在线链接
- 原型开发工具：墨刀（Modao）
- 在线链接：点击查看墨刀原型
说明：点击链接可查看首页、发布页、搜索页、信息详情页，并可演示“首页 → 查看详情”“发布信息 → 发布成功”“搜索物品 → 查看搜索结果”的基本流程。
五、页面设计说明
| 页面 | 主要内容 |
|---|---|
| 首页 | 顶部搜索框；“全部/寻物/招领”分类Tab；信息卡片列表，显示物品名称、地点、时间、状态；底部导航：首页、发布、我的 |
| 发布信息 | 选择“寻物/招领”；填写物品名称、地点、时间、描述、联系方式；点击发布 |
| 搜索页面 | 输入关键词；按类型、地点筛选；展示搜索结果；无结果时给出提示 |
| 信息详情 | 展示物品名称、类型、地点、时间、描述、发布者；按钮“联系TA”“标记完成” |
| 我的发布 | 查看自己发布的信息；修改状态；删除信息 |
六、基本流程图
七、程序展示
八、结对过程
两名同学先阅读《构建之法》第3章、第8章，明确结对合作和需求分析方法。随后讨论用户痛点，确定只做“浏览、发布、搜索、详情、我的发布”五个核心模块。分工上，同学102402147负责首页、搜索页和流程图；同学102402146负责发布页、详情页和“我的发布”。最后共同检查跳转流程和文字说明。
九、PSP表格
| 任务 | 预估耗时/分钟 | 实际耗时/分钟 |
|---|---|---|
| 阅读教材 | 30 | 35 |
| 需求分析 | 30 | 25 |
| 绘制流程图 | 20 | 20 |
| 原型设计 | 90 | 110 |
| 博客撰写 | 60 | 70 |
| 结对讨论 | 20 | 25 |
| 检查提交 | 10 | 10 |
| 合计 | 260 | 295 |
十、个人总结
同学102402147： 本次结对作业让我学会了先分析用户需求，再设计页面，而不是直接画界面。我主要负责首页和搜索页，遇到的问题是如何让搜索筛选既简单又实用，后来只保留关键词、类型和地点。通过结对讨论，我认识到原型要服务于后续实现，不能一味增加功能。
同学102402146： 我主要负责发布页、详情页和“我的发布”。收获是了解了原型工具的基本使用，也体会到流程清晰比界面复杂更重要。遇到的问题是发布字段过多会增加填写负担，最后精简为名称、类型、地点、时间、描述和联系方式。结对过程中，我们通过互相检查发现并修正了页面跳转不完整的问题。
十一、后续开发计划
本次作业已完成需求分析与原型设计，第二次结对作业将基于此原型进行代码实现。为了确保项目顺利落地，我们制定了以下后续开发计划：
1. 技术选型与架构
- 前端：微信小程序原生开发（WXML + WXSS + JS），与原型设计保持高度一致。
- 后端：初期采用微信云开发（云数据库 + 云函数），免去复杂的服务器搭建，降低开发门槛，便于快速实现数据的增删改查。
- 数据存储：设计简单的
items集合，字段包括：物品名称、类型（寻物/招领）、地点、时间、描述、联系方式、发布者、状态（进行中/已完成）。
2. 开发阶段划分
- 第一阶段：环境搭建与基础框架（预计1天）
- 在GitHub上创建组织或仓库，初始化小程序项目结构。
- 配置微信开发者工具与云开发环境。
- 第二阶段：核心页面开发（预计3天）
- 实现首页信息列表渲染、分类Tab切换。
- 实现发布页表单提交与数据写入云数据库。
- 实现搜索页关键词查询与结果展示。
- 实现详情页数据读取与“联系TA”“标记完成”按钮。
- 第三阶段：数据交互与联调（预计1天）
- 前后端数据对接，确保发布后首页能实时刷新，搜索能准确匹配。
- 测试边界情况，如搜索无结果、发布内容为空等。
- 第四阶段：测试与优化（预计1天）
- 两人交叉测试，修复Bug，优化界面细节与交互体验。
3. GitHub 协作规范
- 分支管理：
main分支作为稳定版本，dev分支用于日常开发，各自在feature-xxx分支上完成具体功能后，发起 Pull Request 合并到dev。 - 提交规范：每次提交写明具体改动，如
feat: 完成首页列表渲染或fix: 修复发布页时间格式错误。 - 代码审查：两人互相Review代码，确保逻辑正确、命名规范后再合并。
4. 风险控制
- 功能蔓延：严格遵循原型设计，坚决不添加即时聊天、地图定位等复杂功能，保证核心流程闭环。
- 进度延期：每日同步进度，如遇技术难点及时沟通，必要时简化非核心功能，确保项目按期交付。
浙公网安备 33010602011771号