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

校园失物招领小程序 —— 需求分析与原型设计（结对作业一）

这个作业属于哪个课程	H202601软件工程与软件工程实践
这个作业要求在哪里	2026秋软件工程个人作业（第3次)
这个作业的目标	完成需求分析和原型设计，设计一个简单的“校园失物招领小程序”。

成员	分工
颜俊宇（102401114）	需求分析、功能梳理、墨刀原型绘制与交互连线、流程图、博客撰写
林世颖（102401126）	用户痛点整理、原型字段与交互走查、三条主流程演示、截图整理

一、《构建之法》学习成果

这次作业前我们一起读了《构建之法》第 3 章和第 8 章。第 3 章讲两人合作，体会最深的是结对不是分工做完就完事，而是要互相检查、一起对结果负责；第 8 章讲需求分析，提醒我们别一上来就列一堆功能，得先想清楚用户在什么场景下遇到什么问题，再决定做什么、不做什么。照着这个思路，我们先梳理了校园里失物招领的真实痛点，把地图定位、站内聊天这些当时觉得"加上更完整"的功能砍掉了，只围绕发布、浏览、搜索、详情这条主链路用墨刀原型和流程图跑通，也为下次结对编程提前定好了页面结构和数据字段。

二、用户与需求分析

校园里丢三落四太常见了，校园卡、钥匙、水杯、雨伞、耳机、书，几乎每天都有人丢也有人捡。但现在大家都是在班级群、宿舍群、朋友圈里发，用起来有几个明显问题：寻物和招领信息散在不同的群里，捡到的人发的群丢东西的人根本不在；群消息刷得快，一条招领启事发出去几小时就被刷没了；而且在教学楼捡到东西只能发到自己班群，丢东西的人可能在另一个学院，两边根本碰不上。

我们把用户大概分了三类：丢了东西的人想快点发个寻物启事，也想搜一下是不是已经有人捡到了；捡到东西的人想简单填一下信息就发出去，不想把自己的联系方式随便挂在那；还有一类就是随便逛逛，看看有没有自己或室友最近丢的东西。

这个小程序要做的事其实就是把这些散在各个群里的信息拢到一个地方，能搜、不会被刷走。按作业要求，后台管理、实名认证、即时聊天、地图定位这些都不做，先把主流程跑通。

三、功能设计

主要功能就这几块：浏览失物和招领信息，可以按"全部/寻物/招领"切换；发布寻物信息；发布招领信息，和寻物共用一张表单，选一下类型就行；按物品名称搜索；点进看详情；发布者自己把信息标记成已完结；还有"我的发布"管理自己发过的东西。

四、原型设计

4.1 原型开发工具

原型用墨刀做的。选它主要是拖拽搭页面快，所见即所得，页面之间可以连线设跳转，不是死的静态图。一共做了 6 个页面：首页、发布信息、搜索、信息详情、我的发布、发布成功。界面风格照着微信小程序来的，下次写代码可以直接对着这个原型做。

• 墨刀原型在线预览：https://modao.cc/proto/KzL9EqfZtm26esG3bFH8KE/sharing?view_mode=read_only（免登录可以直接看和点）

4.2 原型页面

首页：顶部是搜索框，下面是信息流，能切寻物和招领，每张卡片左边是物品图，右边是标题和时间地点，右上角有状态标签。

发布信息页：先选"我丢东西了"还是"我捡到东西了"，再填物品名、分类、描述、地点时间和联系方式，分类是点标签不是打字。

搜索页：输入关键词后展示命中结果，顶部提示找到几条。

信息详情页：有大图、地点、描述、发布者信息，底部两个按钮可以联系对方或者标记已解决。

发布成功页：提交后给一个成功反馈，点返回首页就回去。

我的发布页：能看到自己发过的所有东西和状态，可以一键改状态。

4.3 使用流程

主流程就是：进首页 → 随便刷或者搜一下 → 点进详情看 → 联系发布者。

发布流程：点发布按钮 → 选类型填信息 → 提交 → 看到发布成功 → 返回首页。

信息就两种状态：进行中和已完结，发布者自己手动改。三条要求演示的流程我们都实际点过：看信息进详情、发信息到成功、搜"校园卡"出结果。

五、结对过程

我俩是先各自想了一遍，再坐一起对。主要争了三件事：一是要不要做地图定位和站内聊天，后来觉得定位解决的是"去哪还"，但现在的痛点是"信息根本看不见"，聊天更没必要，详情页留个微信号就够了；二是表单字段一开始列了 10 个，自己点了一遍发现发一条要点七八下，太麻烦，就把照片、品牌、颜色这些删了；三是一开始做完发布成功页就停在那，走查的时候觉得别扭，才加了个"返回首页"的出口。这个走查过程就是书上说的"互相审查"——自己做的东西看不出问题，队友一点就发现了。

阶段	主要工作	预估(h)	实际(h)	偏差说明
需求分析	读题、梳理困扰、确定用户角色	1.0	1.2	对"是否做定位/聊天"讨论较久
功能设计	功能清单、功能结构图	1.0	0.8	功能收敛后比预想快
原型设计	页面结构、字段与交互、原型搭建	2.5	3.5	表单字段改了两版
流程与图表	主流程图、发布流程图、状态流转图	1.0	1.0	和预期差不多
原型自查	三条主流程走查、空态检查	0.5	0.8	走查发现发布成功后缺出口
博客撰写	正文、截图整理、排版校对	1.5	1.7	整理图注比较费时间
合计	—	7.5	9.0	主要是原型改了两版

六、个人总结

颜俊宇（102401114）

最深的体会是：需求分析阶段"少做一点"比"多做一点"更考验判断力。 我本能地想加地图定位、站内聊天、实名认证，觉得功能越多越完整；但推演场景后才发现，这些要么解决的不是核心问题，要么把实现成本抬到不合理的高度。最后砍掉的字段比留下的还多，原型反而更清晰，这让我理解了《构建之法》里"需求要先做减法"。

结对也帮到了我：自己写的东西看不出问题，别人一眼就能发现。 我觉得"发布成功"停在本页挺自然，队友走查时直接问"我发完想看看这条长什么样怎么办"，才意识到缺了出口。

七、后续准备

第二次结对作业就照着这个原型写代码了，准备用 GitHub 协作，main 分支为主，功能开发走 Pull Request。技术上初步定微信小程序加云开发数据库，信息表至少要有 type、name、category、place、time、description、contact、status 这几个字段，状态分 open 和 done 两种。