2026秋软件工程结对作业（第一次之需求分析和原型设计）
2026秋软件工程结对作业：校园失物招领小程序需求分析与原型设计
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 202601 软件工程 |
| 这个作业要求在哪里 | 结对作业要求 |
| 这个作业的目标 | 针对校园失物招领场景完成需求分析和原型设计 |
| 学号 | 102401411 |
| 原型链接 | 点击查看校园失物招领小程序原型 |
一、结对成员
| 学号 | 姓名 |
|---|---|
| 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号