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

寫在前面

• 技術最強組的組長博客
• 不用看也知道的做業
• 男主女主顏值爆表的用戶使用場景視頻

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

咱們將工做流程分爲前期、中期、後期來進行。

• 前期
  • 經過需求調研獲取用戶喜愛、需求；
  • 再借助「爬蟲」、數據採集工具獲取更多咱們產品所需信息；
  • 最後完成原型設計，中期與後期的軟件開發流程也會依據此原型進行。
• 中期
  • 完成核心功能的算法實現；
  • 初步開發出美觀、易用的界面；
  • 完成先後端、算法三者的鏈接，測試產品的運行效率、結果，造成一個完整的軟件體系。
• 後期
  • 經過對軟件的維護，不斷迭代更新軟件的內容而且修復潛在bug；
  • 在時間容許的前提下，實現產品的附加功能。

項目logo及思惟導圖

• 項目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. 正文文本字體放大一號
2. 行距由1倍調整至1.5倍
3. 將文本內容設置爲兩端對齊
4. 調整段間距使各處段間距均勻。

需求報告最終版本

別看了，都散了吧

遇到的困難及解決方法

困難1

• 困難描述
  • 本次做業雖然因爲校慶延後了一週，可是組內部分同窗做爲學生幹部反而有更多的事情要作。正值學院的迎新晚會籌備中以及第九周咱們開始了電氣工程實踐而且週六（11.3）是Linux操做系統實踐課程的期末大做業提交時間，全組同窗都忙的焦額爛頭。尤爲是原型設計組，志豪同窗的事情更多。因此咱們遇到的困難之一即是時間不夠用。
• 作過哪些嘗試
  • 咱們試着把本身看成一個「多核處理器」，合理的規劃時間。而且在分工時， 部分事情較少的同窗主動站了出來承擔了任務。
• 是否解決
  • 是
• 有何收穫
  • 加強了咱們團隊的凝聚力以及很好的推動了咱們的貢獻度分配原則（具體如何體現能夠看咱們的本次做業貢獻度分配說明）

困難2

• 困難描述
  • 本次做業要求完成一份需求分析報告，組內同窗們都沒有經驗要如何撰寫，開始時有些不知所措，無從下手。開了屢次會都沒能取得實質性的進展。
• 作過哪些嘗試
  • 咱們認真閱讀了做業中給出的 checklist，而後請教了以前的學長學姐其中包括曾經擔任過這門課的助教。也閱讀了一些前輩的報告，最終造成了一份框架，而後只須要將其填充就行了。
• 是否解決
  • 是
• 有何收穫
  • 瞭解了一份完整的需求分析報告應該包括哪些內容。以及需求分析報告的目標人羣是誰，文字應該如何組織纔可以達到寫這份報告的目的。

PSP

PSP	Personal Software Process Stages	預估耗時（分鐘）	實際耗時（分鐘）
Planning	計劃	10
· Estimate	· 估計這個任務須要多少時間	10
Development	開發	2760
· Analysis	· 需求分析 (包括學習新技術)	1200
· Design Spec	· 生成設計文檔	60
· Design Review	· 設計複審	60
· Coding Standard	· 代碼規範 (爲目前的開發制定合適的規範)	60
· Design	· 具體設計	60
· Coding	· 具體編碼	800
· Code Review	· 代碼複審	120
· Test	· 測試（自我測試，修改代碼，提交修改）	400
Reporting	報告	190
· Test Repor	· 測試報告	60
· Size Measurement	· 計算工做量	30
· Postmortem & Process Improvement Plan	· 過後總結, 並提出過程改進計劃	100
	合計	800

學習進度條

第N周	新增代碼（行）	累計代碼（行）	本週學習耗時（小時）	累計學習耗時（小時）	重要成長
1	200	200	6	6	學習python爬蟲的使用
2	200	600	8	14	學習一些python爬蟲庫
3	300	900	8	22	學習java爬蟲的實現
4	50	950	5	27	Android stutio的安裝和調試
5	500	1450	10	37	Android stutio的學習
6	500	1950	10	47	Android stutio的學習