福大軟工 · 第七次作業 - 需求分析報告
阿新 • • 發佈：2018-11-04
寫在前面
組隊後的團隊專案的整體計劃安排
我們將工作流程分為前期、中期、後期來進行。
- 前期
- 通過需求調研獲取使用者喜好、需求；
- 再借助“爬蟲”、資料採集工具獲取更多我們產品所需資訊；
- 最後完成原型設計，中期與後期的軟體開發流程也會依據此原型進行。
- 中期
- 完成核心功能的演算法實現；
- 初步開發出美觀、易用的介面；
- 完成前後端、演算法三者的連線，測試產品的執行效率、結果，形成一個完整的軟體體系。
- 後期
- 通過對軟體的維護，不斷迭代更新軟體的內容並且修復潛在bug；
- 在時間允許的前提下，實現產品的附加功能。
專案logo及思維導圖
本次作業貢獻度
| 隊員 | 貢獻度 |
|---|---|
| 林燊（組長） | 8% |
| 陳俞辛 | 11% |
| 朱志豪 | 11% |
| 蔡宇航 | 12% |
| 陳柏濤 | 12% |
| 董鈞昊 | 12% |
| 劉巨集巖 | 10% |
| 盧愷翔 | 12% |
| 楊喜源 | 12% |
| 總計 | 100% |
說明：
- 由於組長生病，本次安排了較少的任務，固貢獻度較低。
- 編寫軟體需求規格說明書流程：
首先全體隊員進行開會討論明確撰寫規範和具體分工，參考了《GB9385-2008 計算機軟體需求規格說明規範》、本組商業計劃書以及學長學姐的部落格。然後分塊撰寫，具體分工如下：- 蔡宇航：引言、專案概述（功能描述）、需求分配
- 陳柏濤：類圖、驗收驗證標準
- 盧凱翔：思維導圖、問卷評估
- 需求報告撰寫 —— 蔡宇航、陳柏濤、盧愷翔
- 答辯PPT製作 —— 劉巨集巖
- 視訊拍攝 —— 朱志豪、陳俞辛
- 原型設計 —— 楊喜源、朱志豪
- 部落格撰寫 —— 陳俞辛、董鈞昊
- 上臺答辯 —— 董鈞昊
- 評審表統計 —— 陳柏濤、蔡宇航
- 專案logo —— 劉巨集巖
- 思維導圖 —— 盧愷翔
- 統籌 —— 林燊
評審表
答辯總結
評分
| 組號 | 給分 |
|---|---|
| 第一組 | 86 |
| 第二組 | 75 |
| 第三組 | 74 |
| 第四組 | 89 |
| 第五組 | 60 （???） |
| 第六組 | 77 |
| 第七組 | 69 |
| 第八組 | 78 |
| 第九組 | 89 |
平均分：78.29
提問釋疑
第一組
- 問：如果店鋪識別演算法對某些店鋪就是無法識別，是否考慮用其他方式來修復這一問題？
- 答：首先，若多次出現無法識別的店鋪，我們有提供手動輸入的形式完成資訊查詢；其次，我們會對提供申訴機制，使用者可反饋未能正確識別的商鋪位置，若是在我們規定使用範圍的商圈內，我們會重新採集資料、應用遷移學習訓練。
- 問：應用針對涵蓋吃喝玩樂的各種店鋪，是否有考慮對不同型別的店鋪做一個分類，因為不同型別的店鋪使用者需要獲取的資訊也是不同的
- 答：首先這是一個很好的提議，但這項建議更多應用於給予GPS定位的周邊推薦功能，我們的計劃書中也簡單敘述了這一點——根據使用者希望檢索到的資訊提供周邊同類型商鋪的；而相對於AR掃描識別模組，我們有提供商鋪類別資訊的。
- 問：如果識別不正確，應用會以怎樣的流程來完成後續的操作
- 答：若是返回錯誤結果，使用者可通過重新換個角度掃一掃來實現識別功能；當然，使用者也可通過申訴機制來向我們反饋資訊，如第一問所述，我們也會做適當演算法優化、調整。
第二組
- 問：你們在爬去評論或其他資訊時能否保證準確性，或是否會在進行篩選，並非每個使用使用者都會在你們產品上進行評論，你們自己累積使用者資訊週期是否需要很長時間？
- 答：相對於準確性是可以保證的，各大點評類網站也存在著篩選機制，我們自身也會設定篩選的機制；累計使用者的資訊的一個時間肯定是漫長的，但是每個軟體的盈利週期也同樣不是特別快的一件事情，我們也會提供一些優惠機制來鼓勵使用者點評。
- 問：你們產品需使用到較多且複雜的演算法，是否能夠全部實現你們介紹的功能，且能否保證演算法的穩定和正確性？
- 答：可以全部實現，我們主要應用了目標檢測以及文字識別兩個模組的演算法，足以實現本次的功能。我們也會適當擴充我們的資料集來儘可能保障結果正確性。
- 問：你們在吸引使用者和累積使用者評論資訊上的週期是否會太長，這樣的話能做到維持使用者量和盈利嗎？
- 答：軟體開始盈利的週期都是十分長的，我們也會用一些優惠機制來鼓勵使用者點評商鋪，使用者量則需要我們進一步的推廣，這一點在我們的商業計劃書中有詳細的描述，我們也會通過不斷的迭代來完善我們的功能，以此來吸引更多使用者。
第三組
- 問：店鋪名稱識別精度不低於95%感覺會有難度吧，比如怎麼找到圖裡面哪裡有字？怎麼區別店鋪名的字和其他不需要的字？怎麼區別店鋪名的字和邊上顏色相近的灰塵？
- 答：由於我們需要識別的商鋪，需在我們的資料庫內，識別的難度將會大大降低，95%以上是可行的。
- 我們之前有做過相對於的訓練、測試——首先我們按8:1:1分割資料集，再開始訓練和測試。具體測試結果如下圖所示(擴充樣本指應用多種資料增強手段擴充訓練集)
- 問：請問如果不註冊可以直接用嗎？因為我看你們的介面描述裡只有註冊和其他方式登入
- 答：我們是要求使用者註冊的，我們更希望以雲平臺的形式儲存客戶資訊，也可依據客戶的歷史喜好來完成我們的推薦功能。
- 問：獲得店鋪資訊應該比較簡單，但店鋪的使用者資訊和評論你們要如何獲得？
- 答：我們可以通過“爬蟲”來獲取，不過使用者的個人資訊可能不是不是我們要獲取的。我們僅收集我們的註冊使用者的資訊。
第四組
第五組
- 問：你們的APP一開始需要大量的店鋪資料，你們準備怎麼收集這些資料，耗時會不會很長？
- 答：收集資料時間很快的，可以藉助“爬蟲”來完成，耗時很短的。而相對於資料採集，由於沒有現成的資料，均需要實地拍攝，不過這部分的耗時也不會很長。
- 問：使用者歷史搜尋的推薦要怎麼更加精準？因為使用者很可能只是搜尋了店鋪，但是並不感興趣，這樣會不會導致推薦的時候出現偏差？
- 答：我們會記錄店鋪停留時間的來判定使用者是否感興趣，不過個人認為搜尋了店鋪但是並不感興趣這個問題本身就存在矛盾！
- 問：客服反饋這裡，你們準備怎麼做？要和眾多商家達成共識，還要長時間線上，這個工作量是比較大的，你們有什麼好的解決方法嗎？
- 答：我們團隊會設定專人輪流值班，也可以看到我們的原型設計上也有體現我們的
金牌客服。
第六組
- 問：你好，請問是否需要考慮不同使用者之間的互動？
- 答：我們實現的內容就有包括資訊分享的功能，具體可參見我們的商業計劃書。
- 問：你好，請問是否需要考慮不同模式，以及不同模式下的推薦方案？例如設定心情，且不同心情的推薦是不同的。
- 答：設計不同心情來推薦是一個很好的提議，可能需要通過應用“情感分析”等手段來完成，實現難度略高，我們會考慮有時間實現。
- 問：你好，請問當使用者在嘗試app推薦的地點後，並不滿意，該怎麼做？
- 答：並不滿意的話，使用者可以選擇給個差評，這樣我們便會記錄下資訊以便於我們下一次推薦。不過推薦機制本身就存在著誤推薦的可能性，是很難避免的，我們則更著重於後續的處理。
第七組
- 問：對店鋪資訊獲取問題的補充：除了爬取資料和人工輸入（個人感覺比較麻煩）這兩個方法之外，是否考慮過製作一個專門提供給商家的版本，讓商家自己填寫相關資訊？
- 答：首先，專案初期是很難完成與全部商家的協商的，當然擁有資金的供應也是可以完成的，但就實際一些來看，我們這個軟工實踐所需要做出的專案更多的資料獲取方式難道不是“爬蟲”+人工來解決嗎？其次，我們實現的主要功能也是人工智慧相關的，沒有人工標註的資料集，我們是很難保證演算法的可靠性的；最後，商家的版本這一點，我們更希望作為一個前景展望來做，這一點在我們的商業計劃書中有所提及。
- 問：請問你們是否有考慮過產品做出來後店鋪的覆蓋率能達到什麼程度？
- 答：我們初步考慮覆蓋永嘉這一區域，後續的覆蓋區域會隨著產品規模逐步擴大。
- 問：請問你們原型圖上的“今日推薦”裡面的內容是以什麼為標準來推薦的？真實有效嗎？
- 答：以使用者的歷史喜好以及當前的定位結果來推薦的，真實有效！
第八組
- 問：對於刷贊或者刷評論這樣的有什麼措施解決嗎？
- 答：我們也會考慮提供篩選功能來解決，此類問題解決難度較高。
- 問：有試驗過在晚上或者在天氣狀況不太好的情況下，識別店鋪的準確率嘛？
- 答：我們有通過神經風格遷移來擴充更多場景下的資料集，這樣也可以提高我們的正確率，具體的試驗還沒有測試，但是兩個模組也已經完成。
- 問：如何盈利？
- 答：可以通過廣告等形式來完成盈利，具體規劃可參見我們的商業計劃書。
第九組
- 截至部落格撰寫（2018/11/4 15:30）尚未提問
需求報告修改之處
根據答辯中柯逍老師提出的建議，對需求規格說明書的格式做出了修改：
- 正文文字字型放大一號
- 行距由1倍調整至1.5倍
- 將文字內容設定為兩端對齊
- 調整段間距使各處段間距均勻。
需求報告最終版本
遇到的困難及解決方法
困難1
- 困難描述
- 本次作業雖然由於校慶延後了一週，但是組內部分同學作為學生幹部反而有更多的事情要做。正值學院的迎新晚會籌備中以及第九周我們開始了電氣工程實踐並且週六（11.3）是Linux作業系統實踐課程的期末大作業提交時間，全組同學都忙的焦額爛頭。尤其是原型設計組，志豪同學的事情更多。所以我們遇到的困難之一便是時間不夠用。
- 做過哪些嘗試
- 我們試著把自己當作一個“多核處理器”，合理的規劃時間。並且在分工時， 部分事情較少的同學主動站了出來承擔了任務。
- 是否解決
- 是
- 有何收穫
- 增強了我們團隊的凝聚力以及很好的推進了我們的貢獻度分配原則（具體如何體現可以看我們的本次作業貢獻度分配說明）
困難2
- 困難描述
- 本次作業要求完成一份需求分析報告，組內同學們都沒有經驗要如何撰寫，開始時有些不知所措，無從下手。開了多次會都沒能取得實質性的進展。
- 做過哪些嘗試
- 我們認真閱讀了作業中給出的 checklist，然後請教了之前的學長學姐其中包括曾經擔任過這門課的助教。也閱讀了一些前輩的報告，最終形成了一份框架，然後只需要將其填充就好了。
- 是否解決
- 是
- 有何收穫
- 瞭解了一份完整的需求分析報告應該包括哪些內容。以及需求分析報告的目標人群是誰，文字應該如何組織才能夠達到寫這份報告的目的。
PSP
| PSP2.1 | Personal Software Process Stages | 預估耗時（分鐘） | 實際耗時（分鐘） |
|---|---|---|---|
| Planning | 計劃 | 40 | 30 |
| · Estimate | · 估計這個任務需要多少時間 | 40 | 30 |
| Development | 開發 | 540 | 675 |
| · Analysis | · 需求分析 (包括學習新技術) | 60 | 80 |
| · Design Spec | · 生成設計文件 | 20 | 30 |
| · Design Review | · 設計複審 | 30 | 20 |
| · Coding Standard | · 程式碼規範 (為目前的開發制定合適的規範) | 30 | 30 |
| · Design | · 具體設計 | 60 | 70 |
| · Coding | · 具體編碼 | 300 | 360 |
| · Code Review | · 程式碼複審 | 30 | 50 |
| · Test | · 測試（自我測試，修改程式碼，提交修改） | 30 | 60 |
| Reporting | 報告 | 85 | 130 |
| · Test Repor | · 測試報告 | 60 | 90 |
| · Size Measurement | · 計算工作量 | 10 | 5 |
| · Postmortem & Process Improvement Plan | · 事後總結, 並提出過程改進計劃 | 10 | 15 |
| 合計 | 680 | 820 |
學習進度條
| 第N周 | 新增程式碼(行) | 累計程式碼(行) | 本週學習耗時(小時) | 累計學習耗時(小時) | 重要成長 |
|---|---|---|---|---|---|
| 1 | 72 | 72 | 5 | 5 | map 容器的效能瓶頸分析 |
| 2 | 508 | 580 | 7 | 13 | 完成基本功能的實現及附加功能的構思 |
| 3 | 149 | 729 | 6 | 19 | 學習 python 中與附加功能相關的庫，例如 wordcloud |
| 4 | 0 | 729 | 5 | 24 | 學會需求分析報告的撰寫 |
| 5 | 0 | 729 | 7 | 31 | 學會了簡單的視訊剪輯 |