前言

• 本次作業連結
• 組長部落格連結
• 宣傳視訊連結

專案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