需求分析和評審簡述
by:授客 QQ：1033553122
說明：
以下說明可能不完全正确，主要是給新手對“需求分析和評審”有個大緻的認識
A. 需求分類
是對需求按照可以管理的方式分組。可分為以下：
(一) 原始需求(客戶需求)：原始需求可視為客戶的需求，而客戶是不了解軟體開發技術的，提出的需求是沒有辦法直接用于開發的，輸出文檔：市場需求文檔(Market Requirement Document，MRD)
(二) 産品需求：産品設計人員或者需求分析人員根據原始需求、結合軟體可以實作的功能形成的需求，我個人了解應該就是所說的業務需求，這點待讨論.輸出文檔：産品需求文檔(Product Requirement Document，PRD)
(三) 軟體需求：軟體開發人員根據軟體實作原理進一步将産品需求詳細化，輸出文檔：軟體需求規格說明書（Software Requirements Specification），簡稱SRS
(四) 測試需求：開發人員不了解如何對軟體進行測試，無法将需求詳細到可直接用于測試，是以測試人員還需要将軟體需求轉化為測試需求
客戶需求->産品需求(業務需求)->軟體需求->測試需求，可看成需求由簡單到詳細的過程，對于每個需求類型都要界定需求實作的優先級、工作量和風險
一個經典的例子：
小明說，他要吃豬骨頭火鍋(客戶需求)，80塊吧，但沒想到又碰到了授客。
授客：“真的想吃？”
小明：“想吃！”
授客：“為什麼？”
小明：“我餓了……”（找到了本質）
授客：“哦，這裡是兩個饅頭（産品需求），請你吃，才1塊錢”
……
小知識：客戶和使用者的差別
客戶是為産品或服務買單的人。
使用者是使用産品或服務的人，和産品或服務産生直接的互動過程。
客戶是對産品或服務形成服務請求和達成買賣關系的人或實體。也可以說是對産品或服務購買有決策權的相關人，這裡包含技術決策者和業務決策者等系列人。
客戶一般關注的是價格和效果，效果包括了産品使用後的工作效率提升，也隐含了上司的業績提升。有的時候客戶既不關心價格也不關心效果，他關心自己的個人利益。是以找到客戶的真實意圖是拿單的關鍵所在。
使用者對産品的關注點是好用，簡單，提高效率，帶來便利。産品最終是為使用者服務的，即使産品被客戶買單，但最終使用者用不起來，那麼這也是個失敗的産品。
是以，産品被使用者認可，使用後能提升工作效率，同時給客戶帶來利益，這才是雙赢的局面。
B. 測試需求
什麼是測試需求，見名知意，要測啥？簡單說也就是設計測試用例中的驗證點，測試依據，這裡包括功能性測試需求，也包括非功能性能測試需求。做測試的要學會從需求規格說明書中挖掘需要測試的驗證點，進行用例設計。
例子：從軟體需求規格說明書中擷取測試需求
（舉例目的在于讓新手了解寫用例并不是直接複制需求說明書中的内容，而是要挖掘測試點）
假設需求規格說明書中有如下一功能需求
| 功能名稱 | 快速搜尋 |
| 功能描述 | 可以根據人名或文章、标題的内容進行搜尋 |
| 使用者及角色 | 注冊使用者 |
| 補充說明 | 無 |
輸入項：略
處理流程：略
輸出項：略
即便僅有功能描述的情況下，我們也可對其進行挖掘測試需求：
1.輸入是否支援中文？數字？英文？空格？
2.是否可以輸入較長的搜尋字元？
3.輸入是否支援模糊搜尋？
……
确定以上問題為測試需求後即可把它們作為用例設計的驗證點，進行用例設計
C.
需求評審
1．需求階段評審的角色和職責
一句話，根據具體情況選擇相關人員，充當相關角色，履行相關職責，大家也别吐槽我，現實就是這樣，别去記憶這些死規則了
2．好的需求應具備的特點
完整性：每一項需求都必須将所有要實作的功能描述清楚，以使開發人員獲得設計和實作這些功能所需的所有必要資訊。
正确性：每一項需求都必須準确的陳述其要開發的功能。
一緻性：指與其它軟體需求或高層需求不相沖突
可行性：每一項需求都必須是已系統和環境的權能和限制範圍可以實施的。
無二義性：對所有需求說明的讀者都隻能有一個明确統一的解釋，由于自然語言極易導緻二義性，是以盡量把每項需求簡明的使用者性的語言表達出來。
健壯性：需求的說明中是否對可能出現的異常進行了分析，并且對這些異常進行了容錯處理。
必要性：可了解為每項需求都是用來授權你編寫文檔的“根源”，要使每項需求都能回溯至某項客戶的輸入。
可測試性：每項需求都能通過設計測試用例或其它的驗證方法來進行測試。
可修改性：每項需求隻應在SRS中出現一次。這樣更改時容易保持一緻性。另外，使用目錄清單、索引和互相參照清單方法使軟體需求規格說明書更容易修改。
可跟蹤性：應能在每項軟體需求與它的根源和設計元素、源代碼、測試用例之間建立起連結鍊，這種可跟蹤性要求每項需求以一種結構化的，粒度好(f
i n e - g r a i n e d )的方式編寫并單獨标明，而不是大段大段的叙述。
配置設定優先級：應當對所有的需求配置設定優先級。如果把所有的需求都看作同樣的重要，那麼項目管理者在開發或節省預算或排程中就喪失控制自由度
以上特點也是需求評審的要點，評審前可以根據實際情況指定需求評審檢查表來幫助評審。
可以根據以上特點對需求進行評審
3．軟體需求評審輸出
還是一句話，根據具體情況适當的做好評審記錄，形式不限，輸出文檔名稱也不限，随便你取，^^内容才是重點
4．組織需求評審原則
還是一句話，組織自己定吧，适合就好，效率優先
^^，别吐槽，沒騙你的，不信你百度去，可以百度出不同答案
5.需求評審形式
總
體來說可以分為正式評審與非正式評審。正式評審是指通過開評審會的形式，組織多個專家，将需求涉及到的人員集合在一起，并定義好參與評審人員的角色和職
責，對需求進行正規的會議評審。而非正式的評審并沒有這種嚴格的組織形式，一般也不需要将人員集合在一起評審，而是通過電子郵件、檔案彙簽甚至是網絡聊天
等多種形式對需求進行評審。2種形式各有利弊，在評審時，靈活地利用這2種方式。
仔細來說，可以分為如下：
(1)互相評審、交叉評審(
Pear-to-pear Review
)，甲和乙在一個項目組，處在一個領域，但工作内容不同，甲的工作成果交給乙審查，乙的工作成果交給甲審查，互相評審是最不正式的一種評審形式，但應用友善、有效，被普遍使用
(2)輪查(
Pass-round
)，又稱配置設定審查方法，是一種異步評審方式。作者将需要評審的内容發送給各位評審員，并收集他們的回報意見。是一種一種非正式的同行評審。
(3)走查(Walkthrough
)，産品的作者将産品在現場向一組同僚介紹，描述産品要有怎樣的功能、結構，從頭到尾走一遍，以收集大家的意見。希望參與評審的其他同僚可以發現産品中的錯誤，并能進行現場讨論這種形式介于正式和非正式之間，其應用普遍。是一種一種非正式的同行評審
(4)小組評審(Group
Review)，通過正式的小組會議完成評審工作，是有計劃的和結構化的評審形式。評審定義了評審會議中的各種角色和相應的責任，所有參與者在評審會議的前幾天就拿到了評審材料，并對該材料進行了獨立研究。
(5)審查(Inspection
)。審查和小組評審很相似，但更為嚴格，是最系統化、最嚴密的評審形式，包含了制定計劃、準備群組織會議、跟蹤和分析審查結果等。
6.需求評審的政策
(1)分層次評審
一般，可以分成如下的層次：
*目标性需求指整個系統需要達到的業務目标，是最高層次的、基本的需求，是企業的高層管理人員所關注的。如果讓具體的操作人員去評審目标性需求，容易導緻“撿了芝麻，丢了西瓜”的現象。
*功能性需求指整個系統需要實作的功能和任務，是目标之下的第二層需求，是企業的中層管理人員所關注的。
*操作性需求指完成每個任務具體的人機互動〔UI)需求，是企業的具體操作人員所關注的。
(2)分階段評審
應該在需求形成的過程中進行分階段的多次評審，而不是在需求最終形成後才進行僅有的一次評審分階段評審可以将原本需要進行的大規模評審拆分成各個小規模的評審，這樣就降低了需求分析返工的風險，提高了評審的品質。
這點對于靈活開發模式特别有效。需求按版本為機關劃分，根據版本進行需求評審（确定做啥，是不是那樣做），通過後開發針對該版本需求進行開發，測試根據需求進行用例編寫和維護，然後按這種模式進行疊代。
7.注意事項
精心挑選評審人員->定制規範化評審流程->準備好評審材料->做好結果跟蹤工作等
作者：授客
QQ：1033553122
全國軟體測試QQ交流群：7156436
Git位址：https://gitee.com/ishouke
友情提示：限于時間倉促，文中可能存在錯誤，歡迎指正、評論！
作者五行缺錢，如果覺得文章對您有幫助，請掃描下邊的二維碼打賞作者，金額随意，您的支援将是我繼續創作的源動力，打賞後如有任何疑問，請聯系我!!!
微信打賞
支付寶打賞 全國軟體測試交流QQ群