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

hjj的座標

階段主要任務

計畫時間內容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

爭取在實際場景中能夠試點實施，投入運營

演技max系列

成員分工

貢獻比葛亮

原型優化

14%文斌

14%黃澤

15%靜茹

14%敬甲

logo+思維導圖+功能描述+部落格整理

14%澤明

功能驗收標準

14%劉浩

ppt製作演講

15%想看戳我吧

組號得分179

273376

472566

678775

880977

最後得分：75.71分

第1組

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

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

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

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

3、識別演算法所需要的資料集有乙個收集的標準嗎？

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

第2組

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

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

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

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

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

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

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

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

第4組

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

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

3、產品的市場前景非常巨集大，是否存在乙個詳細的規程來協助產品的迭代維護呢？

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

第5組

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

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

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

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

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

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

第6組

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

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

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

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

第7組

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

2、你們軟體拍照識別支付的操作複雜度是否會大於直接掃視窗的支付寶***？如果這樣對於效率的提公升似乎並不是很大。

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

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

第9組

沒有問題

這次戳我吧

psp

personal software process stages

預估耗時（分鐘）

實際耗時（分鐘）

planning

計畫30

45•estimate

•估計這個任務需要多少時間

390545

development開發0

0•analysis

•需求分析 (包括學習新技術)

6060

•design spec

•生成設計文件

6060

•design review

•設計複審

3045

•coding standard

•**規範(為目前的開發制定合適的規範)

3060

•design

•具體設計

6090

•coding

•具體編碼00

•code review

•**複審00

•test

•測試（自我測試，修改**，提交修改）00

reporting

報告60

120•test repor

•測試報告00

•size measurement

•計算工作量

3020

•postmortem & process improvement plan

•事後總結, 並提出過程改進計畫

3045

合計780

1090

第n周新增**（行）

累計**（行）

本週學習耗時(小時)

累計學習耗時（小時）

重要成長

1500

50025

251熟悉了c++有關vector,map用法 2學習了正規表示式 3學習了狀態轉換圖和有窮自動機250

5508

33看了有關軟體的使用，原型模型以及構建之法

3600

1350

4881

修煉心性，debug能力有提公升，心理素質加強= =90

1350586

感覺這周過於鬆弛= =，後面要狠命還了

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

我們將工作流程分為前期 中期 後期來進行。中期後期 隊員貢獻度 林燊 組長 8 陳俞辛 11 朱志豪 11 蔡宇航 12 陳柏濤 12 董鈞昊 12 劉巨集巖 10 盧愷翔 12 楊喜源 12 總計 100 說明 需求報告撰寫 蔡宇航 陳柏濤 盧愷翔 答辯ppt製作 劉巨集巖 原型設計 楊喜源 朱志...

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

我們將工作流程分為前期 中期 後期來進行。中期後期 隊員貢獻度 林燊 組長 8 陳俞辛 11 朱志豪 11 蔡宇航 12 陳柏濤 12 董鈞昊 12 劉巨集巖 10 盧愷翔 12 楊喜源 12 總計 100 說明 需求報告撰寫 蔡宇航 陳柏濤 盧愷翔 答辯ppt製作 劉巨集巖 原型設計 楊喜源 朱志...

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

階段主要任務 時間任務內容 1專案選題 09.22 10.10 確定選題內容，收集使用者需求，明確定位，競品分析，選題報告 2需求分析 10.11 11.43團隊 11.5 11.10 團隊整改，原型改進，確定編碼，加強團隊協作 4alpha衝刺 11.11 11.23 完成專案核心 一期 功能，準...