2026秋软件工程结对作业(第一次之需求分析和原型设计)
软件工程第一次结对作业:校园失物招领小程序 · 需求分析与原型设计
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | https://edu.cnblogs.com/campus/fzu/202601SofwareEngineering |
| 这个作业要求在哪里 | https://edu.cnblogs.com/campus/fzu/202601SofwareEngineering/homework/16743 |
| 这个作业的目标 | 完成"校园失物招领小程序"的需求分析与原型设计 |
| 学号 / 姓名(同学 A) | 102401331 / 林明亮 |
| 学号 / 姓名(同学 B) | 102401330 / 高一鹏 |
| 原型在线演示链接 | https://4m584fkf72pzf.doubaoapps.com/app/app_17ezr2jmthq |
一、需求分析
1. 问题背景与用户分析
在校园生活中,遗失校园卡、钥匙、水杯、雨伞、耳机、书籍等情况十分常见。目前同学们主要通过班级群、宿舍群和朋友圈发布寻物、招领信息,但信息分散、易被新消息覆盖,丢失者往往看不到捡到者发布的招领信息。软件的主要用户有两类:寻物者(丢失物品、希望尽快找回的学生)与招领者(捡到物品、希望归还失主的学生)。他们的核心诉求一致:快速发布信息、快速找到匹配信息、建立联系。
2. NABCD 需求分析
结合《构建之法》第 8 章的需求分析方法,用 NABCD 模型梳理:
- N(需求):寻物与招领信息分散、易被覆盖、难以检索,缺少统一的集中发布与查找渠道;
- A(做法):集中发布寻物、招领信息,支持关键词搜索与分类筛选,提供联系方式与状态管理;
- B(好处):信息集中、持续可查,显著提高物品找回与归还效率;
- C(竞争):相比班级群、朋友圈,信息结构化、可持续、可搜索,功能聚焦单一场景;
- D(差异化):面向校园轻量设计,无需注册,发布与查找三步完成。
3. 主要功能
- 浏览失物与招领信息(首页信息流,可切换寻物 / 招领分类);
- 发布寻物信息、发布招领信息(发布页,区分两种类型);
- 搜索物品(按名称关键词实时搜索,支持类型筛选);
- 查看物品详情(地点、时间、描述、联系方式);
- 修改信息状态("我的发布"中标记已找到 / 已归还、删除信息)。
二、原型设计
1. 原型开发工具与在线链接
原型采用 HTML / CSS / JavaScript 制作的高保真可交互原型,页面结构与交互逻辑与墨刀、Figma 等高保真原型一致,无需安装、在浏览器中即可点击演示全部流程。我们选择该方式的原因:一是零安装、在线即可演示,方便两人远程协作走查;二是交互完整,能真实演示发布、搜索、状态修改等操作,便于后续结对编程直接参考。
原型在线演示链接: https://4m584fkf72pzf.doubaoapps.com/app/app_17ezr2jmthq(底部导航可切换"首页 / 发布 / 我的")。
2. 页面设计
原型包含首页、搜索页、信息详情页、发布页、发布成功页、"我的发布"页六个页面。整体采用清新绿色调,突出校园互助氛围;信息卡片展示物品图标、名称、类型标签、地点与时间。
首页:信息流列表,顶部搜索入口,可切换"全部 / 寻物 / 招领"分类:

搜索页:输入关键词实时过滤,支持类型筛选,空结果有友好提示:

信息详情页:展示类型、地点、时间、描述与联系方式,可点击"联系发布者":

发布页:先选择"我丢了东西 / 我捡到东西",再填写名称、类别、地点、时间、描述与联系方式:

发布成功页:发布成功后给出明确反馈,可返回首页或查看"我的发布":

"我的发布"页:展示自己发布的信息,可修改状态(已找到 / 已归还)或删除:

三、基本使用流程
软件围绕"查找"和"发布"两条主流程设计,界面操作均在三步以内完成,流程图如下:

流程一(查找):进入首页 → 浏览或搜索信息 → 查看物品详情 → 联系发布者;流程二(发布):进入发布页 → 选择寻物 / 招领 → 填写物品信息 → 点击发布 → 发布成功。
四、PSP 表格
| 任务 | 预估耗时(小时) | 实际耗时(小时) | 差异(小时) |
|---|---|---|---|
| 学习《构建之法》第 3、8 章 | 1 | 1 | 0 |
| 需求分析与用户调研 | 2 | 2.5 | +0.5 |
| 功能与流程设计 | 1.5 | 2 | +0.5 |
| 原型界面与交互实现 | 3 | 3.5 | +0.5 |
| 流程图绘制 | 1 | 1.5 | +0.5 |
| 原型走查与修改 | 1 | 1.5 | +0.5 |
| 博客撰写 | 1.5 | 2 | +0.5 |
| 合计 | 11 | 14 | +3 |
五、结对过程记录
两人先通过线上沟通共同阅读《构建之法》第 3、8 章,结合客户描述讨论痛点与用户场景;随后一人梳理功能清单与流程图,另一人实现原型页面并走查交互流程;最后共同试玩原型,确认"查看→详情、发布→成功、搜索→结果"三条主流程均可顺畅走通,并针对发布校验、状态修改等细节做了调整。


六、个人总结
总结:** 通过本次结对作业,我系统实践了《构建之法》中的需求分析方法,学会用 NABCD 模型把客户描述转化为明确的功能清单。在原型制作中体会到"流程清晰、操作简单"对产品设计的重要性,先定信息结构再排页面,能为后续开发省去返工。遇到的主要问题是信息卡片层级设计,经与搭档讨论后调整为"名称+类型标签+地点时间"的简洁结构,也更理解结对沟通的价值。
浙公网安备 33010602011771号