如果將需求分析階段的工作歸結為編寫需求規格說明書，這種簡化的做法往往是導致專案後期層出不窮問題的罪魁禍首。建議採用以下步驟形成軟體需求：獲取使用者需求→分析使用者需求→編寫需求文件→評審需求文件→管理需求。
下面我們先來討論前兩個步驟（獲取使用者需求、分析使用者需求）的做法。
獲取使用者需求
這是該階段的乙個最重要的任務。以下為獲取使用者需求需要執行的活動（如圖1所示）。
● 了解客戶方的所有使用者型別以及潛在的型別。然後，根據他們的要求來確定系統的整體目標和系統的工作範圍。
● 對使用者進行訪談和調研。交流的方式可以是會議、**、電子郵件、小組討論、模擬演示等不同形式。需要注意的是，每一次交流一定要有記錄，對於交流的結果還可以進行分類，便於後續的分析活動。
例如，可以將需求細分為功能需求、非功能需求（如響應時間、平均無故障工作時間、自動恢復時間等）、環境限制、設計約束等型別。
● 需求分析人員對收集到的使用者需求做進一步的分析和整理。下面是幾條常見的準則：
⑴對於使用者提出的每個需求都要知道「為什麼」，並判斷使用者提出的需求是否有充足的理由；
圖1 獲取使用者需求的活動
⑵將那種以「如何實現」的表述方式轉換為「實現什麼」的方式，因為需求分析階段關注的目標是「做什麼」，而不是「怎麼做」；
⑶分析由使用者需求衍生出的隱含需求，並識別使用者沒有明確提出來的隱含需求（有可能是實現使用者需求的前提條件），這一點往往容易忽略掉，經常因為對隱含需求考慮得不夠充分而引起需求變更。
● 需求分析人員將調研的使用者需求以適當的方式呈交給使用者方和開發方的相關人員。大家共同確認需求分析人員所提交的結果是否真實地反映了使用者的意圖。需求分析人員在這個任務中需要執行下述活動：
⑴明確標識出那些未確定的需求項（在需求分析初期往往有很多這樣的待定項）；
⑵使需求符合系統的整體目標；
⑶保證需求項之間的一致性，解決需求項之間可能存在的衝突。
分析使用者需求
在很多情形下，分析使用者需求是與獲取使用者需求並行的，主要通過建立模型的方式來描述使用者的需求，為客戶、使用者、開發方等不同參與方提供乙個交流的渠道。這些模型是對需求的抽象，以視覺化的方式提供乙個易於溝通的橋梁。使用者需求的分析與獲取使用者需求有著相似的步驟，區別在於分析使用者需求時使用模型來描述，以獲取使用者更明確的需求。
分析使用者需求需要執行下列活動：
● 以圖形表示的方式描述系統的整體結構，包括系統的邊界與介面；
● 通過原型、頁面流或其它方式向使用者提供視覺化的介面，使用者可以對需求做出自己的評價；
● 系統可行性分析，需求實現的技術可行性、環境分析、費用分析、時間分析等；
● 以模型描述系統的功能項、資料實體、外部實體、實體之間的關係、實體之間的狀態轉換等方面的內容。
圖2 dfd示意圖
用於需求建模的方法有很多種，最常用的包括資料流圖（dfd）、實體關係圖（erd）和用例圖（use case）三種方式。dfd作為結構化系統分析與設計的主要方法，已經得到了廣泛的應用，dfd尤其適用於mis系統的表述。dfd使用四種基本元素來描述系統的行為，過程、實體、資料流和資料儲存。
dfd方法直觀易懂，使用者可以方便地得到系統的邏輯模型和物理模型，但是從dfd圖中無法判斷活動的時序關係。圖2描述的是某個專案的dfd示意圖。
erd方法用於描述系統實體間的對應關係，需求分析階段使用erd描述系統中實體的邏輯關係，在設計階段則使用erd描述物理表之間的關係。需求分析階段使用erd來描述現實世界中的物件。erd只關注系統中資料間的關係，而缺乏對系統功能的描述。
如果將erd與dfd兩種方法相結合，則可以更準確地描述系統的需求。
在物件導向分析的方法中通常使用use case來獲取軟體的需求。use case通過描述「系統」和「活動者」之間的互動來描述系統的行為。通過分解系統目標，use case描述活動者為了實現這些目標而執行的所有步驟。
use case方法最主要的優點，在於它是使用者導向的，使用者可以根據自己所對應的use case來不斷細化自己的需求。此外，使用use case還可以方便地得到系統功能的測試用例。
介紹了需求分析五個步驟中的前兩個步驟（獲取使用者需求、分析使用者需求），繼續介紹後三個步驟（編寫需求文件、評審需求文件、管理需求），並與大家討論相關實踐問題。
1、編寫需求文件
需求文件可以使用自然語言或形式化語言來描述，還可以新增圖形的表述方式和模型表徵的方式。需求文件應該包括使用者的所有需求（功能性需求和非功能性需求）。
2、評審需求文件
需求文件完成後，需要經過正式評審，以便作為下一階段工作的基礎。一般的評審分為使用者評審和同行評審兩類。使用者和開發方對於軟體專案內容的描述，是以需求規格說明書作為基礎的；使用者驗收的標準則是依據需求規格說明書中的內容來制訂，所以評審需求文件時使用者的意見是第一位的。
而同行評審的目的，是在軟體專案初期發現那些潛在的缺陷或錯誤，避免這些錯誤和缺陷遺漏到專案的後續階段。
3、管理需求
專案管理：怎樣做需求分析收藏
如果將需求分析階段的工作歸結為編寫需求規格說明書，這種簡化的做法往往是導致專案後期層出不窮問題的罪魁禍首。建議採用以下步驟形成軟體需求：獲取使用者需求→分析使用者需求→編寫需求文件→評審需求文件→管理需求。
下面我們先來討論前兩個步驟（獲取使用者需求、分析使用者需求）的做法。
獲取使用者需求
這是該階段的乙個最重要的任務。以下為獲取使用者需求需要執行的活動（如圖1所示）。
● 了解客戶方的所有使用者型別以及潛在的型別。然後，根據他們的要求來確定系統的整體目標和系統的工作範圍。
● 對使用者進行訪談和調研。交流的方式可以是會議、**、電子郵件、小組討論、模擬演示等不同形式。需要注意的是，每一次交流一定要有記錄，對於交流的結果還可以進行分類，便於後續的分析活動。
例如，可以將需求細分為功能需求、非功能需求（如響應時間、平均無故障工作時間、自動恢復時間等）、環境限制、設計約束等型別。
● 需求分析人員對收集到的使用者需求做進一步的分析和整理。下面是幾條常見的準則：
⑴對於使用者提出的每個需求都要知道「為什麼」，並判斷使用者提出的需求是否有充足的理由；
圖1 獲取使用者需求的活動
⑵將那種以「如何實現」的表述方式轉換為「實現什麼」的方式，因為需求分析階段關注的目標是「做什麼」，而不是「怎麼做」；
⑶分析由使用者需求衍生出的隱含需求，並識別使用者沒有明確提出來的隱含需求（有可能是實現使用者需求的前提條件），這一點往往容易忽略掉，經常因為對隱含需求考慮得不夠充分而引起需求變更。
● 需求分析人員將調研的使用者需求以適當的方式呈交給使用者方和開發方的相關人員。大家共同確認需求分析人員所提交的結果是否真實地反映了使用者的意圖。需求分析人員在這個任務中需要執行下述活動：
⑴明確標識出那些未確定的需求項（在需求分析初期往往有很多這樣的待定項）；
⑵使需求符合系統的整體目標；
⑶保證需求項之間的一致性，解決需求項之間可能存在的衝突。
分析使用者需求
在很多情形下，分析使用者需求是與獲取使用者需求並行的，主要通過建立模型的方式來描述使用者的需求，為客戶、使用者、開發方等不同參與方提供乙個交流的渠道。這些模型是對需求的抽象，以視覺化的方式提供乙個易於溝通的橋梁。使用者需求的分析與獲取使用者需求有著相似的步驟，區別在於分析使用者需求時使用模型來描述，以獲取使用者更明確的需求。
分析使用者需求需要執行下列活動：
● 以圖形表示的方式描述系統的整體結構，包括系統的邊界與介面；
● 通過原型、頁面流或其它方式向使用者提供視覺化的介面，使用者可以對需求做出自己的評價；
● 系統可行性分析，需求實現的技術可行性、環境分析、費用分析、時間分析等；
● 以模型描述系統的功能項、資料實體、外部實體、實體之間的關係、實體之間的狀態轉換等方面的內容。
圖2 dfd示意圖
用於需求建模的方法有很多種，最常用的包括資料流圖（dfd）、實體關係圖（erd）和用例圖（use case）三種方式。dfd作為結構化系統分析與設計的主要方法，已經得到了廣泛的應用，dfd尤其適用於mis系統的表述。dfd使用四種基本元素來描述系統的行為，過程、實體、資料流和資料儲存。
dfd方法直觀易懂，使用者可以方便地得到系統的邏輯模型和物理模型，但是從dfd圖中無法判斷活動的時序關係。圖2描述的是某個專案的dfd示意圖。
erd方法用於描述系統實體間的對應關係，需求分析階段使用erd描述系統中實體的邏輯關係，在設計階段則使用erd描述物理表之間的關係。需求分析階段使用erd來描述現實世界中的物件。erd只關注系統中資料間的關係，而缺乏對系統功能的描述。
如果將erd與dfd兩種方法相結合，則可以更準確地描述系統的需求。
在物件導向分析的方法中通常使用use case來獲取軟體的需求。use case通過描述「系統」和「活動者」之間的互動來描述系統的行為。通過分解系統目標，use case描述活動者為了實現這些目標而執行的所有步驟。
use case方法最主要的優點，在於它是使用者導向的，使用者可以根據自己所對應的use case來不斷細化自己的需求。此外，使用use case還可以方便地得到系統功能的測試用例。
介紹了需求分析五個步驟中的前兩個步驟（獲取使用者需求、分析使用者需求），繼續介紹後三個步驟（編寫需求文件、評審需求文件、管理需求），並與大家討論相關實踐問題。
1、編寫需求文件
需求文件可以使用自然語言或形式化語言來描述，還可以新增圖形的表述方式和模型表徵的方式。需求文件應該包括使用者的所有需求（功能性需求和非功能性需求）。
2、評審需求文件
需求文件完成後，需要經過正式評審，以便作為下一階段工作的基礎。一般的評審分為使用者評審和同行評審兩類。使用者和開發方對於軟體專案內容的描述，是以需求規格說明書作為基礎的；使用者驗收的標準則是依據需求規格說明書中的內容來制訂，所以評審需求文件時使用者的意見是第一位的。
而同行評審的目的，是在軟體專案初期發現那些潛在的缺陷或錯誤，避免這些錯誤和缺陷遺漏到專案的後續階段。
3、管理需求
圖1 需求變更流程
需求的變更是不可避免的，如何以可控的方式管理軟體的需求，對於專案的順利進行有著重要的意義。如果匆匆忙忙地完成使用者調研與分析，則往往意味著不穩定的需求。所以需求管理要保證需求分析各個活動都得到了充分的執行。
對於需求變更的管理，則主要使用需求變更流程和需求跟蹤矩陣的管理方式。需求變更流程和需求跟蹤矩陣分別如圖1和圖2所示。
怎樣做測試需求分析
專案測試需求分析 1.什麼是測試需求？確切地講，所謂的測試需求就是在專案中要測試什麼。我們在測試活動中，首先需要明確測試需求 what 才能決定怎麼測 how 測試時間 when 需要多少人 who 測試的環境是什麼 where 測試中需要的技能 工具以及相應的背景知識，測試中可能遇到的風險等等，以...
採購管理專案需求分析
一 客觀技術需求 傳統採購管理的不足之處 1.缺乏科學的採購計畫，交貨及時性差，採購周期長，採購計畫隨意性大，一方面部分物資庫存積壓，另一方面 缺貨斷貨，緊急救火，臨時抱佛腳的情況時有發生。2.業務資訊共享性差，大多採購業務通過 傳真進 行，手工單據傳輸，甚至上門提貨採購，交易方式落後，辦 公自動化...
怎樣做自我分析
知己知彼百戰百勝，認識自己很重要 1.請列出目前所有託延的事情原因 2.請列出目前生活中所有的問題原因 3.請 在未來一年中可能面臨的每乙個問題原因 4.請列出目前工作中所有必須要改進的地方原因 5.請列出目前工作中所有必須要改進的地方原因 6.在過去十年中你做了哪些重要的決定請列出來原因 7.在過...