第七次作業—需求分析報告
組隊後的團隊專案的整體計劃安排；（5分）
alpha版本的規劃是尋求到合適的音樂源並能夠使用，基礎的播放介面及app主體的實現。
（11.4-11.18）
beta版本則開始對模組化功能進行拓展開發，例如歌詞顯示、歌單合併、快速查詢、主題變換等。
（11.19-12.9）
長期將對流暢度、快速響應進行優化與處理，及時更換失效源，新增更多功能。
（12.9-?）
專案logo及思維導圖（由於校慶作業延時一週，新增要求）
評估團隊中每個人對本次作業的貢獻比例，描述為撰寫需求規格說明書的工作流程、組員分工、組員工作量比例（禁止一鍋端平的情況，如果沒有評估，全組平均後，組長得分減 50%）（5分）
| 組員 | 分工 | 貢獻比例 |
|---|---|---|
| 躍安(2348) | 需求分析報告、評審表製作、評審、Q&A | 21% |
| 泓(2321) | 需求分析報告、評審、Q&A | 13% |
| 裕翔(2531) | 專案logo、評審、Q&A | 5% |
| 傑(2344) | 部落格整理、專案logo、視訊、PPT、原型、評審、Q&A | 24% |
| 鬆(2322) | 需求分析報告、評審、Q&A | 13% |
| 淇(2226) | 原型、評審、Q&A | 12% |
| 佳煒(2531) | 思維導圖、類圖、Q&A | 12% |
視訊&&PPT 20%
原型&&專案LOGO 15%
需求分析報告 36%
評審表&&思維導圖&&類圖 15%
評審&&Q&A 14%
評審表格設計（2分）
答辯總結（20分）
求出本組的現場答辯得分：去除最高總分，最低總分，求平均分（保留2位小數）
最高分78，最低分63，餘
（75+69+66+65+70+72+77）/ 7 = 70.57
收集其他組對本組提出的問題，並回答（每少回答一點，該項得分扣除5%，扣完為止）
==答1組：==
1. 答辯中沒有很好的體現出與競品之間的不同？產品的核心競爭力在於：
與競品的核心競爭力在於我們的UI介面與動效，最早網易雲音樂在多個音樂平臺中脫穎而出正是因為其優雅的介面。同時有一些功能尚未公佈，但在考慮範圍內。如通過多個使用者的歌單來實現反向推薦，例如一些動漫愛好者，他們會在歌單中新增自己喜歡的bgm，通過對重合度的分析，我們可以向用戶反向推薦動漫。
2. 是否考慮過用其他方式規避版權風險同時又實現產品功能？
版權問題實屬無解，否則版權歌曲也不會分佈在各家平臺。
==答2組：==
1. 類似競品較多，你們該如何從類似產品中拉取使用者。
我們會盡力在UI介面與動效上下功夫，最早網易雲音樂在多個音樂平臺中脫穎而出正是因為其優雅的介面。同時有一些功能尚未公佈，但在考慮範圍內。如通過多個使用者的歌單來實現反向推薦，例如一些動漫愛好者，他們會在歌單中新增自己喜歡的bgm，通過對重合度的分析，我們可以向用戶反向推薦動漫。
2. 版權問題該如何解決？音質問題又能否得到保證。
版權問題，請檢視上次的Q&A。
就音質而言，目前的320K已經能夠滿足大部分人的需求。
購買手機時自帶或自己購買的500元內耳機幾乎無大差別。
其次您對於HiFi是什麼看法？在Android的預設設定中，任意取樣率的聲音在Audio Flinger中將被統一升取樣到48kHz播出（這一值可以修改，例如統一修正為44.1kHz），vivo和LG是繞過系統的預設硬體通路，在機身塞進了兩顆專用晶片及一顆運放晶片來實現的（vivo xplay）。
同時一般的無損歌曲單曲可達到百兆級別，您的儲存夠嗎？
希望您能有更多的瞭解後再提出此問題。
3. 如何盈利
前期不考慮盈利，後期通過啟動頁廣告或使用者捐贈，以及可作為後續開發應用的引流入口來進一步獲得收入。
==答3組：==
1. 音樂聚合類軟體，目前市面上已經有成熟的軟體，比如靈音。並且靈音可以播放無損音質。而你們將音樂聚合作為核心功能，請問你們的競爭優勢在哪呢？
靈音這款軟體之前有認識的人用過，就使用者體驗說，介面有點單調，而且player有時候會有bug，打不開無法使用。而之前也提過其他的相關軟體，我們的優勢在於使用介面的簡潔和音樂內容豐富，對平臺也會進行適用性的除錯以及使用者的反饋機制，儘量避免bug的出現以及儘快的修復
2. 音樂聚合行為是侵權的，經常有這類軟體被下架，我想這對產品的推廣也會有很大的阻礙，請問你們要如何應對這個問題？
侵權行為也有例如爬取美團、餓了麼等平臺的資料。在被通告之前我們會盡力滿足使用者需求。
3. 你們的歌曲評論是從多個平臺獲取的嗎？如果每個平臺都有上千條評論，請問你們要怎麼向用戶展示呢？
我們目前的打算是優先選擇網易雲音樂的評論，同時使用者可以自己進行選擇。
==答4組：==
1. 僅是聚合各音樂軟體的介面，且無法保證當前高需求的使用者所希望的無損音質，很難保證使用者體驗極佳，是否存在改進措施？
就音質而言，目前的320K已經能夠滿足大部分人的需求。
購買手機時自帶或自己購買的500元內耳機幾乎無大差別。
其次您對於HiFi是什麼看法？在Android的預設設定中，任意取樣率的聲音在Audio Flinger中將被統一升取樣到48kHz播出（這一值可以修改，例如統一修正為44.1kHz），vivo和LG是繞過系統的預設硬體通路，在機身塞進了兩顆專用晶片及一顆運放晶片來實現的（vivo xplay）。
同時一般的無損歌曲單曲可達到百兆級別，您的儲存夠嗎？
希望您能有更多的瞭解後再提出此問題。
2. 版權問題是否有考慮解決？
暫時不考慮，做大之後考慮轉型。同時有參考一些neets這個網站的做法，起到的是一個社交平臺的作用，不是由我們自身網站提供音源；我有個想法就是，開放性，讓有想法的人為圈子的人進行支付，或者我們提供一個支付手段，可由多個使用者進行支付一首歌的版權
3. 音樂評論的獲取是以什麼渠道呢，若是“爬蟲”來獲取則無法盈利，是否有考慮市場前景問題呢？
爬蟲。只要版權未談好，市場前景就存在。
==答5組：==
1. 如此多的播放器，除去整合功能外，你們還有哪些其他優勢？
與競品的核心競爭力在於我們的UI介面與動效，最早網易雲音樂在多個音樂平臺中脫穎而出正是因為其優雅的介面。同時有一些功能尚未公佈，但在考慮範圍內。如通過多個使用者的歌單來實現反向推薦，例如一些動漫愛好者，他們會在歌單中新增自己喜歡的bgm，通過對重合度的分析，我們可以向用戶反向推薦動漫。
2. 依舊是版權問題，如果你只是單純的做單機的平臺聚合，歌曲整理，是可以的，但是如果牽扯到網路賬號，肯定存在版權問題，如何解決？
擱置爭議，共同開發。
3.關於評論的彈幕化，是否考慮過聽歌時候的狀態，我們在如何的情境下聽音樂，是否多餘的彈幕化？
我們的想法是在mv以及特定的歌曲裡（燃燒我的卡路里等）放置彈幕，預設關閉。
==答6組：==
1. 你好，請問版權問題是怎麼解決的？不盈利的話軟體如何運營？
2. 你好，請問付費歌曲需要使用者通過你們這個軟體從原音樂平臺購買嗎？
不需要，初期未盈利狀態我們將參考網易音樂雲盤的方式進行分享。
3. 你好，請問你們的原型介面的功能十分不明確，沒有查詢等介面，能不能給出原型連結？
==答7組：==
1. ”歌曲搜尋“功能，如果輸入的是停用詞，那麼你們能提供多高的準確率？
這問題……建議回去wiki一下“停用詞”的定義。
2. ”歌曲整合“功能，使用者需要自己手動一個個平臺地整合？每次在一個平臺有更新歌單，也要手動整合嗎，還是已經登陸過的其他平臺地賬號即使當前並沒有登入，也能自動獲取那個賬戶的更新狀態？還有，在獲取歌單的過程中，只是列出所有的歌曲，還是說能把其他平臺已經分類好的歌單也保留下來？你們提供的自動標籤是根據什麼樣的標準分類的，你們定的標準還是使用者的標準？整合的時候對於不同平臺重複的歌曲又是怎麼處理的？
不需要，我們將會在每次使用者開啟app時自動獲取，同時提供一個手動同步按鈕。
就目前瞭解的情況，QQ音樂可以在未登入狀態獲取使用者的歌單。
分類好的歌單會保留，同名進行合併。
目前的計劃是按照評論的熱詞進行檢索匹配。
同一歌單重複歌曲自然是保留一個。
3. ”評論“功能，是使用這個APP的使用者填寫的，還是這首歌所屬平臺的？如果使用你們產品的使用者在你們的產品上對該首歌進行評論，這條評論只會留在你們的產品裡，還是說可以同步到這首歌所屬的平臺，甚至擁有該首歌的其他所有平臺？
屬於這首歌的所屬平臺。
我們期待產生自身的資料，同時將此評論同步至對應平臺，如果使用者有登陸的賬戶的話。
==答8組：==
1. 你們產品最大的亮點是實現多家音樂平臺的整合功能，既然你們不考慮侵權，那我直接百度雲找到資源不就好了？（反正都是侵權）
懶是人的天性。如果同樣的電影，在優酷和百度雲都有，您選擇哪個。
2. 後期的更新和維護在曲庫歌曲龐大的情況下如何進行？因為你們是從其他音樂播放器整合過來的，比如歌詞更新？
歌詞更新將通過使用者的點播來實時獲取。
3. 想知道歌曲具體是怎麼儲存的？如果到後面歌曲太多有些刪掉的話肯定也會影響使用者的體驗？
和大部分的音樂軟體是一樣的處理方式，設定快取上限，超出後則刪除最早的歌曲。如是使用者下載則全部保留。
根據答辯中其他組提出的意見和建議修改完善本組需求分析報告，並標明修改之處（5分）
其中淡藍色為修改部分
提供 《需求規格說明書》作為隨筆的附件（經過修改的最終版本）（5分）
遇到的困難及解決方法（5分）
- 困難描述
- LOGO真滴難做！！
- 有些隊員聯絡不到
- 做過哪些嘗試
- 嘗試過“樂”字的隸書寫法進行變換，然而寫的字真醜，然後……就沒有然後了
- 找聯絡的到的人來完成
- 是否解決
- 隨手一畫完成大事業。
- 解決了提出問題的人，扣他分。
- 有何收穫
- 苦中作樂。
- 無能為力。
PSP（3分）
| PSP2.1 | Personal Software Process Stages | 預估耗時（分鐘） | 實際耗時（分鐘） |
|---|---|---|---|
| Planning | 計劃 | 60 | 60 |
| · Estimate | · 估計這個任務需要多少時間 | 60 | 60 |
| Development | 開發 | 335 | 375 |
| · Analysis | · 需求分析 (包括學習新技術) | 30 | 30 |
| · Design Spec | · 生成設計文件 | 10 | 20 |
| · Design Review | · 設計複審 (和同事稽核設計文件) | 20 | 30 |
| · Coding Standard | · 程式碼規範 (為目前的開發制定合適的規範) | 10 | 10 |
| · Design | · 具體設計 | 60 | 60 |
| · Coding | · 具體編碼 | 180 | 200 |
| · Code Review | · 程式碼複審 | 5 | 10 |
| · Test | · 測試（自我測試，修改程式碼，提交修改） | 20 | 15 |
| Reporting | 報告 | 245 | 340 |
| · Test Report | · 測試報告 | 120 | 180 |
| · Size Measurement | · 計算工作量 | 5 | 10 |
| · Postmortem & Process Improvement Plan | · 事後總結, 並提出過程改進計劃 | 120 | 150 |
| 合計 | 640 | 775 |
學習進度條（2分）
| 第N周 | 新增程式碼（行） | 累計程式碼（行） | 本週學習耗時(小時) | 累計學習耗時（小時） | 重要成長 |
|---|---|---|---|---|---|
| 1 | 500 | 500 | 12 | 12 | 單元測試的編寫 |
| 2 | 200 | 700 | 16 | 28 | Axure原型設計工具的使用、Python的檔案讀寫 |
| 3 | 500 | 1200 | 20 | 48 | Python爬蟲的編寫、詞雲圖的繪製和Python的檔案讀寫 |
| 4 | 300 | 1500 | 20 | 68 | 嘗試使用Python深度學習框架 |
| 5 | 400 | 1900 | 14 | 82 | 繪製思維導圖、利用Qt構建Linux視覺化介面 |