软工第三次作业：校园失物招领小程序——需求分析与原型设计

项目	内容
这个作业属于哪个课程	软件工程
这个作业要求在哪里	软工第三次作业
这个这作业的目标	设计一个简单的“校园失物招领小程序”
成员一	102402147郑宇嘉
成员二	102402146郑仕廷

一、阅读学习

本次作业前，我们阅读了《构建之法》第3章和第8章的相关内容。第3章强调软件工程师需要具备有效交流、与人合作的能力，结对合作有助于提高效率、相互学习。第8章介绍了NABCD需求分析模型和快速原型调研方法，提醒我们应基于“用户是谁、什么场景、什么问题”来确定功能范围。这为本次“先理清需求、再画原型”的协作思路提供了方法指导。

二、用户需求分析

在校园日常生活中，物品遗失是高频事件。校园卡、钥匙、水杯、雨伞、耳机、书籍等物品在图书馆、食堂、教学楼、运动场等地频繁丢失。然而，目前的失物招领信息主要依赖于班级群、宿舍群、朋友圈等社交渠道发布，存在几个极为明显的痛点：

1. 信息高度分散：拾获者与失主往往不在同一个群聊中，信息难以跨群触达。例如，一名同学在图书馆捡到校园卡，发在班级群里，但失主可能是另一个学院的学生，根本看不到这条消息。
2. 信息极易沉没：群聊消息更新频繁，寻物或招领信息很容易被后续的聊天内容覆盖，导致需要的人看不到，事后查找更是如同大海捞针。
3. 缺乏检索手段：社交群聊是线性的信息流，无法按物品名称、丢失地点、时间等维度进行搜索和分类筛选，导致寻找效率极低。

本软件主要面向两类核心用户：

• 失主（寻物者）：需求是快速发布丢失信息（如物品名称、丢失时间、地点），并能通过关键词搜索，看看是否有好心人已经发布了招领信息，最后能通过留下的联系方式迅速找回物品。
• 拾获者（招领者）：需求是能够便捷地发布捡到的物品信息，并希望通过平台能让失主准确看到，避免“好心办坏事”或者嫌麻烦而放弃发布。

此外，还有大量潜在浏览者，他们平时会习惯性地浏览信息，防患于未然，或者确认是否有自己遗失但尚未察觉的物品。

本软件主要解决的问题：将原本碎片化、私域化的社交群聊信息，集中到一个公开、透明、可检索的校园平台上。它打破了班级和宿舍的物理界限，将信息传递范围扩大到全校；同时，通过结构化的字段设计（类别、地点、时间、关键词）和搜索功能，让“找东西”从“碰运气刷屏”变成“精准搜索匹配”，极大提升校园失物寻找和归还的效率。为了确保后续结对编程能顺利实现，本软件不追求复杂功能，只聚焦于最核心的“发布、浏览、搜索、详情”闭环。

三、主要功能

1. 浏览失物和招领信息——首页按“全部/寻物/招领”分类查看；
2. 发布寻物信息——填写物品名称、地点、时间、联系方式；
3. 发布招领信息——与寻物共用发布流程，通过类型切换；
4. 按关键词搜索物品；
5. 查看物品详情——展示完整信息与联系方式；
6. 在“我的发布”中修改状态，如“已找到/已归还”。

暂不实现即时聊天、地图定位、实名认证和复杂后台管理，保证后续结对编程容易实现。

四、原型开发工具与在线链接

• 原型开发工具：墨刀（Modao）
• 在线链接：点击查看墨刀原型

说明：点击链接可查看首页、发布页、搜索页、信息详情页，并可演示“首页 → 查看详情”“发布信息 → 发布成功”“搜索物品 → 查看搜索结果”的基本流程。

五、页面设计说明

页面	主要内容
首页	顶部搜索框；“全部/寻物/招领”分类Tab；信息卡片列表，显示物品名称、地点、时间、状态；底部导航：首页、发布、我的
发布信息	选择“寻物/招领”；填写物品名称、地点、时间、描述、联系方式；点击发布
搜索页面	输入关键词；按类型、地点筛选；展示搜索结果；无结果时给出提示
信息详情	展示物品名称、类型、地点、时间、描述、发布者；按钮“联系TA”“标记完成”
我的发布	查看自己发布的信息；修改状态；删除信息

六、基本流程图

flowchart TD A[进入首页] --> B{选择操作} B -->|浏览| C[查看信息列表] C --> D[查看物品详情] D --> E[联系发布者] B -->|发布| F[进入发布页面] F --> G[填写物品信息] G --> H[点击发布] H --> I[发布成功] B -->|搜索| J[输入关键词] J --> K[查看搜索结果] K --> D

七、程序展示

八、结对过程

两名同学先阅读《构建之法》第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. 风险控制

• 功能蔓延：严格遵循原型设计，坚决不添加即时聊天、地图定位等复杂功能，保证核心流程闭环。
• 进度延期：每日同步进度，如遇技术难点及时沟通，必要时简化非核心功能，确保项目按期交付。