怎麼做需求分析?

來自專欄猿論

大綱：

1、需求分析的痛點

2、需求了解要做什麼?

3、評審時要關注哪些方面？

1、需求研究的痛點

在測試過程中，理解需求是第一步，也是最重要的一步。只有正確理解了需求，後面的工作才能順利進行。

但在了解需求的過程中，經常會遇到各種各樣的問題，比如說：

• 產品人員沒有提供需求文檔，或者提供的文檔不清晰、不規範（有時候甚至用幾句話描述一個複雜需求）
• 測試同學小明對某個需求不清楚，在公司里問了一圈都沒有一個能準確解答他疑問的人（在一些互聯網公司比較常見，產品人員流動性大，公司不重視文檔記錄）
• 產品組織需求評審，詢問與會人員有什麼問題時，測試同學小明一個問題都問不出來
• 產品給出需求文檔後，測試經理安排給某測試同學小明了解需求。一段時間後小明反饋「文檔已經看完了」，但測試經理詢問「這次改了什麼，為什麼這麼改，有哪些影響範圍，什麼時候上線」，小明都說不上來
• 需求開發完了，測試同學小明按照跟研發溝通的結果進行驗證，測試通過後，產品人員（或客戶）驗收時卻反饋這不是他們想要的，最後系統返工重做，浪費了人力物力，最後還失去了客戶。後來公司內部追責時，小明被嚴厲批評

2、了解需求時要做什麼

如果公司中出現了上面提到的場景，往往是因為多方面原因導致的。本文不對此展開細述，有興趣的同學可以加我微信私聊。接下來講講需求評審時我們要要做什麼?

• 需求文檔是否規範、全面（寫的是否清晰、詳盡）。便於節省溝通成本，使項目質量和風險可控。
• 完整閱讀需求，標記疑問（三種不同顏色，灰色代表沒有疑問，紅色表示有錯誤，黃色代表有疑問）。即使測試任務緊張，也要抽出時間來了解需求，不提前看需求，就會出現在需求評審時提不出問題來的尷尬局面。另外我習慣用excel表格把疑問整理下來，這樣有助於知識傳遞。
• 書讀百遍其義自見，多讀幾遍需求可能會自行解決一些疑問，多結合度娘解決一些術語性質的疑問
• 是否有原型圖，新人加入團隊時重點關注，多問問。
• 整個系統的流程圖，發現邏輯缺失（整理資源競爭map、相關性map）
• 口頭溝通的，郵件確認。
• 易用性。所謂移動性，就是「易學習、易理解、易操作」。舉幾個例子如下。
• 功能是否有冗餘，操作路徑是否過深
• 需要進行說明的地方是否有說明？說明是否清晰易懂？
• 文字、圖片、按鈕排版是否合理
• 色調是否符合系統特色？效果是否統一
• 誤操作提示
• 容錯處理

• 在需求了解時，多看看競爭產品是如何設計的，或者類似產品（功能）是怎麼設計的，這有助於從設計角度去看待產品，也是一條有助於迅速積累易用性經驗的建議。

3、評審時要關注哪些方面

最後來說說評審時要關注哪些方面？個人認為最重要的就是多問問幾個為什麼。

• 需求背景，為什麼要做這個需求，要解決什麼問題？為什麼要這麼解決?是否有更好的解決方式，競爭對手怎麼處理的這個問題？他們為什麼要那麼做？——這些問題都是直接或間接的為了明確我們的測試範圍。
• 需求什麼時候給出明確的、書面性的資料，什麼時候開發完，什麼時候上線？以此初步評估測試周期。

作者：青春的小奮鬥

鏈接：http://www.imooc.com/article/29284

來源：慕課網

本文原創發佈於慕課網 ，轉載請註明出處，謝謝合作

推薦閱讀：

【重磅】認證作者招募 | 打造個人品牌 so easy ！

有獎徵文003期|程序員進階路上，哪本書你認為很不錯，對你幫助很大？

四大維度解鎖Webpack 工程化的補充

關於高並發和秒殺系統，你知道的和不知道的一些事

編寫高性能Javascript代碼的若干建議

推薦閱讀：