2026秋软件工程个人作业(第三次)

作业信息

项目	内容
这个作业属于哪个课程	H202601 软件工程与软件工程实践
这个作业要求在哪里	2026 秋软件工程个人作业（第三次）
这个作业的目标	完成「校园失物招领」小程序的需求分析与原型设计，明确主要功能与用户流程，为后续编码打基础
学号 / 姓名	102402124 / 洪豊帧
成员二：学号 / 姓名	102402125 / 黄俊翔
原型工具 / 在线原型	墨刀（Modao）/ 点击查看在线原型

一、队伍分工

本次与黄俊翔组队，采用《构建之法》中驾驶 / 领航的结对方式：
每 40 分钟轮换一次角色——一人当驾驶员动手画原型、写文档，另一人当领航员，
同步对着作业要求和原型走查，发现问题当场提出。

成员	学号	主要负责	同时参与
洪豊帧	102402124	需求分析、首页/信息详情原型、3 张流程图与演示动图、博客初稿	需求评审、原型走查、PSP 记录
黄俊翔	102402125	发布/搜索/我的发布原型、交互反馈与异常状态设计、状态与配色约定	逐条对照作业要求查漏、博客审阅、部分流程图的补充

二、软件构想与设计思路

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

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

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

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

三、需求分析

（1）主要用户及其需求

用户	典型场景	核心诉求
失主：丢了东西的同学	在图书馆丢了钥匙，当天就想找回来	快速知道"有没有人捡到"，并且能马上联系上对方
拾得者：捡到东西的同学	在教学楼捡到一张校园卡	一次把时间、地点、描述写清楚，尽快物归原主
顺路浏览的同学	午休、睡前顺手刷一刷	不想翻聊天记录，搜一下就知道有没有自己的东西

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

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

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

四、主要功能

功能	说明	优先级
浏览失物和招领信息	首页信息流按时间倒序；顶部可切换「全部 / 招领 / 寻物」	P0
发布寻物信息	选「寻物」类型，填写丢失物品的名称、类型、地点、时间	P0
发布招领信息	选「招领」类型，填写拾取到的物品信息	P0
搜索物品	按物品名称等关键词搜索，命中标题与描述	P0
查看物品详情	图片、时间、地点、状态、描述、联系方式	P0
修改信息状态	待认领 / 寻找中 / 已归还 / 已找到	P1
我的发布（附加）	集中管理自己发布的信息，可修改状态与删除	P1

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

五、用户使用流程

1. 查看信息 → 查看详情

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

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

graph TD A([开始]) --> B[进入首页，浏览最新寻物 / 招领信息] B --> C[选择感兴趣的信息] C --> D[点击「查看详情」] D --> E[进入信息详情页] E --> F[查看图片、时间、地点、状态、描述和联系方式] F --> G[点击「联系发布者」] G --> H([结束])

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 里点对应按钮就能看到
（发布页的「清空试试 ›」用来演示"必填项未填"）。

状态	触发场景	界面反馈
搜索结果为空	关键词没有命中任何信息	结果列表底部提示"没有更多结果了，换个关键词试试？"
必填项未填	发布时"物品名称"等带 * 的字段为空	「发 布」按钮置灰，字段旁红字提示；点击不跳转，弹出"请先填写必填项"
已加载全部	首页信息流翻到底	列表底部显示"已加载全部 · 共 126 条信息"，不再继续加载
发布成功	表单提交成功	跳转发布成功页：对勾 + 信息预览 + 「查看我的发布 / 返回首页」
状态修改成功	在详情页或「我的发布」改状态	提示"已标记为「已归还」"，详情页状态标签同步变灰
联系方式保护	点「联系发布者」	复制联系方式并提示，不在详情页直接摊开号码

七、结对过程

本次由洪豊帧与黄俊翔组队完成，采用驾驶/领航的结对方式，每 40 分钟交换角色。
黄俊翔在领航员视角下补充了多项异常状态设计；洪豊帧在驾驶员视角下完成原型主流程搭建。

日期	阶段	做了什么	产出
09-23	读题与需求	一起逐条读要求，圈出"必须做"与"明确不做"，梳理用户与痛点	要求清单、需求分析
09-25	设计与原型	洪豊帧主导首页/详情页，黄俊翔主导发布/搜索/我的发布；两人轮换审查	原型图、可点击原型
09-27	评审与提交	黄俊翔补充空结果提示、必填校验等异常分支；洪豊帧负责最终排版	修改记录、博客终稿

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

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

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

八、PSP 表格

说明：「预估」是开工前两人分别估的；「实际」是提交前回填的真实投入。因结对轮换，部分时间重叠，
总计预估 980 分钟、实际 1300 分钟，与 docs/PSP.md 是同一份数据。多出来的时间主要在原型细节、
插图和字数自检上。

阶段	任务	预估（分钟）	实际（分钟）	说明
计划	读作业要求、读《构建之法》第 3、6 章、拆需求；定范围与分工	50	65	圈出 15 条要求与"不做"清单，比预估多 15 分钟
需求	用户与痛点、用户故事、用例与功能清单、非功能需求	70	95	4 类用户、7 条用户故事、4 个用例；入口拆分返工一次
设计	页面结构与信息架构、状态与配色约定	45	40	首页/搜索/详情/发布/成功/我的，比预估省 5 分钟
原型	必需 4 个页面（首页、发布、搜索、详情）	90	130	配色与间距调三轮 + 详情页为隐私重排，最花时间
原型	补充「发布成功」「我的发布」	40	55	成功页要兼顾「分享」引导，改了两版
原型	流程图 3 张	45	70	查看信息 / 发布信息 / 搜索；第一张漏「否」分支重画一次
测试	三条主流程逐条走查；必填校验、状态切换等分支回归	30	45	渲染 + 交互共 12 项断言，图片做像素自检
文档	博客初稿（800–1200 字 + 插图）	60	85	插图尺寸要统一 + 正文压进 1200 字，来回改三次
文档	自查评审、改错别字与排版	30	40	无搭档，改成对着 15 条要求逐条自查、改错别字
总结	个人总结	30	25	顺着前面的返工记录写，比预估快
合计		490	650	约 10.8 小时（比预估多 33%）

九、个人总结

在结对过程中，我主要担任后半场驾驶员和前半场领航员：洪豊帧先开出需求分析和首页/详情页的底稿，
我接手后把发布页、搜索页和"我的发布"三个页面补完，并在评审阶段帮他把首页的信息流和详情页的
联系方式展示逻辑对齐——我的方向是"先跑通逻辑，再优化细节"，洪豊帧则更追求页面视觉一致性，
两个视角互相拉扯，最后落成现在的版本。

我最有价值的一次改动是补上了异常状态的分支。如果只按"正常路径"走，发布页只会有"点击发布"一个动作；
我在走查自测时用"名称不填就点发布"，结果页面没有任何反应，这让我立刻意识到空态提示和按钮置灰
其实才是这个流程真正被忽略的地方。所以后来我在"发布、搜索无结果、已加载全部、状态修改成功"这四处补了文案或视觉反馈。

另一个体会是原型的"可点击"和"展示图"不是一回事。洪豊帧做的 mermaid 流程图只能说明流转，
而我在 prototype/index.html 里点着走一遍才暴露了几个"图上看着很顺、实际点不动"的页面跳转。
这让我对"回归测试"这个词有了具体理解，也让我意识到——原型要经得起点，不只是经得起看。

最后要感谢洪豊帧在 PSP 记录上的严格：他把每次返工的用时都记录下来，我是受益者，因为返工
大多发生在我自己的页面上。下次我会把"写验收标准 → 动手 → 自测 → 合并"这条线用到更前的位置。

附：本次作业的配套文件

文件	内容
docs/需求分析.md	完整的用户画像、用户故事、用例、功能清单与非功能需求
prototype/screenshots/	6 张原型图 + 3 张流程图 + 1 张主流程演示动图（博客插图的原始文件；另有两张过程截图直接放在 blog/img/）
prototype/index.html	可点击原型（与墨刀版同一份尺寸稿），双击即可演示三条主流程与必填校验等分支
墨刀在线原型	https://modao.cc/proto/5AmeweAStm2iuwqkXScZBn/sharing?view_mode=read_only&screen=rbpVWVSUILF2FBjjF（只读分享，无需登录）
prototype/prototype.py、flowcharts.py、demo_gif.py	原型图、流程图、演示动图的生成脚本（可复现，便于迭代）
tools/	一键重建与自检脚本（build.py、过程截图准备、图片像素探针、字数统计、原型渲染回归）
docs/PSP.md	PSP 时间记录的完整版
docs/结对过程.md	制作过程记录（含过程截图与 GitHub 提交记录的说明）