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

寫在前面

• 技術最強組的組長部落格
• 不用看也知道的作業
• 男主女主顔值爆表的使用者使用場景視訊

組隊後的團隊項目的整體計劃安排

我們将工作流程分為前期、中期、後期來進行。

• 前期
  • 通過需求調研擷取使用者喜好、需求；
  • 再借助“爬蟲”、資料采集工具擷取更多我們産品所需資訊；
  • 最後完成原型設計，中期與後期的軟體開發流程也會依據此原型進行。
• 中期
  • 完成核心功能的算法實作；
  • 初步開發出美觀、易用的界面；
  • 完成前後端、算法三者的連接配接，測試産品的運作效率、結果，形成一個完整的軟體體系。
• 後期
  • 通過對軟體的維護，不斷疊代更新軟體的内容并且修複潛在bug；
  • 在時間允許的前提下，實作産品的附加功能。

項目logo及思維導圖

• 項目logo高清大圖點我點我

  

• 思維導圖高清大圖點我點我

  

本次作業貢獻度

隊員	貢獻度
林燊（組長）	8%
陳俞辛	11%
朱志豪
蔡宇航	12%
陳柏濤
董鈞昊
劉宏岩	10%
盧恺翔
楊喜源
總計	100%

說明：

• 由于組長生病，本次安排了較少的任務，固貢獻度較低。

• 編寫軟體需求規格說明書流程：

  首先全體隊員進行開會讨論明确撰寫規範和具體分工，參考了《GB9385-2008 計算機軟體需求規格說明規範》、本組商業計劃書以及學長學姐的部落格。然後分塊撰寫，具體分工如下：

  • 蔡宇航：引言、項目概述（功能描述）、需求配置設定
  • 陳柏濤：類圖、驗收驗證标準
  • 盧凱翔：思維導圖、問卷評估
• 需求報告撰寫 —— 蔡宇航、陳柏濤、盧恺翔
• 答辯PPT制作 —— 劉宏岩
• 視訊拍攝 —— 朱志豪、陳俞辛
• 原型設計 —— 楊喜源、朱志豪
• 部落格撰寫 —— 陳俞辛、董鈞昊
• 上台答辯 —— 董鈞昊
• 評審表統計 —— 陳柏濤、蔡宇航
• 項目logo —— 劉宏岩
• 思維導圖 —— 盧恺翔
• 統籌 —— 林燊

評審表

• 沒什麼好看的評審表

答辯總結

評分

組号	給分
第一組	86
第二組	75
第三組	74
第四組	89
第五組	60 （???）
第六組	77
第七組	69
第八組	78
第九組

平均分：78.29

提問釋疑

• 問：如果店鋪識别算法對某些店鋪就是無法識别，是否考慮用其他方式來修複這一問題？
• 答：首先，若多次出現無法識别的店鋪，我們有提供手動輸入的形式完成資訊查詢；其次，我們會對提供申訴機制，使用者可回報未能正确識别的商鋪位置，若是在我們規定使用範圍的商圈内，我們會重新采集資料、應用遷移學習訓練。
• 問：應用針對涵蓋吃喝玩樂的各種店鋪，是否有考慮對不同類型的店鋪做一個分類，因為不同類型的店鋪使用者需要擷取的資訊也是不同的
• 答：首先這是一個很好的提議，但這項建議更多應用于給予GPS定位的周邊推薦功能，我們的計劃書中也簡單叙述了這一點——根據使用者希望檢索到的資訊提供周邊同類型商鋪的；而相對于AR掃描識别子產品，我們有提供商鋪類别資訊的。
• 問：如果識别不正确，應用會以怎樣的流程來完成後續的操作
• 答：若是傳回錯誤結果，使用者可通過重新換個角度掃一掃來實作識别功能；當然，使用者也可通過申訴機制來向我們回報資訊，如第一問所述，我們也會做适當算法優化、調整。

• 問：你們在爬去評論或其他資訊時能否保證準确性，或是否會在進行篩選，并非每個使用使用者都會在你們産品上進行評論，你們自己累積使用者資訊周期是否需要很長時間？
• 答：相對于準确性是可以保證的，各大點評類網站也存在着篩選機制，我們自身也會設定篩選的機制；累計使用者的資訊的一個時間肯定是漫長的，但是每個軟體的盈利周期也同樣不是特别快的一件事情，我們也會提供一些優惠機制來鼓勵使用者點評。
• 問：你們産品需使用到較多且複雜的算法，是否能夠全部實作你們介紹的功能，且能否保證算法的穩定和正确性？
• 答：可以全部實作，我們主要應用了目标檢測以及文字識别兩個子產品的算法，足以實作本次的功能。我們也會适當擴充我們的資料集來盡可能保障結果正确性。
• 問：你們在吸引使用者和累積使用者評論資訊上的周期是否會太長，這樣的話能做到維持使用者量和盈利嗎？
• 答：軟體開始盈利的周期都是十分長的，我們也會用一些優惠機制來鼓勵使用者點評商鋪，使用者量則需要我們進一步的推廣，這一點在我們的商業計劃書中有詳細的描述，我們也會通過不斷的疊代來完善我們的功能，以此來吸引更多使用者。

• 問：店鋪名稱識别精度不低于95%感覺會有難度吧，比如怎麼找到圖裡面哪裡有字？怎麼差別店鋪名的字和其他不需要的字？怎麼差別店鋪名的字和邊上顔色相近的灰塵？
• 答：由于我們需要識别的商鋪，需在我們的資料庫内，識别的難度将會大大降低，95%以上是可行的。
  • 我們之前有做過相對于的訓練、測試——首先我們按8:1:1分割資料集，再開始訓練和測試。具體測試結果如下圖所示(擴充樣本指應用多種資料增強手段擴充訓練集)

• 問：請問如果不注冊可以直接用嗎？因為我看你們的界面描述裡隻有注冊和其他方式登入
• 答：我們是要求使用者注冊的，我們更希望以雲平台的形式儲存客戶資訊，也可依據客戶的曆史喜好來完成我們的推薦功能。
• 問：獲得店鋪資訊應該比較簡單，但店鋪的使用者資訊和評論你們要如何獲得？
• 答：我們可以通過“爬蟲”來擷取，不過使用者的個人資訊可能不是不是我們要擷取的。我們僅收集我們的注冊使用者的資訊。

• 問：你們的APP一開始需要大量的店鋪資料，你們準備怎麼收集這些資料，耗時會不會很長？
• 答：收集資料時間很快的，可以借助“爬蟲”來完成，耗時很短的。而相對于資料采集，由于沒有現成的資料，均需要實地拍攝，不過這部分的耗時也不會很長。
• 問：使用者曆史搜尋的推薦要怎麼更加精準？因為使用者很可能隻是搜尋了店鋪，但是并不感興趣，這樣會不會導緻推薦的時候出現偏差？
• 答：我們會記錄店鋪停留時間的來判定使用者是否感興趣，不過個人認為搜尋了店鋪但是并不感興趣這個問題本身就存在沖突！
• 問：客服回報這裡，你們準備怎麼做？要和衆多商家達成共識，還要長時間線上，這個工作量是比較大的，你們有什麼好的解決方法嗎？
• 答：我們團隊會設定專人輪流值班，也可以看到我們的原型設計上也有展現我們的金牌客服。

• 問：你好，請問是否需要考慮不同使用者之間的互動？
• 答：我們實作的内容就有包括資訊分享的功能，具體可參見我們的商業計劃書。
• 問：你好，請問是否需要考慮不同模式，以及不同模式下的推薦方案？例如設定心情，且不同心情的推薦是不同的。
• 答：設計不同心情來推薦是一個很好的提議，可能需要通過應用“情感分析”等手段來完成，實作難度略高，我們會考慮有時間實作。
• 問：你好，請問當使用者在嘗試app推薦的地點後，并不滿意，該怎麼做？
• 答：并不滿意的話，使用者可以選擇給個差評，這樣我們便會記錄下資訊以便于我們下一次推薦。不過推薦機制本身就存在着誤推薦的可能性，是很難避免的，我們則更着重于後續的處理。

• 問：對店鋪資訊擷取問題的補充：除了爬取資料和人工輸入（個人感覺比較麻煩）這兩個方法之外，是否考慮過制作一個專門提供給商家的版本，讓商家自己填寫相關資訊？
• 答：首先，項目初期是很難完成與全部商家的協商的，當然擁有資金的供應也是可以完成的，但就實際一些來看，我們這個軟工實踐所需要做出的項目更多的資料擷取方式難道不是“爬蟲”+人工來解決嗎？其次，我們實作的主要功能也是人工智能相關的，沒有人工标注的資料集，我們是很難保證算法的可靠性的；最後，商家的版本這一點，我們更希望作為一個前景展望來做，這一點在我們的商業計劃書中有所提及。
• 問：請問你們是否有考慮過産品做出來後店鋪的覆寫率能達到什麼程度？
• 答：我們初步考慮覆寫永嘉這一區域，後續的覆寫區域會随着産品規模逐漸擴大。
• 問：請問你們原型圖上的“今日推薦”裡面的内容是以什麼為标準來推薦的？真實有效嗎？
• 答：以使用者的曆史喜好以及目前的定位結果來推薦的，真實有效！

• 問：對于刷贊或者刷評論這樣的有什麼措施解決嗎？
• 答：我們也會考慮提供篩選功能來解決，此類問題解決難度較高。
• 問：有試驗過在晚上或者在天氣狀況不太好的情況下，識别店鋪的準确率嘛？
• 答：我們有通過神經風格遷移來擴充更多場景下的資料集，這樣也可以提高我們的正确率，具體的試驗還沒有測試，但是兩個子產品也已經完成。
• 問：如何盈利？
• 答：可以通過廣告等形式來完成盈利，具體規劃可參見我們的商業計劃書。

• 截至部落格撰寫（2018/11/4 15:30）尚未提問

需求報告修改之處

根據答辯中柯逍老師提出的建議，對需求規格說明書的格式做出了修改：

1. 正文文本字型放大一号
2. 行距由1倍調整至1.5倍
3. 将文本内容設定為兩端對齊
4. 調整段間距使各處段間距均勻。

需求報告最終版本

别看了，都散了吧

遇到的困難及解決方法

困難1

• 困難描述
  • 本次作業雖然由于校慶延後了一周，但是組内部分同學作為學生幹部反而有更多的事情要做。正值學院的迎新晚會籌備中以及第九周我們開始了電氣工程實踐并且周六（11.3）是Linux作業系統實踐課程的期末大作業送出時間，全組同學都忙的焦額爛頭。尤其是原型設計組，志豪同學的事情更多。是以我們遇到的困難之一便是時間不夠用。
• 做過哪些嘗試
  • 我們試着把自己當作一個“多核處理器”，合理的規劃時間。并且在分工時， 部分事情較少的同學主動站了出來承擔了任務。
• 是否解決
  • 是
• 有何收獲
  • 增強了我們團隊的凝聚力以及很好的推進了我們的貢獻度配置設定原則（具體如何展現可以看我們的本次作業貢獻度配置設定說明）

困難2

• • 本次作業要求完成一份需求分析報告，組内同學們都沒有經驗要如何撰寫，開始時有些不知所措，無從下手。開了多次會都沒能取得實質性的進展。
• • 我們認真閱讀了作業中給出的 checklist，然後請教了之前的學長學姐其中包括曾經擔任過這門課的助教。也閱讀了一些前輩的報告，最終形成了一份架構，然後隻需要将其填充就好了。
• • 了解了一份完整的需求分析報告應該包括哪些内容。以及需求分析報告的目标人群是誰，文字應該如何組織才能夠達到寫這份報告的目的。

PSP

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

學習進度條

第N周	新增代碼(行)	累計代碼(行)	本周學習耗時(小時)	累計學習耗時(小時)	重要成長
1	300		15		map 容器的性能瓶頸分析
2		8	23	完成基本功能的實作及附加功能的構思
3	200	500		31	學習 python 中與附加功能相關的庫，例如 wordcloud
4		5	36	學習了分而治之alpha版本事項和用例圖的繪制
			44	學會了簡單的原型設計和寫沒人看的劇本