2018軟工實踐做業七之項目需求分析

時間 2019-12-13

原文原文鏈接

小白吃們的需求分析

團隊項目總體計劃安排

階段	主要任務	計劃時間	內容
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及思惟導圖

項目logo
思惟導圖

一分鐘宣傳視頻

演技max系列c++

團隊做業貢獻比

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

評審表格

想看戳我吧算法

答辯總結

答辯得分

組號	得分
1	79
2	73
3	76
4	72
5	66
6	78
7	75
8	80
9	77

最後得分：75.71分編程

問題收集與回答

第1組
一、在早上的答辯中，爲了解決誠信問題所提出的解決方法須要付出額外的人力成本進行誠信覈查，這是否會影響到項目初衷提升支付效率？小程序

答：出現誠信問題，須要誠信覈查的狀況屬於少數狀況，不會影響總體的結算效率。後端

二、若是算法識別不出菜品，以後軟件的處理邏輯是什麼？服務器

答：在服務器正常運行狀況下，不會出現識別不出菜品的狀況，若是出現極少數識別錯誤的狀況，會在項目落地實施後，若出現極少數識別錯誤的狀況，咱們會與商家協定相應處理措施。微信

三、識別算法所須要的數據集有一個收集的標準嗎？架構

答：咱們的數據集的標準：要求能夠拍攝餐盤內的全部菜品，而且同一個餐盤從菜品不一樣分佈拍攝，每種分佈100張。ide

第2組
一、會不會出現使用產品時識別不出菜品的狀況，到時候該如何解決呢？

答：在服務器正常運行狀況下，不會出現識別不出菜品的狀況，若是出現極少數識別錯誤的狀況，會在項目落地實施後，若出現極少數識別錯誤的狀況，咱們會與商家協定相應處理措施。

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

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

三、會不會出現識別菜品出錯，從而致使算錯了價格，致使用戶（包括學生和商家）的體驗變差

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

第3組
一、大家提到的在線支付容許支付寶、微信、學生卡等多方支付平臺，請問是否有考慮過可行性呢？由於我本身日常尚未碰見過在小程序裏容許支付寶支付的情形。

答：由於平臺和模式限制，咱們目前只提供微信支付的接口，基於微信支付的廣泛性，能夠知足絕大多數用戶的需求。

二、產品的推出主要是爲了方便學生羣體，可是商家可能存在直營、外賣以及使用小二結帳等多平臺致使目不暇接的狀況，如何去處理使得商家更願意使用大家的產品？

答：咱們的產品主要針對食堂的使用場景，知足商家的直營需求，而在學校的監管下經營外賣的食堂商家會愈來愈少直至沒有，因此不會存在經營目不暇接的狀況。

三、大家在數據分析中提到能夠分析出卡路里、熱量等等關乎健康的數據，但就我我的而言，這樣的數據不太能獲得個人認同，由於可信度不高，有什麼更精準更有說服力的數據分析方式嗎？

答：提供的健康數據分析，基於菜品中的食材種類給出相應的數據，但提供給用戶具備必定的參考價值。除此外，咱們會基於用戶的用餐量，提供「猜你喜歡」的推薦功能。

第4組
一、識別錯誤的後續處理是否能保證到用戶體驗呢？

答：識別錯誤勢必致使用戶體驗不佳，因此咱們在儘量減小用戶不良體驗的狀況下，會把更多精力放在提升識別準確率上。

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

答：是的，確實比較困難。目前咱們用YOLO檢測了1W張圖片，準確率在95.4%。而且還在優化中。在咱們優化模型以後，咱們有信心將準確率提升到99%。

三、產品的市場前景很是宏大，是否存在一個詳細的規程來協助產品的迭代維護呢？

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

第5組
一、大家是否有考慮到用戶使用大家的產品會出現的逃費行爲，就是買了產品不付錢，或者只拍部分的食品，這種行爲大家有考慮到如何檢測到或避免嗎？

答：逃單行爲咱們會採用攝像頭人臉識別，匹配帳戶的選餐記錄和支付記錄來作監管。對於只拍部分食品的行爲，也在咱們的考慮範圍內，但沒有很好的解決方案，但這種狀況屬於極少數，損失可彌補。

二、大家PPT給出的自選窗口菜品識別錯誤率控制在1%一下，是否有些偏高呢，畢竟涉及到商家的利益，可否再下降錯誤率，否者商家如何會選擇大家的產品呢

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

三、大家的產品主要賣點就是不用排隊，但大家是否有考慮到排隊其實是能幫助食堂消化人流，若是每一個人都不排隊的話，那麼是會出現不少人找不到座位的，並且取餐人流和取完餐回座位的人流是否會產生衝突混亂呢

答：排隊消化人流是由於食堂自己硬件限制，纔會有這樣的畸形的好處。而排隊結算點單是食堂用餐體驗的硬核需求，咱們不會爲了一粒芝麻丟掉一個西瓜。

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

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

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

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

三、你好，請問是否考慮分析用戶喜愛?

答：會根據用戶的點單量，爲用戶提供「猜你喜歡」功能。

第7組
一、請問當大量用戶沒能及時取餐，而致使有大量的餐盤堆積在商家工做區，這樣給工做人員帶來了極大的不便，大家打算怎麼解決？是否只能到商家附件才能夠點餐，仍是能夠預定點餐？

答：參考如今市場上已有的點單小程序，例如：「漢堡王」等，提供用戶位置選擇界面，讓用戶本身選擇是否到達食堂，同時也有GPS系統的定位，確保用戶到達食堂纔可點單。

二、大家軟件拍照識別支付的操做複雜度是否會大於直接掃窗口的支付寶二維碼？若是這樣對於效率的提高彷佛並非很大。

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

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

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

第9組

沒有問題

需求報告修改

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

需求規格說明書

此次戳我吧

困難及解決

困難描述

一、規格說明書規範化

二、logo以及短視頻的idea

三、驗收標準的完善

四、ppt演講的練習
作過哪些嘗試

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

二、logo參考了ofo的配色，短視頻引用了「真香系列」的思路

三、驗收標準參考了以前學長學姐們的格式，結合本身的實際來完成

四、組內有提早作ppt演練
是否解決

一、文檔規範合格

二、在老師的要求和條件限制下，作出的視頻和logo都不錯

三、驗收標準基本完善，後期會根據狀況作小的調整

四、ppt演講流暢，但還存在過度依賴演講稿的問題
有何收穫

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

二、視頻和logo的製做，讓咱們更貼近本身的項目

三、有了一套基本完善的標準，也是爲以後的完成定下了一個目標和方向

四、關於ppt演示認識到了不少細節問題，再也不一一詳述，演講展現仍需繼續改進

PSP

PSP	Personal Software Process Stages	預估耗時（分鐘）	實際耗時（分鐘）
Planning	計劃	30	45
•Estimate	•估計這個任務須要多少時間	390	545
Development	開發	0	0
•Analysis	•需求分析 (包括學習新技術)	60	60

•Design Spec	•生成設計文檔	60	60
•Design Review	•設計複審	30	45
•Coding Standard	•代碼規範(爲目前的開發制定合適的規範)	30	60
•Design	•具體設計	60	90
•Coding	•具體編碼	0	0
•Code Review	•代碼複審	0	0
•Test	•測試（自我測試，修改代碼，提交修改）	0	0
Reporting	報告	60	120
•Test Repor	•測試報告	0	0
•Size Measurement	•計算工做量	30	20
•Postmortem & Process Improvement Plan	•過後總結, 並提出過程改進計劃	30	45
	合計	780	1090