需求的分類
業務需求：反應了客戶對系統，產品的高層次的目標要求，在專案檢視和範圍文件中予以說明。
功能需求：定義了開發人員必須實現的軟體功能，使得使用者能夠完成他們的任務，從而滿足了業務需求。
使用者需求：文件描述了使用者使用產品必須要完成的任務，在使用者說明書明確體現。
eg：業務需求：企業內部要有自己的通訊簿，簡單好用
功能需求：部門管理，聯絡人管理，新增，修改，刪除，匯入匯出等等功能
使用者需求：要能匯入匯出通訊薄；按部門結構顯示企業內人員，有個人名片；可以呼出**，傳送簡訊，搜尋聯絡人
進行測試需求分析的目的：
把使用者需求轉化為功能需求
1.對測試範圍進行度量
2.對處理分支進行度量
3.對需求的業務場景進行度量
4.明確其功能點對應的輸入，處理和輸出
5.把隱式需求轉為明確
測試活動五要素：
測試需求（what）
決定怎麼測（how）
測試時間（when）
測試需求人員（who）
測試環境（where）：測試中需要的技能，工具以及相應的背景知識，測試中可能遇到的風險等等
測試需求力求詳細明確，以避免測試遺漏和誤解
獲取需求的途徑：
相關的業務培訓，評審
其他相關人員溝通
與軟體相關的文件
其他（如舊系統為原型）
測試需求分析
確認功能：
2.輔助功能：輔助完成業務功能的一些功能或者是細節，eg：設定過濾條件
3.資料約束：功能的細節，主要是用於控制在執行功能時，資料的顯示範圍，資料之間的關係等
4.易用性需求：功能的細節，產品中必須提供，便於功能操作使用的一些細節，eg：快捷鍵就是典型的易用性需求
6.引數需求：功能的細節，在功能執行時，需要根據引數設定不同，進行不同處理的細節。
7.許可權需求：功能的細節，指在功能的執行過程，根據不同的許可權進行不同的處理，不包括直接限制某個功能的許可權
8.效能約束：功能的細節，執行功能時必須滿足的效能需求
分析場景：
1.考慮場景的呼叫者：考慮每乙個場景提供的服務是供哪些外部模組或者系統呼叫，找出所有的呼叫者。呼叫前提，約束都要考慮。每乙個呼叫都可以考慮成乙個大的業務流程（一般和外部有互動的業務出錯概率比較大，需要重點關注）
2.考慮系統內部各個場景之間的：形成內部業務流程圖，需要分析每個場景之間的約束關係，執行條件，組織出各種業務流程圖
挖掘隱性需求：？？？
測試員經驗積累：
1.常用的或規定的業務流程
2.各業務流程分支的遍歷
3.明確規定不可使用的業務流程
4.沒有明確規定但是應該不可以執行的業務流程
5.其他異常或者不符合規定的操作
如何進行軟體需求分析
概念 需求的定義包括從使用者角度 系統的外部行為 以及從 開發者角度 一些內部特性 來闡述需求。關鍵的問題是一定要編寫需求文件。我曾經目睹過乙個專案中途更換了所有的 開發者，客戶被迫與新的需求分析者坐到一起。系統的分析人員說 我們想與你談談你的需求。客戶的第一反應便是 我已經將我的要求都告訴你們前任...
如何進行軟體需求分析
如何進行軟體需求分析 1 概念 需求的定義包括從使用者角度 系統的外部行為 以及從開發者角度 一些內部特性 來闡述需求。關鍵的問題是一定要編寫需求文件。我曾經目睹過乙個專案中途更換了所有的開發者，客戶被迫與新的需求分析者坐到一起。系統的分析人員說 我們想與你談談你的需求。客戶的第一反應便是 我已經將...
如何進行業務需求分析
首先，我們應該明確進行需求分析的目的。我認為，進行業務需求分析的直接目的就是為了進行資訊系統的開發，所謂的需求，就是資訊系統建設的需求。如果乙個業務不需要資訊系統就能有效開展，就不需要進行需求分析，直接開展業務就行。進行需求分析，是為開發資訊系統服務。是為了讓系統開發者明白，需要開發乙個怎樣的資訊系...