# 需求分析報告
前言
項目logo及思惟導圖
項目logo
- 項目Logo設計思路：咱們的項目基於福州大學的各個食堂展開服務，因此咱們的圖標是一個抽象的碗，碗由字母「J」和「S」（即食的拼音縮寫）組成，色調使用了相近的兩種橙色，整個logo意在使得用戶一看到咱們的圖標就聯想到熱鬧的食堂並與咱們的app名產生聯繫。
- 思惟導圖
組隊後的團隊項目的總體計劃安排
| 階段 | 主要任務 | 計劃時間 | 內容 |
|---|---|---|---|
| 1 | 項目選題 | 2018.09.27-2018.10.12 | 肯定選題，完成項目的市場調研和競品分析，指定推廣戰略 |
| 2 | 需求分析 | 2018.10.20-2018.11.04 | 編寫需求說明書 |
| 3 | 編碼規範 | 2018.11.05-11.11 | 完成接口規定、編碼規範、編碼環境搭建 |
| 4 | Alpha衝刺 | 2018.11.11-2018.11.23 | 完成項目的核心功能開發、先後端對接 |
| 5 | 改進總結調整 | 2018.11.24-12.07 | 項目完善、用戶試用反饋、測試計劃改進 |
| 6 | Beta衝刺 | 2018.12.13-2018.12.21 | 完成附加功能的開發以及根據用戶反饋改進 |
隊員本次做業貢獻比例
| 姓名 | 比例（%） | 完成工做 |
|---|---|---|
| 王彬 | 14 | 視頻拍攝、界面原型設計、logo設計 |
| 趙暢 | 10 | 類圖設計、Word彙總、思惟導圖彙總 |
| 李恆達 | 12 | 思惟導圖、視頻拍攝、驗收標準撰寫 |
| 胡展瑞 | 12 | 驗收標準撰寫、PPT製做、視頻製做 |
| 王源 | 12 | 類圖設計、思惟導圖、食堂平面圖設計 |
| 佘嶽昕 | 10 | 驗收標準撰寫、思惟導圖 |
| 陳志煒 | 10 | 功能描述撰寫、思惟導圖 |
| 陳文垚 | 10 | 引言編寫、思惟導圖 |
| 林煌偉 | 10 | 類圖設計、思惟導圖 |
撰寫需求規格說明書的分工
答辯總結
小組得分
- 去掉一個最高分，去掉一個最低分，小組最終得分爲77分
| 組號 | 組名 | 打分 |
|---|---|---|
| 1 | 爸爸餓了隊 | 81 |
| 2 | 拖鞋旅遊隊 | 78 |
| 3 | 彳艮彳亍隊 | 79 |
| 4 | 火箭少男100 | 76 |
| 5 | 起牀一塊兒肝活隊 | 60 |
| 6 | 404 Note Found隊 | 71 |
| 7 | 第三視角 | 78 |
| 8 | 小白吃 | 78 |
| 9 | 我頭髮呢隊 | 79 |
問題彙總
第二組的提問：
- 問題1：用戶一開始使用怎麼能最快得知其口味喜愛並進行正確的推薦，推薦的正確性如何保證？html
- 答：咱們的推薦是創建在用戶使用軟件的當時口味偏好進行推薦的，此外在軟件開發初期，咱們會積極嘗試可能的算法來達到咱們對推薦精確度的要求，初步調查後，隨機森林、kNN等線性迴歸算法在咱們的考慮範圍內， 咱們在項目計劃書中，以及現場PPT展現中都明確闡述了咱們的軟件是基於用戶使用時對3-4道布爾選擇題的選擇來衡量用戶的口味。算法
- 問題2：關於推薦到菜品若是是自選類，可否進行正確的推薦且保證大部分自選都符合用戶的口味？數據庫
- 答：在團隊選題報告答辯中咱們就回答過，自選窗口存在每日菜單變更的問題，這一客觀侷限使得咱們並不打算向用戶推薦自選檔口的菜品，不過如今在考慮面對自選檔口時只推薦檔口的招牌菜的作法的可行性。小程序
- 問題3：如何更大程度吸引用戶選擇大家的產品？後端
- 答：這個問題咱們在團隊選題報告的項目推廣中已經有了全面且清晰的闡述。app
第三組的提問：
- 問題1：每家店鋪都有不一樣的菜品,若是須要細化菜品的話是否須要大量的調查ide
- 答：是的，將各家不一樣的菜品進行口味量化是咱們的項目沒法避免的一部分，也是推薦的可信度的保障，因此咱們在項目初期已經對各個食堂的菜品進行錄入與分析。性能
- 問題2：對於學生街以及食堂來講不少店鋪都在不停的更換,如何及時的更新店鋪數量,須要維護人員按期的調查嗎學習
- 答：咱們目前只針對福大的各個食堂展開咱們的服務，按照經驗來看，食堂大部分的店鋪並不會進行頻繁的菜品輪換，但對店鋪及其菜品的維護也是須要定時進行測試
- 問題3：如何保證評價的可信程度,若是是別的商家惡意評論或者是水軍好評該如何解決？
- 答：咱們的用戶評價更多的是用戶對店鋪的意見和建議，且咱們也不打算提早開發產品的社交屬性，在產品上線後得試運行期間咱們會注意惡意差評得狀況是否出現，並對此採起相應措施
第四組的提問：
- 問題1：請問推薦的準確性如何保證呢？僅採用簡單的線性迴歸雖然效率高可是很難評估準確性。
- 答：咱們在項目需求答辯中已經闡述了咱們對推薦算法的驗收標準，咱們會在訓練模型時努力達成咱們的目標
- 問題2：產品的適用推薦範圍是多大呢？
- 答：咱們的推薦範圍框定在福州大學各個食堂的非自選檔口的菜品中，針對自選檔口也可能會採起推薦檔口特點菜品的方式。
- 問題3：產品是否存在按期的迭代規程？
- 答：感謝您的建議與提醒，咱們已在項目需求計劃書中補上這部份內容
第五組的提問：
- 問題1：有沒有可能出現重複推薦了相同的店可是用戶並不喜歡卻沒法屏蔽的現象？
- 答：咱們在原型設計中就已經考慮到這個問題，當用戶對當前的推薦不滿意時用戶能夠要求程序給出其餘推薦，二被否決的推薦在日後的推薦結果中的權重會相應減少
- 問題2：遇到多人出行不知道吃什麼的時候這款軟件還能適用嘛？
- 答：如何使用本款軟件是用戶的自由，咱們會盡力保證應用自己功能的易用性
- 問題3：關於大家組的logo，與嘀嘀打車的有些類似（塗上色就差很少了），後期有考慮進行修改避嫌麼
- 答：在咱們看來二者差別十分明顯
第六組的提問：
- 問題1：請問用戶的口味細化大家打算怎麼作到？
- 答：咱們經過用戶獲取推薦菜品前作的4道與非選擇題來獲知用戶當下的口味偏好，並做爲咱們推薦的依據
- 問題2：請問軟件推廣過程打算作出什麼努力？
- 答：這部分咱們在項目選題報告中的推廣方式部分已經作出充分詳細的闡述。
- 問題3：如何突顯產品競爭優點吸引用戶
- 答：咱們的產品在一開始的定位就將目標人羣設置爲FZU在校大學生，將使用場景設定在大學食堂的範圍，目標清晰，需求明確。市面上存在一些相似菜品推薦的小程序或APP，但它們的核心都是隨機推薦菜名而沒有綜合考慮用戶需求，也沒有結合所在地區的商鋪進行本地化。此外現階段的類大衆點評軟件的應用理念和操做邏輯基本大同小異，都是根據用戶的地理位置給出附近區域的餐廳推薦，但卻沒有進一步深刻達到某一菜品級別的推薦。以上就是咱們的軟件的競爭優點。
第七組的提問：
- 問題1：請問」用戶分析報告「中「總營業額」、「周客源數」、「支付筆數」大家要怎麼獲取？並非使用大家的產品推薦菜品而且點擊了」帶我去「，或者評論了，就能肯定他爲這道菜品消費了啊
- 答：這是咱們的產品原型對後期產品可能的產品形態的一種展望，爲了達成這個目標，咱們須要打通支付方式、食堂商家的中間道路，因此在產品開發初期，問題中提到的統計信息暫時沒法上線，在先期的開發中咱們會將精力主要集中在普通用戶端的開發與推薦算法的完善，若是產品運行穩定再向咱們的遠期產品願景努力。
- 問題2：請問大家怎們確保推薦的菜餚就是用戶適合的？怎們肯定及斷定用戶的口味及喜好？
- 答：用戶對推薦菜品是否滿意是一個主觀問題，咱們所能作的就是儘可能保證推薦算法的客觀合理性。對用戶口味的斷定是經過用戶每次獲取推薦前的4道布爾選擇題來獲取的，以後咱們的推薦算法會根據用戶的選擇推薦出最可能得到用戶青睞的菜餚
- 問題3：請問大家怎們保證菜品推薦的真是可靠？菜品推薦應該是要基於大量的用戶，請問大家前期推廣打算怎麼吸引用戶？
- 答：咱們推薦的菜品都是經過到食堂實地採集相應的數據並錄入到咱們的數據庫中，因此推薦的菜品都是真實可靠的。關於產品推廣，咱們已經在以前的項目選題報告中的推廣方式部分作出明確詳細的闡述。
第八組的提問：
- 問題1：商家端管理是否須要配備硬件，仍是說只要用手機就行？
- 答：商家端的應用會基於Web端提供服務，由於分析報告內容多樣，採用Web端展現更方便用戶瀏覽。
- 問題2：關於ppt的講解，老師是建議說讓上次沒有參與的非pm的優先，爲何仍是pm講解的？
- 答：由於此次答辯是關於整個軟件的總體方向的報告，PM參與了項目需求報告的撰寫、PPT的製做、宣傳視頻的製做，對此次項目有更全面的認識，因此此次PPT演講依然由PM承擔，在以後深刻到技術層面的演講中會優先讓其餘組員承擔演講任務。
- 問題3：對於推薦算法的那一部分，要作到花費時間少和匹配相對準確，真的能有相對較好的平衡嘛？
- 答：算法的時間複雜度與其準確性之間並無直接的關係，咱們指定了相應的驗收標準對咱們的推薦算法的性能表現進行衡量，確保推薦算法的準確性和運行速度達到應用的要求。
第九組的提問（暫無）：
- 問題1：
- 答：
- 問題2：
- 答：
- 問題3：
- 答：
修改完善本組需求分析報告
- 新增推薦算法驗收標準
- 新增對項目的可維護性要求
- 格式審查:去除首頁的頁碼
《需求規格說明書》附件
評審表格設計
遇到的困難及解決辦法
此次遇到的困難主要有兩個：
- 製做視頻的IDEA
- 驗收標準的撰寫
解決的辦法：
- 組長常年逛B站，提供了幾個潮流的視頻樣本，以及本身邊作視頻邊出現的想法
- 驗收標準參考了國家的標準，以及學習了前面其餘學長的經驗
PSP
| PSP2.1 | Personal Software Process Stages | 預估耗時（分鐘） | 實際耗時（分鐘） |
|---|---|---|---|
| Planning | 計劃 | ||
| · Estimate | · 估計這個任務須要多少時間 | 5 | 5 |
| Development | 開發 | ||
| · Analysis | · 需求分析 (包括學習新技術) | 30 | 30 |
| · Design Spec | · 生成設計文檔 | 35 | 50 |
| · Design Review | · 設計複審 | 12 | 15 |
| · Coding Standard | · 代碼規範 (爲目前的開發制定合適的規範) | 15 | 15 |
| · Design | · 具體設計 | 15 | 15 |
| · Coding | · 具體編碼 | 0 | 0 |
| · Code Review | · 代碼複審 | 0 | 0 |
| · Test | · 測試（自我測試，修改代碼，提交修改） | 0 | 0 |
| Reporting | 報告 | ||
| · Test Repor | · 測試報告 | 30 | 60 |
| · Size Measurement | · 計算工做量 | 5 | 5 |
| · Postmortem & Process Improvement Plan | · 過後總結, 並提出過程改進計劃 | 5 | 5 |
| 合計 | 140 | 200 |
- 1. 需求分析報告
- 2. 需求文檔、需求分析報告、需求規格說明書分析
- 3. 團隊項目-需求分析報告
- 4. 期末項目需求分析報告
- 更多相關文章...
- • TCP報文格式解析 - TCP/IP教程
- • PHP 表單 - 必需字段 - PHP教程
- • Git五分鐘教程
- • 算法總結-二分查找法
-
每一个你不满意的现在，都有一个你没有努力的曾经。