團隊專案第二週 - 需求規格說明書 - 天冷記得穿秋褲隊
團隊專案第二週 - 需求規格說明書 - 天冷記得穿秋褲隊
隊員姓名 | 學號 |
---|---|
陳俊旭(組長) | 3116004630 |
夏瓦克提·木合塔爾 | 3116004658 |
張婷(副組長) | 3216004672 |
周方源 | 3215004673 |
隨著人民日益增長的資源獲取需求與資源節點不足的矛盾日益增長,為了提高單機下載速度,我們團隊打算實現一個具有離線下載功能的下載器,功能類似於百度雲盤的離線下載。使用者可以將下載連結新增進下載器中,下載器離線下載完畢後可以取回檔案。以下是針對第一週的初步設計,給出的更進一步的詳細的需求分析。
需求規格說明書
基本需求
- 支援單使用者單檔案的離線下載
- 支援刪除離線檔案
- 簡單的命令列介面
面向使用者分析:對於一款主打離線下載的下載器來說,最核心的功能就是離線下載。使用者需要的是能夠下載到檔案,並且為了隱私可以刪除掉檔案
功能性分析:提供下載器最基本的功能,即下載。基本需求裡面的支援下載功能可以將使用者的下載連結上傳到伺服器,再將伺服器下載的結果返回給使用者;使用者下載完畢後可以選擇刪除自己的離線記錄;可以通過命令簡單的控制整個下載流程,包括選擇檔案存取路徑等等
技術需求:需要通過aiar2解決伺服器與客戶端之間檔案的傳輸問題;需要支援簡單的命令列輸入控制
高階需求
- 支援單使用者多檔案的離線下載
- 支援檢視檔案離線下載進度
- 提供Chrome的擴充套件程式介面
- 支援檔案上傳
面向使用者分析:很多情況下使用者並不只是下載一個檔案,他們還需要同時下載多個檔案,並且需要知道自己的下載任務還有多久結束,因此希望有一個進度條和剩餘時間方便管理下載。大多數使用者並不會用命令列下載檔案,這對於大多數人來說十分不友好,他們希望有一個輕量級的下載工具;有時候使用者還希望通過下載器儲存一些檔案,因此需要使用者上傳
需求性分析:當用戶多工的離線下載是目前所有下載器支援的特性,而且對於下載器來說是剛需;更加友好的下載頁面既可以方便使用者下載,也可以方便使用者對下載進行管理,是最直觀的留存使用者的手段
技術需求:需要解決多檔案同時下載的併發問題;需要利用 js 和 css 開發一個 extension;需要對下載流進行額外的控制,如增加一個控制流告訴客戶端下載資訊
進階需求
- 支援多使用者多檔案同時下載
- 對於離線的視訊檔案可以線上觀看
- 更加嚴格的系統安全控制(如隔離有害檔案等)
- 更加安全的檔案儲存策略(如多級備份等)
面向使用者分析:使用者在理想視訊的過程中,相比於將視訊下載後再在本地開啟觀看,更希望能夠直接觀看視訊;而且使用者對於檔案下載的隱私非常在意,希望更好的保護自己的下載資訊;使用者還希望下載器能完全地保護他們的資訊,而不被洩露或者遭受破壞
需求性分析:增加多使用者支援符合當今下載器的現狀,可以更加方便地對每個使用者的下載檔案進行管理和控制;對於伺服器來說安全至關重要,因此不僅需要抵抗來自伺服器外的侵略,還要隔離來自使用者下載的有害檔案的攻擊
技術需求:需要解決多使用者訪問伺服器的埠問題;需要對伺服器的硬碟進行分割槽保護;需要支援簡單的使用者管理
系統進一步闡釋
- 真實性
- 目前市場的同類軟體有:迅雷,百度網盤下載等。每個網路使用者都有檔案下載和上傳的需求。
- 可用性
- 我們團隊的檔案離線下載器力求在達到目前市場基本檔案下載器功能的同時,達到檔案下載管理和檔案下載雲端儲存等方面的友好使用程度。
- 作為一款輕量級的檔案離線下載器,使用者在擁有基本的上傳和下載檔案的基本功能的同時,能夠不被服務端限制下載速度(比如迅雷下載的限速現象,普通使用者只有在開通會員才能達到最大速度上傳),而我們團隊的專案致力於實現每個使用者不進行限速,下速度只取決於使用者的頻寬,從而解決如今使用者對現今市場下載軟體諸如此類做法的不滿。
- 價值性
- 對使用者來說,可以極大提升下載體驗;使用者將下載任務上傳至伺服器端後,由伺服器負責下載檔案,使用者可以關閉電腦或者進行其它作業,當伺服器下載完畢後再拉下來,這樣子可以充分利用使用者寬頻,因為傳統的下載節點一般會限制下載速度,而我們的SmellyCat離線下載器並不會。
- 對提供下載的網站來說,可以分流下載流量,避免對伺服器造成過大負載;在沒有離線下載器之前,下載網站是與使用者建立一對一的連線,需要給每個使用者分配一定的下載資源,容易造成伺服器負載過大。而當用戶使用離線下載後,使用者是從我們SmellyCat下載資源,我們再通過一定的策略集中訪問下載網站,避免多個使用者對於同一檔案的多次下載。
- 對運營商來說,可以更有效地進行流量控制和擁塞控制;由於我們的SmellyCat集中處理了使用者的下載請求,可以使得網路中下載的密集度降低,減輕了運營商的壓力。
- 有情懷
- 我們實在是看透了某雷某度雲盤的離線下載限制,因此很努力地想要開發一個真正為使用者下載體驗著想的離線下載器。我們希望將這個專案開源,不僅是為了集思廣益,更是為了讓社群使用者知道我們的透明實現過程,而不是暗箱操作偷偷修改下載速度。
- 此外,我們開發完服務端離線版本後,將可能進一步開發客戶端離線器,顧名思義就是使用者可以選擇貢獻自己的寬頻,以提高整個社群的下載速度。
專案相關
專案碼雲地址:SmellyCat
預期使用者數量:由於下載器對伺服器效能要求較高,因此第一個版本預期支援最多50
團隊計劃
issues列表
將團隊的任務計劃新增到碼雲的團隊專案issues裡面 (√)
原有安排
時間 | 任務進度 |
---|---|
第6周 | 1.團隊組隊,團隊部落格 (√) |
2.團隊介紹、成員展示、角色分配、選題確定 (√) | |
3.制定團隊計劃安排,團隊貢獻分的規定 (√) | |
第7周 | 1.需求規格說明書 |
2.原型設計,隊員估計任務難度並學習必要的技術 | |
3.編碼規範完成、平臺環境搭建完成、初步架構搭建 | |
第8周 | 1.原型改進(給目標使用者展現原型,並進一步理解需求) |
2.架構設計,WBS, 團隊成員估計各自任務所需時間 | |
3.測試計劃 | |
第9周 | 1. 團隊專案Alpha任務分配計劃 |
2. 連續7天的Alpha敏捷衝刺,7 篇 每日Scrum Meeting部落格+程式碼提交 | |
第10周 | 1.使用者反饋+測試計劃改進 |
2. 團隊Alpha階段個人總結 | |
3. 團隊專案Alpha部落格:釋出說明、測試報告、展示部落格、專案管理 | |
第11周 | 1. 團隊專案Alpha部落格:事後分析 |
2. 每個團隊有一人必須離開,自己尋找下一個接納自己的團隊。團隊發部落格宣佈離隊和接納的成員。 | |
第12周 | 1. 團隊專案Beta任務分配計劃,介紹新成員 |
2. 連續7天的Beta敏捷衝刺,7 篇 每日Scrum Meeting部落格+程式碼提交 | |
第13周 | 1. 團隊專案Beta部落格:釋出說明、測試報告、展示部落格 |
2. 團隊Beta階段個人總結 | |
第14周 | 1. 團隊專案Beta部落格:事後分析, 宣佈每人的貢獻分 |
第15周 | 1.團隊整個階段總結,分析使用者資料,整理文件,保證以後的團隊能接手。 |
校正後的安排
時間 | 任務進度 |
---|---|
第6周 | 1.團隊組隊,團隊部落格 (√) |
2.團隊介紹、成員展示、角色分配、選題確定 (√) | |
3.制定團隊計劃安排,團隊貢獻分的規定 (√) | |
第7周 | 1.需求規格說明書 (√) |
2.原型設計,隊員估計任務難度並學習必要的技術 (√) | |
3.編碼規範完成、平臺環境搭建完成、初步架構搭建 (√) | |
第8周 | 1.原型改進(給目標使用者展現原型,並進一步理解需求) |
2.架構設計,WBS, 團隊成員估計各自任務所需時間 | |
3.測試計劃 | |
第9周 | 1. 團隊專案Alpha任務分配計劃 |
2. 連續7天的Alpha敏捷衝刺,7 篇 每日Scrum Meeting部落格+程式碼提交 | |
第10周 | 1.使用者反饋+測試計劃改進 |
2. 團隊Alpha階段個人總結 | |
3. 團隊專案Alpha部落格:釋出說明、測試報告、展示部落格、專案管理 | |
第11周 | 1. 團隊專案Alpha部落格:事後分析 |
2. 每個團隊有一人必須離開,自己尋找下一個接納自己的團隊。團隊發部落格宣佈離隊和接納的成員。 | |
第12周 | 1. 團隊專案Beta任務分配計劃,介紹新成員 |
2. 連續7天的Beta敏捷衝刺,7 篇 每日Scrum Meeting部落格+程式碼提交 | |
第13周 | 1. 團隊專案Beta部落格:釋出說明、測試報告、展示部落格 |
2. 團隊Beta階段個人總結 | |
第14周 | 1. 團隊專案Beta部落格:事後分析, 宣佈每人的貢獻分 |
第15周 | 1.團隊整個階段總結,分析使用者資料,整理文件,保證以後的團隊能接手。 |
矯正計算方法
由於第六週和第七週給出有充足的時間進行系統設計和需求分析,這兩週的小組成員都可以按照計劃穩步推進,因此可以完成原有計劃表給出的安排,本週暫時不需要對計劃表進行矯正
其他
團隊分工
隊員姓名 | 分工 |
---|---|
陳俊旭 | 開發服務端的下載模組,向前端提供檔案下載和管理的介面 |
夏瓦克提·木合塔爾 | 測試前端外掛是否符合使用者習慣,是否能正常下載檔案,並提交反饋報告 |
張婷 | 開發chrome外掛模組,負責向用戶提供管理介面,並且支援友好的互動體驗 |
周方源 | 協助張婷同學進行前端開發,及時處理組員間的討論糾紛 |
完成情況
隊員姓名 | 完成情況 |
---|---|
陳俊旭 | 初步完成需求分析 |
夏瓦克提·木合塔爾 | 初步完成需求分析 |
張婷 | 正在學習chrome外掛開發知識 |
周方源 | 初步完成需求分析 |
感想
陳俊旭: 我們分析了整個專案應該如何下手,雖然過程中大家都有分歧,但是PM的帶領下大家都能回到理智的討論中,希望大家能進一步努力
夏瓦克提·木合塔爾:作為測試人員前期的工作不多,主要是參與需求的討論,在討論過程中能知道其他同學是怎麼想的
張婷:在需求確定完成後我就開始著手學習相關知識,可以說明確的需求真的可以縮短學習的週期,因為更加清楚確定需要什麼技術
周方源:認識到作為一名PM真的需要對專案有很好的把控, 一方面是避免小組成員無意義的討論,另一方面是可以發散大家的思維, 做出大家都滿意的產品