Author：歪瑞古德小隊
Project：海島漂流
一、需求規格說明書
1.1 引言
1.1.1 編寫目的
為明確軟件需求、安排項目規划與進度、組織軟件開發與測試，撰寫本文檔。
1.1.2 適用范圍
- 產品名稱：海島漂流
- 適用環境：Android 5.0 +
- 界面語言：中文（簡體）
- 適用年齡：12歲以上人士
- 產品功能：提供一個社交平台，允許用戶通過寫信，樹洞，時間膠囊，海島等多種方式進行社交活動。
1.1.3 術語定義
| 術語 | 解釋 |
|---|---|
| 信件 | 本系統中的信件是指以信件的格式書寫的計算機文本， 通過互聯網在本系統中的用戶之間傳遞信息 |
| 樹洞 | 本系統中的樹洞是指一個匿名的公共空間，用戶以匿名 的方式在此空間留言 |
| 時間膠囊 | 本系統中的時間膠囊是指用戶書寫的信件可以設定一個 未來的時間開啟。 |
| 海島 | 本系統中的海島是指每個用戶擁有的一個個人空間， 用戶可以在個人空間中發布自己的動態 |
1.2 項目闡述
1.2.1 產品功能
用戶在這里互相通過寫信的方式交流，不僅可以結交筆友，還可以讓信件隨機發給某個用戶。此外，還有樹洞，時間膠囊，海島漂 流等多種多樣的社交玩法。
1.2.2 預期用戶量
考慮到我們的推廣渠道有限，系統預期的用戶量為2000
1.2.3 真實性
人們的日常生活離不開社交，各種社交產品成千上萬，本產品的真實性不言自明
1.2.4 可用性
本產品面向廣大的年輕用戶群體而開發，這一用戶群體數量龐大，對新事物接受程度高，同時也是在隨着互聯網發展而成長起來的一代人，早已熟悉QQ，微信，微博等各類社交應用，因此這些用戶對本產品的學習成本很低，對於這種新鮮的游戲化社交應用，也具有很大的好奇心和使用需求。
1.2.5 產品價值
在這樣一個信息爆炸的時代，人們在互聯網中任何一個地方，幾乎都避免不了各種廣告信息的侵襲，各種精心包裝的標題之下毫無營養的軟文，各種”大V“和”腦殘粉“之間唾沫橫飛的論戰撕逼。身處這樣一個嘈雜的時代，人們需要一款遠離喧囂，專注於內心真實的情感，純粹的文字表達的社交應用，本產品的價值就在於此。
1.2.6 產品情懷
本產品的切入點是”信件“這樣一種原始的交流方式，看似不便，實際上這種具有儀式感的寫作方式，更加能夠讓用戶表達自己真實的情感。同時，發送信件的方式，類似於當年微信漂流瓶的方式，這也是一代人的年代回憶。當然，我們也致力於解決微信漂流瓶信息泛濫的弊端，從而給用戶呈現一個更完美的產品。
1.3 面向用戶分析
本產品的目的在於提供一個更加純粹的社交平台，促進人們用文字去表達自己最真實的感情。主要面向的是15到30歲之間，希望尋找一個更好社交平台的年輕互聯網用戶。
1.4 功能需求分析
1.4.1 功能結構圖
1.4.2 系統數據流圖
1.4.3 具體功能列表
| 功能 | 詳細描述 |
|---|---|
| 登錄注冊 | 用戶使用賬號密碼登錄 用戶注冊一個賬號 用戶選擇忘記密碼 |
| 用戶信息管理 | 用戶修改密碼 用戶修改頭像 用戶修改筆名 用戶修改郵箱 用戶修改簽名 |
| 我的郵票 | 用戶可以查看自己擁有的郵票列表 |
| 通知 | 用戶收到新信件時進行提醒 用戶看完通知之后信件狀態改變 |
| 書寫信件 | 書寫新的信件 選擇信件的信紙（背景） |
| 發送信件 | 隨機選擇筆友 選擇一個發送的筆友 選擇一張使用的郵票 系統根據兩邊距離計算發信所需時間 發信消耗一張郵票 |
| 草稿箱 | 用戶查看草稿 用戶編輯草稿 用戶更新草稿 用戶發送草稿 |
| 筆友 | 用戶可以把另一個添加為筆友（不需要對方同意） 用戶可以看到筆友列表 用戶點擊筆友可以看到兩人之間來往的信件 用戶可以給筆友寫信 |
| 個人海島 | 每個用戶有一個自己的海島 用戶可以設置自己海島的背景 |
| 他人海島 | 用戶可以看到他人海島的動態 動態可以看到內容，發送時間，發送者，瀏覽量 用戶可以在動態下面評論和回復 |
| 進入海島 | 漂流：用戶可以隨機到達一個海島 用戶可以根據海島名稱搜索海島 到達一個海島后有一定幾率獲得郵票和時間膠囊 |
| 海島列表 | 用戶可以看到自己標記過的海島列表 用戶可以在自己的海島發動態 用戶可以標記他人的海島 |
| 數據統計 | 發送了多少信件 受到過多少信件 在信件中寫過多少文字 路過多少個海島 |
| 創建樹洞 | 用戶可以創建一個樹洞，填寫樹洞名稱，樹洞內容 用戶最多只能創建5個樹洞 其他用戶可以查看樹洞內容 其他用戶可以在樹洞下面留言（只能給樹洞留言，不能互相回復） |
| 修改樹洞 | 修改已經創建的樹洞 |
| 刪除樹洞 | 刪除已經創建的樹洞 |
| 時間膠囊 | 用戶書寫一封信 用戶可以指定在將來某個時間打開這個膠囊 用戶一開始只有3個膠囊 把一封信放進膠囊會消耗一顆膠囊 |
1.5 技術需求分析
1.5.1 開發技術選型
前端技術選型：
| 技術項 | 具體技術 |
|---|---|
| 編程語言 | JavaScript,HTML,CSS |
| 開發框架 | Vue + Router + Vuex + jquery |
| 打包技術 | Weex，webpack |
| 測試環境 | nodeJs + chorme瀏覽器 |
| 實際運行環境 | Android 5.0 + |
| css預編譯語言 | eless |
后端服務器技術選型:
| 技術項 | 具體技術 |
|---|---|
| 編程語言 | Java |
| 通信協議 | HTTP |
| JDK | 1.8.0_202 |
| 數據庫 | MySQL 5.7 , Redis 5.0.8 |
| Web服務器 | Nginx 1.17.8 |
| 代碼版本控制 | Git |
| 技術框架 | springboot 2.6.0，mybatis-plus 3.0，Maven 3.0 Freemarker |
| 外部接口 | 高德開放平台API |
1.5.2 性能需求
- 系統的平均響應時間應該在500ms以內
- 系統的平均吞吐量應該達到300TPS以上
- 系統應該至少能夠承載10萬以上的總用戶量
- 系統應該支持300以上的並發用戶數
二、團隊計划和分工
2.1 團隊Github倉庫
2.1.1 倉庫地址
https://github.com/gdut-very-good
2.1.2 issue截圖
2.2 修正前的團隊計划
| 序號 | 功能 | 功能詳情 | 時間安排（開始到完成） |
|---|---|---|---|
| 一 | 登錄注冊 | 4.30-5.2 | |
| 1. | 用戶使用賬號密碼登錄 | 使用賬號密碼登錄 | 4.30-5.1 |
| 2. | 用戶注冊一個賬號 | 進行注冊操作 | 5.1-5.2 |
| 3. | 用戶選擇忘記密碼 | 進行忘記密碼並修改密碼操作 | 5.2-5.2 |
| 二 | 用戶信息管理 | 4.30-5.2 | |
| 1. | 修改密碼 | 修改密碼操作 | 4.30-5.1 |
| 2. | 修改頭像 | 修改個人資料操作 | 5.1-5.2 |
| 3. | 修改筆名 | 修改個人資料操作 | 5.1-5.2 |
| 4. | 修改郵箱 | 修改個人資料操作 | 5.1-5.2 |
| 5. | 修改簽名 | 修改個人資料操作 | 5.1-5.2 |
| 三 | 信件模塊 | 4.30-5.8 | |
| 1. | 書寫新的信件 | 寫信，選擇書信背景 | 4.30-5.1 |
| 2. | 發送信件 | 1. 隨機選擇筆友 2. 選擇一個發送的筆友 3.選擇一張使用的郵票 4. 系統根據兩邊距離計算發信所需時間 5. 發信消耗一張郵票 | 5.2-5.8 |
| 四 | 草稿箱模塊 | 5.3-5.4 | |
| 1. | 用戶可以看到所寫的未發送信件列表 | 可以看到未發送的信件列表 | 5.3-5.3 |
| 2. | 用戶可以查看草稿，編輯草稿，更新草稿 | 1. 查看草稿 2. 編輯草稿 3. 更新草稿 | 5.3-5.4 |
| 3. | 用戶可以將草稿發送出去 | 發送草稿 | 5.4-5.4 |
| 五 | 筆友 | 5.2-5.3 | |
| 1. | 用戶可以將另一個人添加為筆友 | 不需要對方同意，將對方添加為筆友 | 5.2-5.2 |
| 2. | 用戶可以看到筆友列表 | 查看筆友列表 | 5.2-5.3 |
| 3. | 點擊筆友查看兩人來往信件 | 查看兩人來往信件 | 5.3-5.3 |
| 4. | 用戶可以給筆友寫信 | 發送信件 | 5.3-5.3 |
| 六 | 我的郵票 | 5.8-5.8 | |
| 1. | 用戶可以查看自己擁有的郵票列表 | 查看郵票列表 | 5.8-5.8 |
| 七 | 海島模塊 | 5.3-5.8 | |
| 1. | 個人海島 | 1. 設置海島背景 2. 發表海島動態 | 5.3-5.5 |
| 2. | 他人海島 | 1. 查看他人海島動態 2. 看到動態內容，發送時間，發送者，瀏覽量 | 5.5-5.5 |
| 3. | 進入海島 | 1. 隨機漂流進入海島 2. 根據海島名稱進入海島 3. 到達海島后隨機獲得郵票和時間膠囊 | 5.5-5.7 |
| 4. | 海島列表 | 查看自己所到達過的海島 | 5.7-5.8 |
| 八 | 測試 | 對已開發的功能進行測試 | 5.1-5.8 |
2.3 修正后的團隊計划
團隊計划的整體時間安排分為三個迭代計划：
| 版本名稱 | 開始時間 | 發布時間 |
|---|---|---|
| Alpha 1.0 | 2020年4月30日 | 2020年5月09日 |
| Alpha 2.0 | 2020年5月09日 | 2020年5月16日 |
| Alpha 3.0 | 2020年5月16日 | 2020年5月23日 |
每個版本包含的功能如下：
| 功能 | 功能詳情 | 所屬版本 |
|---|---|---|
| 登錄注冊 | 用戶使用賬號密碼登錄 用戶注冊一個賬號 用戶選擇忘記密碼 |
Alpha 1.0 |
| 用戶信息管理 | 修改密碼 修改頭像 修改筆名 修改郵箱 修改簽名 |
Alpha 1.0 |
| 我的郵票 | 用戶可以查看自己擁有的郵票列表 | Alpha 1.0 |
| 通知 | 用戶收到新信件時進行提醒 用戶看完通知之后信件狀態改變 |
Alpha 1.0 |
| 書寫信件 | 書寫新的信件 選擇信件的信紙（背景） |
Alpha 1.0 |
| 發送信件 | 隨機選擇筆友 選擇一個發送的筆友 選擇一張使用的郵票 系統根據兩邊距離計算發信所需時間 發信消耗一張郵票 |
Alpha 1.0 |
| 草稿箱 | 查看草稿 編輯草稿 更新草稿 發送草稿 |
Alpha 1.0 |
| 筆友 | 用戶可以把另一個添加為筆友（不需要對方同意） 用戶可以看到筆友列表 用戶點擊筆友可以看到兩人之間來往的信件 用戶可以給筆友寫信 |
Alpha 1.0 |
| 個人海島 | 每個用戶有一個自己的海島 用戶可以設置自己海島的背景 |
Alpha 2.0 |
| 他人海島 | 用戶可以看到他人海島的動態 動態可以看到內容，發送時間，發送者，瀏覽量 用戶可以在動態下面評論和回復 |
Alpha 2.0 |
| 進入海島 | 漂流：用戶可以隨機到達一個海島 用戶可以根據海島名稱搜索海島 到達一個海島后有一定幾率獲得郵票和時間膠囊 |
Alpha 2.0 |
| 海島列表 | 用戶可以看到自己標記過的海島列表 用戶可以在自己的海島發動態 用戶可以標記他人的海島 |
Alpha 2.0 |
| 數據統計 | 發送了多少信件 受到過多少信件 在信件中寫過多少文字 路過多少個海島 |
Alpha 3.0 |
| 創建樹洞 | 用戶可以創建一個樹洞，填寫樹洞名稱，樹洞內容 用戶最多只能創建5個樹洞 其他用戶可以查看樹洞內容 其他用戶可以在樹洞下面留言（只能給樹洞留言，不能互相回復） |
Alpha 3.0 |
| 修改樹洞 | 修改已經創建的樹洞 | Alpha 3.0 |
| 刪除樹洞 | 刪除已經創建的樹洞 | Alpha 3.0 |
| 時間膠囊 | 用戶書寫一封信 用戶可以指定在將來某個時間打開這個膠囊 用戶一開始只有3個膠囊 把一封信放進膠囊會消耗一顆膠囊 |
Alpha 3.0 |
2.4 矯正計算方法
-
將項目的需求划分了三個版本，為項目的整體搭建預留更多的時間，做出更好的方案
-
根據“先核心功能再次要功能，先易后難“的原則，為核心的書信功能預留更多開發時間，把樹洞，時間膠囊的功能放在了第三版
-
考慮到五一勞動節大家的游玩，因此將海島模塊（原第七點）的開發移動至第二階段，增加了通知模塊（第七點），工作量相對減少。
2.5 團隊分工
| 職責 | 參與成員 |
|---|---|
| UI設計 | 丘麗珊 |
| 前端開發 | 張文俊，余聖源 |
| 后端開發 | 陳宇，黃煜淇，丘麗珊，黃鈺朝 |
| 測試 | 陳宇，黃煜淇，丘麗珊， 張文俊，余聖源，黃鈺朝 |
| 文檔和復審 | 黃煜淇，黃鈺朝 |
三、本周進展和總結
3.1 本周分工情況
可以查看詳細安排
| 任務 | 關鍵結果 | 負責人 | 時間 | 重要程度 |
|---|---|---|---|---|
| 設計第一版UI | 設計出包含第一版 功能的UI界面 |
丘麗珊 | 4月30號中午前 | ！！！ |
| 預估難度 學習必要技術 |
1.仔細閱讀項目需求 2.預估項目難度 3.學習必要技能 參考以下學習清單 |
全員 | 本周內 | ！！ |
| 建立接口文檔 | 前后端開會討論 並編寫接口文檔 |
全員 | 暫定4月30號 下午16點30分 |
！！！ |
| 團隊博客 | 編寫團隊博客 | 黃鈺朝 | 5月1號晚前 | ！！ |
| 數據庫 初步設計 |
根據需求初步設計數據庫 | 黃煜淇，陳宇，黃鈺朝 | 本周內 | ！！ |
| 團隊計划 | 1.給出原有安排和 校正后的安排 2.給出矯正計算方法 3.將團隊的任務計划 添加到GitHub的團隊 項目issues里面（參考） |
黃煜淇，陳宇 | 5月1號晚前 | ！！ |
| 編碼規范 | 編寫團隊編碼規范 和git使用規范 |
黃鈺朝 | 本周內 | ！ |
| 完成情況和感想 | 每個人在共享文檔中 填寫自己這周做了哪 些工作，進度如何， 這周的感想 |
全員 | 5月1號晚前 | ！ |
3.2 本周工作進展
3.2.1 學習必要的技術
| 學習內容 | 學習成員 |
|---|---|
| Weex | 余聖源，張文俊 |
| UI設計相關知識 | 丘麗珊 |
| 敏捷開發和scrum框架 worktile的使用 Postman的使用 Restful API設計原則 |
全員 |
| Mybatis-plus | 黃煜淇，陳宇，黃鈺朝 |
3.2.2 平台環境搭建
- 建立Github組織和倉庫：https://github.com/gdut-very-good
- 建立開發數據庫
- 建立worktile團隊
- 制定編碼規范：歪瑞古德小隊編碼規范
- 制定Git使用規范：歪瑞古德小隊Git使用規范
3.3 總結和感想
| 成員名稱 | 工作內容 | 目前進度 | 本周感想 |
|---|---|---|---|
| 黃鈺朝 | 1.學習相關知識 2.制定編碼規范 3.參與建立接口文檔 4.參與設計數據庫 |
100% | 1.需求還是要明確可行，如果存在模糊和 分歧的地方，工作就難以進行。同時也應該 考慮合理性 2.作為PM去分配工作時要明確，如果沒有 描述清楚任務，就會使得接受任務的隊員 不知道如何執行，也會降低團隊的效率，這是 需要改進的地方 3.工作任務分配之后不應該隨意改動，這會 給執行者造成很大的負擔 |
| 黃煜淇 | 1. 參與建立接口文檔 2. 參與設計數據庫 3. 制定一部分工作安排表 4. 參與添加issue到倉庫 |
100% | 1. 本周團隊組織了一次線上會議，主要討論了 接口文檔的制定以及工作計划的修改 2. 本周暫未開始編碼工作，主要都是在進行項目 開始前的安排，方便了接下來的編碼工作 3. 隊長認真負責，多次督促隊員完成任務 |
| 陳宇 | 1. 參與建立接口文檔 2. 參與設計數據庫 3.參與添加issue到倉庫 |
100% | 1.了解了issue在倉庫中可以用來跟蹤bug,提出 意見等功能 2.每個人及時完成分配到的任務，才能使團隊 合作更高效 3. 隊長認真負責，多次督促隊員完成任務 |
| 余聖源 | 1.建立app項目 2.根據任務要求完成第一版的UI 3.參與建立接口文檔 |
50% | 1.初建了一個前端項目准備轉為安卓app， 踩了不少的坑 2.體會了一次真正按照規范的團隊協作，感覺 步驟略為繁瑣，不是拿到就干，讓我不是很舒服。 3.隊長十分負責任，責任分數拉滿。 |
| 丘麗珊 | 1.原型設計 2.參與建立接口文檔 |
100％ | 1.畫圖比寫代碼費眼一百倍 2.增加了奇怪的Axure技能 3.求求需求文檔寫清晰一點，不然設計人員容易誤會 4.會繼續做好團隊的泥石流 5.大家都說隊長認真負責，只有我想揍隊長一頓 |
| 張文俊 | 1. 進行項目搭建和依賴的完善 2. 學習開發知識 |
90％ | 1. 使用了新的開發工具，坑很多，腦殼疼 2. 在開發初期進行了很多的開發前准備，比如溝通文檔和需求，比之前的項目開發專業不少 3. 隊長十分負責任，責任分數拉滿。 |