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

目录

• 一、项目引言
  • 1.1 编写目的
  • 1.2 项目背景
  • 1.3 参考资料
  • 1.4 术语和缩略语
• 二、项目总体描述
  • 2.1 项目目标
  • 2.2 团队项目计划与里程碑
  • 2.3 版本路线
• 三、项目具体要求
  • 3.1 关键点、难点与风险分析
  • 3.2 组员分工与工作量比例
  • 3.3 成员协作方式
• 四、界面原型
  • 4.1 原型展示
  • 4.2 原型链接
• 五、功能描述及验收验证标准
  • 5.1 具体功能描述
  • 5.2 本次作业目录与交付链接
  • 5.3 验收验证标准

一、项目引言

1.1 编写目的

本文用于说明《校园突袭》团队项目的开发背景、目标、阶段计划、关键风险、成员分工、协作方式及课程交付物，便于团队成员、课程教师和评审人员了解项目如何开展、当前完成情况以及后续验收重点。文中“计划”“当前状态”和“待完成”分别表示目标安排、已有材料或工程证据、尚需完成的工作，避免将计划表述为已完成成果。

1.2 项目背景

1.3 参考资料

1. GB/T 8567—2006《计算机软件文档编制规范》。
2. GB/T 9385—2008《计算机软件需求规格说明规范》。
3. 《校园突袭》项目设计方案、需求规格说明书及界面原型材料。
4. Unity 官方文档及团队当前 Demo 工程。

1.4 术语和缩略语

二、项目总体描述

2.1 项目目标

开发意图：

团队通过需求分析、原型设计、面向对象建模和 Unity 实现，完成一款可演示的校园题材团队射击游戏，实践软件工程中的需求管理、模块分工、接口协作、版本控制和验收验证方法。

应用目标和作用范围：

本项目面向课程展示、同学试玩和软件工程实践教学。当前交付重点为可在单机环境体验的核心比赛流程，由人工玩家与 AI 角色组成对战队伍；工程中包含局域网联机实现，是否纳入本阶段验收以完成双设备实测为准。账号、战绩服务和大规模在线匹配属于后续设想，不作为当前阶段已交付功能。

产品前景：

当前版本以核心玩法闭环和课程演示为目标。后续可在稳定单机比赛流程的基础上完善局域网联机、增加地图与武器、改进 AI 行为，并进一步优化设置和比赛反馈。是否扩展由团队根据课程周期、用户反馈和实现成本评估。

2.2 团队项目计划与里程碑

《校园突袭》是一款以校园建筑为战场的第一人称团队战术射击游戏。项目以团队歼灭为核心，红蓝双方在地图中交战；单机模式由 AI 补足队伍人数，工程中也包含局域网对战代码。项目计划周期为四周，当前处于第二周。团队按“需求与环境准备—核心玩法实现—比赛流程集成—测试与交付”的顺序推进；表中状态以当前第二周为基准，具体日历日期可按课程安排补填。

2.3 版本路线

• 当前阶段（第 2 周）重点： 跑通射击、伤害、死亡和基础 AI 对战，及时记录问题并稳定需求规则。
• 第 3–4 周重点： 集成比赛流程和主要界面，随后完成回归验证、独立构建、目标设备复测及课程材料整理；真实玩家试玩应留存反馈记录。
• 后续扩展： 完成双机局域网验收后，再评估更大规模联机、账号/战绩服务、更多地图和新模式；未经排期和验收的扩展不作为本阶段承诺。

三、项目具体要求

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

项目关键点与技术难点

1. 需求、原型和实现保持一致。 比赛规则、队伍人数、武器选择和页面状态会同时出现在说明书、原型和代码中。任何规则变更都应同步更新三处材料及验收用例。
2. AI 的可感知信息和难度公平。 AI 应通过视线、遮挡和声音等规则发现对手，不能直接读取不可见玩家位置；反应时间、射击间隔和命中率需要通过试玩调整。
3. 比赛状态和界面信息一致。 回合计时、比分、存活状态、击杀播报和结算都应由统一比赛状态驱动，避免界面显示与实际胜负判定不一致。
4. Unity 模块集成与场景资源协作。 玩家、武器、AI、地图、比赛流程和 UI 同时依赖场景对象、预制体与公共接口；未经沟通修改公共接口或场景资源容易造成合并后无法运行。
5. 局域网联机的端到端验证。 房间发现、连接、主机权威、同步、断线和防火墙行为受设备与网络环境影响，仅在编辑器本机运行不能证明双机可用。

风险清单与应对

3.2 组员分工与工作量比例

本次分工按作业要求的七类成果安排：博客随笔、界面原型、原型答辩 PPT、需求规格说明书、需求分析报告 PPT、界面原型设计评审表和需求分析评审表。每项成果指定一名主负责人，其他成员参与内容互审、试讲或验收。下表贡献度为本次作业的预计工作量比例，合计 100%；提交前应依据实际完成情况和工作记录确认。

所有成员共同参与两份评审表的评审、说明书和 PPT 的交叉校对、课堂汇报演练及最终验收。

3.3 成员协作方式

沟通工具

• 微信群： 日常进度同步、接口变更提醒、阻塞问题快速讨论；结论较复杂时转为会议或文档记录。
• 腾讯会议： 每周至少一次阶段同步，检查里程碑、演示当前成果、确定负责人和截止时间。

版本仓库协作

• 远程仓库：**[仓库地址]**。
• main 保持可演示版本；日常任务从开发分支或最新主线切出 feature/* 分支，修复使用 fix/* 分支。
• 提交前先同步远程主线，完成本地运行或对应模块检查；通过 Pull Request/合并请求说明改动、影响范围和验证结果，经相关模块成员审查后合并。
• Commit 信息使用 feat:、fix:、docs:、test:、refactor: 等前缀，方便追踪功能、缺陷和文档变化。
• 场景、预制体和公共配置文件容易产生冲突，应提前指定主要维护人；多人修改前先约定修改范围，避免在 Unity 中同时覆盖同一资源。

冲突处理与任务同步

• 接口冲突： 先由相关模块负责人说明变更原因、调用方和兼容方案；确认后更新接口约定与受影响需求。
• 代码冲突： 在功能分支中合并主线，逐项检查冲突资源和代码，再运行受影响场景；无法确定时由双方负责人共同评审，不直接覆盖他人提交。
• 计划冲突： 将依赖关系和阻塞项记录到任务表，由项目协调人排定先后顺序；超出原里程碑的功能先评估是否延期或移入后续版本。
• 同步频率： 每周例会更新一次全部任务；里程碑前每日更新未完成项；每次决策记录结论、负责人和复查时间。

AI 辅助开发约定

使用 AI 工具生成的代码或文档须由负责成员检查需求依据、接口、异常处理和许可证/来源，再进行运行验证和代码审查；未经人工确认的内容不直接合并。成员应能说明自己负责模块的输入、输出、关键类和与其他模块的依赖。

四、界面原型

4.1 原型展示

01 · 主菜单

02 · 选择模式

03 · 部署前简报

04 · AI 编组示例

05 · 作战设置

06 · 部署确认

07 · 模拟对局准备

08 · 退出确认

09 战前选装 · 武器配置

10 对局中 · 基础 HUD 与击杀提示

11 回合结算 · 红队胜利

12 回合结算 · 蓝队胜利

13 完整对局结束 · 最终结算

4.2 原型链接

原型源文件链接： [figma原型文件链接]

原型覆盖主菜单、模式选择、设置、退出确认、部署前配置、队伍编组、部署确认、战前选装、对局 HUD、回合结算和整局结算等页面。文档中对静态原型、Unity 已实现界面和待验证的战斗画板作了区分。静态画面用于说明信息布局；按钮跳转和数据联动仍需通过交互原型或运行版本验收。

五、功能描述及验收验证标准

5.1 具体功能描述

本阶段围绕“进入比赛—完成准备—参与战斗—查看结果”组织功能展示：

1. 启动与菜单： 用户启动游戏后进入主菜单，可选择开始、设置或退出等入口。
2. 战前准备： 用户选择比赛模式并完成队伍、部署或武器配置；具体页面以当前原型和 Demo 实现为准。
3. 对局战斗： 玩家可进行第一人称移动、视角控制、射击、换弹和武器切换；AI 角色参与对战并遵循队伍识别、感知和攻击逻辑。
4. 比赛流程： 系统显示回合时间、比分和玩家状态，并在回合或整局结束后展示结算结果。

5.2 本次作业目录与交付链接

作业目录与评分要点核对

5.3 验收验证标准

1. 需求与文档： 需求规格说明书、原型、Demo 和答辩材料中的核心规则保持一致；目录、图片、链接和术语可正常阅读。
2. 界面： 从主菜单进入主要页面，页面状态和按钮反馈清楚；在目标分辨率下文字可读、控件不遮挡或溢出，结算信息与比赛结果一致。
3. 单机功能： 在目标设备上启动最终构建，完成开始比赛、战前准备、移动与射击、回合结束、整局结算及重新开始的完整流程；关键异常有明确反馈。
4. AI 行为： AI 能识别敌我并参与战斗；遮挡时不应依据不可见位置直接攻击；导航、死亡和回合重置行为可重复验证。
5. 用户试玩： 邀请目标玩家完成主要任务，记录操作困难、规则理解和改进项；如尚未开展，应标记为待完成，不写作已验证。