软件工程 第一次结对作业

项目	内容
这个作业属于哪个课程	202601 软件工程 - 福州大学
这个作业要求在哪里	2026秋软件工程结对作业（第一次之需求分析和原型设计）
这个作业的目标	设计一个"校园失物招领小程序"，重点完成需求分析和原型设计
成员1	102401108 李铭媛
成员2	102401202 洪雅琳
原型链接	UI视图 编辑视图

需求分析

软件解决的主要问题

参考《构建之法》P174页中定义需求的方法

现有痛点	解决方案
信息分散：群聊信息孤立，缺乏统一信息池	失物/招领信息集中发布与展示
时效性差：消息滚动快，历史信息易被覆盖	提供关键词搜索，提高查找效率

主要用户及其需求

用户角色	核心需求
失主	① 快速发布寻物信息 ② 搜索匹配物品 ③ 联系拾主 ④ 确认认领并关闭信息
拾主	① 快速发布招领信息 ② 搜索相关寻物信息 ③ 联系失主 ④ 确认归还并关闭信息

管理员作为平台运营者，其审核、统计等需求属于支撑性功能，第一版暂不实现，留待后续迭代；普通用户的浏览需求与失主/拾主重合，不单独设计功能。

功能定位

参考《构建之法》8.5.1节 "功能分析四象限"

	外围功能	杀手级功能
必须需求	浏览列表 查看详情 （第一版实现）	集中发布与搜索 （重点投入）
辅助需求	分类、筛选 （第一版实现） 分享、社区 （后续迭代）	失主拾主平台内联系 消息通知 （后续迭代）

非功能性需求

对应作业要求设计一套简单、清晰、易用的解决方案

维度	需求说明
简洁性	聚焦核心任务，避免功能堆砌
清晰性	信息明确
易用性	核心功能入口直观，发布流程简短

原型制作

本次原型使用 Figma完成，共设计了6类核心页面：

首页

功能：展示最新的寻物和招领信息，提供搜索入口

搜索页

功能：支持用户按关键词搜索失物招领信息，快速定位目标物品。

详情页

功能：展示单条失物招领信息的完整内容，提供发布者信息。

编辑页

功能：提供表单让用户填写失物或招领信息并提交发布。

个人页

功能：展示用户个人信息和发布记录，方便用户管理自己发布的信息。

弹窗页

功能：在用户完成发布操作后，给予正向反馈提示。

PSP表格

阶段	活动	预估耗时(h)	实际耗时(h)	偏差(h)
一、准备与讨论	阅读《构建之法》（第四版）第4章、第8章	1	1.5	0.5
	研读作业要求文档	0.5	0.5	0
	明确结对分工与协作方式	0.25	0.25	0
	合计	1.75	2.25	0.5
二、需求分析	现有解决方案局限性分析	0.5	0.5	0
	核心用户需求分析	0.5	0.5	0
	功能定位	0.5	1.5	1
	合计	1.50	2.5	1
三、原型设计	规划页面结构与信息架构	0.5	1	0.5
	页面设计	3	5.5	2.5
	配置页面交互跳转	0.5	0.5	0
	合计	4	7	3
四、整合与提交	绘制流程图	1.5	3	1.5
	撰写作业博客	1.5	2.5	1
	填写个人总结	0.5	0.5	0
	合计	3.5	6	2.5
总计		10.75	17.75	7

合作记录

部分合作记录如下

1. 核心业务逻辑确定

我们围绕失物招领帖子的状态管理展开讨论。

2. 页面交互流程梳理

我们绘制初步业务流程图，梳理个人主页 “我的” 模块操作逻辑。

3. 流程图设计

个人总结

1. 团队协作与周哈里窗口

本次结对合作让我对《构建之法》中的"周哈里窗口"有了切身体会。队友的反馈能指出我思考中的盲点，高效协作本质上就是持续扩大"开放区"的过程：通过分享各自掌握的信息缩小隐藏区，通过交流反馈缩小盲区，通过共同探索未知区拓展共同认知边界。

2. 需求分析实践

本次项目通过交流完成需求分析并记录于博客。我认识到，需求分析的关键是从真实问题中提炼功能需求，围绕核心用户的使用场景和痛点推导功能设计，而非凭空想象。

3. 反思与改进

本次遇到主要问题是在制作过程中将功能设计过度复杂化。本应做MVP，却受日常APP影响添加了过多功能（如交流渠道、个人帖子管理等），导致原型臃肿。同时忽略了模块和样式的复用性，后期删改反而增加了时间成本。

附录：资源引用说明

1. 图片素材

   原型制作过程中使用的图片素材（宿舍钥匙遗失物图片）由 Qwen 生图工具生成，仅用于原型演示，不涉及真实物品。

2. 图标资源

   原型中使用的图标来源于 Figma 平台的 Simple Design System 资源库，遵循该资源库的使用许可规范。