軟工實踐 · 第七次作業 - 需求分析報告
福大軟工 · 第七次作業 - 需求分析報告
"Jarvis For Chat"需求分析報告
團隊專案的整體計劃安排
專案logo及思維導圖
專案logo
思維導圖
個人貢獻分分配
- 本著多幹多得的原則，我們儘可能地降低基礎績效的佔比，目的在於鼓勵大家多參與軟體開發的過程。不作為的隊員在我們隊伍裡是得不到高分的。
- 定期分析團隊成員的貢獻情況，屆時每個成員得到一個單次總分，待最終評分時，根據大家的總分按比例分餅。
- 單次總分上限為120分，其中特別貢獻分額外計分，原則上不超過20分，如果做得真的特別特別好，可以考慮突破20分。
個人單次貢獻表格如下：
| 待評分項 | 衡量指標 | 評分方式 | 專案佔分 | 備註 |
|---|---|---|---|---|
| 基礎績效 | 固定分數 | 25 | 無 | |
| 工作時長 | 總工作時長 | 專案經理計算 | 40 | 參與了什麼工作、工作的重要程度 |
| 工作質量 | 程式碼可用性、可靠性 | 團隊互評得到 | 20 | 工作做得怎麼樣 |
| 參與協作程度 | 線上及線下議會出席情況 | 專案經理評估 | 15 | 一般情況下為滿分，視具體情況扣除 |
| 特別貢獻分 | 特殊貢獻（範圍不定） | 團隊討論得出 | 20 | 額外計分 |
| 總分 | 120 |
本次作業個人貢獻分（去除基礎績效）
本次作業個人貢獻分佔比
分數圖片
現場得分及QA總結
| 第一組 | 第二組 | 第三組 | 第四組 | 第五組 | 第六組 | 本組 | 第八組 | 第九組 | |
|---|---|---|---|---|---|---|---|---|---|
| 本組對其評分 | 78 | 75 | 79 | 69 | 76.5 | 84 | 91 | 75 | 69 |
| 對本組的評分 | 80 | 79 | 84 | 74 | 72 | 74 | 91 | 84 | 85 |
本組的現場答辯得分：暫無
第一組提出的問題：
問：在這次答辯中並未進一步提及專案需求中說到的主要功能“聊天機器人”？
- 並非不開發，而是可能會推遲到專案後期才開發。我們以需求為導向，經過問卷形式的使用者調研後，發現使用者對聊天機器人的需求並不高，或者說重要程度沒有熱詞分析、關鍵詞提醒來得大。所以我們暫不開發聊天機器人功能，待熱詞分析、關鍵詞提醒、個性化訊息群發、單向好友刪除功能完成後，再開發聊天機器人的功能。
問：如果熱詞篩選遺漏了某些群內熱點，如何處理這些遺漏？
- 我們將使用NLP中的分詞技術，提取出相關名詞，經過相關篩選(主要是與熱詞庫作匹配)後得出熱點名詞。這個過程中確實可能出現遺漏，不過出現的概率並不高；而且我們也會不斷更新我們的熱詞庫，儘量減少這種情況的出現。
問：對熱詞篩選演算法是否指定相應的驗收標準？
- 我們暫時還未對熱詞分析結果的內容做相關的驗收標準。我們只能說盡可能選出熱詞。分析結果暫時無法給出很明確的保證。
第二組提出的問題：
問：是否可以排除掉一些使用者們經常使用到的但是不是關鍵內容的詞，比如牛逼。
- 完全可以考慮。我們將使用NLP中的分詞技術，提取出相關名詞，經過相關篩選(主要是與熱詞庫作匹配)後得出熱點名詞。只需要在我們自己的熱詞庫中剔除您所說的這部分內容即可。
問：打算如何恰當處理使用者的隱私問題。
- 我們不會嘗試獲取使用者隱私。而且從技術層面上我們確實獲取不到使用者的隱私，主要原因是登入時是在模擬使用者在web端登入微信，登入過程騰訊是有做加密的，我們獲取不到相關的資訊。
問：團隊獲取利益的途徑都有什麼？
- 如果真的要獲利，主要是通過會員版本的收費來獲利。
第三組提出的問題：
問：你們對於資料的處理以及使用者的資訊有保障嗎？
- 我們並不清楚該組所提出的的資料的處理是指哪一方面，追問後得知是有關隱私的問題。我們不會嘗試獲取使用者隱私。而且從技術層面上我們確實獲取不到使用者的隱私，主要原因是登入時是在模擬使用者在web端登入微信，登入過程騰訊是有做加密的，我們獲取不到相關的資訊。
問：在群發功能的使用上,是不是可以有更廣的使用範圍？
- 目前我們頭腦風暴想到的情景主要是：1. 手機號變更了需要在QQ微信上通知大家 2. 節日祝福 3. 活動通知。之後我們還會繼續我們的頭腦風暴，儘可能想出更多的使用範圍
問：團隊的技術維持和可預盈利比是否是樂觀的？
- 技術層面上我們目前還是比較忐忑的，因為是基於前輩開發的庫進行開發，如果前輩開發的庫並沒有提供相關功能，我們的軟體的部分功能就無法實現。至於可盈利性，我們不做出很樂觀的估計。
第四組提出的問題：
注：該組在規定時間內未對我組提出任何問題，故不做回答。
第五組提出的問題：
問：你好，請問你們熱詞分析有沒有考慮近義詞的問題？
- 目前沒有考慮，不過後期如果有需要的話我們會考慮加入。
問：你好，請問你們群發祝福的祝福語是如何來的？如果是手工書寫，後期工作量會不會太大？如果是網上爬來的，如何使好友覺得這條祝福語不像是群發的？
- 首先可以在每個節日來臨之際為使用者提供部分節日祝福模板來供使用者選擇，這樣做的工作量並不大。使用者也可以自己從網上找相關的祝福語，簡單修改（在合適的位置加入暱稱）即可使用我們的功能。
問：你好，看你們的原型設計好像是電腦端風格?電腦很難保證隨時開機，你們有沒有考慮做手機端的產品
- 首先我們一直都是想在電腦端做產品。暫時沒有考慮做手機端的產品，一方面我們是基於web端的qq和微信進行開發，登入時需要掃碼，如果將產品部署在手機端又如何讓手機自己掃自己呢（不是做不到只是有點麻煩）；另一方面我們還考慮到手機算力不足、續航不夠長的問題。所以最終是想將它部署在電腦端的。另外我們可以考慮為使用者提供略收費的伺服器端7×24小時代掛機服務。
第六組提出的問題：
問：你好，請問對於關鍵字設定一個關鍵字搜尋功能是否能夠提供更好的使用者體驗？
- 感謝貴組寶貴的建議，我們在開發過程中會考慮加入。
問：你好，請問需求說明書中的群發物件只能選擇群組，而實際群發時物件經常是qq中的好友分組，增加這一功能是否會好些？
- 我們始終都是再說讓使用者選擇群發物件，而沒有限定群發物件只能是群組呀，勞煩貴組再仔細看一遍相關部分的內容。
問：你好，請問這一軟體設計到大量使用者隱私，關於隱私保護是否能夠很好的做出保證？
- 我們不會嘗試獲取使用者隱私。而且從技術層面上我們確實獲取不到使用者的隱私，主要原因是登入時是在模擬使用者在web端登入微信，登入過程騰訊是有做加密的，我們獲取不到相關的資訊。
第七組提出的問題（本組）
第八組提出的問題：
問：在PPT的展示中沒有驗收標準，簡介概括一下
- 驗收標準內容較多，就算放到PPT上也未必看得清，故本次並沒有將它放入PPT。不過PPT裡是放得下驗收標準的概括的，我們下次注意改進！
問：利用備註群發祝福的功能，只能初步實現對於數字的刪除等，對於後面正確的識別名字真的能實現嗎？
- 我們會盡可能地提取出來。
問：安全性如何更好的保障？使用者已經算是把最隱私的資料都透露給你們了。還有就是如何盈利？
- 我們不會嘗試獲取使用者隱私。而且從技術層面上我們確實獲取不到使用者的隱私，主要原因是登入時是在模擬使用者在web端登入微信，登入過程騰訊是有做加密的，我們獲取不到相關資訊。
- 盈利的話，我們不做出十分樂觀的估計。
第九組提出的問題
注：該組在規定時間內未對我組提出任何問題，故不做回答。
各小組對我組提出的建議及我組改進總結
第一組：
建議：在下一步的開發中繼續以使用者的視角來提升產品功能的易用性與合理性
- 改進：會在專案開發過程中進行改進，需求報告中暫不更改。
第二組：
建議：排除掉一些經常用的並且不是使用者需要獲取的詞
- 改進：我們會在做熱詞分析時建立一套熱詞庫，這個熱詞庫中會盡量的剔除那些“常用的但不重要的”詞
第三組：
建議：建議拓展功能的面向群眾
- 改進：感謝貴組的建議，但無法在需求報告中更改。
第四組：
建議：使用者需求不侷限在電腦端，建議可以向安卓端和IOS端拓展
- 改進：暫無面向安卓端、IOS端開發的意向，故無更改。首先我們一直都是想在電腦端做產品。暫時沒有考慮做手機端的產品，一方面我們是基於web端的qq和微信進行開發，登入時需要掃碼，如果將產品部署在手機端又如何讓手機自己掃自己呢（不是做不到只是有點麻煩）；另一方面我們還考慮到手機算力不足、續航不夠長的問題。所以最終是想將它部署在電腦端的。另外我們可以考慮為使用者提供略收費的伺服器端7×24小時代掛機服務。
第五組：
建議：切實使用者需求，根據需求改進功能演算法，使用者的使用快捷方便體驗友好應該在首位。
- 改進：我們一直都在也一直都會以使用者的需求為導向呀。
第六組：
建議：根據使用者實際需求改進功能
- 改進：我們一直都在也一直都會以使用者的需求為導向呀。
建議：對關鍵字這一功能還可以繼續優化
- 改進：暫時不明白貴組是建議優化關鍵詞的哪一方面，我們會在專案進行過程中不斷收集使用者反饋來改進產品。
建議：思維導圖可以更加細化
- 改進：由於製作的思維導圖有點大，考慮到需求說明書裡就算放了也看不清的問題我們沒有放，並不是我們沒有做更加細化的思維導圖。如需要可以在本頁面搜尋思維導圖。
第八組：
建議：單單根據備註然後智慧群發訊息可能稍微有點欠缺
- 改進：我們儘可能去做好就是啦(#^.^#)
第九組：
建議：建議多花一些篇幅介紹軟體的安全的設計部分，這是可能是使用者最為關心的部分。在獲取聊天記錄方面尋找一些可行的方法。在軟體安全部分要多注意，可以將這部分作為主打的賣點之一。
- 改進：保護使用者隱私是我們的底線，我們多次強調我們不會嘗試獲取使用者隱私。而且從技術層面上我們確實獲取不到使用者的隱私，主要原因是登入時是在模擬使用者在web端登入微信，登入過程騰訊是有做加密的，我們獲取不到相關資訊。因此在專案說明書中增加使用者安全部分的描述。
《需求規格說明書》
修改之前的《需求規格說明書》
修改之後的《需求規格說明書》（紅色的字為修改之處）
遇到的困難及解決方法
困難一
- 困難描述：Pad上手繪完成的視訊通過QQ導給電腦時十分模糊的問題
- 做過哪些嘗試：通過堅果雲、U盤進行傳輸等
- 是否解決：解決
- 有何收穫：不能拿QQ匯出視訊，否則會被壓縮。
困難二
- 困難描述：核實wxpy、qqbot庫時發現部分功能無法實現
- 做過哪些嘗試：再次核實wxpy、itchat庫
- 是否解決：無法解決
- 有何收穫：站在巨人的肩膀上開發也是一件不容易的事情，巨人沒去過的地方你怕是也去不了。
PSP表格
| PSP2.1 | Personal Software Process Stages | 預估耗時（分鐘） | 實際耗時（分鐘） |
|---|---|---|---|
| Planning | 計劃 | 15 | 20 |
| · Estimate | · 估計這個任務需要多少時間 | 15 | 20 |
| Development | 開發 | 650 | 1130 |
| · Analysis | · 需求分析 (包括學習新技術) | 60 | 90 |
| · Design Spec | · 生成設計文件 | 260 | 380 |
| · Design Review | · 設計複審 | 30 | 60 |
| · Coding Standard | · 程式碼規範 (為目前的開發制定合適的規範) | 0 | 0 |
| · Design | · 具體設計 | 300 | 600 |
| · Coding | · 具體編碼 | 0 | 0 |
| · Code Review | · 程式碼複審 | 0 | 0 |
| · Test | · 測試（自我測試，修改程式碼，提交修改） | 0 | 0 |
| Reporting | 報告 | 75 | 115 |
| · Test Repor | · 測試報告 | 0 | 0 |
| · Size Measurement | · 計算工作量 | 15 | 25 |
| · Postmortem & Process Improvement Plan | · 事後總結, 並提出過程改進計劃 | 60 | 90 |
| 合計 | 740 | 1265 |
學習進度條
| 第N周 | 新增程式碼（行） | 累計程式碼（行） | 本週學習耗時(小時) | 累計學習耗時（小時） | 重要成長 |
|---|---|---|---|---|---|
| …… |