需求規格說明書

需求規格說明書

修訂歷史記錄

日期	版本	說明	做者
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.小組成員首次合做，須要明確責任，互相配合，迅速度過磨合期。在遇到問題時須要小組組長能進行有效的協調，才能快速，有效地完成開發過程。

• 技術約束：
  一、小組成員在相關技術水平方面存在必定欠缺，缺少相關項目經驗，在文檔編制能力方面也有待提高。
  二、小組成員在美工方面，能力有限。

• 時間約束：
  本系統開發週期較短，時間相對緊張。

• 其餘約束：
  因爲在開發期間，小組成員還有其餘科目的學習任務，將對項目進度形成必定的影響。

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）子彈發射的頻率和速度要合理。