團隊做業3：需求改進&系統設計（歪瑞古德小隊）

時間 2020-06-06

標籤團隊需求改進系統設計小隊欄目快樂工作简体版

原文原文鏈接

Author：歪瑞古德小隊php

Project：海島漂流css

1、需求&原型改進

1.1 用戶需求調查

爲了進一步理解用戶的需求和痛點，咱們經過發放問卷的方式調查當代年輕人的社交習慣和需求，並收集用戶對於社交類應用開發者的建議。如下是問卷的數據報表和分析。html

Q1：你對如今主流的社交應用的感覺是？前端

這道題目的設計目的是調查用戶對新型社交應用的須要程度和對目前主流社交應用的感覺java

調查結果顯示，認爲主流的社交應用沒有新鮮感的人數佔比最多，也有至關一部分人認爲目前主流的社交應用的功能不足以知足他們的需求，表示不喜歡的使用社交應用的人數佔比很小。mysql

Q2：你會由於什麼緣由減小使用或者卸載一款社交應用？nginx

這道題目從用戶卸載一款社交應用的緣由的角度調查用戶使用社交應用的痛點sql

調查結果顯示，社交應用致使用戶流失的主要緣由是使用過程當中出現煩人的廣告，使用過程當中看到不少過激和不當的言論，應用中的內容質量差，信息繁雜等。數據庫

Q3：你會由於什麼選擇使用一款新的社交應用？apache

這道題目調查用戶選擇使用新的社交應用的緣由，以便尋找應用的核心競爭力

調查結果顯示，產品的新功能最容易吸引用戶使用一款新的社交應用，其次是應用中有優質的內容，在上面找到了喜歡的人或者圈子，社區的氛圍好等緣由。

Q4：你對寫信這種社交方式的見解是？

這道題目調查用戶對於寫信這種社交方式的接受程度和興趣

調查結果顯示，不會寫信，可是想要的嘗試的人數佔比最多，其次是喜歡寫信，可是沒有寫信的對象。所以本應用應該致力於幫助用戶快速學習寫信，以及找到寫信的筆友。

其中不喜歡寫信的緣由以下：

選項	緣由
不喜歡寫信	寫信是慢節奏的通訊方式，已經不太適合現代通訊
不喜歡寫信	這種交流方式反饋時間太長了
不喜歡寫信	直接能夠微信或者電話就能夠聊天
不喜歡寫信	我字醜

Q5：你對社交類應用開發者有什麼建議？

如下是一些具備表明性的建議：

你對社交類應用開發者有什麼建議？
建議界面作的好看一點，而且求求你們善待設計組，設計組很是不容易。並且但願該軟件能夠有比較好的交互，不要學習某微博，交互按鈕作的很是奇怪，好像倒大黴同樣，並且該應用還常常崩，時不時就裂開
社交類軟件應該加設電腦或手機投屏功能，若是已經有了這個功能，應該去優化這個功能，例如提升共享屏幕的分辨率和穩定性，減小卡頓，掉幀，數據包丟失的狀況發生
創新吧有本身的風格有足夠新有趣的點能夠吸引人
界面簡潔纔是用戶最想要的，首頁不要擠滿東西，想要作什麼咱們本身會點

從調查結果來看，用戶比較在乎的是簡潔美觀的界面和新穎獨特的功能。

1.2 選題需求改進

在向目標用戶展現原型以後，針對用戶提出的問題，咱們作出以下改進：

問題1：我以爲郵箱地址屬於用戶隱私，查看其餘人的我的資料時不要顯示出來

改進1：其餘人查看的我的資料的頁面隱藏郵箱地址

問題2：我以爲不能未經對方贊成就添加對方爲筆友

改進2：去掉添加筆友功能，提供給陌生用戶寫信功能，第一次給對方寫信以後自動添加爲筆友

問題3：我以爲樹洞內容不能修改，否則會出現留言和樹洞內容不對應的狀況

改進3：去掉修改樹洞內容的功能

問題4：能不能限制用戶輸入一些敏感詞？否則匿名的應用很容易出現各類低俗內容

改進4：後臺服務器加入敏感詞過濾系統，屏蔽信件，樹洞，海島等公開內容的敏感詞

1.3 功能分析的四個象限

需求\功能	外圍功能	殺手功能
必要需求	用戶信息管理，海島功能	信件功能
輔助需求	樹洞功能，時間膠囊功能，數據統計功能	筆友功能，草稿箱功能

1.4 完善需求規格說明書

完整的需求規格說明書：需求規格說明書

咱們主要是對功能需求列表的部分作出修改，以解決用戶提出的問題，修改後的功能列表以下：

功能	詳細描述
登陸註冊	用戶使用帳號密碼登陸用戶註冊一個帳號用戶選擇忘記密碼
用戶信息管理	用戶修改密碼用戶修改頭像用戶修改筆名用戶修改郵箱用戶修改簽名
個人郵票	用戶能夠查看本身擁有的郵票列表
通知	用戶收到新信件時進行提醒用戶看完通知以後信件狀態改變
書寫信件	書寫新的信件選擇信件的信紙（背景）
發送信件	隨機選擇筆友選擇一個發送的筆友選擇一張使用的郵票系統根據兩邊距離計算髮信所需時間發信消耗一張郵票
草稿箱	用戶查看草稿用戶編輯草稿用戶更新草稿用戶發送草稿
筆友	第一次給對方寫信以後自動添加爲筆友用戶能夠看到筆友列表用戶點擊筆友能夠看到兩人之間來往的信件用戶能夠給筆友寫信
我的海島	每一個用戶有一個本身的海島用戶能夠設置本身海島的背景
他人海島	用戶能夠看到他人海島的動態動態能夠看到內容，發送時間，發送者，瀏覽量用戶能夠在動態下面評論和回覆
進入海島	漂流：用戶能夠隨機到達一個海島用戶能夠根據海島名稱搜索海島到達一個海島後有必定概率得到郵票和時間膠囊
海島列表	用戶能夠看到本身標記過的海島列表用戶能夠在本身的海島發動態用戶能夠標記他人的海島
數據統計	發送了多少信件受到過多少信件在信件中寫過多少文字路過多少個海島
建立樹洞	用戶能夠建立一個樹洞，填寫樹洞名稱，樹洞內容用戶最多隻能建立5個樹洞其餘用戶能夠查看樹洞內容其餘用戶能夠在樹洞下面留言（只能給樹洞留言，不能互相回覆）
刪除樹洞	刪除已經建立的樹洞
時間膠囊	用戶書寫一封信用戶能夠指定在未來某個時間打開這個膠囊用戶一開始只有3個膠囊把一封信放進膠囊會消耗一顆膠囊

1.5 任務分解WBS調整

根據用戶提出的問題，調整任務分解WBS以下：

1.6 項目進度計劃調整

根據用戶提出的問題，對具體的功能需求作出調整，並把樹洞，時間膠囊功能調整到第二版，海島功能調整到第三版。調整後的項目進度計劃以下：

功能	功能詳情	所屬版本
登陸註冊	用戶使用帳號密碼登陸<br用戶註冊一個帳號用戶選擇忘記密碼	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
建立樹洞	用戶能夠建立一個樹洞，填寫樹洞名稱，樹洞內容用戶最多隻能建立5個樹洞其餘用戶能夠查看樹洞內容其餘用戶能夠在樹洞下面留言（只能給樹洞留言，不能互相回覆）	Alpha 2.0
刪除樹洞	刪除已經建立的樹洞	Alpha 2.0
時間膠囊	用戶書寫一封信用戶能夠指定在未來某個時間打開這個膠囊用戶一開始只有3個膠囊把一封信放進膠囊會消耗一顆膠囊	Alpha 2.0
我的海島	每一個用戶有一個本身的海島用戶能夠設置本身海島的背景	Alpha 3.0
他人海島	用戶能夠看到他人海島的動態動態能夠看到內容，發送時間，發送者，瀏覽量用戶能夠在動態下面評論和回覆	Alpha 3.0
進入海島	漂流：用戶能夠隨機到達一個海島用戶能夠根據海島名稱搜索海島到達一個海島後有必定概率得到郵票和時間膠囊	Alpha 3.0
海島列表	用戶能夠看到本身標記過的海島列表用戶能夠在本身的海島發動態用戶能夠標記他人的海島	Alpha 3.0

2、後端架構文檔

2.1 文檔簡介

2.1.1 目的

本文檔將從構架方面對系統進行綜合概述，其中會使用多種不一樣的構架視圖來描述軟件系統的各個方面，記錄並表述已對系統的構架方面做出的重要決策。

2.1.2 範圍

本文檔用於歪瑞古德小隊正在開發中的海島漂流項目。海島漂流項目是一款以信會友的匿名遊戲化社交應用。

2.1.3 定義、首字母縮寫詞和縮略語

術語	解釋
信件	本系統中的信件是指以信件的格式書寫的計算機文本，經過互聯網在本系統中的用戶之間傳遞信息
樹洞	本系統中的樹洞是指一個匿名的公共空間，用戶以匿名的方式在此空間留言
時間膠囊	本系統中的時間膠囊是指用戶書寫的信件能夠設定一個將來的時間開啓。
海島	本系統中的海島是指每一個用戶擁有的一個我的空間，用戶能夠在我的空間中發佈本身的動態

2.1.4 參考資料

暫無

2.2 架構表示方式

本文檔經過如下一系列視圖來表示海島漂流項目的軟件架構：用例視圖，部署視圖，數據視圖

2.3 架構目標和約束

本系統在開發過程當中有以下設計約束：開發語言爲Java，採用關係型數據庫存放數據。
全部用戶必須在保證網絡鏈接的狀況下可經過互聯網訪問系統
系統必須保證數據的安全訪問，用戶需經過用戶名和密碼來進行身份驗證，同時對數據的訪問要進行受權驗證

2.4 用例視圖

2.5 部署視圖

2.5.1 User Client

用戶主要經過APP來訪問系統，暫時只支持安卓系統

2.5.2 Server

應用服務器運行海島漂流系統，採用nginx對用戶請求進行分流，同時搭建服務器集羣進行負載均衡。系統採用SpringBoot框架搭建，同時採用MyBatis-plus框架與數據庫進行交互。

2.5.3 DB Server

數據服務器運行mysql5.7數據庫

2.6 數據視圖

數據庫ER圖：

friend表：

列名	註釋	類型
friend_id	id	int(255)
friend_user_id	筆友的用戶id	int(255)
user_id	用戶的id	int(255)
remark	筆友備註	varchar(255)

letter表：

列名	註釋	類型
letter_id	信件id	int(255)
sender_id	發送者id	int(255)
send_time	發送時間	datetime
receiver_id	接收者id	int(255)
receive_time	接收時間	datetime
content	信件內容	text
paper	信紙	varchar(255)
is_send	是否發送(true=發送，false=保存爲草稿)	tinyint(255)
stamp_id	使用的郵票id	int(11)
header	信件標題	varchar(255)

message表：

列名	註釋	類型
message_id	樹洞留言id	int(255)
writer_id	留言者id	int(255)
content	內容	varchar(255)
tree_hole_id	樹洞id	int(255)
time	留言時間	datetime

notice:

列名	註釋	類型
notice_id	通知id	int(255)
user_id	用戶id	int(255)
is_read	是否已讀(0=未讀，1=已讀)	tinyint(255)
title	通知標題	varchar(255)
content	通知內容	varchar(255)

post表：

列名	註釋	類型
post_id	海島動態id	int(255)
user_id	用戶id	int(255)
content	內容	text
time	發佈時間	datetime
view	瀏覽量	int(255)

reply表：

列名	註釋	類型
reply_id	回覆id	int(255)
writer_id	回覆者id	int(255)
be_reply_id	被回覆的回覆id	int(255)
content	回覆內容	varchar(255)
post_id	帖子id	int(255)
time	回覆時間	datetime

stamp表：

列名	註釋	類型
stamp_id	郵票id	int(11)
user_id	用戶id	int(255)
stamp_name	郵票名稱	varchar(255)

star表：

列名	註釋	類型
star_id	星標id	int(255)
user_id	用戶id	int(255)
island_id	海島用戶id	int(255)

tree_hole表：

列名	註釋	類型
tree_hole_id	樹洞id	int(255)
creator_id	建立者id	int(255)
content	樹洞內容	text
create_time	建立時間	datetime

user表：

列名	註釋	類型
user_id	用戶id	int(255)
username	用戶名	varchar(255)
password	密碼	varchar(255)
mail	郵箱	varchar(255)
word	用戶寫過的字數	int(255)
photo	頭像	varchar(255)
nickname	暱稱	varchar(255)
signature	簽名	varchar(255)
background	海島背景	varchar(255)
city	所在城市	varchar(255)
capsule	膠囊數量	int(11)

2.7 大小與性能

本系統採用的軟件架構能夠很好的支持如下性能需求：

系統的平均響應時間應該在500ms之內
系統的平均吞吐量應該達到300TPS以上
系統應該至少可以承載10萬以上的總用戶量
系統應該支持300以上的併發用戶數

2.8 質量

本系統採用的軟件結構能夠很好的支持系統質量方面的需求：

系統應當方便全部用戶的使用，對於普通用戶的培訓時間不該該超過20分鐘。
系統必須可以保證天天24小時不間斷運行，服務可用率達99.99%。
合理的設計系統結構以保證較高的可維護性，系統的模塊應該能夠替換。
系統應當正確處理發生的異常或錯誤，並返回錯誤信息。
系統應當具有健全的日誌系統，以便及時排查錯誤緣由。

3、Alpha任務分配計劃

3.1 Product Backlog和Sprint Backlog

依據項目組能提供的總時間、功能模塊的優先級以及模塊之間的依賴關係，在Product Backlog中選取待實現的功能項，對已選擇的功能項再作進一步分解，分解爲1-10小時左右的任務，構成Sprint Backlog。

Product Backlog	Sprint Backlog
用戶模塊	登錄註冊，用戶信息管理，數據統計
信件模塊	筆友列表，發送信件，樹洞和時間膠囊
草稿箱模塊	草稿列表，修改草稿，發送草稿
海島模塊	海島列表，評論回覆，我的海島

3.2 開發任務分配

在PM的協助下，編碼的同窗對任務進行認領，分工的結果以下：

開發任務	前端頁面負責人	後端接口負責人	預計工時
登錄註冊功能	餘聖源	黃煜淇	4h
用戶信息功能	餘聖源	黃煜淇，陳宇，丘麗珊	4h
數據統計	餘聖源	黃鈺朝	4h
筆友列表	餘聖源	陳宇	8h
發送信件	餘聖源	黃鈺朝	4h
樹洞和時間膠囊功能	餘聖源	黃煜淇，陳宇	8h
草稿箱列表	張文俊	黃煜淇	4h
修改草稿	張文俊	黃鈺朝	2h
發送草稿	張文俊	黃鈺朝	2h
我的海島	張文俊	黃鈺朝，黃煜淇	4h
海島列表	張文俊	黃煜淇，陳宇	8h
評論回覆	張文俊	黃煜淇，陳宇	4h

3.3 Alpha階段衝刺計劃甘特圖

gantt title Alpha階段衝刺計劃 dateFormat YYYY-MM-DD section 用戶模塊登錄註冊: done,dlzc, 2020-05-20,1d 用戶信息管理: done, yhxxgl, after login,2d 數據統計: active, after yhxxgl,3d section 信件模塊筆友列表: active, bylb, 2020-05-20,2d 發送信件: fsxj, after bylb,4d 樹洞和時間膠囊: after bylb, 5d section 草稿箱模塊草稿列表: active,cglb, 2020-05-20, 2d 修改草稿: after cglb,2d 發送草稿: after cglb,2d section 海島模塊海島列表:active,hdlb, 2020-05-20, 3d 評論回覆:after hdlb,3d 我的海島:after hdlb,4d section 測試發佈功能測試: gncs,2020-05-27,3d 性能測試: xncs,after gncs,1d 安全測試: aqcs,after gncs,1d 項目發佈: 1d

4、測試計劃

4.1 引言

4.1.1 項目背景

本文檔用於歪瑞古德小隊正在開發中的海島漂流項目。海島漂流項目是一款以信會友的匿名遊戲化社交應用

4.1.2 使用人羣

項目經理、產品、開發、測試人員

4.1.3 測試方式

軟件測試的 W 模型

4.2 測試範圍

功能模塊測試

信件模塊、用戶模塊、海島模塊、時間膠囊模塊、樹洞模塊五大模塊
兼容性測試

基於 app開發，對多種安卓手機測試
壓力測試

對數據的承載量測試
安全測試

對系統的安全性能進行測試

4.3 測試策略

4.3.1 功能測試

須要對如下功能進行測試：

功能	詳細描述
登陸註冊	用戶使用帳號密碼登陸用戶註冊一個帳號用戶選擇忘記密碼
用戶信息管理	用戶修改密碼用戶修改頭像用戶修改筆名用戶修改郵箱用戶修改簽名
個人郵票	用戶能夠查看本身擁有的郵票列表
通知	用戶收到新信件時進行提醒用戶看完通知以後信件狀態改變
書寫信件	書寫新的信件選擇信件的信紙（背景）
發送信件	隨機選擇筆友選擇一個發送的筆友選擇一張使用的郵票系統根據兩邊距離計算髮信所需時間發信消耗一張郵票
草稿箱	用戶查看草稿用戶編輯草稿用戶更新草稿用戶發送草稿
筆友	第一次給對方寫信以後自動添加爲筆友用戶能夠看到筆友列表用戶點擊筆友能夠看到兩人之間來往的信件用戶能夠給筆友寫信
我的海島	每一個用戶有一個本身的海島用戶能夠設置本身海島的背景
他人海島	用戶能夠看到他人海島的動態動態能夠看到內容，發送時間，發送者，瀏覽量用戶能夠在動態下面評論和回覆
進入海島	漂流：用戶能夠隨機到達一個海島用戶能夠根據海島名稱搜索海島到達一個海島後有必定概率得到郵票和時間膠囊
海島列表	用戶能夠看到本身標記過的海島列表用戶能夠在本身的海島發動態用戶能夠標記他人的海島
數據統計	發送了多少信件受到過多少信件在信件中寫過多少文字路過多少個海島
建立樹洞	用戶能夠建立一個樹洞，填寫樹洞名稱，樹洞內容用戶最多隻能建立5個樹洞其餘用戶能夠查看樹洞內容其餘用戶能夠在樹洞下面留言（只能給樹洞留言，不能互相回覆）
刪除樹洞	刪除已經建立的樹洞
時間膠囊	用戶書寫一封信用戶能夠指定在未來某個時間打開這個膠囊用戶一開始只有3個膠囊把一封信放進膠囊會消耗一顆膠囊

試圖發現如下幾類錯誤：

是否有不正確或遺漏的功能。
在接口上，可否正確地接受輸入數據，可否產生正確地輸出信息。
訪問外部信息是否有錯。
界面是否有錯，是否不美觀。
初始化或終止錯誤。

4.3.2 系統兼容性測試

對於移動端的用戶，對不一樣安卓手機進行測試

4.3.3 性能壓力測試

採用apache的開源測試工具jmeter，經過http協議發送訪問請求，收集服務器響應速度，監控服務器運行狀態和資源耗用狀況

4.3.4 安全測試

用acunentix測試，測試人員模擬非法入侵，採用各類方法衝破防線。記錄各項攻擊數據，破防時間，攻擊地點，攻擊方式及代價。

4.4 測試資源

4.4.1 測試人員

後端測試人員：陳宇、黃煜淇、黃鈺朝、丘麗珊

前端測試人員：餘聖源、張文俊

4.4.2 測試環境

手機：Android 手機

網絡環境：WIFI、手機移動網絡

4.4.3 測試工具

postman,jmeter

4.4.4 測試服務器

阿里雲服務器

4.5 進度安排

任務	時間	執行人員	預期工做量
編寫測試計劃	2020.05.19	陳宇	半天
測試計劃的修改	項目全程	全體人員	半天
第一輪的功能測試（包含兼容性測試）	2020.05.27	陳宇、黃煜淇、黃鈺朝、丘麗珊	半天
性能測試、迴歸測試	2020.05.29	陳宇、黃煜淇、黃鈺朝、丘麗珊	2 小時
發佈前內測	2020.06.01	全體成員	1 小時
測試報告總結	發佈後	陳宇	半天
合計			4 天 3 小時

4.6 輸出文檔

《項目測試計劃書》

《項目測試報告書》

4.7 發佈標準

完成全部的測試類型
沒有影響用戶正常使用的 bug
經過壓力測試，而且設計符合用戶要求
沒有 bug 或 bug 通過風險評估
經過交叉檢查，非該代碼開發人員測試經過
產品使用說明書或用戶手冊等已經完備

4.8 風險說明

上述工做量的預估中，對需求的變動進行了必定的風險覆蓋，但若是需求的變動超出目前的預計，則可能致使編寫測試用例和執行測試相關工做量的增長、測試進度延遲。
開發提交的測試版本比該計劃的風險，發生此種狀況時，執行測試的時間應該合理順延。
提交測試版本質量較低的風險，可能致使比該計劃更多輪次的迴歸測試。

5、前端設計文檔

5.1 前端基礎描述

Vue	用於構成整個html，css，js的框架
Weex	用於將前端代碼打包行成安卓java代碼

5.2 前端基礎功能劃分

功能概述	功能描述
登錄註冊展現	提供用戶註冊和進入系統的入口
筆友頁面	1.展現筆友列表。2.時間膠囊，給將來的本身寫一封信。3.樹洞。
草稿頁面	1.給用戶編寫草稿，
海島展現頁面	1.海島列表 2.評論回覆 3.我的海島
個人信息頁面	1.個人信息須要提供給用戶一個查看本身帳戶資料，編輯資料的功能。2.查看本身擁有的郵票。3.查看本身的消息。4.退出登錄