團隊項目需求分析

45度炸隊項目需求分析

1、總體計劃安排和明確里程碑

• 總體計劃

截止時間	具體安排
10.27	最終版SRS《軟件規格說明書》的撰寫與全員基礎安卓知識填充
11.5	架構設計與UI設計
11.14	編碼與多重測試，併發布Alpha版本
11.23	用戶體驗計劃，刪改功能模塊
11.24	深度DEBUG測試，發佈Beta版本
12.8	正式版本的推送

• 咱們團隊因爲人數有限，力量相對薄弱，所以對於整個項目的規劃要更加的嚴格與謹慎。考慮到咱們團隊是三隻毫無開發APP經驗的菜鳥，咱們決定仍是先從安卓開發的基礎知識入手。先掌握關鍵的、最爲基本的開發常識。這項任務原本是國慶完成，可是因爲老師手一抖連甩兩個任務不得不將計劃推遲，咱們三我的須要快速完成安卓基礎知識的填充。

• 此後咱們的總體策略採用邊作邊學的方式開展項目開發，在作中學，不斷地積累更多知識，來搭建整個APP所需的知識框架。考慮到10月28日就要發佈Alpha版本的演示，可能還會推遲，但無論怎麼樣，咱們三我的要在這些天完成大量的開發工做。初步打算從核心功能作起，優先搭建咱們的日曆線，基本實現"個人足跡"、日記、備忘、規劃的雲端共享，簡單初步搭載點數系統和規則系統，給出最基礎的系統規則明細，尤爲是給出咱們的"規則系統"的亮點。咱們把本來的"上傳圖片"、"上傳視頻"和"每日一推"的功能做爲擴展功能，放在往後實現。這裏再次強調，咱們作的不僅是一個日記和一個日曆，日曆只是咱們串聯咱們功能模塊的副產物，而日記只是咱們養成類APP的冰山一角，這點在答疑的時候貌似助教和老師一直沒有理解。

• 具體實現順序：日曆、日記、規劃、規則系統、個人足跡、點數系統。
  （這裏根據助教和老師的喜愛，暫時主打規則系統和"個人足跡"）

• Alpha版本完成之後，咱們會進行嚴格的DEBUG測試，咱們會進一步在真實手機上，尋找不一樣的用戶羣體，幫咱們查找隱藏的BUG，而且提出寶貴的意見，幫助咱們一點一點的修正APP的方方面面。另外一邊，咱們會開展擴展功能的實現，以及完善系統規則明細。

• 在收集完用戶意見以及明顯的BUG的處理以後，咱們會對部分功能進行調整，增長部分功能，刪除部分功能，使得總體的APP更加的人性化與和諧。固然，咱們爭取在功能上可以給出更多的咱們團隊的亮點，這也是咱們往後考慮的方向之一。

---

2、工做流程

• 首先先開會討論，根據老師和助教的建議作出功能和原型上細化和調整的方案
• 小組討論具體實施和更變狀況
• 根據初代《「假的日曆」項目需求條例和功能模塊細則》進一步細化原型設計，進一步的調整功能模塊。
• 網上參考了《軟件需求規格說明書》國標規範文本，根據實際狀況加以改造。
• 組長肯定SRS整個文檔的大體目錄結構，對word文檔的標題、正文等進行統一的格式規範。例如：
  - 標題必須所有加粗
  - 一級標題黑體小二號，二級標題黑體三號，其他次級標題以此類推...
  - 全文內容使用宋體小四號
  - 表格內字體使用等線中文正文五號字體
• 咱們是比較團結的一組，你們都挺努力的，於是決定由組員挑選本身喜歡的部分來各自編寫，而且由組長作出適當的調整。
• 上述安排，考慮到原型須要作出部分調整，需求分析須要大量原型的支持，所以將需求分析和驗收驗證標準這塊內容交給比較熟悉這塊的蔡鴻傑和陳甘霖。曾瑋詩是咱們當中最先接觸到MarkDown以及最先開始寫博客的人，因此博客整理排版方面，他比較駕輕就熟，整理起來也比較快速，一直以來的團隊做業博客編排也都是他在作。
• 初步肯定「文檔」內容分工：
  • 蔡鴻傑：需求分析部分的撰寫
  • 曾瑋詩：引言和整體描述部分的撰寫
  • 陳甘霖：驗收驗證標準部分的撰寫
• 整體秉持誰悠閒誰就接管下一個任務的原則，因爲咱們團隊只有三我的。

---

3、隊內成員分工狀況

團隊成員	成員分工
蔡鴻傑	需求分析討論，需求分析（主要）、調整原型設計、細化原型設計部分設計內容
曾瑋詩	需求分析討論，引言和整體描述部分、UML設計、博客整理和排版
陳甘霖	需求分析討論，驗收驗證標準、博客內容的撰寫、總體計劃安排、工做流程和明確里程碑的書寫和確立

---

4、《需求規格說明書》附件

5、評審表設計