软件工程第一次结对作业

项目	内容
课程	H202601软件工程与软件工程实践
作业要求	软件工程第一次结对作业
作业目标	完成「校园失物招领小程序」需求分析和原型设计
学号和姓名	同学 A：102401614 林志涛；同学 B：102401625 朱铮睿

一、阅读《构建之法》的思考

第 3 章“软件工程师的成长”让我们看到，工程能力不仅仅是编写代码，还包括用 PSP科学地估计、记录和复盘耗时，这是从“码农”向“工程师”蜕变的关键。第 8 章“需求分析”则是一针见血地提醒我们：必须从“用户困扰”而非“功能清单”出发。如果系统只能让用户发布消息，却无法进行高效检索，或者找回物品后状态无法及时更新，那么核心痛点依然没有解决。因此，在本次设计中，我们坚决贯彻“以解决问题为导向”的思路，优先打磨搜索、详情展示和状态反馈这三个核心模块。在结对评审环节，我们要求彼此必须清晰说明每一处设计的业务理由，并交叉检查交互逻辑的遗漏点。

二、项目来源与用户需求

目前校园内的失物消息多呈碎片化，散落在各个班级群、专业大群和朋友圈中，不仅极易被海量聊天记录覆盖，且拾到者与失主往往存在严重的信息壁垒（如不在同一个群）。系统的目标用户主要分为三类：失主、拾取者，以及帮忙留意查询的同学。他们分别对应着发布、精准检索与快速核对信息的核心需求。

现存的核心问题在于：信息难集中、难精准匹配、难确认闭环状态。

例如，一位拾到校园卡的同学发布了招领启事；失主通过小程序搜索关键字“校园卡”，核对时间地点无误后，双方取得联系，完成物品交接，最后由发布者在系统中将状态更新为“已归还”，形成完整的业务闭环。

三、功能与页面设计

围绕“发布—查找—联系—结束”的核心闭环，我们精简并打磨了 9 页原型：首页、发布与成功、搜索与结果、详情、联系、我的发布、状态已更新。主要功能点如下：

• 浏览与搜索： 首页按类型浏览，输入关键词后查看结果。
• 发布寻物／招领： 填写名称、时间、地点、描述与联系方式，照片可选；提交后显示成功页。
• 查看与联系： 详情页呈现图片、时间地点和状态，再进入联系页。
• 修改状态： 在“我的发布”标记已找回或已归还，并查看更新反馈。

考虑到敏捷开发的迭代周期，实名认证、即时聊天系统和基于 LBS 的地图定位功能暂不列入本次核心范围，将在后续版本中视需求优先级引入。

四、用户流程与改进设想

下图从首页出发，清晰划分了浏览、发布、管理三条主线；实线代表当前原型已落地的路径，虚线代表后续的迭代设想。

在下一轮迭代中，我们拟将笼统的“地点”字段拆分为“大区域（如生活区、教学区）＋详细地点”，并增加搜索结果的复合筛选面板；详情页将补全物品的“特征标签”并支持照片双指缩放查看；同时，在点击联系前，增加弹窗提示双方核对关键特征，并提醒切勿在公开描述中暴露校园卡完整卡号等敏感信息。目前为了保证核心流程的跑通，这些细分功能本次尚未在原型中实现。

五、原型工具与检查

本次作业采用 Figma 设计移动端界面。为了保证原型的保真度与后续开发的可复用性，所有的文字、卡片和按钮均采用独立图层与组件库化处理，坚决抵制“整页贴图”的偷懒做法。

在内部验收阶段，我们进行了角色扮演，同伴成功走通了“查看详情”、“发布成功”、“搜索结果”三项核心任务，并严格检查了状态更新时的交互反馈与界面的分享权限设定。

Figma 设计文件

六、结对过程

在初期规划阶段，我们借助 AIGC 工具进行了多轮结构化 Prompt 对话，快速发散并梳理出了校园失物场景下的核心痛点与用户旅程。初稿设计时我们曾尝试用整页贴图配合热区来做演示，但在复盘时发现一旦需求变更，整图替换成本极高，且元素无法独立修改。

于是我们及时调整策略，转而使用 Figma 及其内置 Agent 辅助生成了九页完全可编辑的高保真原型。考虑到本次迭代的时间盒限制以及作业要求，我们没有盲目加码，而是理性地将这些灵感以虚线形式保留在流程图中。在整个过程中，两人通过屏幕共享和语音保持高频沟通，不仅磨合了协作节奏，也锻炼了对需求边界的把控力。

PSP 记录

PSP 阶段	预估耗时/分钟	实际耗时/分钟
计划与需求分析	55	65
流程与页面设计	75	90
原型制作与连线	155	180
评审与修改	40	35
博客与最终检查	100	85
合计	425	455

七、个人总结

这次作业让我学到的最实在的一点就是 “不要贪多”。刚开始看需求觉得什么功能都想加，但时间根本不够，硬塞的话反而连最基础的功能都做得很粗糙。后来我们在流程图里用实线和虚线做了区分，先把眼下必须交付的核心功能敲定，以后想加的先画个大饼，这样心里就有底了。另外，结对一起商量真的很有必要，自己一个人画图很容易思维局限，同伴一起看往往一眼就能揪出漏掉的地方。