# 20172306
**Repository Path**: CS-IMIS-23/20172306
## Basic Information
- **Project Name**: 20172306
- **Description**: java设计
- **Primary Language**: Java
- **License**: GPL-2.0
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No
## Statistics
- **Stars**: 0
- **Forks**: 0
- **Created**: 2018-03-08
- **Last Updated**: 2020-12-19
## Categories & Tags
**Categories**: Uncategorized
**Tags**: None
## README
## 目录
1.引言
- 1.1 编写目的
- 1.2 项目背景
- 1.3 参考资料
2.项目概述
- 2.1 产品描述
- 2.2 产品功能
- 2.3 用户特点
- 2.3.1 用户示例场景
- 2.3.2 用户需求分析
- 2.3.3 用例图
- 2.3.4 用例说明
- 2.4 假定和约束
- 2.4.1 假定
- 2.4.2 约束
3.具体需求
- 3.1 功能需求
- 3.2 外部接口需求
- 3.3 性能需求
- 3.4 属性
- 3.4.1 可用性
- 3.4.2 可维护性
4.验证验收标准及相关需求
- 4.1 验收标准
- 4.2 灵活性
- 4.3 时间特性要求
- 4.4 其他要求
## 1. 引言
### 1.1 编写目的
- 经过一个学期的java学习与Android Studio的自学过程，我们迫切地需要清楚地了解自身知识的掌握程度与运用能力，于是我们在老师的引导下开始了此次做游戏的实践任务。
- 本游戏定义为休闲游戏，基于Android平台。编写本功能需求说明书的目的是为了详尽呈现出该游戏
的用户需求、设计理念与游戏特性分析；明确包含游戏性质、软件运行界面、功能需求、代码编写特点的
描述，便于用户、开发人员的协调工作，并在此基础上进一步提出概要设计说明书，建立可确认、可验证
的一个基本依据，以完成后续的设计与开发工作。
- 本文档面向的预期读者范围与阅读建议：
- 项目经理：项目经理根据该文档了解预期产品的功能，并据此进行系统设计、项目管理。
- 程序员：了解需求的程序特点与系统功能。
- 测试员：根据本文档作出测试用例，对软件进行功能性测试与非功能测试。
- 用户：清晰了解软件使用方式
### 1.2 项目背景
- 项目开发单位：北京电子科技学院-2017级23班- IG团队
- 本次待开发的软件为游戏选择平台类软件。本游戏软件将被投放至应用市场供群众下载，用户使用该软件进行游戏选择，娱乐休闲，放松心情。
### 1.3 参考资料
- 《报课系统软件需求规格说明书》
- 《报课系统需求规格说明书》
- 《一起买APP需求规格说明书》
## 2. 项目概述
### 2.1 产品描述
- 该软件是基于Android平台开发的app。旨在充分满足用户游戏喜好的选择游戏平台，一款app即可玩多款游戏。
### 2.2 产品功能
- 通过新用户的一些选择来判断新用户喜好，进行游戏推荐，并提供多种类型的游戏供用户选择娱乐。
### 2.3 用户特点
本产品可使用于一切能独立使用Android手机的用户。适用于选择困难症的游戏用户。
#### 2.3.1 用户示例场景
- 用户场景A：小荷是一名公司职员，她在地铁上准备去上班，闲来无聊，于是拿出手机登录该款app选择自己喜欢的游戏在上班途中休闲娱乐。
- 用户场景B：小王是一名高中生，他闲来无聊，不知道玩什么，那么他可以利用该款app看一下游戏推荐，进行娱乐。
#### 2.3.2 用户需求分析
- 场景A：该款app中有多种游戏，可以让用户选择多样，提高各种能力。
- 场景B：闲来无事的时候，手机里有一款含有多个游戏的app，一带多，好玩又方便。
#### 2.3.3 用例图
#### 2.3.4 用例说明
### 2.4 假定和约束
#### 2.4.1 假定
- 1.可操作性：假定该app用户在使用后可以很好的应用。
- 2.用户支持：假定在本app开发的各个环节中得到用户的有效支持和配合。
- 3.技术支持：假定开发初期，小组成员成分认识app的需求，认真学习相关知识。假定在开发过程中遇到问题，可以及时得到老师的指导与帮助。
- 4.人员配合：假定小组成员不会出现变动，并且在项目开发过程中不会有突发情况的发生而导致项目成员无法正常参与开发工作。
- 5.时间限定：假定项目的截止时间不会提前。
- 6.需求限定：假定项目需求基本确定之后，不会有太大改变。
#### 2.4.2 约束
- 人员约束： 团队成员均为大二学生，共5人。
- 管理约束：1.本次开发，实行以一人担任小组组长，各组员分工合作的模式进行。每个人负责切实具体的流程板块，并且按照进度表进行，开发过程中遇到的问题通过小组会议得到一致的解决。 2.小组成员首次
合作，需要明确责任，互相配合，迅速度过磨合期。在遇到问题时需要小组组长能进行有效的协调，才能
快速，有效地完成开发过程。
- 技术约束：1、小组成员在相关技术水平方面存在一定欠缺，缺乏相关项目经验，在文档编制能力方面也有待提升。 2、小组成员在美工方面，能力有限。
- 时间约束： 本系统开发周期较短，时间相对紧张。
其他约束： 由于在开发期间，小组成员还有其他科目的学习任务，将对项目进度造成一定的影响。
## 具体需求
### 3.1 功能需求
#### 3.1.1 界面设计
### 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.不断从各方面操作进行测试。
## 4. 验证验收标准及相关要求
### 4.1 验收标准
#### 4.1.1 文档验收标准
- （1）app项目开发计划
- （2）软件需求说明书
- （3）团队项目及时记录和总结报告（团队博客）
#### 4.1.2 软件验收标准
- APP安装包
#### 4.1.3 界面验收标准
- 满足app的点击要求和界面之间的连接要流畅
#### 4.1.4 功能验收标准
- 满足可以登录和注册
- 满足可以通过用户的选择进行游戏的推荐
- 满足可以通过点击各类型的游戏，进行游戏的娱乐
### 4.2 灵活性
本软件最终完成后，短期内需求不会发生太大变化。相应地，即当需求发生某些变化时，该软件具备对这些变化的适应能力：本系统的操作方式相对简单，用户可以很容易掌握。 在系统前期的需求分
析和交互设计方面已经做了充分的考虑和设计，一般不会发生太大的变化。不过我们可以根据用户需求的变化，做一些更改和扩充，具有比较好的扩展性。
### 4.3 时间特性需求
此APP对时间特性的要求不高，没有什么要求。
### 4.4 其它要求
- 安全要求：
不向用户索要个人信息，尽量提示用户该APP的安全性。
- 可靠性：
系统具有较强的稳定性，不存在太多的不稳定因素。
- 使用方便要求：
（1）该系统的所有界面要简洁且易懂。
（2）操作完成时有统一规范的提示信息。
- 可维护性
（1）保留系统的源代码。
（2）代码注释详细，包括方法实现过程以及变量的含义。
（3）清晰的系统结构和命名规范，界面规范。
（4）全面考虑系统，加强后期的维护，不断从各方面操作进行测试。
- 性能需求：