前言

• 本次作業鏈接
• 組長博客鏈接
• 宣傳視頻鏈接

項目logo及思維導圖

項目logo

• 項目Logo設計思路：我們的項目基於福州大學的各個食堂展開服務，所以我們的圖標是一個抽象的碗，碗由字母“J”和“S”（即食的拼音縮寫）組成，色調使用了相近的兩種橙色，整個logo意在使得用戶一看到我們的圖標就聯想到熱鬧的食堂並與我們的app名產生聯系。

• 思維導圖

組隊後的團隊項目的整體計劃安排

隊員本次作業貢獻比例

撰寫需求規格說明書的分工

答辯總結

小組得分

• 去掉一個最高分，去掉一個最低分，小組最終得分為77分

問題匯總

第二組的提問：

-? 問題1：用戶一開始使用怎麽能最快得知其口味喜好並進行正確的推薦，推薦的正確性如何保證？

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

-? 問題2：關於推薦到菜品如果是自選類，能否進行正確的推薦且保證大部分自選都符合用戶的口味？

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

-? 問題3：如何更大程度吸引用戶選擇你們的產品？

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

第三組的提問：

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

-? 答：是的，將各家不同的菜品進行口味量化是我們的項目無法避免的一部分，也是推薦的可信度的保障，所以我們在項目初期已經對各個食堂的菜品進行錄入與分析。

-? 問題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：

-? 答：

修改完善本組需求分析報告

• 新增推薦算法驗收標準

• 新增對項目的可維護性要求

• 格式審查:去除首頁的頁碼

《需求規格說明書》附件

需求規格說明書

評審表格設計

評審表格下載

遇到的困難及解決辦法

• 困難描述

  對於制作類圖和思維導圖沒有經驗，書寫需求說明書沒有經驗

• 做過哪些嘗試

  上網學習，跟有經驗的同學交流學習，自己慢慢嘗試制作

• 是否解決

  是

• 有何收獲

  學習了如何制作類圖，思維導圖。掌握了繪圖工具的使用，了解了軟件需求說明書的書寫格式

PSP

學習進度條

需求分析報告