這是《落葉》文集里第 322 片落葉寇甸，希望你能喜歡塘偎，不為別的，只為這份堅持拿霉。
第八章 你真的理解了什么是軟件需求嗎吟秩？
當(dāng)我只是個測試執(zhí)行人員
我走進(jìn)老大的辦公室，把我自己梳理的答案告訴了他绽淘，他沖我微微一笑涵防，問了我一個問題：“你真的理解了什么是軟件需求嗎？”
我不假思索地回答道：“當(dāng)然理解啊沪铭，我好歹也看過很多需求文檔壮池，并且評審過不少需求了呀偏瓤。我平時接觸的過的需求文檔和評審，都是由各種各樣的產(chǎn)品功能和產(chǎn)品優(yōu)化組成的椰憋，比如新增一個用戶取消訂單的功能硼补，或者是提高用戶搜索結(jié)果的匹配精準(zhǔn)度等等，所以熏矿，需求就是指的產(chǎn)品一個個功能要求已骇。”
老大說票编，“你跟很多人一樣褪储，都把用戶自己提出的或產(chǎn)品經(jīng)理給出的解決方案當(dāng)作了需求，不管是取消訂單慧域，還是提高搜索結(jié)果匹配精準(zhǔn)度鲤竹，都不是用戶最原始或者說最真實的需求，這些其實都是最后的功能性需求昔榴⌒猎澹”
“我們要理解的不就是最終的功能性需求嗎？”
“你平時看到的的確就是這些功能性需求互订，如果你只是從依據(jù)需求梳理測試點或者設(shè)計測試用例的角度來看吱肌，理解了功能性需求，也差不多滿足要求了仰禽。但是氮墨，如果你想站在測試項目管理者的角度，做好需求的評審吐葵、分析和設(shè)計规揪，那還有些不足∥虑停”
當(dāng)我是個測試項目管理者
我們先來看下軟件需求的基本概念：
- 為了解決問題或達(dá)到目標(biāo)猛铅，用戶所需的條件或能力；
- 為了滿足協(xié)議凤藏、標(biāo)準(zhǔn)奸忽、規(guī)范或其他限定性文檔、系統(tǒng)清笨、系統(tǒng)組件月杉、產(chǎn)品或服務(wù)需要具備的條件或能力刃跛；
- 需求包括發(fā)起人抠艾、客戶和其他干系人的已量化且書面記錄的需要和期望；
我再把老大跟我說了 N 個小時的有關(guān)需求的理解提煉成了一句話：
軟件需求就是為了滿足用戶想解決某個問題桨昙、想達(dá)成某個目標(biāo)检号，或作為某種角色時需求提供的一些功能或非功能性的軟件能力腌歉。
當(dāng)我理解了這個概念之后，也就很清楚自己在評審需求時最應(yīng)該首先弄清楚哪些東西：
- 產(chǎn)品的用戶是誰齐苛，如果不清楚用戶翘盖，也就談不上需求，需求只可能來自用戶的期望凹蜂，而不可能來自產(chǎn)品本身馍驯；
- 用戶有哪些不同的角色，以及每個角色之間的關(guān)系玛痊，和每個角色都有哪些業(yè)務(wù)汰瘫；
- 業(yè)務(wù)流程和邏輯關(guān)系，根據(jù) 1 和 2擂煞，是可以繪制出 Use Case 圖（UML混弥，統(tǒng)一建模語言）的；
- 產(chǎn)品的功能模塊对省、分類蝗拿，模塊之間的關(guān)系和優(yōu)先級，在理清楚不同角色的用戶蒿涎、業(yè)務(wù)流程和邏輯關(guān)系之后哀托，這些也可以梳理出來了；
- 不同角色的用戶是怎么使用每一個功能的劳秋，也就是每一個功能被使用的場景萤捆；
- 非功能性的需求有哪些，比如性能上的要求俗批，安全上的要求俗或，兼容性上的要求等等；
如果弄清楚這些岁忘，到了后面的測試設(shè)計階段辛慰，也是受益匪淺。
《告訴你如何從執(zhí)行測試到管理測試》帶你邁出第（8）步干像！帅腌，點擊這里可查看完整地圖
作者簡介：14 年測試 + 11 年項目管理 + 11 年團隊管理 = 一個測試?yán)媳?/p>
