軟件生命周期中，需求是整個周期的源頭。良好的開端，是成功的一半。需求的重要性自然不言而喻。但是，在很多企業中，并沒有對需求引起足夠的重視。原因并不是PM們不知道需求的重要性，而是商業競爭中不得不裁剪某些看似不能獲得很大利益的步驟。
什么是需求?很多PM和開發人員都未必真正考慮過這個問題。IEEE對需求有以下兩種定義的方式。
1. 解決用戶問題或達到用戶目標需要具備的條件或能力
2. 遵守合同、協議、規范或其他要求
然后用規范的文檔描述出來，就成了我們熟悉的SRS。
我們常說的需求，其實并不是我們認為的SRS。SRS應該叫做需求規格說明書。那需求是什么呢?與需求規格有什么區別?
需求：對要實現的功能的粗略描述
需求規格：對需求的精確定義
我們知道，在軟件開發過程中，只有得知了需求的精確定義，才能開展工作。比如功能方面，編輯框能支持多少位字符。性能方面，時間和容量規定等。當然還包含其他非功能，性能方面的定義。
除了以上所說的需求，對于測試人員，還必須有測試需求。這個環節，很少有企業會重視。測試需求分為2方面：
需要測試哪些方面
軟件是否可測，需要增加哪些開發需求
其中第一條，很多企業都列到了測試計劃中，這也可以，沒有規定一定要放到哪個文檔里。但是對于第二條，可以說幾乎沒有多少企業去做。
接下來，在沒有明確需求，需求規格，測試需求的情況下，我們怎么去做測試呢?現在很多企業，其實就是在這種情況下做項目的。
當測試人員接手一個項目后，第一件事情一定是想了解這個系統的功能，背景，架構。于是，馬上就會想得到需求文檔。但結果往往是失望的，根本沒有文檔，或者文檔根本不具備參考價值。此時不必太失望，因為這種情況實在是太常見啦。這時，請試著從以下幾個步驟著手。
查閱文檔：文檔是最具權威的，也是記憶最長久的。有時，我們的項目可能是在原有產品的基礎上，進行版本升級。這時，先去找找，有沒有原有版本留下的需求，或者是用戶手冊等文檔。從這些文檔中，了解項目的背景，系統的基本功能。這對了解新項目是有很大好處的。并且，在產品升級的項目中，驗證老版本的功能在新版本中是否正常，也是一個必要的工作�？梢韵葏⒖祭习姹镜南嚓P文檔，設計新版本中的用例。
也有時，我們的項目是一個行業項目，比如金融項目。我們可以參考一些行業知識的書籍，文檔。這對理解系統也有很大的好處。
實在沒有文檔，那只好暫時跳過這一步驟了。
在進入下一步驟之前，你可能得到了一些相關文檔，也可能什么也沒得到。無論如何，你可能對系統已經有了一些了解。這時，請記錄下來，寫成文檔。無論是對自己，還是對別人，在以后都可能極有參考價值。試想一下，如果前人已經給你留下了這些文檔，你是否可以輕松很多?還要注意及時更新你的文檔。因為你對系統的理解，隨時都在變化著，一定要保證你的文檔和當前你對系統的理解是一致的。
試著使用系統，根據經驗和常識猜測：既然沒有需求，那可以推測，該項目的管理一定是很糟糕的，對軟件測試也不會投入很大的成本。因此，測試人員一般都是在編碼完成后才進入項目。這時，應該已經可以看到成型的系統了。在沒有需求的情況下，試著先“玩”一下系統吧。在這過程中，你應該對系統有可更深入的認識，在上一階段中，你可能留下很多疑惑或是猜測，這時應該能排除一部分了。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
