在專案中需求文件有3種現狀：
1. 有詳細的需求文件：這當然是很專業了，測試人員只要認真研讀文件，並和產品確認問題即可
2. 需求文件不明確即有文件但是文件很粗糙：
1）那麼就需要自己去溝通對於文件中不明確的點問清楚，儘量減少因為不明確導致的開發瞎做，到時候確認問題浪費的時間
2）當然因為條件有限，我們不可能完全想全面，很多問題還是會在測試的時候才能體現，所以這時需要注意的是測試時間一定不要高估，一定要比你以為的時間再增加幾天，相信我，你絕對按時完成不了
3. 沒有需求文件：
第一種靠嘴去問，大家去協調，協商溝通，然後大家都回答沒問題了，我會自己寫乙個概要的需求描述，然後讓他去確認，他說可以，那咱們就這樣測，有問題就不斷的口頭溝通；
第二種要基於使用者使用的場景和行業的經驗來去做判斷它是不是合理的。
如何完成需求文件
1 提煉使用者的行為 使用者的行為，決定於這個產品的價值所在。通過分析使用者的行為，深入了解使用者這個行為背後的目的是什麼，這個需求能給使用者產生什麼樣的價值。2 組織專案干係人討論，通過舉例的方式說明使用者的行為需求 所謂舉例，其實就是使用者使用場景，不是憑空拍腦袋想出來的，最好是經過與使用者溝通...
如何寫好需求文件
需求文件可能是很多產品的學習第一課，到底怎麼寫好乙份需求文件，還是要追根溯源從根本上說起 本著萬物可追溯，萬物可分解的原則，這個問題可以分解成三個問題 1 不寫行不行 推動需求落地的一般來說需要以下幾個步驟 1 前期溝通 2 宣講 3 原型 文件 4 後續溝通 所以原型 需求文件在整個落地過程中處於...
如何書寫報表類需求文件
如何書寫報表類需求文件 最近做了一些報表方面的工作，在寫需求文件時，深感報表型別需求的難以書寫，特別是中式報表，不僅錶樣複雜，並且統計方式演算法繁多，經常連表頭都需要動態變化，寫演算法時經常感覺不知道如何去寫，動態的如何寫，靜態的如何書寫，正巧接觸了一下潤幹報表，感覺按其思路進行報表書寫能將報表演算...