在軟件缺陷的8020原則中指出，軟件測(cè)試過程中，從需求分析開始到集成測(cè)試階段引入測(cè)試手段，能發(fā)現(xiàn)所有缺陷的80%;系統(tǒng)測(cè)試階段引入測(cè)試手段，能發(fā)現(xiàn)剩余缺陷中80%的缺陷;在運(yùn)行維護(hù)階段經(jīng)過長時(shí)間、大量運(yùn)行軟件后，能夠發(fā)現(xiàn)最后剩余的20%缺陷。(來自于官方引用)也就是說明需求階段是軟件缺陷存在問題較多的地方。

　　在需求階段中，用戶一般是非計(jì)算機(jī)專業(yè)人員，軟件開發(fā)人員和用戶的溝通存在較大困難，對(duì)要開發(fā)的產(chǎn)品功能理解不一致。由于軟件產(chǎn)品還沒有設(shè)計(jì)、實(shí)現(xiàn)，完全靠想象去描述系統(tǒng)的實(shí)現(xiàn)結(jié)果，所以有些特性在當(dāng)時(shí)不可能很清晰。需求變化的不一致性，用戶的需求總是在不斷地變化，這些變化應(yīng)該在與需求相關(guān)的各類文檔中得到描述，但往往被忽略，并容易引起前后文、上下文的矛盾。沒有得到開發(fā)團(tuán)隊(duì)或管理層的足夠重視，在需求分析和定義上投入的人力、時(shí)間不足。

　　在整個(gè)開發(fā)隊(duì)伍中沒有進(jìn)行充分溝通，不同角色之間對(duì)需求的理解不一致。那么怎么能夠高效率獲取需求呢?咱們今天來分析一波。

　　測(cè)試需求分析過程包括需求采集、需求分析和需求評(píng)審三個(gè)環(huán)節(jié)。其中測(cè)試需求采集的輸入是需求規(guī)格說明書，測(cè)試需求分析的輸入是測(cè)試要點(diǎn)分析、功能交互分析、質(zhì)量特性分析和測(cè)試類型分析，而需求評(píng)審的輸入是測(cè)試需求。測(cè)試需求分析的輸出包括：原始測(cè)試需求表、測(cè)試需求跟蹤矩陣和評(píng)審結(jié)論。

　　首先在收集測(cè)試需求階段，通過和軟件相關(guān)的文檔以及參考手冊(cè)，整理出原始的測(cè)試需求列表。

　　有了原始測(cè)試需求列表，接下來就可以進(jìn)行測(cè)試需求分析，是測(cè)試人員將原始測(cè)試需求列表中的需求進(jìn)行分析，分析軟件測(cè)試的測(cè)試類型、測(cè)試階段以及需求文檔本身未闡述清楚問題，形成測(cè)試需求跟蹤矩陣。

　　需求文檔不完善時(shí)，可通過上圖各方面去分析，并與用戶、業(yè)務(wù)人員、產(chǎn)品經(jīng)理或產(chǎn)品設(shè)計(jì)人員、開發(fā)人員等溝通，逐步讓測(cè)試需求清晰起來。

　　經(jīng)過可測(cè)性分析，整理出測(cè)試需求之后，進(jìn)行需求評(píng)審，確認(rèn)需求和軟件目標(biāo)的一致性，識(shí)別出功能、非功能需求，為后續(xù)測(cè)試工作提供依據(jù);確認(rèn)需求規(guī)格說明書的正確性——經(jīng)驗(yàn)在豐富的需求人員也可能有需求遺漏或疏忽;使項(xiàng)目相關(guān)角色，對(duì)需求理解達(dá)成一致，降低修改和溝通成本;需求評(píng)審的主要對(duì)象是需求規(guī)格說明書。

　　需求評(píng)審會(huì)議結(jié)束后，如果沒有問題，那么測(cè)試人員在此階段結(jié)束后，明確了測(cè)試范圍。