團隊做業2：需求規格說明書（歪瑞古德小隊）

目錄

• 1、需求規格說明書
  • 1.1 引言
    • 1.1.1 編寫目的
    • 1.1.2 適用範圍
    • 1.1.3 術語定義
  • 1.2 項目闡述
    • 1.2.1 產品功能
    • 1.2.2 預期用戶量
    • 1.2.3 真實性
    • 1.2.4 可用性
    • 1.2.5 產品價值
    • 1.2.6 產品情懷
  • 1.3 面向用戶分析
  • 1.4 功能需求分析
    • 1.4.1 功能結構圖
    • 1.4.2 系統數據流圖
    • 1.4.3 具體功能列表
  • 1.5 技術需求分析
    • 1.5.1 開發技術選型
    • 1.5.2 性能需求
• 2、團隊計劃和分工
  • 2.1 團隊Github倉庫
    • 2.1.1 倉庫地址
    • 2.1.2 issue截圖
  • 2.2 修正前的團隊計劃
  • 2.3 修正後的團隊計劃
  • 2.4 矯正計算方法
  • 2.5 團隊分工
• 3、本週進展和總結
  • 3.1 本週分工狀況
  • 3.2 本週工做進展
    • 3.2.1 學習必要的技術
    • 3.2.2 平臺環境搭建
  • 3.3 總結和感想

Author：歪瑞古德小隊

Project：海島漂流

1、需求規格說明書

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、團隊計劃和分工

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、本週進展和總結

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. 隊長十分負責任，責任分數拉滿。