團隊項目-需求分析報告

組長本次做業博客連接

1、組隊後的團隊項目的總體計劃安排

階段	主要任務	計劃時間	內容
1	項目選題	第七週	選擇可行性強而且能在帶給福大學子便利的項目，完成項目描述市場調研，競品分析等
2	需求分析	第八週	撰寫需求分析說明報告，安排具體分工以及初步原型設計
3	設計分工	第9、十週	編碼規範、平臺環境搭建、初步架構搭建、明確細節分工
4	模塊編程 綜合對接	第11、十二週	各模塊編碼、測試、項目管理同步推動、各模塊完成後進行對接
5	測試反饋	第十三週	實景測試反饋優化、造成最終正式版本
6	優化完善	第十四周	根據測試反饋優化，造成最終正式版本
7	項目宣發	第十5、十六週	用戶手冊、發佈、文案

2、團隊分工

肯定alpha版本須要作哪些事情

須要十分緊湊嚴格的任務安排，須要時間和熬夜，須要團隊成員共同的努力和穩定輸出...

* alpha版本：

模塊序號	模塊名	模塊具體內容
1	登陸註冊模塊	完成用戶的登陸與註冊
2	推薦模塊	根據專業年級只能推薦書籍
3	搜索模塊	買家自主搜索書籍，按關鍵字的相關度或者分類
4	交易模塊	買家和賣家之間下單、線下交易
5	社區模塊	用戶間關於書籍的交流
6	我的基礎信息模塊	暱稱、性別等我的信息的編輯存儲
7	個性化模塊	多樣的界面

各成員分工明細及TODO list

成員	分工明細	TODO list
張逸傑	跟蹤項目進程、安排總體計劃、後端助攻	跟蹤後端小分隊進程，協商完成後端開發
蘇凱婷	前端主力一號	完成登陸註冊模塊、搜索模塊、個性化模塊前端開發
鮑冰如	原型設計、UI設計	配合前端開發進程，完成各個界面UI設計
陳榮傑	後端主力三號、接口設計輔助	完成各模塊的接口設計，配合後端開發
楊錦鑌	前端主力二號	完成推薦模塊、交易模塊前端開發
王嶔	接口設計、後端輔助	配合完成接口設計、配合完成後端開發
林家偉	後端主力一號、數據庫搭建	完成後端開發
黃彬煌	後端主力二號	完成後端開發
黃智鋒	原型設計、UI設計	配合前端開發進程，完成各個界面UI設計
吳智勇	接口設計，數據庫搭建輔助	配合完成接口設計、配合完成數據庫搭建
劉汪洋	前端主力三號	完成社區模塊、我的基礎信息前端開發

燃盡圖

3、思惟導圖

下面是「易書」app的思惟導圖：

4、團隊成員貢獻比例

撰寫需求規格說明書的流程圖

組員分工及工做量

負責人	任務	工做量比例
張逸傑	撰寫需求分析報告	8%
蘇凱婷	答辯演講	15%
鮑冰如	撰寫博客	10%
陳榮傑	PPT和評審表的製做	10%
楊錦鑌	PPT和評審表的製做	10%
王嶔	撰寫需求分析報告	8%
林家偉	撰寫需求分析報告	8%
黃彬煌	繪製UML圖	8%
黃智鋒	原型設計	10%
吳智勇	原型設計	8%
劉汪洋	文檔審覈	5%

5、評審表格設計

下面是咱們團隊這次製做的評審表：

6、UML

Part1 用例圖

這裏描述的是系統哪一個部分？

描述了用戶選擇買家找書和買家賣書以及買家和賣家交易的方法。

這部分要面臨什麼樣的問題？

如何肯定元素之間，角色之間，用例之間關係。

如下設計解決了什麼樣的問題

明確了用例間的關係，獲取了需求，對過程當中的其餘工做流起到指導做用。

附用例圖

Part2 類圖

這裏描述的是系統哪一個部分？

描述的是系統的各類類。

這部分要面臨什麼樣的問題？

須要瞭解實現功能所需的各個類以及相應方法

如下設計解決了什麼樣的問題

總結了各個類對象所必需的屬性，以及實現活動圖各個操做的方法

附類圖

Part3 活動圖

這裏描述的是系統哪一個部分？

活動圖描述了買家買書和賣家賣書的具體流程，例如尋找書籍和上架書籍信息等。

這部分要面臨什麼樣的問題？

買家和賣家如何交易二手書籍的這個流程須要更多的考量。

如下設計解決了什麼樣的問題

解決了買家得到所需書籍的方式，包括智能分類和自主搜索，以及賣家和買家之間在社區留言板關於書籍的交流。

附活動圖

Part4 狀態圖

這裏描述的是系統哪一個部分？

狀態圖描述了系統在不一樣使用場景下的狀態轉移邏輯。狀態圖將系統分爲九種狀態，用戶首先處於未註冊狀態，通過註冊的觸發進入已已註冊狀態；再通過登陸成功的觸發進入選擇角色（買家或者賣家）的狀態；若是進入買家的狀態，則可進入找書的狀態，進而到買書、結算或者留言的狀態，而賣家能經觸發進入與買家結算的狀態。

這部分要面臨什麼樣的問題？

包括各類狀態的設置，狀態轉移關係的設置。

如下設計解決了什麼樣的問題

明確了系統在不一樣使用場景下的狀態轉移邏輯

附狀態圖

Part5 實體關係圖

這裏描述的是系統哪一個部分？

用來描述信息系統中概念模型的數據存儲。買傢俱備用戶名、支付帳號、郵箱等屬性，訂單具備訂單號和訂單時間等屬性，賣傢俱備用戶名、收款帳號、郵箱等屬性，書城具備書籍號、書籍名等屬性。

這部分要面臨什麼樣的問題？

須要明確數據在系統中各個處理階段的狀態是怎樣的。

如下設計解決了什麼樣的問題

解決了實體間關聯模糊的問題。

附實體關係圖

7、工具選擇

使用StarUML製做思惟導圖，用例圖，活動圖，狀態圖，類圖；使用WPS製做ER圖、燃盡圖。

8、工具評價

StarUML是一款顏值高的軟件，簡直讓人想要火燒眉毛畫個UML圖，界面也很簡潔，使用起來也沒什麼障礙，體驗很好。WPS是熟悉的工具，製做ER圖也沒有很大的難度。

9、答辯總結

小組現場答辯得分

組名	得分
第一組	54
第二組	54
第三組	55.8（去掉最高分）
第四組	54
第五組	52.8（）去掉最低分
第六組	54
第七組	54.6
第八組	55
第九組	53
第十組	55.2

去掉一個最低分和一個最高分，最後得分54.225

回答提問

(1)請問大家是怎樣保證安全性？

因爲咱們的軟件主要面向福大的學生，而學生的學號也具備惟一性，因此針對用戶的登陸安全，咱們到時會在登陸註冊時進行學號驗證，即用戶輸入教務處帳號和教務處密碼，綁定成功便可登陸註冊。

(2)大家是如何對用戶上傳的二手書籍信息進行審覈的呢？

對於二手書籍的審覈比較關鍵的問題是要對用戶上傳信息的真實性進行驗證，而咱們的軟件要求用戶上傳商品時同時上傳商品照片和商品描述，再者，由於咱們的主要用戶是福大學子，而咱們相信，福大學子是有內涵，有情操，有思想，爲人誠信的完美用戶，他們是不會作這種上傳虛假商品的無聊行徑，用戶的自覺性也是咱們審覈工做的保障。

完善和修改需求分析報告

（1）建議：能夠添加用戶登陸安全性的驗證

修改：添加了用戶的安全性由教務處帳號密碼保障的說明。

(2)建議：能夠添加關於用戶上傳的二手書籍信息的審覈說明

修改：着重說明賣家上傳書籍信息時要包括書籍照片和新舊程度介紹，以及添加了號召用戶發揮自覺性建立良好二手交易氛圍的部分。

10、需求規格說明書

點擊下載需求規格說明書

11、遇到的困難及解決辦法

（1）原型設計方面

困難描述：

在咱們這款app的原型設計工做上，風格或者功能排版等設計很難將每一個人的想法統一塊兒來

作過哪些嘗試

兩我的參與原型設計，一塊兒決定app各部分的設計，風格也採起簡潔風。

是否解決

是，解決了，作出了優秀的原型設計，兩我的一塊兒提意見一塊兒設計。

有何收穫

增長了咱們在移動端原型設計上的經驗，在設計的時候也要和隊友多交流，避免設計風格不統一的問題。

（2）需求分析報告方面

困難描述：

很難對用戶的需求面面俱到地進行分析，一我的下一子都不能作好需求分析，缺少對項目需求分析的經驗，對非功能性需求中的整體需求和性能需求的定義不清楚

作過哪些嘗試

安排三人完成需求分析報告，人多力量大；搜尋相關文檔，參考網絡上的相似案例，逐步深刻需求細節

是否解決

是，解決了，明確了用戶的需求，順利製做了需求分析報告

有何收穫

對軟件工程的需求分析有了初步的認識，也對接下來的工做流程更加了解了。需求分析須要和隊友之間密切交流討論，不斷完善分析，感覺到了團隊的重要性。

12、PSP

PSP2.1	Personnal Software Process Stagese	預估耗時 （分鐘）	實際耗時 （分鐘）
Planning	計劃	20	20
· Estimate	· 估計這個任務須要多少時間	20	20
Development	開發	500	650
· Analysis	· 需求分析（包括學習新技術）	60	90
· Design Spec	· 生成設計文檔	220	240
· Design Review	· 設計複審	20	30
· Coding Standard	· 代碼規範（爲目前的開發制定合適的規範）	0	0
· Design	· 具體設計	240	220
· Coding	· 具體編碼	0	0
· Test	· 測試（自我測試，修改代碼，提交修改）	0	0
Reporting	報告	50	80
· Test Repor	· 測試報告	0	0
· Size Measurement	· 計算工做量	30	30
· Postmortem & Process Improvement Plan	· 過後總結，並提出過程改進計劃	30	30
	· 合計	1190	1980

十3、學習進度條

第N周	新增代碼（行）	累計代碼（行）	本週學習耗時(小時)	累計學習耗時（小時）	重要成長
1	0	0	10	10	學習axure的使用方法
2	2000+	2000+	130	140	學習html,css,js,前端製做
3	1000+	3000+	20	160	算法
4	0	3000+	20	180	對需求分析報告有了更深瞭解
...