软件工程实践团队第二次作业——原型设计&需求分析

你不对我队 2026-10-15 14:40:10

项目	内容
这个作业属于哪个课程	202601福大-软件工程实践-W班社区
这个作业要求在哪里	软件工程实践团队第二次作业——原型设计&需求分析
团队名称	你不对我队
这个作业的目标	完成《最后一班地铁：0017》的界面原型设计与需求分析：交付可访问的界面原型、符合国标规范的软件需求规格说明书、需求分析与原型答辩两份 PPT、两份评审表，并在博客中记录团队计划、分工与协作方式
其他参考文献	GB/T 9385《计算机软件需求规格说明规范》；GB/T 8567《计算机软件文档编制规范》；《构建之法》；Ink 叙事脚本格式说明；本项目《团队展示与选题报告》

「你不对我队」——原型设计 & 需求分析

队名：你不对我队　|　项目：《最后一班地铁：0017》——一款 27 分钟的调度叙事游戏（最终形态由 Godot 实现、导出 Web 版；本次作业交付的界面原型为 2D 交互原型）　|　团队规模：8 人
上一篇：「你不对我队」——团队展示与选题报告
交付仓库：华为云 CodeArts Repo —— 0017_1

本次交付物一览

#	交付物	入口
1	本篇博客随笔	就是本页
2	界面原型设计（可访问）	线上可玩：https://visionary-concha-bf9fea.netlify.app/ ｜仓库 `prototype/`
3	界面原型设计答辩 PPT	仓库 `slides/原型答辩.pptx` + `slides/原型答辩.pdf`
4	软件需求规格说明书	仓库 `srs/srs-v1.5.docx` + `srs/srs-v1.5.pdf`（70 页，含第 4 章 14 张界面截图）
5	需求分析报告 PPT	仓库 `slides/需求分析.pptx` + `slides/需求分析.pdf`
6	界面原型设计评审表	腾讯共享文档：https://docs.qq.com/sheet/DV0N2QkRXU3dsa2d5?tab=000001
7	需求分析评审表	腾讯共享文档：https://docs.qq.com/sheet/DV3RGaW5DVFdpRm9x?tab=000001

说明：仓库中的文档均同时提供源文件与导出的 PDF，PDF 为对外阅读版本。点开仓库进入对应目录，打开文件后复制地址栏链接即可直达。

博文目录

一、团队项目计划

1.1 项目里程碑

周次按周一至周日划分。第二次作业从第 2 周周五（10/9 作业发布）启动，交付落在第 3 周。

周次	时间	阶段目标	主要交付	主责	状态
第 1 周	9/28–10/4	立项与原型	选题报告、团队展示、范围确认、角色认领、30 秒时间原型	制作人 / 核心程序	已完成
第 2 周	10/5–10/11	第一条循环 · 第二次作业启动（10/9）	时间推进、一个广播事件、一个事故结局；10/9 作业发布后定下范围与分工	核心程序 / UI 程序	已完成
第 3 周	10/12–10/18	第二次作业交付（垂直切片）	界面原型、需求规格说明书、需求分析 PPT、原型答辩 PPT、两份评审表、博客；10/15 截止、10/16 课堂答辩	全体	本次已完成
第 4 周	10/19–10/25	垂直切片收尾	前两轮循环 + 2 名乘客 + 线索板 + 重开跑通	叙事 / 程序	未开始
第 5–6 周	10/26–11/8	核心内容完成	3 名乘客、4 轮循环、2 个结局、存档	叙事 / 程序	未开始
第 7–8 周	11/9–11/22	美术与演出	地图、头像、图标、广播、转场、音效	美术 / 动效 / 音频	未开始
第 9–10 周	11/23–12/6	测试与优化	全流程回归、新手引导、性能与 Bug 修复	测试 / 全体	未开始
第 11–12 周	12/7–12/20	答辩交付	宣传视频、PPT、博客、现场演示与备用录屏	制作人 / 全体	未开始

第 4 周硬门槛：如果在前两轮循环 + 2 名乘客 + 重开仍未跑通，立即冻结内容扩展，优先保证核心闭环可运行。

说明：里程碑以「可运行版本」为准，不以「写了多少代码」为准；每周五在周会上核对一次，延期需提前一天说明。

1.2 本次作业排期

以 10/9（周五）作业发布 为第 0 天起算，到 10/15（周四）23:59 截止、10/16（周五）课堂答辩。

时间	里程碑	产出	实际
10/9（周五）	作业发布 · 范围与分工确认	吃透作业要求与评分口径；定下五个组与组长；建好华为云仓库与目录	达成
10/10–10/12（周六～周一）	原型与文档骨架	可玩原型跑通主流程；需求规格说明书搭起「引言 / 用户场景 / 类图」三节；两份 PPT 定结构	达成
10/13（周二）晚	启动会 + 骨架就位	分工确认、仓库与目录建好、两份腾讯评审表创建并开放权限	达成
10/14（周三）	三大件初稿	需求规格说明书合稿、需求分析 PPT 初稿、原型答辩 PPT 初稿、原型链接可访问	达成（当晚合稿到 v1.4）
10/15（周四）上午	交叉评审 + 定稿	逐章复核并改错；两份 PPT 导出 PDF；说明书回填第 4 章 14 张界面截图	达成（SRS v1.6、四份 PDF 均入库）
10/15（周四）14:00 前	博客发布	博客正文发布、四个链接回填、两份评审表链接填入汇总文档	已发布
10/15（周四）18:00 前	自查与提交	无痕窗口逐条验链接（共 6 条），作业页面提交	待执行
10/15（周四）23:59	截止	—	—
10/16（周五）	课堂答辩	界面原型演示 + 需求分析 PPT + 原型答辩 PPT	—

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

2.1 事前识别

关键点 / 难点 / 风险	可能影响	应对措施
需求规格说明书是本次最重的交付（32 分 + 国标规范 12 分）	内容堆砌但读者看不懂，得分低	按国标目录分「引言—总体描述—具体要求—界面原型—功能与验收」五层展开；每写完一节，由一名不负责该节的成员按「外人能否读懂」标准复核
界面原型必须可访问，且原型与需求必须一一对应	原型改了但文档 PPT 没同步，答辩时对不上	原型作为唯一事实来源，界面编号在说明书、两份 PPT 中统一引用；改动后由交互负责人当天同步三处
时间紧：10/15 截止、10/16 答辩、博客需审核	卡点发布导致缺交或 50% 计分	博客提前发布；所有文件 10/14 晚先上传仓库占位，10/15 更新版本
评审表与仓库链接的访问权限	老师或他组打不开，排序评分受影响	腾讯共享文档与仓库均开放访问，提交前用无痕窗口逐一验证
8 人并行改多份文档	版本冲突、内容重复或丢失	一份文件同时只有一名主责人在改；其他人走「先说明再改」
分工与贡献度需可追溯	贡献度写成主观数字，被质疑	贡献度以仓库提交记录、任务板状态和评审记录为依据，博客中给出 8 人的具体工作内容

2.2 事后复盘：我们实际踩到的坑

计划里没写、但真实发生了的三件事，以及我们怎么处理的 —— 这部分是本次最值得记下来的经验。

坑 1：三份材料的「口径」先于内容崩塌。
原型、说明书、两份 PPT 是四条并行线，合稿时才发现四份材料对同一件事有四种说法：项目形态写成了 2D / 3D / WebGL+Three.js 三种，单局时长写成 27 分钟 / 20–30 分钟两种，界面编号并存 UI-xx / U-x / A0x–B0x 三套。

处理：先定死一句话口径（本次交付 = 2D 交互原型；最终成品 = Godot 实现、导出 Web 版），再让四份材料逐条对齐；界面编号统一到说明书第 4 章的 UI-01～UI-14，并按下表把截图、说明书、两份 PPT 三处编号对齐。教训：口径必须在开工第一小时冻结，不能等合稿。

坑 2：文档写了「待回填」，然后就真的没回填。
说明书第 4 章的 14 张界面截图一度是占位框，理由听起来很合理——「原型还没定稿」。结果一直拖到答辩前一天，第 4 章（8 分）几乎裸奔。

处理：把原型组已有的截图按编号逐张回填，同时在说明书里如实标注两处例外（广播、人员安排这两个界面在本版原型中没有独立画面，以主界面 HUD 提示条呈现），而不是含糊过去。教训：占位符必须带截止时间和负责人，否则等于没有。

坑 3：原型与说明书描述的不是同一套界面。
说明书第 4 章原本写的是一套「调度台 + 列车/广播/人员三个覆盖面板」的界面，而真实原型是「一屏一目标、点标签推进」的屏幕式结构，两边对不上。

处理：以真实原型为准，把第 4 章的界面清单整章重排为 UI-01 启动页 / UI-02 主菜单 / UI-03 读取存档与设置 / UI-04 序章·控制台 / UI-05 调度台主界面 / UI-06 背包（兼线索板）/ UI-07 岔区·道岔信号 / UI-08 改环线·绿灯放行 / UI-09 轮次结算与循环过渡 / UI-10 结局界面，10 个界面全部配真实截图。教训：说明书要跟着原型走，不是原型跟着说明书走。

三、项目分工

3.1 角色分工

角色	成员	主要职责
制作人 / 项目经理	小千（102400126）	维护范围、任务板、里程碑、版本号、风险清单、PPT 与最终提交
主笔 / 叙事策划	。。（102400128）	3 名乘客小传、4 轮剧情变化、线索表、广播、对白与两个结局
核心系统程序员（同时兼任各交付组组长：心境—需求分析 PPT 组、chs—原型答辩 PPT 组、飞哟飞—原型组）	sleeplis（102400106）、心境（102400114）、飞哟飞（102400121）	游戏时钟、事件触发、状态机、循环重置、线索管理与存档
交互 / UI 程序员	王嘉萍（102400206）	车站地图、调度台、线索板、乘客详情与完整交互流程
场景与角色美术	chs（102400101）	地图、3 名乘客头像、功能图标、事故插画与结局配图
测试 / 音频 / 构建	yuesart（102400107）	测试用例与 Bug 表、音效整理、构建、部署、备份与录屏

每个模块设一名负责人与一名交叉评审人，所有人参与测试与代码评审。

3.2 本次作业分工与贡献度

学号	工作内容	贡献度
102400126	小千（统筹组）：仓库与最终提交；博客撰写与发布；两份评审表的创建、权限配置与小组排名表；答辩主讲（两份 PPT 均由小千主讲）；并参与界面原型的开发与迭代	13%
102400128	。。（需求规格说明书组组长）：目录与章节结构、用户场景、功能描述、验收验证标准；全文合成与导出 PDF	13%
102400206	王嘉萍（需求规格说明书组）：界面原型章节、界面验收标准、交互流程说明	12%
102400106	sleeplis（需求规格说明书组）：类图与属性说明、数据模型、可用性与安全性	13%
102400114	心境（需求分析 PPT 组组长）：需求分析报告 PPT 主编、导出 PDF；答辩时负责该份 PPT 的补充问答	13%
102400101	chs（原型答辩 PPT 组组长）：界面原型答辩 PPT 主编、界面视觉规范与原型截图；答辩时负责该份 PPT 的补充问答	12%
102400121	飞哟飞（原型组组长）：可访问的界面原型链接	12%
102400107	yuesart（需求规格说明书组）：引言、项目背景与参考资料；验收标准可验证性复核	12%

合计 100%。贡献度以仓库提交记录 + 任务板状态 + 评审记录为依据，不按主观印象填写。

3.3 答辩分工

环节	谁	内容
开场	小千	队名、项目一句话介绍、为什么做这个游戏
需求分析 PPT 主体	小千	用户与场景、业务流程、用例与数据流图、类图与数据模型、功能与验收标准（PPT 主编：心境）
计划落实与分工	小千	里程碑完成情况、8 人分工与工作量比例、成员协作方式
界面原型答辩 PPT	小千	原型整体流程、关键界面、设计取舍、与需求条目的对应（PPT 主编：chs）
现场原型演示	飞哟飞	按脚本演示，出问题立即切换备用录屏
补充问答	。。、sleeplis、王嘉萍、心境、chs	剧情设定、类图与数据、界面与交互、两份 PPT 的细节问题分别由主责人回答
计时与翻页	yuesart	控场计时，超时提醒

四、成员协作方式

4.1 沟通工具

场景	工具	约定
日常同步	微信群	任务认领、阻塞上报、文件链接都在群里留文字记录，不用语音结论
评审与答辩演练	腾讯会议	启动会、定稿会、答辩前演练各一次
文档协同	腾讯共享文档	评审表与汇总表，权限对所有评审方开放
代码与文件	华为云 CodeArts Repo	所有交付物源文件与 PDF 统一存放

4.2 版本仓库协作

仓库结构：prototype/（界面原型）、srs/（需求规格说明书）、slides/（两份 PPT）、reviews/（评审表）、blog/（博客备份）；
每份文件同时提交源文件与导出的 PDF，PDF 为对外链接版本；
commit message 统一格式：[模块] 内容 - 负责人，例如 [srs] 引言与用户场景初稿 - 。。；
每位成员使用本人账号提交，禁止代提交、禁止直接覆盖他人文件；
文件命名优先使用英文小写与连字符，例如 srs-v1.5.pdf。

4.3 冲突处理

同一份文件在同一时间只有一名主责人在编辑，其他人改动前先在群里说明；
出现方案分歧时，由制作人收集两版方案的依据，全组投票决定，不挂起、不重复返工；
如果两人改了同一处的不同版本，保留两者当场比对，由主责人合并后重新提交，并在群里说明合并了什么。

4.4 任务同步机制

任务板认领制：每项任务有负责人、截止时间和验收标准，未认领的任务在复盘时强制指派；
每日 22:00 群内报进度，固定三段式：已完成 / 进行中 / 阻塞与需要的支持；
遇到阻塞，30 分钟内记录报错、复现步骤和已尝试的方法再求助，主动暴露问题不扣分；
每周五按《团队绩效考核方案》复盘一次，公布依据，成员可提出申诉。

4.5 交叉评审

每份交付物设一名主责人与一名交叉评审人，本次作业的交叉安排：需求规格说明书由 sleeplis 复核，需求分析 PPT 由。。复核，原型答辩 PPT 由飞哟飞复核，博客由 yuesart 复核。评审意见当天给出，主责人在 24 小时内回复处理结果。

本次交叉评审真实拦下了问题：复核意见集中在「口径不一致」上——时长口径、界面编号、线索条数三处，都在定稿前改掉了（见 2.2 坑 1）。

4.6 协作留痕

图 1　团队协作留痕（一）

图 2　团队协作留痕（二）

我们的协作不靠「印象里大家都很配合」，而是每条约定都留下可查的记录：任务认领在群里留文字、进度每天 22:00 汇总、文件变更看仓库提交记录、方案分歧留投票结论。上面两张截图是本次作业期间的协作留痕。

五、软件需求规格说明书

**文档链接：https://devcloud.cn-north-4.huaweicloud.com/codehub/project/dd4db3ea414b4e9093b5256a5533eed1/codehub/3097650/home?ref=master&filePath=srs%252Fsrs-v1.5.pdf&isFile=true

参照 GB/T 9385《计算机软件需求规格说明规范》撰写，按「引言 — 用户场景 — 类图与数据模型 — 界面原型 — 功能描述及验收验证标准」分层展开，全文 5 章 + 附录 A–E，共 70 页；
第 4 章按 UI-01～UI-14 逐界面给出「用途 / 界面元素 / 跳转关系 / 原型截图」，10 张截图均取自真实原型；
第 5 章给出可判定的验收标准：功能验收 A1–A7 与端到端验收用例 T1–T8，每条都写明判定方法与通过标准；
文档内的分工表按「文档工作量比例」统计，与博客中的贡献度口径分开说明。

六、界面原型设计

原型在线地址： https://visionary-concha-bf9fea.netlify.app/
仓库位置： prototype/

可玩原型：浏览器直接打开，无需安装；覆盖「启动 → 主菜单 → 读取存档 / 设置 → 序章·控制台 → 第 1～4 轮 → 岔区道岔 → 改环线 → 00:17 结算 → 结局 A / 结局 B」，含时间代价、分支判定与双结局；
界面设计稿：prototype/svg/（8 屏矢量，文字图形可编辑）与 prototype/png/（8 屏位图）；prototype/screenshots/ 收有原型合集 16 张截图；
Figma 16 屏生成器：prototype/figma-plugin/，导入 Figma 后可一键生成 16 屏高保真界面并连通热区；
编号口径：说明书、两份 PPT 中的界面编号统一为 UI-01～UI-14（第 4 章表 4-1）。

关于「循环」的设定（答辩常被问到，这里先写明）：十七年前的当天，0017 次在岚桥站驶入废弃四道，十九人没能下车。这一天，4 号线改造唤醒了封存多年的旧信号设备，那一夜的 23:50–00:17 被重新播放——最多 4 次机会，每次 27 分钟。循环只对坐在调度席上的人成立：三名乘客不记得循环，但会记得玩家。

七、需求分析 PPT

**PPT 链接：https://devcloud.cn-north-4.huaweicloud.com/codehub/project/dd4db3ea414b4e9093b5256a5533eed1/codehub/3097650/home?ref=master&filePath=slides%252F%25E9%259C%2580%25E6%25B1%2582%25E5%2588%2586%25E6%259E%2590.pdf&isFile=true

内容：项目目的与意义、用户与使用场景、业务流程、用例与数据流图、类图与数据模型、功能与验收标准（含当前进度）；
报告部分说明本次作业的团队计划落实情况、分工与工作量比例。

八、界面原型答辩 PPT

**PPT 链接：https://devcloud.cn-north-4.huaweicloud.com/codehub/project/dd4db3ea414b4e9093b5256a5533eed1/codehub/3097650/home?ref=master&filePath=slides%252F%25E5%258E%259F%25E5%259E%258B%25E7%25AD%2594%25E8%25BE%25A9.pdf&isFile=true

内容：原型目标与范围、三层原型架构、原型整体流程、视觉规范、关键界面讲解、设计取舍、与需求条目的对应关系、演示路径与备用方案。

九、评分要点自查

评分项	分值	对应位置	自查
博客排版与四个链接	2	开头格式表、本次交付物一览、五至八节	✅ 已逐条给出
组队后项目整体计划安排	6	1.1 / 1.2	✅ 里程碑 + 排期 + 实际达成
关键点、难点分析	5	二节	✅ 事前识别 + 事后复盘三个真实坑
组员分工与工作量比例	7	3.1 / 3.2	✅ 8 人具体工作内容 + 贡献度合计 100%
成员协作方式	16	四节	✅ 工具 / 仓库 / 冲突 / 同步 / 交叉评审 / 留痕
需求规格说明书：引言、用户场景、类图、界面原型、功能描述、验收标准	32	五节所链接文档	✅ 5 章齐全，第 4 章含 10 张真实截图
国标规范符合度	12	五节所链接文档	✅ 目录 / 术语与缩写 / 图表编号 / 统一字体行距
答辩：目的背景、研发内容、计划落实与分工、PPT、报告	20	七、八节所链接 PPT	✅ 两份 PPT + 现场演示脚本

十、总结与反思

本次作业我们真正学到的，不是「怎么写一份国标格式的说明书」，而是四条并行线必须在第一小时对齐口径。

8 个人、4 条交付线（原型 / 说明书 / 两份 PPT）同时推进，最容易出事的不是谁写得少，而是同一件事在不同文档里有不同说法：项目是 2D 还是 3D、单局是 27 分钟还是 20–30 分钟、界面编号是 UI-xx 还是 A0x–B0x、线索是 6 条还是 5 件。这些问题单个看都很小，但合在一起就是「文档和原型对不上」——恰恰是评分表里最容易被看出来的地方。

我们的做法是：先冻结一句话口径，再让四份材料逐条对齐，并把三处真实踩过的坑写进 2.2 节。下一次交付，我们会把「口径表」作为开工第一个产出物，而不是等到合稿才回头找。

另外附上本次交付的核对口径，供评审参考：

项目形态：本次作业交付的界面原型是 2D 交互原型；最终成品由 Godot 实现并导出 Web 版部署到浏览器；
单局时长：真实单局 20～30 分钟；游戏内单轮时间窗 23:50–00:17（27 分钟），共 4 轮；
首版规模：1 个车站、3 名关键乘客、4 轮循环、5 件记录、2 个结局、三类调度操作；
界面编号：说明书第 4 章 UI-01～UI-14，与两份 PPT、原型截图三处一致。

更新记录

日期	更新内容	更新人
2026-10-13	建立博客骨架，填写计划、分工、协作方式	小千
2026-10-15	补齐四份交付物链接、新增事后复盘与总结、回填协作留痕截图	小千

...全文