需求分析報告

2022-08-15 13:48:15 字數 3767 閱讀 1417

階段主要任務

計畫時間內容1

專案選題

2018.09.27-2018.10.12

確定選題,完成專案的市場調研和競品分析,指定推廣戰略

2需求分析

2018.10.20-2018.11.04

編寫需求說明書

3編碼規範

2018.11.05-11.11

完成介面規定、編碼規範、編碼環境搭建

4alpha衝刺

2018.11.11-2018.11.23

完成專案的核心功能開發、前後端對接

5改進總結調整

2018.11.24-12.07

專案完善、使用者試用反饋、測試計畫改進

6beta衝刺

2018.12.13-2018.12.21

完成附加功能的開發以及根據使用者反饋改進

姓名比例(%)

完成工作

王彬14

趙暢10

類圖設計、word彙總、思維導圖彙總

李恆達12

胡展瑞12

王源12

類圖設計、思維導圖、食堂平面圖設計

佘岳昕10

驗收標準撰寫、思維導圖

陳志煒10

功能描述撰寫、思維導圖

陳文垚10

引言編寫、思維導圖

林煌偉10

類圖設計、思維導圖

組號組名打分1

爸爸餓了隊812

拖鞋旅遊隊783

彳艮彳亍隊794

火箭少男100765

起床一起肝活隊606

404 note found隊717

第三視角788

小白吃78

9我頭髮呢隊

79-  答:我們的推薦是建立在使用者使用軟體的當時口味偏好進行推薦的,此外在軟體開發初期,我們會積極嘗試可能的演算法來達到我們對推薦精確度的要求,初步調查後,隨機森林、knn等線性回歸演算法在我們的考慮範圍內, 我們在專案計畫書中,以及現場ppt展示中都明確闡述了我們的軟體是基於使用者使用時對3-4道布林選擇題的選擇來衡量使用者的口味。

-  答:在團隊選題報告答辯中我們就回答過,自選視窗存在每日選單變動的問題,這一客觀侷限使得我們並不打算向使用者推薦自選檔口的菜品,不過現在在考慮面對自選檔口時只推薦檔口的招牌菜的做法的可行性。

-  問題3:如何更大程度吸引使用者選擇你們的產品?

-  答:這個問題我們在團隊選題報告的專案推廣中已經有了全面且清晰的闡述。

-  問題1:每家店鋪都有不同的菜品,如果需要細化菜品的話是否需要大量的調查

-  問題2:對於學生街以及食堂來說很多店鋪都在不停的更換,如何及時的更新店鋪數量,需要維護人員定期的調查嗎

-  答:我們目前只針對福大的各個食堂展開我們的服務,按照經驗來看,食堂大部分的店鋪並不會進行頻繁的菜品輪換,但對店鋪及其菜品的維護也是需要定時進行

-  問題3:產品是否存在定期的迭代規程?

-  問題2:遇到多人出行不知道吃什麼的時候這款軟體還能適用嘛?

-  答:如何使用本款軟體是使用者的自由,我們會盡力保證應用本身功能的易用性

-  問題3:關於你們組的logo,與嘀嘀打車的有些相似(塗上色就差不多了),後期有考慮進行修改避嫌麼

-  答:在我們看來兩者差異十分明顯

-  問題1:請問使用者的口味細化你們打算怎麼做到?

-  問題2:請問軟體推廣過程打算做出什麼努力?

-  答:這部分我們在專案選題報告中的推廣方式部分已經做出充分詳細的闡述。

-  問題3:如何突顯產品競爭優勢吸引使用者

-  答:這是我們的產品原型對後期產品可能的產品形態的一種展望,為了達成這個目標,我們需要打通支付方式、食堂商家的中間道路,所以在產品開發初期,問題中提到的統計資訊暫時無法上線,在先期的開發中我們會將精力主要集中在普通使用者端的開發與推薦演算法的完善,如果產品執行穩定再向我們的遠期產品願景努力。

-  答:使用者對推薦菜品是否滿意是乙個主觀問題,我們所能做的就是盡量保證推薦演算法的客觀合理性。對使用者口味的判定是通過使用者每次獲取推薦前的4道布林選擇題來獲取的,之後我們的推薦演算法會根據使用者的選擇推薦出最可能獲得使用者青睞的菜餚

-  答:我們推薦的菜品都是通過到食堂實地採集相應的資料並錄入到我們的資料庫中,所以推薦的菜品都是真實可靠的。關於產品推廣,我們已經在之前的專案選題報告中的推廣方式部分做出明確詳細的闡述。

-  問題1:商家端管理是否需要配備硬體,還是說只要用手機就行?

-  答:商家端的應用會基於web端提供服務,因為分析報告內容多樣,採用web端展示更方便使用者瀏覽。

-  問題2:關於ppt的講解,老師是建議說讓上次沒有參與的非pm的優先,為什麼還是pm講解的?

-  問題1:

-  答:

-  問題2:

-  答:

-  問題3:

-  答:

需求規格說明書

psp2.1

personal software process stages

預估耗時(分鐘)

實際耗時(分鐘)

planning計畫5

5· estimate

· 估計這個任務需要多少時間55

development

開發100

120· analysis

· 需求分析 (包括學習新技術)

6060

· design spec

· 生成設計文件

1010

· design review

· 設計複審

1010

· coding standard

· **規範 (為目前的開發制定合適的規範)00

·  design

· 具體設計

2040

· coding

· 具體編碼00

· code review

· **複審00

· test

· 測試(自我測試,修改**,提交修改)00

reporting

報告20

20· test repor

· 測試報告00

· size measurement

· 計算工作量

1010

· postmortem & process improvement plan

· 事後總結, 並提出過程改進計畫

1010

合計125

145第n周 | 新增**(行)| 累計**(行)| 本週學習耗時(小時) | 累計學習耗時(小時) | 重要成長

---|---|---|---|---|---|---

1 | 500 | 500 | 12 | 12 | 單元測試的編寫

2 | 0 | 500 | 10 | 22 | axure原型設計工具的使用

3 | 500 | 1000 | 10 | 32 | c++演算法設計編寫能力,debug除錯能力

4 | 200 | 1200 | 10 | 42 | 學習網頁設計(html)

5 | 200 | 1400 | 10 | 52 | 學習網頁設計(css)

需求分析報告

組長部落格 組員主要任務 徐俊傑規劃專案程序 ppt演講 李家湧撰寫部落格 黃麗萍ppt製作 朱雅珊ppt製作 連振昇提出相關假設 范文輝非功能規格設計 李煒煒專案logo設計 江列湫uml圖製作 楊文uml圖製作 彭佳偉設計評審表 評分 工作流程 組員分工 貢獻比例 徐俊傑ppt 評審 15 李家...

需求分析報告

階段編號 階段時間 階段主要任務 完成情況 第零階段 9.4團隊組建 已完成第一階段 9.6討論選題 已完成第一階段過渡期 9.11 1.確認團隊專案,撰寫專案初期策劃 2.前後端人員分工 已完成第二階段 9.11 10.11 1.分析專案需求 2.專案功能討論 已完成第二階段過渡期 10.12 1...

專案需求分析報告

作業鏈結 截止時間 工作內容 10.26 需求規格說明書 ui設計 11.22 站立式會議 編碼 測試 發布alpha版本 11.25 專案完善 使用者使用反饋 測試計畫改進 12.17 站立時會議 測試 編碼 發布beta版本 12.31 正式版本完善測試 使用者使用手冊 1.5正式版本發布,撰寫...