C++輪子隊-軟件需求規格說明書

團隊Github項目倉庫

軟件規格需求說明書

引言

編寫目的

軟件規格需求說明書書了「2048俄羅斯方塊」1.0版本的軟件功能性需求和非功能性需求。

文檔約定

描述編寫文檔時所採用的標準或排版約定，包括正文風格，提示區或重要符號。例如，說明高層需求的優先級是否能夠被全部細化分需求所繼承，或者每一個需求陳述是否都有優先級。

讀者對象和閱讀建議

該軟件需求規格說明書針對開發人員、測試人員等，用於開發初期肯定軟件的系統設計，詳細設計。本文內容包括面向用戶分析、功能性需求、技術需求，闡述了系統的真實性、可用性以及價值所在。

項目範圍

「2048俄羅斯方塊」是在軟件工程第三次大做業由C++輪子隊提出來的一個項目，主要目的是供隊員學習軟件工程的開發過程，並經過這次開發，對C++掌握更加牢固。該遊戲軟件適用於大多數學生和上班族打發零散的空閒時間。

預期用戶數量

咱們預計的用戶數量是1000人以上。

整體描述

產品前景

「2048俄羅斯方塊」1.0版本是由微信小程序「個人方塊2048」的改進版，增長了一些新的功能來吸引更多用戶。

產品的簡述

遊戲規則：合併相同數字方塊，合成2048或更大數字得到勝利，格子填滿或方塊超出上界遊戲失敗

得分規則：合成塊對應分值 - 遊戲時間

具體操做：左右控制方塊移動，下鍵使懸空方塊馬上落下

真實性

2048和俄羅斯方塊都是兩款很火頗有意思的遊戲，相信二者的結合體「2048俄羅斯方塊」將會得到用戶的青睞。

可用性

「2048俄羅斯方塊」的玩法十分簡單，只要曾經玩過2048和俄羅斯方塊，就能很快入手。

價值所在

• 知足人們休閒娛樂的需求
• 兩款經典遊戲的結合，給用戶不同的體驗

運行環境

Linux/X十一、Mac、Windows、Embedded Linux、Windows CE / Mobile、Symbian、Meego、Wayland、Android、IOS、Amazon Kindle DX… QT For Everywhere!

設計和實現上的約束

爲了確保可移植性，本項目使用C++進行編寫，圖形庫、網絡庫使用QT內置的實現。 開發規範：

1. 禁止使用宏
2. 分號之前不加空格
3. 行寬原則上不超過80
4. 一行只定義一個變量
5. 大括號換行
6. return 後面的數值不加 ( )
7. 每一個文件應該含有版權信息及做者
8. 左圓括號以後和右圓括號以前無空格
9. 一目運算符與變量之間不加空格符隔開
10. 函數名與參數同行
11. 換行代碼縮進4個空格，而且使用四個空格符取代製表符
12. 二目以上的運算符與變量，常量之間用空格隔開（各種括號除外）
13. 不論控制語句，循環語句後面的循環體有多少行，都必須使用花括號
14. 普通函數，類型（含類與結構體，枚舉類型），常量等使用大小寫混合，可包含下劃線
15. 除函數定義的左大括號可置於行首之外，包括函數/類/結構體/枚舉聲明，各類語句的左大括號必須置於行末，全部右大括號獨立成行

硬件限制

1. 鍵盤輸入設備
2. 顯示屏
3. 具體硬件配置需求待測試

系統功能

圖形界面

分數統計

障礙塊

難度調整

在線排名

外部接口需求

用戶界面

整體界面：包括方塊，背景板，計分板，開始按鈕，暫停按鈕，結束按鈕。

硬件接口

描述系統中硬件每一個接口的特徵。可能包括支持的硬件類型、軟硬件之間交流的數據和控制信息的性質以及所使用的通訊協議

軟件接口

描述產品與其它外部組件的鏈接，包括數據庫，操做系統，工具庫和集成的商業組件。明確並描述在軟件組件之間交換數據或信息的目的，描述所須要的服務及內部組件通訊的性質，肯定將在組件之間共享的數據。若是必須用一種特殊的方法來實現數據共享機制，那麼就必須把它定義爲一種實現上的限制

通訊接口

描述與產品所使用的通訊功能相關的需求，包括電子郵件、WEB瀏覽器、網絡通訊標準或協議及電子表格等，定義相關的信息格式、規定通訊安全或加密問題、數據傳輸速率和同步通訊機制

非功能性需求

性能需求

點擊開始，暫停，結束按鈕時，馬上（1S內）出現相應的反應。 用戶用鍵盤控制方塊左右移動，按下鍵盤←→鍵，在2ms內方塊移動，讓用戶感受不到延遲。 按↓鍵，方塊應在5ms內到達底部。 還要定義容量需求，例如存儲器和磁盤空間的需求或者存儲在數據庫中表的最大行數。也可能須要針對每一個功能需求或特性分別陳述其性能需求

軟件質量屬性

可用性：程序用戶界面運行時不崩潰，按鈕佈局合理有效、易學容易掌握，在知足配置條件下能全程無明顯卡頓的運行，聯機時比分狀態雙機同步。在整個過程當中儘可能爲用戶帶來絲滑順暢的操做體驗。 健壯性：圖形界面上若佈局排列異常則根據內存數據重置界面

制定團隊計劃

將團隊的任務計劃添加到碼雲(Github)的團隊項目issues裏面(Done)

提供issues截圖(Done)

給出團隊項目的時間安排表(Todo)

本來時間安排(done)

時間	安排
10.14 - 10.20	分析需求，完成規格說明書，學習團體開發須要用到的技術
10.21 - 10.27	改進需求，進行系統設計、制定詳細的開發計劃
10.28 - 11.3	Alpha 衝刺
11.4 - 11.10	用戶測試 + 改進，收尾
11.11 - end	總結

校訂後的安排(Todo)

其餘

排版(Todo)

團隊分工 & 績效算法

團隊分工

• 湖倩：文檔
• yy：圖形界面
• 澤翰：圖形界面
• 秉坤：數字類、圖形界面
• 育招：控制類控制方向
• 綠豬：控制類判斷方向

績效算法

成員的績效 = 團隊得到的分數 + 我的的團隊貢獻分

在項目alpha 和 beta 階段評審後， 團隊會獲得一個項目分數（每一個成員都會獲得一樣的分數，作爲本身的原始分數的一部分）。團隊成員的努力程度不一樣，達成目標的程度不一樣，幫助同伴的付出不一樣，那就要在「團隊貢獻分」 上有所區分。 全部人貢獻分的總和爲 20N，其中N爲團隊的人數。 在alpha/beta 以後，團隊按照本身制定的規則，把 （20N）瓜分給每人，這就是 「團隊貢獻分」。

要求：請每人閱讀教材 「人、績效和職業道德」一章，而後團隊開一個討論會，協商討論團隊貢獻分的分配規則。每人得分爲天然數，而且每一個人分數不能相同。 請寫一個團隊博客詳細說明每一個團隊的成員計劃如何幫助團隊完成任務，以及團隊貢獻分的分配規則。

每一個人的完成狀況(Todo)

 

 

每一個人的感想(Todo)

育招：在這一週，咱們團隊完成了需求規格說明書，並制定了團隊計劃。假如一我的開發一個項目的話，大部分狀況下只能本身拿定主意，可是團隊開發就不同了，能夠進行頭腦風暴，進行思惟的碰撞，從而產生更好的想法，開發出更好的產品。另外，因爲我比較菜，因此在這一週裏，我去學習了一下團隊git的協做方式，弄懂了issue和branch的基礎操做，爲接下來的團隊開發作好準備。

澤翰：這周主要仍是參加討論與前期知識的學習與儲備，圖形界面設計方面以前僅僅是接觸了MFC框架與C#相關的皮毛。藉着這次團隊項目的學習實踐，以前也很想了解的Qt編程也有機會學習與實戰了。這周裏也是看了不少Qt的編程教程與相關書籍，因爲是第一次接觸，目前尚且在進行一些實例的練手。總的而言，這次的團隊項目不管是從我的編程經驗的積累仍是團隊的合做成長，都是十分使人期待的。

秉坤：由於個人任務是兼項的,負責界面的同時也負責數字類模塊,念及接下來的開發都是基於這個類進行開發,而且這個模塊的內容並不難, 因此這一週我提早了一點點將這個模塊基本上完成,相信可以跟其餘人有更好的對接.

綠豬：瞭解並實踐了軟件工程中項目需求分析與團隊分工相關的知識，深深感到用戶需求對軟件的重要性。成功的軟件產品是創建在成功的需求基礎之上的，而高質量的需求來源於用戶與開發人員之間有效的溝通與合做。當用戶有一個問題能夠用計算機系統來解決，而開發人員開始幫助用戶解決這個問題，溝通就開始了。

需求獲取多是最困難、最關鍵、最易出錯及最須要溝通交流的活動。對需求的獲取每每有錯誤的認識：用戶知道需求是什麼，咱們所要作的就是和他們交談從他們那裏獲得需求，只要問用戶系統的目標特徵，什麼是要完成的，什麼樣的系統能適合商業須要就能夠了，可是實際上需求獲取並非想象的這樣簡單，這條溝通之路佈滿了荊棘。首先需求獲取要定義問題範圍，系統的邊界每每是很難明確的，用戶不瞭解技術實現的細節，這樣形成了系統目標的混淆。

其次是對問題的理解，用戶對計算機系統的能力和限制缺少了解，任何一個系統都會有不少的用戶或者不一樣類型的用戶，每一個用戶只知道本身須要的系統，而不知道系統的總體狀況，他們不知道系統做爲一個總體怎麼樣工做效率更好，也不太清楚那些工做能夠交給軟件完成，他們不清楚需求是什麼，或者說如何以一種精確的方式來描述需求，他們須要開發人員的協助和指導，可是用戶與開發人員之間的交流很容易出現障礙，忽略了那些被認爲是"很明顯"的信息。最後是需求的確認，由於需求的不穩定性每每隨着時間的推移產生變更，使之難以確認。爲了克服以上的問題，必須有組織的執行需求的獲取活動。

葉鈺羽：第一次團隊合做寫一個小遊戲，隊友都是精通C++，做爲只瞭解Java的我，代碼編寫對我來講相對較難。所以，在此次合做中，我擔任UI設計的角色。ui對我來講也是比較新的領域，以前僅僅是手畫用戶故事，用文檔實現demo，此次會嘗試用畫圖軟件設計UI。 葉湖倩：在此次團隊合做中，我負責文檔編輯，進度統計以及博客發表工做。個人工做基本不涉及技術編程類，但我但願在此次的團隊任務中，可以向其餘隊友們學習一些技術，讓本身的編程能力有所提升。和團隊成員初步接觸，我發現溝通很重要，有效的溝通能提升你們的效率，避免在合做過程當中出現誤會。 ---恢復內容結束---

 

團隊Github項目倉庫

軟件規格需求說明書

引言

編寫目的

軟件規格需求說明書書了「2048俄羅斯方塊」1.0版本的軟件功能性需求和非功能性需求。

文檔約定

描述編寫文檔時所採用的標準或排版約定，包括正文風格，提示區或重要符號。例如，說明高層需求的優先級是否能夠被全部細化分需求所繼承，或者每一個需求陳述是否都有優先級。

讀者對象和閱讀建議

該軟件需求規格說明書針對開發人員、測試人員等，用於開發初期肯定軟件的系統設計，詳細設計。本文內容包括面向用戶分析、功能性需求、技術需求，闡述了系統的真實性、可用性以及價值所在。

項目範圍

「2048俄羅斯方塊」是在軟件工程第三次大做業由C++輪子隊提出來的一個項目，主要目的是供隊員學習軟件工程的開發過程，並經過這次開發，對C++掌握更加牢固。該遊戲軟件適用於大多數學生和上班族打發零散的空閒時間。

預期用戶數量

咱們預計的用戶數量是1000人以上。

整體描述

產品前景

「2048俄羅斯方塊」1.0版本是由微信小程序「個人方塊2048」的改進版，增長了一些新的功能來吸引更多用戶。

產品的簡述

遊戲規則：合併相同數字方塊，合成2048或更大數字得到勝利，格子填滿或方塊超出上界遊戲失敗

得分規則：合成塊對應分值 - 遊戲時間

具體操做：左右控制方塊移動，下鍵使懸空方塊馬上落下

真實性

2048和俄羅斯方塊都是兩款很火頗有意思的遊戲，相信二者的結合體「2048俄羅斯方塊」將會得到用戶的青睞。

可用性

「2048俄羅斯方塊」的玩法十分簡單，只要曾經玩過2048和俄羅斯方塊，就能很快入手。

價值所在

• 知足人們休閒娛樂的需求
• 兩款經典遊戲的結合，給用戶不同的體驗

運行環境

Linux/X十一、Mac、Windows、Embedded Linux、Windows CE / Mobile、Symbian、Meego、Wayland、Android、IOS、Amazon Kindle DX… QT For Everywhere!

設計和實現上的約束

爲了確保可移植性，本項目使用C++進行編寫，圖形庫、網絡庫使用QT內置的實現。 開發規範：

1. 禁止使用宏
2. 分號之前不加空格
3. 行寬原則上不超過80
4. 一行只定義一個變量
5. 大括號換行
6. return 後面的數值不加 ( )
7. 每一個文件應該含有版權信息及做者
8. 左圓括號以後和右圓括號以前無空格
9. 一目運算符與變量之間不加空格符隔開
10. 函數名與參數同行
11. 換行代碼縮進4個空格，而且使用四個空格符取代製表符
12. 二目以上的運算符與變量，常量之間用空格隔開（各種括號除外）
13. 不論控制語句，循環語句後面的循環體有多少行，都必須使用花括號
14. 普通函數，類型（含類與結構體，枚舉類型），常量等使用大小寫混合，可包含下劃線
15. 除函數定義的左大括號可置於行首之外，包括函數/類/結構體/枚舉聲明，各類語句的左大括號必須置於行末，全部右大括號獨立成行

硬件限制

1. 鍵盤輸入設備
2. 顯示屏
3. 具體硬件配置需求待測試

系統功能

圖形界面

分數統計

障礙塊

難度調整

在線排名

外部接口需求

用戶界面

整體界面：包括方塊，背景板，計分板，開始按鈕，暫停按鈕，結束按鈕。

硬件接口

描述系統中硬件每一個接口的特徵。可能包括支持的硬件類型、軟硬件之間交流的數據和控制信息的性質以及所使用的通訊協議

軟件接口

描述產品與其它外部組件的鏈接，包括數據庫，操做系統，工具庫和集成的商業組件。明確並描述在軟件組件之間交換數據或信息的目的，描述所須要的服務及內部組件通訊的性質，肯定將在組件之間共享的數據。若是必須用一種特殊的方法來實現數據共享機制，那麼就必須把它定義爲一種實現上的限制

通訊接口

描述與產品所使用的通訊功能相關的需求，包括電子郵件、WEB瀏覽器、網絡通訊標準或協議及電子表格等，定義相關的信息格式、規定通訊安全或加密問題、數據傳輸速率和同步通訊機制

非功能性需求

性能需求

點擊開始，暫停，結束按鈕時，馬上（1S內）出現相應的反應。 用戶用鍵盤控制方塊左右移動，按下鍵盤←→鍵，在2ms內方塊移動，讓用戶感受不到延遲。 按↓鍵，方塊應在5ms內到達底部。 還要定義容量需求，例如存儲器和磁盤空間的需求或者存儲在數據庫中表的最大行數。也可能須要針對每一個功能需求或特性分別陳述其性能需求

軟件質量屬性

可用性：程序用戶界面運行時不崩潰，按鈕佈局合理有效、易學容易掌握，在知足配置條件下能全程無明顯卡頓的運行，聯機時比分狀態雙機同步。在整個過程當中儘可能爲用戶帶來絲滑順暢的操做體驗。 健壯性：圖形界面上若佈局排列異常則根據內存數據重置界面

制定團隊計劃

將團隊的任務計劃添加到碼雲(Github)的團隊項目issues裏面(Done)

提供issues截圖(Done)

給出團隊項目的時間安排表(Todo)

本來時間安排(done)

時間	安排
10.14 - 10.20	分析需求，完成規格說明書，學習團體開發須要用到的技術
10.21 - 10.27	改進需求，進行系統設計、制定詳細的開發計劃
10.28 - 11.3	Alpha 衝刺
11.4 - 11.10	用戶測試 + 改進，收尾
11.11 - end	總結

校訂後的安排(Todo)

其餘

排版(Todo)

團隊分工 & 績效算法

團隊分工

• 湖倩：文檔
• yy：圖形界面
• 澤翰：圖形界面
• 秉坤：數字類、圖形界面
• 育招：控制類控制方向
• 綠豬：控制類判斷方向

績效算法

成員的績效 = 團隊得到的分數 + 我的的團隊貢獻分

在項目alpha 和 beta 階段評審後， 團隊會獲得一個項目分數（每一個成員都會獲得一樣的分數，作爲本身的原始分數的一部分）。團隊成員的努力程度不一樣，達成目標的程度不一樣，幫助同伴的付出不一樣，那就要在「團隊貢獻分」 上有所區分。 全部人貢獻分的總和爲 20N，其中N爲團隊的人數。 在alpha/beta 以後，團隊按照本身制定的規則，把 （20N）瓜分給每人，這就是 「團隊貢獻分」。

要求：請每人閱讀教材 「人、績效和職業道德」一章，而後團隊開一個討論會，協商討論團隊貢獻分的分配規則。每人得分爲天然數，而且每一個人分數不能相同。 請寫一個團隊博客詳細說明每一個團隊的成員計劃如何幫助團隊完成任務，以及團隊貢獻分的分配規則。

每一個人的完成狀況(Todo)

 

 

每一個人的感想(Todo)

育招：在這一週，咱們團隊完成了需求規格說明書，並制定了團隊計劃。假如一我的開發一個項目的話，大部分狀況下只能本身拿定主意，可是團隊開發就不同了，能夠進行頭腦風暴，進行思惟的碰撞，從而產生更好的想法，開發出更好的產品。另外，因爲我比較菜，因此在這一週裏，我去學習了一下團隊git的協做方式，弄懂了issue和branch的基礎操做，爲接下來的團隊開發作好準備。

澤翰：這周主要仍是參加討論與前期知識的學習與儲備，圖形界面設計方面以前僅僅是接觸了MFC框架與C#相關的皮毛。藉着這次團隊項目的學習實踐，以前也很想了解的Qt編程也有機會學習與實戰了。這周裏也是看了不少Qt的編程教程與相關書籍，因爲是第一次接觸，目前尚且在進行一些實例的練手。總的而言，這次的團隊項目不管是從我的編程經驗的積累仍是團隊的合做成長，都是十分使人期待的。

秉坤：由於個人任務是兼項的,負責界面的同時也負責數字類模塊,念及接下來的開發都是基於這個類進行開發,而且這個模塊的內容並不難, 因此這一週我提早了一點點將這個模塊基本上完成,相信可以跟其餘人有更好的對接.

綠豬：瞭解並實踐了軟件工程中項目需求分析與團隊分工相關的知識，深深感到用戶需求對軟件的重要性。成功的軟件產品是創建在成功的需求基礎之上的，而高質量的需求來源於用戶與開發人員之間有效的溝通與合做。當用戶有一個問題能夠用計算機系統來解決，而開發人員開始幫助用戶解決這個問題，溝通就開始了。

需求獲取多是最困難、最關鍵、最易出錯及最須要溝通交流的活動。對需求的獲取每每有錯誤的認識：用戶知道需求是什麼，咱們所要作的就是和他們交談從他們那裏獲得需求，只要問用戶系統的目標特徵，什麼是要完成的，什麼樣的系統能適合商業須要就能夠了，可是實際上需求獲取並非想象的這樣簡單，這條溝通之路佈滿了荊棘。首先需求獲取要定義問題範圍，系統的邊界每每是很難明確的，用戶不瞭解技術實現的細節，這樣形成了系統目標的混淆。

其次是對問題的理解，用戶對計算機系統的能力和限制缺少了解，任何一個系統都會有不少的用戶或者不一樣類型的用戶，每一個用戶只知道本身須要的系統，而不知道系統的總體狀況，他們不知道系統做爲一個總體怎麼樣工做效率更好，也不太清楚那些工做能夠交給軟件完成，他們不清楚需求是什麼，或者說如何以一種精確的方式來描述需求，他們須要開發人員的協助和指導，可是用戶與開發人員之間的交流很容易出現障礙，忽略了那些被認爲是"很明顯"的信息。最後是需求的確認，由於需求的不穩定性每每隨着時間的推移產生變更，使之難以確認。爲了克服以上的問題，必須有組織的執行需求的獲取活動。

葉鈺羽：第一次團隊合做寫一個小遊戲，隊友都是精通C++，做爲只瞭解Java的我，代碼編寫對我來講相對較難。所以，在此次合做中，我擔任UI設計的角色。ui對我來講也是比較新的領域，以前僅僅是手畫用戶故事，用文檔實現demo，此次會嘗試用畫圖軟件設計UI。

葉湖倩：在此次團隊合做中，我負責文檔編輯，進度統計以及博客發表工做。個人工做基本不涉及技術編程類，但我但願在此次的團隊任務中，可以向其餘隊友們學習一些技術，讓本身的編程能力有所提升。和團隊成員初步接觸，我發現溝通很重要，有效的溝通能提升你們的效率，避免在合做過程當中出現誤會。