软件工程第一次结对作业之需求分析和原型设计
2026秋软件工程结对作业：校园失物招领小程序需求分析与原型设计
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 202601 软件工程 |
| 这个作业要求在哪里 | 结对作业要求 |
| 这个作业的目标 | 针对校园失物招领场景完成需求分析和原型设计 |
| 学号 | 102401409 |
| 原型链接 | 点击查看校园失物招领小程序原型 |
一、结对成员
| 学号 | 姓名 |
|---|---|
| 102401409 | 陈宝荣 |
| 102401411 | 陈博淇 |
本次作业采用结对合作方式完成。在完成作业前，我们阅读了《构建之法》第3章和第8章的相关内容，并尝试将结对协作、需求分析以及原型设计的方法应用到实际设计过程中。
二、需求分析
1. 项目背景
在校园生活中，校园卡、钥匙、耳机、水杯、雨伞等物品遗失的情况十分常见。目前同学们通常通过班级群、宿舍群、朋友圈等渠道发布寻物或招领信息，但这种方式存在几个明显的问题：
- 信息分散在不同群聊中，失主和拾取者可能无法互相看到信息；
- 群聊消息更新速度快，寻物和招领信息很容易被后续消息覆盖；
- 缺少统一的搜索方式，无法根据物品名称、地点等信息快速查找；
- 物品已经找回后，原有信息缺少明确的状态管理。
因此，我们希望设计一个简单的校园失物招领小程序，将校园内的寻物和招领信息集中展示，提高信息匹配和物品归还的效率。
2. 目标用户
软件主要面向校内学生，同时也可以供有失物招领需求的教职工使用。
用户的主要需求包括：
- 浏览校园内最新的寻物和招领信息；
- 发布自己的寻物或招领信息；
- 根据物品名称、类别等关键词搜索；
- 查看物品的详细信息和联系方式；
- 在物品找回后修改发布信息的状态。
三、功能设计
考虑到第二次结对作业需要基于本次原型继续进行代码实现，我们没有加入即时聊天、地图定位、实名认证等复杂功能，而是围绕失物招领的核心流程进行设计。
主要功能包括：
- 信息浏览：首页集中展示寻物和招领信息，并可以通过“全部、寻物大厅、招领大厅”进行切换。
- 搜索与分类：在“发现”页面输入物品名称进行搜索，并可以按照数码电子、卡片证件、交通工具等类别筛选。
- 发布信息：填写物品名称、丢失或拾取地点、详细描述并上传图片后发布。
- 查看详情：查看物品图片、发布时间、地点、描述及发布者等信息。
- 联系方式保护：点击“获取联系方式”后先展示安全与隐私保护提示，再进行后续联系。
- 我的发布：查看自己曾经发布的信息，并在物品找回后将其标记为“已解决”。
在核心需求之外，我们还加入了一个轻量级的防重复设计。当用户发布信息时，如果系统发现地点和物品特征相似的已有信息，会提示用户先查看可能匹配的物品；如果并非自己的物品，则可以继续完成发布。
四、基本使用流程
1. 浏览并查看详情
该流程对应最基本的“查看信息 → 查看详情”需求。
2. 发布信息
该流程完整展示了“发布信息 → 发布成功”。
3. 搜索物品
该流程对应“搜索物品 → 查看搜索结果”。
五、原型设计
本次原型使用 Figma 完成。
原型在线展示链接：
目前原型主要包含：首页、发布信息、信息详情、发现/搜索、我的发布、相似信息提示、发布成功提示以及安全隐私提示等页面和状态。
1. 首页
首页采用卡片式布局展示校园中的寻物和招领信息，并通过“全部、寻物大厅、招领大厅”进行分类。
用户点击物品卡片即可进入详情页面；底部导航栏可以进入首页、发现、发布和我的四个主要模块。
2. 发布信息页面
发布页面主要填写：
- 物品名称；
- 丢失/拾取地点；
- 详细描述；
- 物品照片。
完成填写后点击“确认发布”。
为了减少重复信息，在确认发布之后，如果发现已有相似招领信息，会提示用户先进行核对。
如果确认并非自己的物品，则继续完成发布，并显示“发布成功”。
3. 发现与搜索页面
“发现”页面提供关键词搜索以及类别筛选功能。
用户可以根据物品名称进行搜索，也可以通过数码电子、卡片证件等类别缩小范围，点击结果卡片后进入物品详情。
4. 信息详情页面
详情页面展示物品图片、招领/寻物类型、物品名称、发布时间、地点、详细描述及发布者等信息。
为了避免直接公开联系方式，我们设计了“获取联系方式”按钮。用户点击后首先看到安全与隐私保护提示，再继续联系发布者。
5. 我的发布
“我的”页面用于查看用户已经发布的信息，并显示已发布数量和已找回/归还数量。
对于已经完成归还的物品，可以修改状态为“已解决”，形成从发布到找回的完整业务闭环。
六、结对过程
本次作业采用结对方式完成。
在需求分析阶段，我们首先根据题目给出的校园场景讨论用户真正需要解决的问题，并将功能范围控制在浏览、发布、搜索、查看详情和状态管理等核心功能内。
在原型设计阶段，我们共同讨论页面结构和交互流程，并使用 Figma 完成页面设计。初版原型完成后，又对页面之间的跳转关系进行检查，重点保证以下三条流程能够完整演示：
- 首页浏览信息 → 查看物品详情；
- 发布信息 → 相似信息检查 → 发布成功；
- 搜索物品 → 查看搜索结果 → 查看详情。
在原型复审过程中，我们还针对信息重复和联系方式直接公开的问题进行了讨论，因此增加了相似信息提示和安全隐私提示，但没有继续扩大功能范围，以保证下一次代码实现的可行性。
七、PSP 表格
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 30 | 40 |
| Estimate | 估计任务所需时间 | 30 | 40 |
| Development | 开发 | 380 | 420 |
| Analysis | 需求分析 | 60 | 80 |
| Design Spec | 功能及流程设计 | 60 | 50 |
| Design Review | 两人进行设计复审 | 20 | 30 |
| Prototyping | 学习 Figma 并制作原型 | 180 | 200 |
| Prototype Review | 原型及交互流程复审 | 30 | 30 |
| Documentation | 撰写博客 | 30 | 30 |
| Reporting | 报告与总结 | 50 | 60 |
| Test Report | 总结与反思 | 30 | 40 |
| Size Measurement | 工作量统计 | 10 | 10 |
| Postmortem | 最终检查与提交 | 10 | 10 |
| 合计 | 460 | 520 |
八、个人总结
通过本次结对作业，我对软件开发中的需求分析和原型设计有了更加具体的认识。以前容易直接从“要做哪些页面”开始思考，而这次需要先从校园失物招领的现实问题出发，再将用户需求转化为具体的软件功能。
在与队友讨论的过程中，我们也不断删除不必要的功能，尽量保证每一个页面和交互都能够服务于核心需求。Figma 原型制作过程中，对页面布局和交互连接的不断调整也让我认识到，原型不仅要好看，更重要的是让用户能够清楚地完成操作。
九、本次作业小结
通过本次结对作业，我们完成了从现实问题分析、用户需求提取、功能设计、流程设计到 Figma 原型制作的完整过程。
最终原型围绕“浏览、搜索、发布、查看详情、联系发布者和状态管理”形成了较完整的校园失物招领流程，同时保留了相似物品提示和隐私保护两个轻量级辅助设计。
下一次结对编程将继续以本次原型为基础进行实现。在后续开发过程中，我们计划使用 GitHub 进行版本管理和结对协作，在保证核心功能能够实现的基础上，再根据实际开发情况逐步完善细节。
浙公网安备 33010602011771号