软件工程实践团队作业第二次 —— 原型设计 & 需求分析（拾光・校园失物招领小程序）

本博客为 2601_FZU_SE 软件工程实践团队作业第二次提交。内容包括团队项目整体计划与里程碑、关键点难点与风险分析、组员分工与工作量比例、成员协作方式，以及《需求规格说明书》、界面原型设计、需求分析 PPT、界面原型设计答辩 PPT 的链接。

作业格式描述

项目	内容
这个作业属于哪个课程	https://bbs.csdn.net/forums/2601_CS_SE_FZU
这个作业要求在哪里	https://bbs.csdn.net/topics/620545161
团队名称	拾光友人帐
这个作业的目标	完成团队项目的需求分析与界面原型设计，产出符合国标规范的《需求规格说明书》、可交互界面原型与两份答辩 PPT，并通过博客记录项目计划、难点风险与团队协作过程
其他参考文献	[1] GB/T 9385-2008《计算机软件需求规格说明规范》；[2] 邹欣.《构建之法》[M]. 人民邮电出版社；[3] 微信小程序开发文档；[4] uni-app 官方文档

目录

@

文章目录

---

一、团队项目计划

1.1 项目概述

项目名称：拾光・校园失物招领微信小程序。

一句话描述：把校园里零散、碎片化、不可检索的失物信息整理成可发布、可匹配、可追溯的失物招领平台，通过拍照发布、智能匹配与即时通知，让失主与拾者高效对接。

目标用户：校园师生（失主）、拾到物品的同学（拾者）、失物收容点、校园组织与助教。

核心链路：丢失 / 拾到拍照发布 → 结构化入库 → 智能匹配 → 即时通知 → 匿名对接 → 确认取回。这条链路是项目的验收底线，任何阶段都不能让它中断。

1.2 项目整体计划与阶段划分

项目自组队确定选题后分为四个阶段推进，每个阶段必须留下可演示、可评审的成果。

阶段	时间安排	主要任务	阶段成果与验收方式
第一阶段	9 月下旬	团队组建、选题论证、NABCD 分析、团队绩效考核方案	选题说明文档与选题答辩 PPT，已通过课堂选题答辩
第二阶段	10 月上旬	需求分析、界面原型设计、类图与数据建模、接口约定	本博客对应的四份交付物，可评审、可演示
第三阶段	10 月下旬至 11 月	前后端开发、信息发布与匹配算法、微信订阅消息对接	可发布寻物 / 招领信息并收到匹配通知的可运行小程序
第四阶段	11 月至期末	匿名对接完善、测试、部署与演示准备	可访问、可复现、可讲解的完整成品

flowchart LR
    A["阶段一：选题与团队建设<br/>9 月下旬 · 已完成"] --> B["阶段二：需求分析与原型设计<br/>10 月上旬 · 本次作业"]
    B --> C["阶段三：发布匹配与即时通知<br/>10 月下旬至 11 月"]
    C --> D["阶段四：反馈闭环与测试部署<br/>11 月至期末"]

1.3 本次作业的里程碑安排

本次作业周期为 10 月 9 日至 10 月 15 日，10 月 16 日课堂答辩，因此采用倒排方式安排里程碑，每个里程碑都有明确的日期与可交付成果。

里程碑	截止时间	交付成果	负责人
M0 计划冻结	10-13 24:00	术语表初稿、页面清单、任务看板卡片	全体成员
M1 需求冻结	10-14 12:00	4 个用户场景与用例、信息架构图、类图初稿	王永臻
M2 原型 v1	10-14 18:00	全部页面可点击原型、类图定稿	许煜煌
M3 首稿完成	10-15 12:00	《需求规格说明书》初稿、需求分析 PPT 初稿	刘传浩，李明学
M4 全部定稿	10-15 16:00	说明书定稿、界面原型设计答辩 PPT 完稿	全体成员
M5 博客发布	10-15 20:00	本博客发布，四份交付物上传华为云仓库并取回链接	刘伟鑫
M6 提交完成	10-15 23:59	按检查清单交叉核对并提交作业页面	全体成员
M7 课堂答辩	10-16	需求分析 PPT 与界面原型设计答辩 PPT 各彩排一次并现场讲述	许毅君

关键路径：术语表 → 类图 → 说明书第 3 章；页面清单 → 界面原型 → 说明书第 4 章；场景与用例 → 功能需求编号 → 验收标准；说明书与原型 → 两份答辩 PPT → 博客。其中类图是三条支线共同的上游，被安排在 M1 阶段优先完成。

每日节奏：每晚 21:00 进行一次 15 分钟站会，每人只回答三个问题 —— 昨天完成了什么、今天计划做什么、当前有什么阻塞。

---

二、项目关键点、难点与风险分析

2.1 三个关键点

关键点一：需求粒度必须可验收。

需求分析最常见的失败是写出 "功能愿望清单"—— 读起来完整，但无法判断做没做完。我们的对策是让每条功能需求都携带编号、描述、输入、输出、异常流程、优先级和来源场景，并提供需求追溯矩阵，把 "用户场景 → 功能需求 → 原型页面 → 验收用例" 串成一条可回溯的链路。

关键点二：界面原型必须能倒推回需求。

原型设计容易 "凭审美画画"，与需求文档脱节。我们在界面原型设计答辩 PPT 中专门保留一页，展示每个页面与需求编号的对应关系，用可核查的映射证明界面是为需求服务的。

关键点三：招领类产品的需求必须用指标表达。

"要方便"" 要快 ""匹配要准" 这类描述无法验收。我们把它翻译成可测量指标：信息发布成功率、匹配命中率、通知触达率、失物取回闭环率、匿名对接纠纷率，并把每个指标的定义、测量方式和目标值写进《需求规格说明书》的非功能需求章节。

2.2 四个难点与应对思路

难点	为什么难	我们的应对
类图与需求难以保持一致	类图容易画成技术架构图，出现消息队列、缓存等与业务无关的类，导致与需求对不上	先冻结术语表与实体清单，类图只画业务实体及其关系；画完后再逐条回读功能需求做交叉检查，删掉无需求支撑的类
用户场景容易写成空话	缺少真实用户输入，写出来的场景往往是团队想象	以本班同学、课程助教和小组自身为样本做 5 至 8 人小范围访谈，把真实丢 / 捡物品的经历整理进场景描述，并在文档中标注场景来源
界面原型范围容易膨胀	页面数量乘以状态数量画板暴增，按课程周期画不完	分级投入：主链路页面做高保真，管理类页面做中保真，状态设计只在核心页面完整展开
周期紧且有两轮答辩	10 月 15 日交作业，10 月 16 日就要课堂答辩，几乎没有缓冲	原型与 PPT 并行推进；说明书 10 月 15 日定稿，博客 10 月 15 日必须发布；四份交付物各设一名备份负责人

2.3 风险分析与应对措施

风险	影响程度	应对措施
博客审核延迟，帖子显示 404	高	10 月 15 日提前发布；若发布后仍显示 404，先在班级作业页面提交链接，等待审核通过，避免被判定为伪造提交
华为云仓库链接权限设置错误	高	每份文件上传后用无痕窗口逐个验证链接可访问，确认无误后再写入博客
Word 文档排版样式不统一	中	指定唯一排版负责人，先确定样式模板再合并各章内容，图表统一编号
说明书、PPT、博客三处口径不一致	中	抽出 "术语表 + 需求编号表 + 指标定义" 三份单一事实来源，三处均引用同一份
临近期末成员投入度下降	中	任务看板每张卡片都有负责人与截止时间，关键模块设置备份负责人；阻塞超过 24 小时即升级为全组讨论
匿名对接被滥用（冒领、骚扰）	中	把 "身份核验、匿名中转、举报与追溯" 写成显式需求项，答辩时用需求编号回应质疑
微信订阅消息接口或云存储不可用	低	需求文档中明确通知与存储通过兼容接口调用，避免技术选型绑死单一厂商

---

三、项目分工

3.1 组员分工与工作量比例

本次作业的分工按 "交付物主责制" 划分，每份交付物有且只有一名主责人、一名协作人，避免多人同时改一份文件导致版本混乱。

成员	工作内容	贡献度
102400424刘伟鑫	统筹协调；需求规格说明书主编统稿（引言、描述、要求）；项目计划与协作机制；博客撰写与发布；仓库与链接汇总	16%
102400430许煜煌	界面原型设计主责（信息架构、页面绘制、可交互原型制作）；界面原型设计答辩 PPT	16%
102400423刘传浩	类图建模与关系说明；用户场景调研与用例；需求说明书技术要求章节；	16%
102400426王永臻	界面原型辅助审核（视觉规范、关键页面细化、状态设计）；界面原型评审表	16%
102400416李明学	需求分析 PPT；需求分析评审表；难点与风险分析；术语表维护与追溯矩阵核对	16%
102400429许毅君	界面原型设计答辩 PPT ；需求分析答辩	20%

3.2 工作量比例的计算依据

工作量比例不是平均分配，也不是主观拍板，而是按 "主责交付物的分值权重 × 实际投入工时" 综合确定，并与任务看板卡片、Git 提交记录一一对应，做到可追溯、可申诉。

交付物	主要工作投入	主责人	协作人
需求规格说明书	章节撰写、类图建模、关系说明、排版与图表统一	刘传浩	李明学
界面原型设计	信息架构、页面绘制、交互与状态设计、设计规范	许煜煌	王永臻
团队项目计划、难点风险、分工与协作描述	素材整理、统稿、博客排版与发布	刘伟鑫	全员提供素材
需求分析报告 PPT	大纲设计、页面制作、讲稿撰写与现场讲述	李明学	许毅君
界面原型设计答辩 PPT	大纲设计、原型走查编排、讲稿撰写与现场讲述	王永臻	许毅君
两份评审表	模板调整、腾讯共享文档维护、排名汇总	刘伟鑫	王永臻，李明学

本次作业的评分重心集中在《需求规格说明书》（本博客对应章节合计 32 分，含国标规范）与博客本身（合计 36 分，含团队协作描述），界面原型同时服务于说明书第 4 章与界面原型设计答辩 PPT，两份答辩 PPT 合计 20 分。结合分值权重与实际投入工时，最终形成 20%、16%、16%、16%、16%、16% 的贡献度比例。若后续出现成员临时请假或任务调整，比例会在阶段复盘时同步修订，并保留修订记录。

3.3 每位成员的具体工作内容

102400424刘伟鑫

• 编写《需求规格说明书》第 1 章引言（编写目的、项目背景、术语与缩写、参考资料）。

• 编写第 2 章总体描述（产品目标、用户特征、运行环境与约束、假设与依赖、非目标）。

• 补写第 5 章功能描述中的具体功能描述、输入输出格式与界面验收标准。

• 撰写并发布本博客，负责各章节素材统稿为统一口径；汇总华为云仓库全部交付物链接。

102400430许煜煌

• 设计界面原型的信息架构与导航结构，输出页面地图。

• 使用原型工具完成全部页面的中高保真原型，主链路页面做高保真。

• 负责核心页面的交互细节（发布表单、匹配结果、匿名对接等）。

• 制作界面原型设计答辩 PPT。

• 输出可交互原型链接，供其他成员与助教直接点击体验。

102400423刘传浩

• 负责用户调研，访谈 5 至 8 位同学与助教，整理用户画像与 4 个典型场景。

• 编写第 3 章具体要求中的类图设计，使用工具编写类图源码，并在正文中逐条解释类之间关系与多重性。

• 编写数据需求与非功能需求（可用性、安全性、性能）。

• 参与两次内部评审，负责核对术语一致性。

102400426王永臻

• 制定界面设计规范，包括主色、辅助色、字号阶梯、间距与常用组件样式。

• 负责管理类页面与四种状态（空态、加载态、错误态、无权限态）的视觉设计。

• 负责《需求规格说明书》的最终排版：统一标题样式、正文字号、行距、图表编号与页眉页脚。

• 维护界面原型设计评审表。

102400416李明学

• 编写第 5 章功能描述及验收验证标准（输入输出格式、界面验收标准与功能验收标准）。

• 制作需求分析报告 PPT。

• 维护需求分析评审表，从测试视角核对验收标准的可判定性。

• 编写难点与风险分析章节。

102400429许毅君

• 辅助制作需求分析报告 PPT，负责现场讲述中的需求与类图部分。

• 辅助制作界面原型设计答辩 PPT，并配合完成课堂讲述。

---

四、成员协作方式

4.1 沟通工具与沟通节奏

场景	工具	约定
日常异步沟通、问题求助	微信群	工作时间内 12 小时内响应，紧急事项直接在群里 @ 对应负责人
文档协作与评审	腾讯共享文档	评审表、会议记录共用，链接统一放在群公告
原型协作	Figma / 墨刀	按页面编号划分画板责任人，跨页面改动先在群里同步
代码与文档托管	华为云仓库 / Git	仓库为唯一事实来源，本地文件不作为交付依据

4.2 版本仓库协作

分支模型：主分支 main 只保留可交付版本，任何中间状态不允许直接提交到 main。每位成员从 main 拉取 feat / 模块名 分支开展自己的工作，完成后提交 Pull Request 申请合并。

目录约定（示例）：

shigu/
├── docs/            # 需求规格说明书、会议记录、决策记录
├── diagrams/        # 类图、流程图等源码与导出图
├── prototype/       # 原型导出文件与截图
├── slides/          # 两份答辩 PPT 及导出的 PDF
└── README.md        # 项目说明与交付物索引

提交信息规范：统一采用「类型：内容」格式。常用类型包括 docs（文档）、design（设计）、slides（演示材料）、fix（修正）。

合并前检查：每次 Pull Request 必须由一名非作者的成员 Review 后才能合并，避免自审自合。

4.3 冲突处理

• 文档冲突：《需求规格说明书》按章节拆分为多个文件，每人只修改自己负责的章节，最后由排版负责人统一合并为 Word 成稿。

• 原型冲突：Figma 画板按页面编号划分责任人；若某次改动影响其他页面（如统一修改主色），先改设计规范文件，再由各责任人同步到自己的画板。

• 需求分歧：先回到用户场景和验收标准寻找依据；无法一致时由该交付物主责人拍板，并把决策原因记录到 docs/decisions/ 目录，供后续复盘和答辩使用。

• 进度冲突：某成员任务阻塞影响下游（如类图未定稿导致说明书无法推进）超过 24 小时，升级为全组讨论，由备份负责人接手或调整优先级。

4.4 任务同步机制

• 任务看板：按 "待办 / 进行中 / 待评审 / 已完成" 四列管理。每张卡片必须包含任务描述、负责人、截止时间、验收标准四项，缺一项不允许进入 "进行中"。

• 周期同步：每周日更新进度表与风险表，把看板数据写进博客里程碑进度小节。

• 交付前核对：每个里程碑到达时，由非主责人按检查清单逐条核对，结果记录在看板卡片评论中。

---

五、软件需求规格说明书

《需求规格说明书》链接：【金山文档 | WPS云文档】 拾光·校园失物招领小程序 软件需求规格说明书_v1.5
https://www.kdocs.cn/l/caWM1Pmn6RkY

5.1 文档结构

文档参考 GB/T 9385-2008《计算机软件需求规格说明规范》组织，在国标规定目录基础上补充了 "术语与缩写" 和 "非目标" 两节，满足国标对缩写必须先定义的要求，并明确需求边界。

章节	内容
1 引言	编写目的、项目背景、术语与缩写、参考资料
2 总体描述	产品目标、用户特征、用户场景、运行环境与约束、假设与依赖、非目标
3 具体要求	类图、数据需求、接口需求、非功能需求
4 界面原型	信息架构与导航、页面清单、关键交互流程、界面设计规范
5 功能描述及验收验证标准	具体功能描述、输入输出格式、界面验收标准、功能验收标准
附录 A	需求追溯矩阵
附录 B	原型页面索引

5.2 用户场景

需求分析阶段围绕校园失物找回的完整闭环，梳理出四类典型参与者（失主、拾主、校园管理员、系统），并沉淀出四个核心场景。每个场景的每一步都可回溯到具体用例（UC-xx）与功能（F-xx）：

场景	涉及用例	触发情境	用户目标	关键流程	对应功能
场景一：雨天走失的折叠伞（从发布到取回）	UC-01→UC-08→UC-04→UC-05→UC-06→UC-07	林同学在图书馆自习区遗失鼠尾草绿折叠伞	尽快找回	发布寻物→系统按类别 / 颜色 / 地点 / 时间匹配出 92% 线索→匿名沟通核验独有细节→提交认领→拾主确认→服务台取回	F-07、F-21、F-25、F-18、F-28
场景二：拾主的善意闭环	UC-02→UC-04→UC-05→UC-07→UC-10	叶同学在教学楼拾到物品并拍照	安全、体面归还且不暴露手机号	发布招领→登记服务台代管→匹配提醒→匿名核验→确认归还→善意值 +10	F-08、F-18、F-25、F-28、F-30
场景三：暂时没有线索的等待	UC-01→UC-08（无线索分支）→UC-09	发布寻物后暂无候选	不丢线索、持续被主动提醒	展示 "暂无线索"→调整描述重算→一周后产生 54% 新线索并推送	F-20、F-22、F-21、F-23
场景四：防冒领的异常路径	UC-06→UC-07（异常分支）→UC-11	认领细节对不上	杜绝冒领	认领被驳→招领单恢复 "待认领"→涉嫌冒领举报→管理员处理并回写	F-18、F-19、F-23

此外还梳理了 5 类边界场景：未认证用户首次使用、收纳点代管与取回、招领墙筛选无结果、关闭订阅提醒、草稿续写，分别覆盖认证引导、线下交归、空态提示、隐私开关与草稿恢复等异常路径。

5.3 类图

按墨刀高保真原型的界面与交互态做对象化建模，共抽象出 17 个类，按职责划分为五层：

• 用户与角色层：用户（抽象）、学生用户、校园管理员 —— 承载校园认证、账号资料与善意值，是全部业务的归属主体；

• 失物与发布层：失物（抽象）、寻物单、招领单 —— 承载 "我丢东西了" 与 "我捡到了" 两条业务线的结构化记录；

• 匹配与认领层：匹配记录、认领申请、收藏 —— 承载线索生成、核验申请与取回闭环；

• 消息与互动层：消息（抽象）、匿名私信、系统通知、匿名会话、评论、举报 —— 承载四类消息、匿名沟通与内容治理；

• 支撑层：善意值记录、收纳点 —— 承载善意激励与线下交归。

  classDiagram
      class User { userId nickname avatarUrl verifyStatus kindnessScore }
      class Student { studentNo college publishedCount recoveredCount }
      class Admin { adminNo campus handledCount }
      class LostItem { itemId itemNo category color detail occurPlace occurTime status }
      class LostReport { reportId ownerId searchStatus clueCount }
      class FoundReport { reportId finderId keeperMessage claimCount }
      class MatchRecord { matchId lostReportId foundReportId similarity criteria state }
      class Claim { claimId secretDetail takeMethod progress }
      class Message { msgId receiverId type isRead }
      class PrivateMessage { senderId text sendState }
      class SystemNotice { noticeType actionText pushed }
      class Conversation { userAId userBId state }
      class KindnessRecord { recordId delta reason balance }
      class StoragePoint { pointId name location }
      Student "1" --> "0..*" LostReport : 发布寻物
      Student "1" --> "0..*" FoundReport : 发布招领
      LostReport <|-- LostItem
      FoundReport <|-- LostItem
      LostReport "1" --> "0..*" MatchRecord
      FoundReport "1" --> "0..*" MatchRecord
      MatchRecord "1" --> "0..*" SystemNotice : 触发
      Conversation "1" --> "1..*" PrivateMessage : 组合
      PrivateMessage <|-- Message
      SystemNotice <|-- Message
      Student "1" --> "0..*" Claim
      Claim "1" --> "0..1" KindnessRecord : 归还后+10
      StoragePoint "1" --> "0..*" FoundReport : 代管
  

关系说明摘录：寻物单与招领单共用父类「失物」的物品特征与状态，差异只体现在业务身份（失主 ownerId / 拾主 finderId），避免同一套表单结构重复建模；匹配记录是关联实体，相似度与判据属于 "关系" 而不属于任何一张单据；匿名会话与匿名私信为组合关系，会话结束即不可再发；同一账号在不同业务中以失主、拾主身份出现，故不按角色拆类。

5.4 功能描述与验收验证标准

功能项按业务模块组织，共 F-01～F-30：首页与导航、发布、招领墙、物品详情与认领、智能匹配、消息与沟通、个人中心与善意值七大模块，每条功能用统一模板记录。示例如下：

F-21 相似度排序与判据展示
  描述：按相似度倒序展示候选招领记录，每条含相似度百分比（92% / 68% / 54%）与判据标签（✓类别一致 ✓颜色接近 ✓同一地点）。
  入口：匹配页「查看线索 ›」进入线索解释页。
  处理：类别、颜色、关键词、地点、时间加权计算 → 按相似度降序 → 附判据标签。
  输出：排序后的候选列表与判据说明。
  异常：相似度低于展示阈值（建议 50%）的候选不进入列表；列表底部固定提示"相似度只提供线索，认领仍需双方核验"。
  优先级：P0
  来源场景：场景一、场景三（UC-08）

验收验证标准分三类，全部写成可执行、可判定的形式：

类别	验收项	编号	通过标准
界面验收（墨刀原型逐页走查）	UI-01～UI-10	首页、发布、招领墙、详情、智能匹配、线索解释、认领核验、匿名沟通、消息、个人中心	全部满足 "元素齐全 + 跳转正确 + 无遮挡"
功能验收（用例逐条执行）	TC-01～TC-20	覆盖发布、匹配、认领、消息、善意值等 P0 场景	P0 用例全部通过；P1 未通过须记录原因与处理计划
非功能验收（质量属性）	NFR-U-01～10、NFR-S-01～10	可用性（易学性、操作步数、响应时间）与安全性（认证、隐私、认领核验、越权防护）	每条均有可判定的度量口径，如 NFR-U-01：3 名新生 3 分钟内独立完成发布≥2 人

功能验收关键用例示例：

用例	关联功能	操作步骤	预期结果
TC-05	F-07 发布校验	不填必填项直接提交	不可提交并定位到首个必填项
TC-17	F-21 相似度排序	从匹配页进入线索解释页	线索按 92%→68%→54% 降序，判据与数值对应
TC-15	F-18 认领核验	不填细节提交；再填细节并勾选提交	第一次不可提交，第二次提交成功并提示等待拾主确认
TC-19	F-28 善意值	完成一次归还确认	善意值 +10，排行榜降序、本人行高亮

5.5 需求分析过程中的设计思路、问题与解决方式

设计思路：先回答 "谁在什么情境下遇到什么困难"，再收敛为用例与功能需求，最后落到界面原型与验收标准。推导链条为：用户调研 → 角色与用例（UC）→ 场景（SC）→ 类图与数据模型 → 功能编号（F）→ 界面与验收标准（UI / TC / NFR）。

问题一：需求描述过于模糊，无法验收。

初稿出现 "系统要快"" 匹配要准 " 这类主观表述。解决办法是把主观描述翻译成可测指标（如 NFR-U-07 响应时间：招领墙首屏 ≤1.5s；NFR-U-01 易学性：3 名新生 3 分钟内独立完成发布≥2 人），并明确测量口径。

问题二：类图混入了技术组件。

初稿类图出现缓存、消息队列等与业务实体无关的类。解决办法是冻结业务实体清单与术语表，明确类图只描述业务实体（17 类五层），技术组件改由后续设计文档描述。

问题三：用户场景缺乏真实依据。

第一版场景是团队内部讨论写出来的，读起来合理但无法验证。解决办法是补做小范围访谈，把真实丢 / 捡物品的经历整理进四个场景与边界场景，删除没有依据的臆测场景，并让每个场景步骤可回溯到 UC 与 F 编号。

问题四：文档章节口径不一致。

不同成员负责不同章节，出现同一概念多种叫法（如 "招领信息" 与 "拾到信息"）。解决办法是建立术语表作为单一事实来源（失主 / 拾主、寻物单 / 招领单、线索、相似度、善意值），合并时由统稿人统一核查，并新增 "跨章追溯矩阵"（表 4-7）保证每个功能、每个验收用例都有来源。

---

六、界面原型设计

界面原型设计链接：拾光·校园失物招领平台——可交互原型

设计工具与演示规格：墨刀；移动端界面，基准尺寸为 390 × 844 px。原型设置首页、发布寻物、招领列表、失物详情、智能匹配、消息通知、个人中心共 7 个入口画板，内部包含 29 个界面或场景。以下内容依据截至 2026 年 10 月 15 日完成的原型编写。

6.1 设计目标与设计原则

本次原型围绕"丢失物品后，怎样找到线索并取回"展开。用户应当能够从首页找到发布入口，填写寻物信息，查看与某件寻物相关的匹配线索，再通过站内沟通、特征核验和取回确认完成闭环。

设计遵循以下四条原则：

1. 主链路优先。突出"我丢东西了""我捡到了"两个入口，优先完善发布、匹配、详情、沟通与取回流程。首页直接呈现搜索、发布入口和招领信息，减少到达核心功能所需的步骤。

2. 信息分层，操作有反馈。列表展示物品名称、地点、状态与时间，详情页补充物品特征和保管说明。发布校验、草稿保存、消息发送、收藏和取回确认均提供相应反馈；暂无匹配时提供继续寻找的路径。

3. 保护隐私，先核验再认领。公开页面以昵称和物品信息为主，提供匿名联系入口，不要求用户在公开描述中填写手机号、微信号或证件号码。认领页面引导双方核对划痕、刻字等独有细节，匹配相似度仅作为线索。

4. 交互一致，表达贴近校园生活。统一底部导航、卡片、表单、按钮及状态标签，采用暖米底、深青墨和琥珀色。文案使用"我丢东西了""有线索啦""把它带回家"等表达，让用户容易理解下一步操作。

6.2 信息架构

一级导航设置为"首页、招领、发布、匹配、我的"。消息由首页和匹配页的消息气泡图标进入。信息架构如下：

flowchart TD
    Home["首页"] --> Search["搜索 / 招领列表"]
    Home --> LostPub["发布寻物"]
    Home --> FoundPub["发布招领"]
    Home --> Match["匹配：我的寻物列表"]
    Home --> Notify["消息通知"]
    Home --> Me["个人中心"]
    Search --> LostList["寻物列表"]
    Search --> Detail["物品详情"]
    Match --> Results["所选物品的匹配结果 / 暂无线索"]
    Results --> Detail
    Notify --> Results
    Notify --> Inbox["私信会话列表"]
    Inbox --> Chat["与小叶同学的私信"]
    Detail --> Chat
    Detail --> Claim["认领核验"]
    Chat --> Claim
    Claim --> Return["取回安排与确认"]
    Return --> Thanks["找回与感谢"]
    Me --> Posts["我的发布与草稿"]
    Me --> Rank["善意值排行榜"]
    Me --> Favorites["我的收藏"]
    Me --> Stations["校园失物收容点"]
    Me --> Settings["隐私与通知设置"]

其中，"匹配"采用"先选寻物，再看线索"的两层结构。用户先看到自己发布的多件寻物，选择雨伞、耳机充电盒或课本后，再进入对应的结果页面，避免不同物品的线索混在一起。针对具体物品的首页提醒和匹配通知，可以直接进入该物品的结果页。

"私信"采用"会话列表—聊天详情"结构，先展示联系人、最新消息、时间与未读标记，点击联系人后再进入聊天。个人中心保留发布记录、收藏、收容点、设置等管理入口，个性签名支持点击编辑。

6.3 页面清单

按功能归纳，当前原型包含下列 22 类页面，共 29 个界面或场景。表中"高保真"表示视觉细节及主要操作路径较完整；"中保真"表示已呈现页面结构、内容和入口，部分操作以提示或预设结果演示。保真度不代表已经连接后台服务。

编号	页面名称	数量	保真度	关键要素
P01	首页	1	高	校区信息、搜索、寻物与招领双入口、具体物品的新线索提醒、招领卡片、消息入口、底部导航
P02	发布寻物	1	高	图片展示与添加入口、名称、类别、颜色、地点、时间、补充描述、匿名联系、提醒选项、存草稿与发布
P03	发布招领	1	高	拾获物品信息、拾到地点与时间、图片入口、匿名联系、提醒选项、草稿与发布
P04	招领列表	1	高	关键词搜索、类别筛选、地点与时间筛选入口、物品卡片、寻物列表切换
P05	寻物列表	1	高	待寻找物品、地点、发布时间、分类与搜索、详情入口
P06	物品及线索详情	5	高	图片、名称、状态、拾到时间与地点；雨伞主详情含特征、拾到者说明、匿名联系和认领入口，其他线索详情展示对应物品资料
P07	匹配：我的寻物列表	1	高	多件寻物卡片、缩略图、发布时点、寻找状态、线索数量、查看线索入口
P08	分物品匹配结果	3	高	雨伞、耳机和课本各自的结果；相似度、匹配理由、拾到时间、线索发布时间，以及暂无结果状态
P09	消息通知	1	高	匹配提醒、私信回复、认领进度、归还反馈、未读标识、全部已读与订阅提醒选项
P10	私信会话列表	1	高	联系人头像与昵称、最新消息、时间、未读标记、会话搜索
P11	匿名私信会话	1	高	与小叶同学的聊天、关联物品、回复输入与发送、认领申请入口
P12	个人中心	1	高	昵称与认证展示、可编辑个签、发布与归还统计、善意值卡片、发布记录、收藏、收容点与设置入口
P13	发布成功	2	中	寻物发布成功、招领发布成功，展示后续处理步骤及匹配、首页入口
P14	认领核验	1	高	独有特征填写、取回方式选择、归属声明、提交申请
P15	取回安排与确认	1	高	核验通过的预设结果、交接地点、取回时间、位置示意、联系入口、再次确认取回
P16	找回与感谢	1	中	已找回提示、感谢标签、感谢文字、匿名展示选项、返回个人中心
P17	暂无匹配	1	中	无合适线索的说明、补充描述建议、返回发布或招领墙的入口
P18	我的发布与草稿	1	中	进行中与已完成入口、草稿提示、发布记录、匹配、编辑与暂停入口
P19	善意值排行榜	1	中	校园排名、昵称、累计善意值、本人分数与名次、"我"所在行的突出显示
P20	隐私与通知设置	1	中	默认匿名联系、匹配和认领进度提醒、校园认证展示、使用说明
P21	校园失物收容点	1	中	服务台名称、开放时间、位置、可暂存物品及交接说明
P22	我的收藏	1	中	已关注的物品卡片及详情入口

当前版本以已进入平台的校内用户为演示身份，未单独设计登录、注册页面。收容点页面属于服务信息查询，尚不包含工作人员批量登记或权限管理页面。列表采用滚动浏览，未设计分页组件。

原型中的物品、昵称、匹配百分比、通知、排行榜及统计均为演示数据。图片添加、举报、真实消息推送和校园认证等尚未连接后台；认领通过使用预设场景展示。原型主要用于验证页面结构和操作流程。

6.4 关键交互流程

主链路一：从丢失到发布。

用户在首页点击"我丢东西了"，填写名称、类别、颜色、遗失地点、时间及物品细节，确认匿名联系与提醒选项后提交。信息不完整时，页面显示校验提示；用户也可以先保存草稿。发布成功页提供查看匹配线索和返回首页的入口。

flowchart LR
    A["首页：我丢东西了"] --> B["填写物品信息与图片"]
    B --> C["确认匿名联系与提醒选项"]
    C --> D{"表单校验"}
    D -->|"未通过"| B
    D -->|"通过"| E["发布成功"]
    E --> F["查看该物品的匹配线索"]
    B --> G["保存草稿，稍后继续"]

图片在当前原型中用于展示布局与添加反馈，真实文件上传属于后续开发内容。

主链路二：从匹配到取回。

用户点击底部"匹配"，先在"我的寻物"中选择要找的物品，再查看该物品的线索。每条线索分别标明拾到时间和发布时间，帮助用户判断事件先后与信息新旧。进入详情后，用户可通过匿名联系核对独有特征，再提交认领申请、查看取回安排并确认收到物品。

flowchart TD
    A["匹配：我的寻物列表"] --> B["选择一件寻物"]
    B --> C["查看相似度、匹配理由和发布时间"]
    N["收到具体物品的匹配提醒"] --> C
    C --> D["查看物品详情"]
    D --> E["匿名联系，核对独有特征"]
    E --> F["提交认领申请"]
    F --> G["查看取回安排"]
    G --> H["线下核对并取回"]
    H --> I["再次确认已收到"]
    I --> J["标记已找回，填写感谢"]

原型通过预设核验通过结果串联流程；实际系统应由拾到者或工作人员完成核验后更新申请状态。取回按钮设置再次确认，减少误触导致的提前结束。

辅助流程：私信与善意反馈。

• 私信：消息 → 私信 → 会话列表 → 小叶同学 → 聊天。进入会话后清除该会话的未读标记；发送回复后，列表中的最新消息同步更新。原型在本机浏览器中保留演示聊天内容。

• 个签编辑：个人中心 → 点击个签或铅笔 → 编辑 → 保存或取消。输入上限为 60 字，保存后在同一浏览器中保留，取消不改变原文。

• 善意值排行：个人中心 → 点击"你的善意，有人记得"卡片 → 善意排行榜。页面按示例分数排序，并展示本人 120 分、第 4 名及"我"的标记。界面说明双方确认归还后善意值增加，分数结算和排名更新尚未与后台联动。

6.5 状态设计

状态设计以原型中可观察到的页面和交互为依据，区分已经覆盖的情况与后续联调需要补充的情况。

状态	触发条件	界面表现	当前完成情况
正常状态	存在招领信息或匹配线索	卡片、状态标签、地点、时间、详情入口；匹配页附相似度和原因	已覆盖
暂无匹配	所选寻物暂无线索	显示暂无结果，提示补充细节或到招领墙继续查找	已覆盖课本暂无结果及独立暂无匹配页
搜索无结果	物品或私信搜索没有匹配内容	显示无结果说明，引导更换关键词或发布寻物	已覆盖
输入校验未通过	发布信息不完整，或认领特征、归属确认未满足要求	显示提示，停留在当前表单以便补充	已覆盖前端校验
操作反馈	保存草稿、收藏、发送消息、全部已读等操作	短时提示、文字或未读标记更新	已覆盖前端演示反馈
未读与已读	存在新消息，或进入会话、执行全部已读	数字或"新"标记，阅读后移除相应标记	已覆盖演示交互
取回确认与完成	用户点击确认收到并再次确认	首次提示再次核对，确认后进入找回与感谢页，展示已找回状态	已覆盖
加载状态	网络请求、文件上传或匹配计算尚未完成	后续补充加载提示，必要时防止重复提交	尚未制作独立加载场景
网络或服务错误	发布、上传、取数失败	后续补充失败原因、重试入口及输入内容保留	尚未接入真实网络错误场景
未登录或无权限	访问需要身份或工作人员权限的功能	后续结合认证与后台职责补充登录引导或访问限制	当前未设计对应页面

因此，当前原型已经覆盖核心流程的正常状态、暂无结果、输入校验和操作反馈，但不将加载、网络错误、登录及权限场景列为已完成内容。

6.6 界面设计规范

视觉规范沿用选题材料的暖米、深青和琥珀色，结合圆角卡片及物品插画，形成温和、清晰的校园互助界面。

类别	规范	实际应用
页面尺寸	390 × 844 px，纵向浏览	与当前墨刀手机演示设备一致，长内容在页面内滚动
主背景	暖米色 #FBF6EC	页面底色，降低大面积纯白的生硬感
主色	深青墨 #1F4E5F	标题、正文重点、主按钮、善意值信息卡
强调色	琥珀色 #C98A2D	发布入口、未读标记、线索提示、排名和分数重点
辅助色	鼠尾草绿 #DCE6DD，近白 #FFFDF8	招领入口、温和状态、列表卡片与表单底色
文本与分隔	灰绿 #798782；浅灰米 #E5DFD2	辅助说明、时间地点、边框和分隔线；状态同时使用文字标签表达
字体	微软雅黑、苹方等中文无衬线字体；部分分值使用 Georgia	中文信息以易读为主，排名与相似度通过数字大小突出
字号层级	页面标题约 20–22 px；内容标题约 15–26 px；正文约 12–14 px；辅助文字约 10–12 px	区分页面名称、物品名称、说明与时间；原型中的少量标记使用更小字号
间距与留白	内容区左右各 20 px；常用间距 12、16、20、24 px，局部按内容调整	表单、卡片和模块对齐；当前原型未强制所有尺寸均为 8 px 倍数
圆角与边框	常用卡片圆角约 14–22 px，辅以 1 px 浅色边框	卡片、按钮、输入框采用相近的圆角语言
按钮	深青主按钮；浅绿次按钮；琥珀用于发布等突出操作	使用明确的动词，如"发布寻物""提交申请""确认收到"
表单	标签位于输入项上方，必填项标星，结构化信息使用选择框	名称、类别、颜色、地点、时间与补充描述按顺序排列
导航	首页、招领、发布、匹配、我的；发布入口突出	一级页面使用统一底部导航，二级流程使用返回入口或底部主操作区
时间与状态	拾到时间和发布时间分别标注；使用"寻找中""待认领""已找回"等标签	避免混淆物品事件发生时间与线索发布时间
常用组件	搜索栏、操作按钮、表单项、物品卡片、标签、会话行、未读角标、提示条、个签编辑弹窗	相同用途采用一致样式；当前原型未使用抽屉组件

最终首页已移除顶部宣传卡片，以"校区信息与消息—搜索—发布双入口—线索提醒—招领物品"的顺序组织内容。通过上移核心操作、统一模块间距并调整物品图片区大小，使用户进入首页后可以更直接地发布或查找物品。

---

七、需求分析 PPT 链接

需求分析 PPT 链接：【金山文档 | WPS云文档】 拾光校园失物招领平台需求分析
https://www.kdocs.cn/l/cjlEZcvuc3Ga

页码内容规划：1 封面 → 2 目录 → 3 项目背景与问题来源 → 4 目标用户与用户画像 → 5 用户场景（SC-01 至 SC-04）→ 6 功能需求范围 → 7 类图 → 8 数据需求与接口需求 → 9 界面原型目标与页面清单 → 10 信息架构 → 11 关键交互流程 → 12 验收验证标准 → 13 关键点难点与风险 → 14 团队分工与进度落实情况。

---

八、界面原型设计答辩 PPT 链接

界面原型设计答辩 PPT 链接：【金山文档 | WPS云文档】 拾光·校园失物招领 答辩汇报（拾光友人帐）
https://www.kdocs.cn/l/cmJrLY4Zblit

界面原型设计答辩 PPT 围绕 "设计原则、信息架构、关键路径、状态设计、设计规范" 五条线组织，页面截图全部来自可运行的原型。

---

九、小组评审表

按照作业要求，每个小组需要提交本次作业的简易评审表，内容包括小组名称、项目名称、评审的内容、评审建议，以及各小组名称和排名，采用腾讯共享文档填写。

评审表	链接
界面原型设计评审表	https://docs.qq.com/sheet/DRUtITXJFb1dmeW9n?tab=000001
需求分析评审表	https://docs.qq.com/sheet/DY2h5Tk1wd1VzaW5x?tab=000001

评审表在上一阶段《报告评审表》模板基础上调整评分维度：界面原型设计评审表按信息架构、页面完整度、交互设计、视觉规范、可落地性五个维度评分；需求分析评审表按需求真实性、用户场景、类图、功能描述与验收标准、需求边界五个维度评分。各维度均给出具体评审建议，不只给分数。

---

十、评分要点自检

评分项	分值	本文对应位置
博客排版，采用 markdown 排版，正确给出需求规格说明书、界面原型设计、界面原型设计答辩 PPT、需求分析 PPT 四个链接	2	全文使用 markdown 排版，四个链接分别见第五、六、七、八章
组队后项目整体计划安排，有明确的里程碑	6	第一章，含四阶段计划与 M0 至 M7 里程碑表
项目进行过程中可能遭遇的关键点、难点与风险分析	5	第二章，含 3 个关键点、4 个难点、7 项风险
组员分工、组员工作量比例	7	第三章，含规定格式的分工表与比例计算依据
加强团队成员分工协作，描述成员协作方式	16	第四章，含沟通工具与节奏、版本仓库协作、冲突处理、任务同步机制
需求规格说明书：引言、用户场景、类图、界面原型、功能描述、验收验证标准	32	第五章，含文档结构、用户场景表、类图、功能需求模板与验收标准表
参考国标规范撰写需求规格说明书	12	第五章 5.1 节，文档结构参照 GB/T 9385-2008 组织

---

十一、结语

本次作业的核心不是把文档写厚，而是把 "用户真实遇到什么问题" 翻译成 "软件必须做到什么" 再翻译成 "用什么界面承载、用什么标准验收"。整个过程中我们最深的体会是：失物招领这类产品，难的不是功能多，而是让 "丢东西" 这个高频又紧急的场景真正被快速、可靠地解决。为此我们付出了多轮返工 —— 把主观描述拆成可测指标、把混入类图的技术组件移出、把没有访谈支撑的场景删掉 —— 但这些返工让后面的原型设计和验收标准都有了共同的判断依据。