团队项目-需求分析报告
生活随笔
收集整理的這篇文章主要介紹了
团队项目-需求分析报告
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
組長本次作業博客鏈接
一、組隊后的團隊項目的整體計劃安排
| 階段 | 主要任務 | 計劃時間 | 內容 |
|---|---|---|---|
| 1 | 項目選題 | 第七周 | 選擇可行性強并且能在帶給福大學子便利的項目,完成項目描述市場調研,競品分析等 |
| 2 | 需求分析 | 第八周 | 撰寫需求分析說明報告,安排具體分工以及初步原型設計 |
| 3 | 設計分工 | 第九、十周 | 編碼規范、平臺環境搭建、初步架構搭建、明確細節分工 |
| 4 | 模塊編程 綜合對接 |
第十一、十二周 | 各模塊編碼、測試、項目管理同步推進、各模塊完成后進行對接 |
| 5 | 測試反饋 | 第十三周 | 實景測試反饋優化、形成最終正式版本 |
| 6 | 優化完善 | 第十四周 | 根據測試反饋優化,形成最終正式版本 |
| 7 | 項目宣發 | 第十五、十六周 | 用戶手冊、發布、文案 |
二、團隊分工
確定alpha版本需要做哪些事情
需要十分緊湊嚴格的任務安排,需要時間和熬夜,需要團隊成員共同的努力和穩定輸出...
* alpha版本:
| 模塊序號 | 模塊名 | 模塊具體內容 |
|---|---|---|
| 1 | 登錄注冊模塊 | 完成用戶的登錄與注冊 |
| 2 | 推薦模塊 | 根據專業年級只能推薦書籍 |
| 3 | 搜索模塊 | 買家自主搜索書籍,按關鍵字的相關度或者分類 |
| 4 | 交易模塊 | 買家和賣家之間下單、線下交易 |
| 5 | 社區模塊 | 用戶間關于書籍的交流 |
| 6 | 個人基礎信息模塊 | 昵稱、性別等個人信息的編輯存儲 |
| 7 | 個性化模塊 | 多樣的界面 |
各成員分工明細及TODO list
| 成員 | 分工明細 | TODO list |
|---|---|---|
| 張逸杰 | 跟蹤項目進程、安排整體計劃、后端助攻 | 跟蹤后端小分隊進程,協商完成后端開發 |
| 蘇凱婷 | 前端主力一號 | 完成登錄注冊模塊、搜索模塊、個性化模塊前端開發 |
| 鮑冰如 | 原型設計、UI設計 | 配合前端開發進程,完成各個界面UI設計 |
| 陳榮杰 | 后端主力三號、接口設計輔助 | 完成各模塊的接口設計,配合后端開發 |
| 楊錦鑌 | 前端主力二號 | 完成推薦模塊、交易模塊前端開發 |
| 王嵚 | 接口設計、后端輔助 | 配合完成接口設計、配合完成后端開發 |
| 林家偉 | 后端主力一號、數據庫搭建 | 完成后端開發 |
| 黃彬煌 | 后端主力二號 | 完成后端開發 |
| 黃智鋒 | 原型設計、UI設計 | 配合前端開發進程,完成各個界面UI設計 |
| 吳智勇 | 接口設計,數據庫搭建輔助 | 配合完成接口設計、配合完成數據庫搭建 |
| 劉汪洋 | 前端主力三號 | 完成社區模塊、個人基礎信息前端開發 |
燃盡圖
三、思維導圖
下面是“易書”app的思維導圖:
四、團隊成員貢獻比例
撰寫需求規格說明書的流程圖
組員分工及工作量
| 負責人 | 任務 | 工作量比例 |
|---|---|---|
| 張逸杰 | 撰寫需求分析報告 | 8% |
| 蘇凱婷 | 答辯演講 | 15% |
| 鮑冰如 | 撰寫博客 | 10% |
| 陳榮杰 | PPT和評審表的制作 | 10% |
| 楊錦鑌 | PPT和評審表的制作 | 10% |
| 王嵚 | 撰寫需求分析報告 | 8% |
| 林家偉 | 撰寫需求分析報告 | 8% |
| 黃彬煌 | 繪制UML圖 | 8% |
| 黃智鋒 | 原型設計 | 10% |
| 吳智勇 | 原型設計 | 8% |
| 劉汪洋 | 文檔審核 | 5% |
五、評審表格設計
下面是我們團隊此次制作的評審表:
六、UML
Part1 用例圖
這里描述的是系統哪個部分?
描述了用戶選擇買家找書和買家賣書以及買家和賣家交易的方法。
這部分要面臨什么樣的問題?
如何確定元素之間,角色之間,用例之間關系。
以下設計解決了什么樣的問題
明確了用例間的關系,獲取了需求,對過程中的其他工作流起到指導作用。
附用例圖
Part2 類圖
這里描述的是系統哪個部分?
描述的是系統的各種類。
這部分要面臨什么樣的問題?
需要了解實現功能所需的各個類以及相應方法
以下設計解決了什么樣的問題
總結了各個類對象所必需的屬性,以及實現活動圖各個操作的方法
附類圖
Part3 活動圖
這里描述的是系統哪個部分?
活動圖描述了買家買書和賣家賣書的具體流程,例如尋找書籍和上架書籍信息等。
這部分要面臨什么樣的問題?
買家和賣家如何交易二手書籍的這個流程需要更多的考量。
以下設計解決了什么樣的問題
解決了買家獲得所需書籍的方式,包括智能分類和自主搜索,以及賣家和買家之間在社區留言板關于書籍的交流。
附活動圖
Part4 狀態圖
這里描述的是系統哪個部分?
狀態圖描述了系統在不同使用場景下的狀態轉移邏輯。狀態圖將系統分為九種狀態,用戶首先處于未注冊狀態,經過注冊的觸發進入已已注冊狀態;再經過登錄成功的觸發進入選擇角色(買家或者賣家)的狀態;如果進入買家的狀態,則可進入找書的狀態,進而到買書、結算或者留言的狀態,而賣家能經觸發進入與買家結算的狀態。
這部分要面臨什么樣的問題?
包括各種狀態的設置,狀態轉移關系的設置。
以下設計解決了什么樣的問題
明確了系統在不同使用場景下的狀態轉移邏輯
附狀態圖
Part5 實體關系圖
這里描述的是系統哪個部分?
用來描述信息系統中概念模型的數據存儲。買家具有用戶名、支付賬號、郵箱等屬性,訂單具有訂單號和訂單時間等屬性,賣家具有用戶名、收款賬號、郵箱等屬性,書城具有書籍號、書籍名等屬性。
這部分要面臨什么樣的問題?
需要明確數據在系統中各個處理階段的狀態是怎樣的。
以下設計解決了什么樣的問題
解決了實體間關聯模糊的問題。
附實體關系圖
七、工具選擇
使用StarUML制作思維導圖,用例圖,活動圖,狀態圖,類圖;使用WPS制作ER圖、燃盡圖。
八、工具評價
StarUML是一款顏值高的軟件,簡直讓人想要迫不及待畫個UML圖,界面也很簡潔,使用起來也沒什么障礙,體驗很好。WPS是熟悉的工具,制作ER圖也沒有很大的難度。
九、答辯總結
小組現場答辯得分
| 組名 | 得分 |
|---|---|
| 第一組 | 54 |
| 第二組 | 54 |
| 第三組 | 55.8(去掉最高分) |
| 第四組 | 54 |
| 第五組 | 52.8()去掉最低分 |
| 第六組 | 54 |
| 第七組 | 54.6 |
| 第八組 | 55 |
| 第九組 | 53 |
| 第十組 | 55.2 |
去掉一個最低分和一個最高分,最后得分54.225
回答提問
(1)請問你們是怎樣保證安全性?
由于我們的軟件主要面向福大的學生,而學生的學號也具有唯一性,所以針對用戶的登錄安全,我們到時會在登錄注冊時進行學號驗證,即用戶輸入教務處賬號和教務處密碼,綁定成功即可登錄注冊。
(2)你們是如何對用戶上傳的二手書籍信息進行審核的呢?
對于二手書籍的審核比較關鍵的問題是要對用戶上傳信息的真實性進行驗證,而我們的軟件要求用戶上傳商品時同時上傳商品照片和商品描述,再者,因為我們的主要用戶是福大學子,而我們相信,福大學子是有內涵,有情操,有思想,為人誠信的完美用戶,他們是不會做這種上傳虛假商品的無聊行徑,用戶的自覺性也是我們審核工作的保障。
完善和修改需求分析報告
(1)建議:可以添加用戶登錄安全性的驗證
修改:添加了用戶的安全性由教務處賬號密碼保障的說明。
(2)建議:可以添加關于用戶上傳的二手書籍信息的審核說明
修改:著重說明賣家上傳書籍信息時要包括書籍照片和新舊程度介紹,以及添加了號召用戶發揮自覺性創建良好二手交易氛圍的部分。
十、需求規格說明書
點擊下載需求規格說明書
十一、遇到的困難及解決辦法
(1)原型設計方面
困難描述:
在我們這款app的原型設計工作上,風格或者功能排版等設計很難將每個人的想法統一起來
做過哪些嘗試
兩個人參與原型設計,一起決定app各部分的設計,風格也采取簡潔風。
是否解決
是,解決了,做出了優秀的原型設計,兩個人一起提意見一起設計。
有何收獲
增加了我們在移動端原型設計上的經驗,在設計的時候也要和隊友多交流,避免設計風格不統一的問題。
(2)需求分析報告方面
困難描述:
很難對用戶的需求面面俱到地進行分析,一個人下一子都不能做好需求分析,缺乏對項目需求分析的經驗,對非功能性需求中的總體需求和性能需求的定義不清楚
做過哪些嘗試
安排三人完成需求分析報告,人多力量大;搜尋相關文檔,參考網絡上的類似案例,逐步深入需求細節
是否解決
是,解決了,明確了用戶的需求,順利制作了需求分析報告
有何收獲
對軟件工程的需求分析有了初步的認識,也對接下來的工作流程更加了解了。需求分析需要和隊友之間密切交流討論,不斷完善分析,感受到了團隊的重要性。
十二、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 |
十三、學習進度條
| 第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 | 對需求分析報告有了更深了解 |
| ... |
總結
以上是生活随笔為你收集整理的团队项目-需求分析报告的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 动脉粥样硬化能不能吃生红萝卜
- 下一篇: 怎么创建具有真实纹理的CG场景岩石?