福大軟工 · 第七次作業 - 需求分析報告

小白吃們的需求分析

hjj的坐标

目錄

• 項目整體計劃安排
• 項目logo及思維導圖
• 一分鐘宣傳視訊
• 團隊作業貢獻比
• 評審表格
• 答辯總結
• 需求報告改進
• 需求規格說明書
• 困難及解決
• PSP
• 學習進度條

團隊項目整體計劃安排

階段	主要任務	計劃時間	内容
1	項目選題	18.09.27—18.10.12	項目選擇，經市場調研并與老師溝通後确定選題
2	需求分析	18.10.13—18.11.04	完成需求規格說明書
3	設計分工	18.11.04—18.11.11	項目詳細分工，代碼規範，平台環境基本架構，界面初步美化設計，視覺識别算法完善
4	子產品程式設計及對接	18.11.11—18.11.23	後端伺服器搭建完成，界面互動完全實作，各子產品編碼基本完成後，進行對接
5	測試	18.11.24—18.12.07	d對alpha版本進行應用測試，根據測試結果确定beta版本優化内容
6	優化完善	18.12.07—18.12.21	根據上一階段測試回報内容，對項目進行進一步優化改善，形成正式版本
7	項目實施	18.12.21—19.01.08	争取在實際場景中能夠試點實施，投入營運

• 項目logo

  

• 思維導圖

  

[演技max系列]（https://www.bilibili.com/video/av35306211）

成員	分工	貢獻比
葛亮	原型優化	14%
文斌	視訊剪輯+評審表設計
黃澤	報告整理、規範+視訊演員	15%
靜茹	視訊idea+視訊演員+答辯記錄
敬甲	logo+思維導圖+功能描述+部落格整理
澤明	功能驗收标準
劉浩	ppt制作演講

想看戳我吧

• 答辯得分

組号	得分
	79
	73
	76
	72
	66
	78
	75
8	80
9	77

最後得分：75.71分

• 問題收集與回答

第1組

1、在早上的答辯中，為了解決誠信問題所提出的解決方法需要付出額外的人力成本進行誠信核查，這是否會影響到項目初衷提高支付效率？

​ 答：出現誠信問題，需要誠信核查的情況屬于少數情況，不會影響整體的結算效率。

2、如果算法識别不出菜品，之後軟體的處理邏輯是什麼？

​ 答：在伺服器正常運作情況下，不會出現識别不出菜品的情況，如果出現極少數識别錯誤的情況，會在項目落地實施後，若出現極少數識别錯誤的情況，我們會與商家協定相應處理措施。

3、識别算法所需要的資料集有一個收集的标準嗎？

答：我們的資料集的标準：要求可以拍攝餐盤内的所有菜品，并且同一個餐盤從菜品不同分布拍攝，每種分布100張。
           

第2組

1、會不會出現使用産品時識别不出菜品的情況，到時候該如何解決呢？

2、消費者的信用問題該如何得到更好的解決？

​ 答：以項目投入使用前的宣傳手段和信用支付監管手段共同完善對信用問題的解決。

3、會不會出現識别菜品出錯，進而導緻算錯了價格，導緻使用者（包括學生和商家）的體驗變差

​ 答：算法的置信度現已達到95.4%以上，在投入使用前會達到99%以上，識别錯誤機率極低。在項目落地實施後，若出現極少數識别錯誤的情況，我們會與商家協定相應處理措施。

第3組

1、你們提到的線上支付允許支付寶、微信、學生卡等多方支付平台，請問是否有考慮過可行性呢？因為我自己平常還沒有遇見過在小程式裡允許支付寶支付的情形。

​ 答：因為平台和模式限制，我們目前隻提供微信支付的接口，基于微信支付的普遍性，可以滿足絕大多數使用者的需求。

2、産品的推出主要是為了友善學生群體，但是商家可能存在直營、外賣以及使用小二結賬等多平台導緻應接不暇的情況，如何去處理使得商家更願意使用你們的産品？

​ 答：我們的産品主要針對食堂的使用場景，滿足商家的直營需求，而在學校的監管下經營外賣的食堂商家會越來越少直至沒有，是以不會存在經營應接不暇的情況。

3、你們在資料分析中提到可以分析出卡路裡、熱量等等關乎健康的資料，但就我個人而言，這樣的資料不太能得到我的認同，因為可信度不高，有什麼更精準更有說服力的資料分析方式嗎？

​ 答：提供的健康資料分析，基于菜品中的食材種類給出相應的資料，但提供給使用者具有一定的參考價值。除此外，我們會基于使用者的用餐量，提供“猜你喜歡”的推薦功能。

第4組

1、識别錯誤的後續處理是否能保證到使用者體驗呢？

​ 答：識别錯誤勢必導緻使用者體驗不佳，是以我們在盡可能減少使用者不良體驗的情況下，會把更多精力放在提高識别準确率上。

2、識别錯誤率控制在1%以下是十分困難的一件事，如果是基于速度快的YOLO算法的目标檢測來完成，是否在準确性方面達到的效果不會特别好呢？

答：是的，确實比較困難。目前我們用YOLO檢測了1W張圖檔，準确率在95.4%。并且還在優化中。在我們優化模型之後，我們有信心将準确率提高到99%。
           

3、産品的市場前景非常宏大，是否存在一個詳細的規程來協助産品的疊代維護呢？

​ 答：暫時沒有，精力有限，能力有限，放眼當下。

第5組

1、你們是否有考慮到使用者使用你們的産品會出現的逃費行為，就是買了産品不付錢，或者隻拍部分的食品，這種行為你們有考慮到如何檢測到或避免嗎？

​ 答：逃單行為我們會采用攝像頭人臉識别，比對賬戶的選餐記錄和支付記錄來做監管。對于隻拍部分食品的行為，也在我們的考慮範圍内，但沒有很好的解決方案，但這種情況屬于極少數，損失可彌補。

2、你們PPT給出的自選視窗菜品識别錯誤率控制在1%一下，是否有些偏高呢，畢竟涉及到商家的利益，能否再降低錯誤率，否者商家如何會選擇你們的産品呢

答：不會偏高，技術雖好也有瓶頸和天花闆。識别錯誤率控制得極低，也有相應的回報機制，在這兩個前提下，即便有錯誤和損失，成本也極低，在給商家帶來足夠的利益的前提下，商家能夠接受這樣的額外成本。

3、你們的産品主要賣點就是不用排隊，但你們是否有考慮到排隊實際上是能幫助食堂消化人流，如果每個人都不排隊的話，那麼是會出現很多人找不到座位的，而且取餐人流和取完餐回座位的人流是否會産生沖突混亂呢

答： 排隊消化人流是因為食堂本身硬體限制，才會有這樣的畸形的好處。而排隊結算點單是食堂用餐體驗的硬核需求，我們不會為了一粒芝麻丢掉一個西瓜。

第6組

1、你好，請問原型登陸頁面老師、學生登入按鈕不夠清晰，原型不夠美觀，有考慮改進嗎？

​ 答：現有原型主要為了展現項目邏輯，美觀度會在項目實施時改進。

2、你好，請問視訊背景音樂太過嘈雜，是否考慮改進？

答：會在上傳到b站時使用強降噪改進。
           

3、你好，請問是否考慮分析使用者喜好?

​ 答：會根據使用者的點單量，為使用者提供“猜你喜歡”功能。

第7組

1、請問當大量使用者沒能及時取餐，而導緻有大量的餐盤堆積在商家工作區，這樣給從業人員帶來了極大的不便，你們打算怎麼解決？是否隻能到商家附件才可以點餐，還是可以預約點餐？

​ 答：參考現在市場上已有的點單小程式，例如：“漢堡王”等，提供使用者位置選擇界面，讓使用者自己選擇是否到達食堂，同時也有GPS系統的定位，確定使用者到達食堂才可點單。

2、你們軟體拍照識别支付的操作複雜度是否會大于直接掃視窗的支付寶二維碼？如果這樣對于效率的提升似乎并不是很大。

​ 答：拍照支付的位置是在座位上，二維碼是在視窗前，即便操作複雜度相同，也是更好的體驗。

3、請問你們調查過商家願意使用你們産品的比例嗎？當商家使用的比率不高的時候，你們打算怎麼說服商家？

​ 答：沒有調查過。宣傳和合作方式有很多種，不是技術層面簡單明了，涉及到人的意願的問題，總是複雜的，也總是有解決辦法的。

第9組

沒有問題

需求報告修改

根據其他組的意見和建議，沒有需要修改的地方。

這次戳我吧

• 困難描述

  1、規格說明書規範化

  2、logo以及短視訊的idea

  3、驗收标準的完善

  4、ppt演講的練習

• 做過哪些嘗試

  1、在網上查找比較好的一整套文檔規範，并寫入文檔

  2、logo參考了ofo的配色，短視訊引用了“真香系列”的思路

  3、驗收标準參考了之前學長學姐們的格式，結合自己的實際來完成

  4、組内有提前做ppt演練

• 是否解決

  1、文檔規範合格

  2、在老師的要求和條件限制下，做出的視訊和logo都不錯

  3、驗收标準基本完善，後期會根據情況做小的調整

  4、ppt演講流暢，但還存在過分依賴演講稿的問題

• 有何收獲

  1、學習到了比較好的文檔規範

  2、視訊和logo的制作，讓我們更貼近自己的項目

  3、有了一套基本完善的标準，也是為之後的完成定下了一個目标和方向

  4、關于ppt示範認識到了很多細節問題，不再一 一詳述，演講展示仍需繼續改進

	Personal Software Process Stages	預估耗時（分鐘）	實際耗時（分鐘）
Planning	計劃	30	45
•Estimate	•估計這個任務需要多少時間	390	545
Development	開發
•Analysis	•需求分析 (包括學習新技術)	60
•Design Spec	•生成設計文檔
•Design Review	•設計複審
•Coding Standard	•代碼規範(為目前的開發制定合适的規範)
•Design	•具體設計		90
•Coding	•具體編碼
•Code Review	•代碼複審
•Test	•測試（自我測試，修改代碼，送出修改）
Reporting	報告		120
•Test Repor	•測試報告
•Size Measurement	•計算工作量		20
•Postmortem & Process Improvement Plan	•事後總結, 并提出過程改進計劃
合計	780	1090

第N周	新增代碼（行）	累計代碼（行）	本周學習耗時（小時）	累計學習耗時（小時）	重要成長
5.6	420	640		32	學習python語言，可以簡單的爬取網頁的一些東西，對HTML語言也有了一丢丢的了解，可以對資料進行簡單的一些可視化處理
	270	910	10	42	學習python，推薦算法，決策樹等