需求规格说明书

修订历史记录

日期	版本	说明	作者
2018.11.23	V0.1	第一个版本，根据项目形成基本构架	RSP小组
2018.11.27	V0.2	第二个版本，将基本项目所要实现页面加入，并解释	RSP小组

0. 目录

• 需求规格说明书
• 修订历史记录
  • 0. 目录
  • 1. 引言
    • 1.1 目的
    • 1.2 背景
    • 1.3 定义
    • 1.4 参考文献
  • 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.1.1 界面设计
        • 开始界面
        • 关卡选择界面
        • 游戏界面
        • 通关界面
        • 关于界面
        • 退出界面
    • 3.2 外部接口需求
      • 3.2.1 用户接口
      • 3.2.2 硬件接口
      • 3.2.3 软件接口
      • 3.2.4 通信接口
    • 3.3 性能需求
      • 3.3.1 精度需求
    • 3.4 属性
      • 3.4.1 可用性
      • 3.4.2 可维护性
  • 4. 验证验收标准及相关要求
    • 4.1 验收标准
      • 4.1.1 文档验收标准
      • 4.1.2 软件验收标准
      • 4.1.3 界面验收标准
      • 4.1.4 功能验收标准
      • 4.1.5 游戏验收标准
    • 4.2 灵活性
    • 4.3 时间特性需求
    • 4.4 其它要求

1. 引言

1.1 目的

• 该文档首先给出项目的整体结构和功能结构概貌，试图从总体架构上给出整个系统的轮廓。同时对功能需求、性能需求进行了详细的描述。便于用户、开发人员进行理解和交流，反映出用户问题的结构，可以作为软件开发工作的基础和依据以及确认测试和验收的依据。

• 本文档面向多种读者对象：

  （1）老师：老师可以根据该文档了解预期产品的功能，并据此进行系统设计、项目管理。

  （2）设计员：对需求进行分析，并设计出系统，包括数据库的设计。

  （3）程序员：了解系统功能，编写《用户手册》。

  （4）测试员：根据本文档编写测试用例，并对软件产品进行功能性测试和非功能性测试。

  （5）用户：了解预期产品的功能和性能，并与分析人员一起对整个需求进行讨论和协商。

• 在阅读本文档时，首先要了解产品的功能概貌，然后可以根据自身的需要对每一功能进行适当的了解。

1.2 背景

• 对于这学期的最后的总结，我们需要一个项目来验证我们在本学期的学习情况。通过对这个游戏的开发，我们将会巩固所学的内容，虽然这款游戏在Android端有很多版本，但我相信我们会做出一个更好的产品。

• 项目开发单位：北京电子科技学院2017级23班RSP小组

• 本次待开发的软件为休闲游戏类软件。

1.3 定义

序号	缩写	定义
1	app	应用程序，Application的缩写，一般指手机软件
2	Android	Android是一种基于Linux的自由及开放源代码的操作系统，主要是使用移动设备，如智能手机和平板电脑，由Google公司和开放手机联盟领导及开发。

1.4 参考文献

• 《报课系统软件需求规格说明书》

• 《报课系统需求规格说明书》

• 《一起买APP需求规格说明书》

2. 项目概述

2.1 产品描述

• 通过开发基于Android平台的游戏app，巩固所学内容和开发项目的能力，旨在锻炼，提供一个在学习后疲倦缓解压力的小游戏。
  

2.2 产品功能

• 功能介绍图（WBS）：
  

序号	基础功能	功能介绍
1	背景音乐	在玩游戏过程中有音乐伴随，与大多数游戏的BGM相类似
2	音量设定	控制游戏BGM的音量
3	菜单界面	选择开始游戏（选择难度-待后续开发），并有关于，音量，退出游戏
4	游戏界面	设有战斗界面（血条）和消消乐矩阵，暂停，设置，退出

2.3 用户特点

本软件的用户限4岁以上群体使用，无其他特殊要求，各类人群都可以成为该app的用户，特别适合学生党和上班族打发空余时间。

2.3.1 用户示例场景

• 用户场景A：小明是一名大中生，由于敲了一整天的Java，好不容易回到寝室，为了放松和朋友用各自的手机玩游戏，想要比比谁过的关多。

• 用户场景B：小王是一个公司职员，上午上了半天班有点累，中午休息的时候不知道干什么，于是拿出了手机玩了几分钟小游戏来放松一下。

2.3.2 用户需求分析

• 场景A：小游戏有趣，游戏可以通过打BOSS
  来过关
• 场景B：小游戏操作简单，不需要费神去学习和使用，能用于闲暇时的放松和打发时间。

2.3.3 用例图

2.3.4 用例说明

项目	内容
用例名称	关卡选择
用例编号	001
主要参与者	用户A
风险承担者	游戏设计者
简要说明	在正式进入游戏界面前有一个关卡选择，关卡选择可以决定游戏难度
前置条件	用户A已下载游戏
基本事件流	1.用户A进入“关卡界面”。2.游戏系统显示出已解锁的关卡和文字索引栏。
后置条件	点击关卡，可直接进入游戏界面
其他	无

2.4 假定和约束

2.4.1 假定

1.可操作性：假定本游戏用户在试玩后能很快上手游戏。

2.用户支持：假定在本游戏开发的各个环节中得到用户的有效支持和配合。

3.技术支持：假定开发初期，小组成员成分认识游戏的需求，认真学习相关知识。假定在开发过程中遇到问题，可以及时得到老师的指导与帮助。

4.人员配合：假定小组成员不会出现变动，并且在项目开发过程中不会有突发情况的发生而导致项目成员无法正常参与开发工作。

5.时间限定：假定项目的截止时间不会提前。

6.需求限定：假定项目需求基本确定之后，不会有太大改变。

2.4.2 约束

• 人员约束：
  团队成员均为大二学生，共4人。

• 管理约束：
  1.本次开发，实行以一人担任小组组长，各组员分工合作的模式进行。每个人负责切实具体的流程板块，并且按照进度表进行，开发过程中遇到的问题通过小组会议得到一致的解决。
  2.小组成员首次合作，需要明确责任，互相配合，迅速度过磨合期。在遇到问题时需要小组组长能进行有效的协调，才能快速，有效地完成开发过程。

• 技术约束：
  1、小组成员在相关技术水平方面存在一定欠缺，缺乏相关项目经验，在文档编制能力方面也有待提升。
  2、小组成员在美工方面，能力有限。

• 时间约束：
  本系统开发周期较短，时间相对紧张。

• 其他约束：
  由于在开发期间，小组成员还有其他科目的学习任务，将对项目进度造成一定的影响。

3. 具体需求

• 需求功能优先级象限图：
  

• 对应版本需求
  • Alpha版本
    • 1.开始，退出，暂停按钮...
    • 2.游戏界面各种元素：消消界面，怪物界面
  • β版
    • 1.音乐功能...
  • 发布版本
    • 1.添加用户反馈渠道，实现与用户交流的功能

3.1 功能需求

3.1.1 界面设计

开始界面

• 用户选择开始游戏，结束游戏或者查看游戏说明：

关卡选择界面

• 在用户点击关卡选择之后，会有多个关卡来让用户选择。

• 用户在选择关卡之后会直接进入游戏界面

游戏界面

• 在游戏界面中，。

• 用户点击右上角的暂停键或点击手机的返回键的时候会出现选项让用户选择继续游戏亦或是退出当前游戏返回主界面。

图片

通关界面

• 顺利通关：

• 挑战失败：

• 显示完直接跳回主界面，设个延迟两秒

关于界面

• 产品归属，开发人员等。。。

退出界面

• 退出游戏的提醒

3.2 外部接口需求

3.2.1 用户接口

无特殊需求。

3.2.2 硬件接口

无特殊需求。

3.2.3 软件接口

无特殊需求。

3.2.4 通信接口

无特殊需求。

3.3 性能需求

3.3.1 精度需求

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 界面验收标准

序号	界面名称	界面描述	备注
1	开始界面	页面上半部分标题栏显示游戏名称""，中间部分从上至下依次有按钮"闯关模式"和按钮"结束游戏"。
2	选车界面	页面分为左上，右上，左下，右下四个板块，每个板块是用户需要选择的车辆按钮
3	游戏边框界面（两边）	页面左边框是动画效果处于移动中的路旁的画面，左边框上部有提示栏"关卡：XXX"与"分数：XXX",页面右边框同是动画效果处于移动中的路旁的画面，右边框上部有按钮暂停框" ‖"
4	游戏主界面（中部）	中部界面有方形的人工移动光标"车"，界面上方有系统随机产生自上而下规律移动的光标"汽车"和"障碍"，主界面背景为动画效果样式处于移动中的道路（分4条主道）。	"汽车"和"障碍"属于不同类型，详见功能说明部分
5	暂停界面	该界面大小约为主界面的三分之一，上部有状态提示语"暂停"，下部左右依次有按钮键"继续"和"退出"
6	音乐界面	该界面含有多首音乐的按钮，点击后进入游戏主界面
7	返回界面	该界面与暂停界面相同位置及大小，上部有提示语"是否返回"，下部分左右依次有按钮键"是"与"否"。	由暂停界面"退出"键进入返回界面
8	结束界面	界面为弹出框，框上部有提示语"游戏结束"和"你的最终分数是：XXXX分"，框下部有按钮键"确认"
9	通关界面	界面为弹出框，有结语"恭喜你！你已通关！"和"你的最终分数是：XXXX分"，框下部是按钮键"确认"。

4.1.4 功能验收标准

序号	功能名称	操作界面	详细操作	备注
1	进入游戏	开始界面	点击"闯关模式"转入游戏界面
2	结束游戏	开始界面	点击"结束游戏"退出游戏回到手机上一级主界面
3	游戏	开始界面、选车界面、游戏界面	通过点击"闯关模式"进入选车界面，点击想要使用的车辆进入游戏界面，手机通过屏幕感应移动光标躲避从上到下迎来的障碍物和车辆，避免碰撞
4	计分	游戏边框界面、结束界面、通过界面	每躲避一个障碍物加10分，躲避或消灭一个车辆加20分，达到一定的分数标准则进入下一关，左边框上部实时记录游戏关卡以及得分，若碰撞障碍物则即时停止计分。在游戏左边框界面上部、通关界面和结束界面会显示游戏得分	若碰撞障碍物则即时停止计分，转入结束界面
5	选歌	游戏界面、音乐界面	进入选车界面后进入音乐界面，点击界面内任何一首歌曲则背景音乐切换到该歌曲，用户点手机的返回键回到上一界面	初始背景音乐默认为第一首歌曲的单曲循环
6	暂停	暂停界面、游戏边框界面、开始界面、返回界面	点击游戏右边框界面上部"‖"按钮进入暂停界面弹出框，点击"继续"返回游戏界面继续游戏，点击"退出"则弹出返回界面框
7	返回	暂停界面、返回界面、开始界面	在暂停界面点击"退出"按钮进入返回界面，点击"是"则回到开始界面，点击"否"则返回暂停界面
8	通关	游戏界面、通关界面	在游戏界面通过所有关卡后进入通关界面，点击"确认"返回开始界面
9	结束	游戏界面、结束界面、开始界面	在游戏中碰撞到障碍物及车辆会进入结束界面，点击"确认"则返回开始界面

4.1.5 游戏验收标准

序号	功能名称	操作界面	详细操作	备注
1	光标移动	游戏界面	用户通过按住屏幕"车"通过滑动改变其位置
2	环境	游戏界面、游戏边框界面	进入游戏后游戏界面背景"公路"实现移动状态，游戏边框界面的路旁景象实现移动状态，二者要求同步移动速率
3	车辆障碍	游戏界面	实现"车辆"和"障碍"两种不同类型的"敌人"，使二者随机出现，以不同速率从游戏界面上部进入，垂直向下移动，直至移出界面
4	射击	游戏界面	用户操纵的车辆可以发射垂直向上"导弹"，击中车辆会使消失并产生爆炸效果
5	音乐	后台	音乐界面选默认第一首歌，单曲循环

4.2 灵活性

本软件最终完成后，短期内需求不会发生太大变化。相应地，即当需求发生某些变化时，该软件具备对这些变化的适应能力：操作方式上的变化。本系统的操作方式相对简单，用户可以很容易掌握。 在系统前期的需求分析和交互设计方面已经做了充分的考虑和设计，一般不会发生太大的变化。不过我们可以根据用户需求的变化，做一些更改和扩充，具有比较好的扩展性。

4.3 时间特性需求

此APP对时间特性的要求不高，只需在合理时间内响应用户的请求即可。例如点击按钮反应时间不得超过1s等。

4.4 其它要求

安全要求：

不会向用户索要个人信息，尽量提示APP本身的安全性

可靠性：

系统具有较强的稳定性，不存在太多的不稳定因素。

使用方便要求：

（1）该系统的所有界面要简洁且易用。

（2）操作完成时有统一规范的提示信息。

可维护性：

（1）保留系统的源代码

（2）代码注释详细，包括方法实现过程以及变量的含义。

（3）清晰的系统结构和命名规范，界面规范。

（4）每次调试都会记入日志。

（5）全面考虑系统，加强后期的维护，不断从各方面操作进行测试。

性能需求：

（1）用户控制的车辆不能移到道路外。

（2）障碍物或障碍车辆碰撞用户车辆的判断要精确。

（3）子弹与障碍车辆接触判断要精确。

（4）障碍物和障碍车辆要出现在道路内。

（5）子弹的发射位置要在用户车的中见

（6）子弹发射的频率和速度要合理。