软件工程第三次作业

软件工程第三次作业

项目内容	说明
这个作业属于哪个课程	202601 软件工程 - 福州大学
这个作业要求在哪里	2026秋软件工程结对作业（第一次之需求分析和原型设计）
这个作业的目标	设计一个"校园失物招领小程序"，重点完成需求分析和原型设计
成员1	102401225 王圣杰
成员2	102401227 林子涵
原型链接	UI视图（在线预览，可点击） ・ 编辑视图（源文件）

---

一、客户的问题：信息太散，找不回来

校园里丢东西很常见：校园卡、钥匙、水杯、雨伞、耳机、教材。丢了之后大家习惯发班级群、宿舍群和朋友圈——发得快，但信息散在不同群里，群消息一条压一条，昨天的招领信息今天就翻不到了。更要紧的是，捡到校园卡的同学和丢卡的同学往往不在同一个群，两边都在发消息，却互相看不见。我们想做的不是"再开一个群"，而是把信息集中到一个池子里，并且能按关键词搜到。

二、用《构建之法》的方法做需求分析

学了《构建之法》第 3、8 章后，我们先弄清"谁在用、为什么用"，再用 NABCD 说明这个软件存在的理由；原型只做最小可用版本。

主要用户与需求

用户角色	使用场景	核心需求
失主（丢东西的同学）	校园卡落在教室、雨伞落在食堂	发一条寻物信息；搜搜看有没有人捡到
拾得者（捡到东西的同学）	在图书馆捡到耳机、在操场捡到学生证	发一条招领信息；不想公开太多隐私
普通同学（旁观者）	随手刷一刷首页	快速浏览，看到眼熟的物品提醒失主

• N（需求）：群聊与朋友圈的信息分散、容易被刷掉、跨社交圈不可见，失主和拾得者缺少一个碰面的地方。
• A（做法）：把寻物和招领集中到同一列表，条目结构化（类型、名称、分类、时间、地点、状态），并支持关键词搜索。
• B（好处）：发布一次全校可见，搜索几秒就能定位；信息带"待认领／已归还"状态，避免看到过时信息白跑一趟。
• C（竞争）：群聊发得快但不可检索，校园墙靠人工转发、格式杂乱；我们的优势是集中、可搜索、状态可见。
• D（推广）：微信小程序扫码即用、不用下载，二维码贴在食堂和宿舍楼下就能传播；第一版只做核心页面。

实名认证、即时聊天、地图定位、后台审核都不做：它们会明显抬高实现成本，却解决不了"信息集中、能搜到"这个主要矛盾。

三、主要功能

编号	功能	说明
F1	浏览失物／招领信息	首页按"全部／寻物／招领"分类列表展示
F2	发布寻物信息	我丢了东西，填写后发布
F3	发布招领信息	我捡到东西，可只公开部分特征
F4	搜索物品	按物品名称、描述等关键词检索
F5	查看物品详情	查看分类、时间、地点、描述与联系方式
F6	修改信息状态	发布者标记"已找回／已归还"
F7	我的发布	集中管理自己发布过的信息

四、基本使用流程

三条基本流程如下。

用户主流程与发布流程

搜索物品流程

五、原型设计

原型工具： 我们使用 Figma 完成原型设计与在线演示，先把 6 个页面画成高保真 Frame，再用 Prototype 功能添加点击跳转，分享链接即可在线评审。

在线原型链接（UI 视图，可直接点击）： https://www.figma.com/proto/tg1hSDpDZrwfdYXW97AXt6/UI?node-id=1-2&p=f&t=f1xnbjYww4Uw61nk-1&scaling=scale-down&content-scaling=fixed&page-id=0%3A1&starting-point-node-id=1%3A2

编辑视图（源文件）： https://www.figma.com/design/tg1hSDpDZrwfdYXW97AXt6/UI?node-id=0-1&p=f&t=8EMLtw7kB4AtGyk1-0

原型共 6 个页面：首页、搜索、发布信息、发布成功、信息详情、我的发布。首页点卡片进详情，点底部"＋"进入发布，点搜索框进入搜索。

原型总览

首页	搜索页面

发布信息页面	发布成功页面

信息详情页面	我的发布

几个讨论后定下的细节：招领信息只写部分特征（校园卡只写尾号），认领时请对方说出完整特征；联系方式点击后才展示。

六、PSP 表格

任务阶段	预估耗时（分钟）	实际耗时（分钟）
需求分析（读教材、讨论客户描述、明确用户与需求）	40	45
绘制流程图	30	25
原型设计（首页、发布、搜索、详情等页面）	90	110
两人评审原型并修改	30	35
撰写博客	50	55
合计	240	270

七、结对过程记录

9 月 26 日晚我们开线上会议过了一遍客户描述，把"信息分散、容易被刷掉、跨群看不到"写在纸上，再把功能砍到 7 条；9 月 27 日下午在图书馆画流程图，晚上分工做页面：一人负责首页、搜索和详情，一人负责发布、发布成功和我的发布，完成后交换评审，找出并改掉了 3 处问题。

![结对讨论需求]

八、个人总结

林子涵： 我负责首页、搜索和信息详情三个页面，也参与了前期需求分析和流程图整理。最大的收获是"先想清楚再动手"：我本来想加入即时聊天和地图定位，队友提醒我这些功能会明显增加第二次结对作业的代码量，却没有解决"信息分散、找不到"的核心问题；用 NABCD 写下理由后，我们才把功能收敛到 F1-F7。困难在于把需求翻译成页面：哪些信息必须出现在列表卡片上、哪些放到详情页，我们改了两版才定下来。

九、下一步

第二次结对作业将基于本原型，用微信小程序（或 Web 前端加简易后端）实现首页、发布、搜索、详情四条主链路，数据先用本地存储托管，代码协作使用 GitHub。