# 五小福团队---UNO项目团队作业
**Repository Path**: zeroslove/AppProject
## Basic Information
- **Project Name**: 五小福团队---UNO项目团队作业
- **Description**: 基于安卓开发的有趣味性的UNO纸牌小游戏
- **Primary Language**: Java
- **License**: AGPL-3.0
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No
## Statistics
- **Stars**: 0
- **Forks**: 1
- **Created**: 2024-07-27
- **Last Updated**: 2024-07-27
## Categories & Tags
**Categories**: Uncategorized
**Tags**: None
## README
## 目录
[1.引言](#1)
- [1.1 编写目的](#11)
- [1.2 项目背景](#12)
- [1.3 参考资料](#13)
[2.项目概述](#2)
- [2.1 产品描述](#21)
- [2.2 产品功能](#22)
- [2.3 用户特点](#23)
- [2.3.1 用户示例场景](#231)
- [2.3.2 用户需求分析](#232)
- [2.3.3 用例图](#233)
- [2.3.4 用例说明](#234)
- [2.4 假定和约束](#24)
- [2.4.1 假定](#241)
- [2.4.2 约束](#242)
[3.具体需求](#3)
- [3.1 功能需求](#31)
- [3.2 外部接口需求](#32)
- [3.3 性能需求](#33)
- [3.4 属性](#34)
- [3.4.1 可用性](#341)
- [3.4.2 可维护性](#342)
[4.验证验收标准及相关需求](#4)
- [4.1 验收标准](#41)
- [4.2 灵活性](#42)
- [4.3 时间特性要求](#43)
- [4.4 其他要求](#44)
## 1. 引言
### 1.1 编写目的
- 经过一个学期的java学习与Android Studio的自学过程，我们迫切地需要清楚地了解自身知识的掌握程度与运用能力，于是我们在老师的引导下开始了此次做游戏的实践任务。
- 本游戏定义为休闲游戏，基于Android平台。编写本功能需求说明书的目的是为了详尽呈现出该游戏
的用户需求、设计理念与游戏特性分析；明确包含游戏性质、软件运行界面、功能需求、代码编写特点的
描述，便于用户、开发人员的协调工作，并在此基础上进一步提出概要设计说明书，建立可确认、可验证
的一个基本依据，以完成后续的设计与开发工作。
- 本文档面向的预期读者范围与阅读建议：
- 项目经理：项目经理根据该文档了解预期产品的功能，并据此进行系统设计、项目管理。
- 程序员：了解需求的程序特点与系统功能。
- 测试员：根据本文档作出测试用例，对软件进行功能性测试与非功能测试。
- 用户：清晰了解软件使用方式
### 1.2 项目背景
- 项目开发单位：北京电子科技学院-2017级23班- 五小福团队
- 本次待开发的软件为休闲游戏类软件。本游戏软件将被投放至应用市场供群众下载，用户使用该软件进
行娱乐，放松身心，锻炼思维能力与反应能力。
### 1.3 参考资料
- 《报课系统软件需求规格说明书》
- 《报课系统需求规格说明书》
- 《一起买APP需求规格说明书》
## 2. 项目概述
### 2.1 产品描述
- 该游戏是基于Android平台开发的app。UNO（优诺）是一个好玩且益智的纸牌游戏，该游戏可用于提高反应程度、增加思维敏锐度。
### 2.2 产品功能
- 功能介绍图
- 该产品为平面2D纸牌游戏，游戏目标是尽快出完手中的牌。
### 2.3 用户特点
本产品可使用于一切能独立使用Android手机的用户。适用于想要锻炼思维能力，喜欢纸牌类游戏的用户。
#### 2.3.1 用户示例场景
- 用户场景A：小荷是一名高中生，周末放假回家闲来无事，想玩游戏，于是拿起手机开始玩UNO。
- 用户场景B：小王是一个公司职员，上午上了半天班有点累，中午休息的时候不知道干什么，于是拿出了手机玩UNO小游戏来放松一下。
#### 2.3.2 用户需求分析
- 场景A：UNO游戏比较新潮，可以玩一玩教给大家。
- 场景B：UNO游戏很有趣味性，而且也不会占用时间，还可以益智。
#### 2.3.3 用例图
#### 2.3.4 用例说明
用户在点击该APP时，首先会出现一个登录的界面，若已有账号就可直接登录，否则进行注册。登陆成功后将会出现欢迎的动画。动画结束后可以选择开始游戏和退出游戏界面，开始游戏后可选择规模或者继续上次游戏，然后按规则正常进行游戏；用户在游戏过程中则操控右上角菜单栏，菜单栏包含四个选项（退出、重来、存档和音乐），点击退出就直接可以回到主界面，点击重来就重新开始，点击存档就可以保存此次游戏进度，点击音乐可以操控音乐的有无。
### 2.4 假定和约束
#### 2.4.1 假定
- 1.可操作性：假定本游戏用户在试玩后能很快灵活操作游戏。
- 2.用户支持：假定在本游戏开发的各个环节中得到用户的有效支持和配合。
- 3.技术支持：假定开发初期，小组成员成分认识游戏的需求，认真学习相关知识。假定在开发过程中遇到问题，可以及时得到老师的指导与帮助。
- 4.人员配合：假定小组成员不会出现变动，并且在项目开发过程中不会有突发情况的发生而导致项目成员无法正常参与开发工作。
- 5.时间限定：假定项目的截止时间不会提前。
- 6.需求限定：假定项目需求基本确定之后，不会有太大改变。
#### 2.4.2 约束
- 人员约束： 团队成员均为大二学生，共5人。
- 管理约束：1.本次开发，实行以一人担任小组组长，各组员分工合作的模式进行。每个人负责切实具体的流程板块，并且按照进度表进行，开发过程中遇到的问题通过小组会议得到一致的解决。 2.小组成员首次
合作，需要明确责任，互相配合，迅速度过磨合期。在遇到问题时需要小组组长能进行有效的协调，才能
快速，有效地完成开发过程。
- 技术约束：1、小组成员在相关技术水平方面存在一定欠缺，缺乏相关项目经验，在文档编制能力方面也有待提升。 2、小组成员在美工方面，能力有限。
- 时间约束： 本系统开发周期较短，时间相对紧张。
其他约束： 由于在开发期间，小组成员还有其他科目的学习任务，将对项目进度造成一定的影响。
## 3.具体需求
### 3.1 功能需求
#### 3.1.1 界面设计
- 我们小组使用Xmind实现如下：
- 登录界面
首先跳出一段我们制作的欢迎动画，让玩家感受到满满的游戏画面感。
然后进入登录界面
登录界面包括两个内容，注册与登录。
若已经注册则直接点击登录进入游戏，若尚未注册则点击注册进入注册页面，待注册完毕后登录进入游戏。
- 准备界面
准备界面包括开始游戏、退出游戏、游戏介绍。
点击开始游戏即可进入下一个界面，下一个界面包括继续上次游戏和选择游戏场规模两个选项；若选择继续上次游戏就直接进入游戏界面继续游戏，若单击选择游戏场规模就进入对游戏场的选择。一共有四个游戏场规模的选择，分别是三人场、四人场、五人场和无限场（不对牌的数量做限制）。再通过选择后进入游戏场。
- 游戏界面
游戏界面包括以下内容：
（1）牌类
该内容显示你现在所拥有的所有手牌，以及不同分类，还有其他玩家的手牌个数，牌堆剩余个数。
（2）功能按钮类
- 一键整理按钮：可以整理你的手牌
- 选色按钮：为下一家指定颜色。
- 出牌按钮：选定你选择的牌并点击出牌，若是满足游戏规则就正常出牌，若是不满足就报错给玩家。
- 菜单栏
- 存档：保存当前游戏，下次可在准备界面中选择继续游戏。
- 音乐选择：可以选择打开或者关闭
- 重来：重新开局
- 退出：直接退回开始的主界面。
### 3.2 外部接口需求
#### 3.2.1 用户接口
无特殊需求。
#### 3.2.2 硬件接口
无特殊需求。
#### 3.2.3 软件接口
无特殊需求。
#### 3.2.4 通信接口
无特殊需求。
### 3.3 性能需求
### 3.4 属性
#### 3.4.1 可用性
- 1.易操作，易理解。界面设计简洁易用。
- 2.操作完成时有统一规范的提示信息。
#### 3.4.2 可维护性
- 1.保留系统的源代码
- 2.代码注释详细，包括方法实现过程以及变量的含义。
- 3.清晰的系统结构和命名规范，界面规范。
- 4.每次调试都会记入日志。
- 5.不断从各方面操作进行测试。
## 4. 验证验收标准及相关要求
### 4.1 验收标准
#### 4.1.1 文档验收标准
- （1）app项目开发计划
- （2）软件需求说明书
- （3）团队项目及时记录和总结报告（团队博客）
#### 4.1.2 软件验收标准
- APP安装包
#### 4.1.3 界面验收标准
#### 4.1.4 功能验收标准
#### 4.1.5 游戏验收标准
### 4.2 灵活性
本软件最终完成后，短期内需求不会发生太大变化。相应地，即当需求发生某些变化时，该软件具备对这些变化的适应能力：本系统的操作方式相对简单，用户可以很容易掌握。 在系统前期的需求分
析和交互设计方面已经做了充分的考虑和设计，一般不会发生太大的变化。不过我们可以根据用户需求的变化，做一些更改和扩充，具有比较好的扩展性。
### 4.3 时间特性需求
此APP对时间特性的要求不高，没有什么要求。
### 4.4 其它要求
- 安全要求：
不向用户索要个人信息，尽量提示用户该APP的安全性。
- 可靠性：
系统具有较强的稳定性，不存在太多的不稳定因素。
- 使用方便要求：
（1）该系统的所有界面要简洁且易懂。
（2）操作完成时有统一规范的提示信息。
- 可维护性
（1）保留系统的源代码。
（2）代码注释详细，包括方法实现过程以及变量的含义。
（3）清晰的系统结构和命名规范，界面规范。
（4）每次调试都会记入日志。
（5）全面考虑系统，加强后期的维护，不断从各方面操作进行测试。
- 性能需求：