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

作业信息

一、队伍分工

本次未找到搭档，全部工作由本人独立完成。为了不丢掉"配对"的好处，我把课程里的驾驶 / 领航做法保留下来： 每 40 分钟换一次角色——先当驾驶员动手画原型、写文档，再退回领航员视角，对着作业要求逐条查漏。

二、软件构想与设计思路

我想做的不是"又一个群聊"，而是一个公开、可检索的校园失物招领信息池： 捡到东西的人与丢了东西的人不用认识、也不用在同一个群，只要在同一个池子里"发一条、搜一下"就能接上。

读完《构建之法》第 3 章和第 6 章后，我把思路收敛成三条原则：

1. 需求先落在场景里：先写清"谁、什么时候、遇到什么问题"，再决定做不做某个功能；
2. 范围要克制：只做"发布 → 检索 → 联系"这条最小闭环，后台管理、实名认证、即时聊天、地图定位明确不做；
3. 流程要简单：发布不超过 3 步，首页一屏内看到搜索框、分类和信息流。

产品骨架因此是一条时间流：首页信息流（浏览 / 搜索）→ 详情页 → 发布页 → 我的发布。

三、需求分析

（1）主要用户及其需求

（2）软件主要解决什么问题

现状是把信息发到班级群、宿舍群、朋友圈：信息分散、跨班级看不到、被新消息顶掉、想找只能翻聊天记录。

要解决的是三件事：集中发布（一个地方看全校失物招领）、 关键词检索（按物品名称直接搜）、状态可更新（归还后标记"已归还"）。

四、主要功能

前 6 项覆盖了作业要求列出的功能点；「我的发布」是补充项，解决"发错了、已归还没法改"的问题。 寻物用橙色、招领用绿色，扫一眼就能分辨。

五、用户使用流程

1. 查看信息 → 查看详情

首页浏览信息 → 点卡片「点击查看详情」→ 详情页看图片、地点、时间、状态、描述和联系方式 → 点「联系发布者」。

同一张图的 mermaid 源码（博客园可直接渲染）：

2. 发布信息 → 发布成功

点首页「＋ 发布」→ 选类型 → 填名称、地点、时间 → 上传照片、填联系方式 → 点「发布」→ 进入发布成功页。

3. 搜索物品 → 查看搜索结果

点首页搜索框 → 输入关键词（如"校园卡"）→ 查看结果列表；结果为空时提示更换关键词。

4. 三条基本流程综合演示

动图按「首页 → 信息详情 → 发布信息 → 发布成功 → 搜索物品 → 我的发布」循环播放，每帧停 1.4 秒， 正好走完上面三条基本流程；同一个原型在 prototype/index.html 里可以真实点击走一遍。

六、原型设计

1. 原型工具与在线链接

原型使用 墨刀（Modao） 制作，在线链接：https://modao.cc/proto/5AmeweAStm2iuwqkXScZBn/sharing?view_mode=read_only&screen=rbpVWVSUILF2FBjjF

链接是墨刀的只读分享链接，无需登录即可打开；点页面里的卡片、按钮和底部导航，

就能走完「查看信息→查看详情 / 发布信息→发布成功 / 搜索物品→查看搜索结果」三条主流程。

prototype/index.html 是同一份尺寸稿的 HTML 版可点击原型，双击也能演示主流程与必填校验等分支。

2. 页面清单

作业要求至少包含首页、发布信息、搜索、信息详情；我们另补了「发布成功」「我的发布」。

设计上把握三点：首页一屏给全入口；详情页按"是不是我的东西"排序； 状态用颜色加文案双重表达（待认领绿、寻找中橙、已归还灰）。

3. 三条基本流程在原型中的走法

4. 交互反馈与异常状态

原型不只有"一路顺利"的路径：下面几种打断情况都给了明确反馈，在 prototype/index.html 里点对应按钮就能看到 （发布页的「清空试试 ›」用来演示"必填项未填"）。

七、结对过程（本次为单人独立完成）

本次未组队，由本人独立完成；为了避免"自己骗自己"，我把角色拆成两步走：先做（驾驶），再退回检查（领航）。

图 1：做原型时的界面——在墨刀里调「发布成功」页，并顺手把「分享」面板的連結權限设为 「所有人」（对应作业要求第 2 条的可分享原型、第 11 条的过程截图）。

图 2：画流程图的过程——在画布上摆节点、连「是」分支、再补上「否 · 必填校验」分支的草稿； 「五、用户使用流程」里的 3 张流程图就是照这张草稿画的（脚本可复现，见文末配套文件）。

两个最有价值的发现都来自"退回检查"这一步：失物与招领不该做成两个独立入口（用户只关心"有没有我的东西"）， 以及详情页直接展示联系方式会泄露隐私（改为仅登录可见）。文档与原型源文件按作业要求第 15 条用 GitHub 管理。

八、PSP 表格

说明：「预估」是开工前估的；「实际」是提交前回填的真实投入——预估 490 分钟、实际 650 分钟， 多出来的时间几乎都在没做过的事情上（原型细节打磨、插图和字数自检），与 docs/PSP.md 是同一份数据。

九、个人总结

洪豊帧（学号 102402124）

最大的收获是明白了需求分析到底在做什么。我一开始把"失物"和"招领"做成两个独立入口，总觉得别扭；

后来按《构建之法》的方法先写"谁、在什么场景下、遇到什么问题"，才反应过来用户只关心"有没有我的东西"，

于是合并成一条信息流加类型筛选。

第二点是"退回检查"能挡住自己的盲区。画完原型容易顺着自己的思路看下去，换成"领航员"视角

对着 15 条要求逐条查漏，才发现发布表单要滚动两次才点得到"发布"、详情页摊开联系方式有隐私风险；

画流程图时又发现"搜索无结果"这条分支完全没写——用户搜不到会以为程序坏了，补上"提示更换关键词"。

取舍上，功能列了十几个只留 P0 六项，标准是"不做这一项，用户的困扰还算不算解决"；

PSP 里预估 490 分钟、实际 650 分钟，多出来的几乎都在没做过的事上（原型细节、图片与字数自检）。

下次我会先写验收标准再动手，并把重复劳动继续脚本化。

附：本次作业的配套文件