樣的待定項）；

?、剖剐枨蠓舷到y(tǒng)的整體目標(biāo)；

?、潜ＷC需求項之間的一致性，解決需求項之間可能存在的沖突。

　分析用戶需求

　在很多情形下，分析用戶需求是與獲取用戶需求并行的，主要通過建立模型的方式來描述用戶的需求，為客戶、用戶、開發(fā)方等不同參與方提供一個交流的渠道。這些模型是對需求的抽象，以可視化的方式提供一個易于溝通的橋梁。用戶需求的分析與獲取用戶需求有著相似的步驟，區(qū)別在于分析用戶需求時使用模型來描述，以獲取用戶更明確的需求。分析用戶需求需要執(zhí)行下列活動：

　● 以圖形表示的方式描述系統(tǒng)的整體結(jié)構(gòu)，包括系統(tǒng)的邊界與接口；

　● 通過原型、頁面流或其它方式向用戶提供可視化的界面，用戶可以對需求做出自己的評價；

　● 系統(tǒng)可行性分析，需求實現(xiàn)的技術(shù)可行性、環(huán)境分析、費用分析、時間分析等；

　● 以模型描述系統(tǒng)的功能項、數(shù)據(jù)實體、外部實體、實體之間的關(guān)系、實體之間的狀態(tài)轉(zhuǎn)換等方面的內(nèi)容。 　　

　圖2 DFD示意圖

　用于需求建模的方法有很多種，最常用的包括數(shù)據(jù)流圖（DFD）、實體關(guān)系圖（ERD）和用例圖（Use Case）三種方式。DFD作為結(jié)構(gòu)化系統(tǒng)分析與設(shè)計的主要方法，已經(jīng)得到了廣泛的應(yīng)用，DFD尤其適用于MIS系統(tǒng)的表述。DFD使用四種基本元素來描述系統(tǒng)的行為，過程、實體、數(shù)據(jù)流和數(shù)據(jù)存儲。DFD方法直觀易懂，使用者可以方便地得到系統(tǒng)的邏輯模型和物理模型，但是從DFD圖中無法判斷活動的時序關(guān)系。圖2描述的是某個項目的DFD示意圖。

　ERD方法用于描述系統(tǒng)實體間的對應(yīng)關(guān)系，需求分析階段使用ERD描述系統(tǒng)中實體的邏輯關(guān)系，在設(shè)計階段則使用ERD描述物理表之間的關(guān)系。需求分析階段使用ERD來描述現(xiàn)實世界中的對象。ERD只關(guān)注系統(tǒng)中數(shù)據(jù)間的關(guān)系，而缺乏對系統(tǒng)功能的描述。如果將ERD與DFD兩種方法相結(jié)合，則可以更準(zhǔn)確地描述系統(tǒng)的需求。

　在面向?qū)ο蠓治龅姆椒ㄖ型ǔＪ褂肬se Case來獲取軟件的需求。Use Case通過描述“系統(tǒng)”和“活動者”之間的交互來描述系統(tǒng)的行為。通過分解系統(tǒng)目標(biāo)，Use Case描述活動者為了實現(xiàn)這些目標(biāo)而執(zhí)行的所有步驟。Use Case方法最主要的優(yōu)點，在于它是用戶導(dǎo)向的，用戶可以根據(jù)自己所對應(yīng)的Use Case來不斷細(xì)化自己的需求。此外，使用Use Case還可以方便地得到系統(tǒng)功能的測試用例。

　介紹了需求分析五個步驟中的前兩個步驟（獲取用戶需求、分析用戶需求），繼續(xù)介紹后三個步驟（編寫需求文檔、評審需求文檔、管理需求），并與大家討論相關(guān)實踐問題。

　1、編寫需求文檔

　需求文檔可以使用自然語言或形式化語言來描述，還可以添加圖形的表述方式和模型表征的方式。需求文檔應(yīng)該包括用戶的所有需求（功能性需求和非功能性需求）。

　2、評審需求文檔

　需求文檔完成后，需要經(jīng)過正式評審，以便作為下一階段工作的基礎(chǔ)。一般的評審分為用戶評審和同行評審兩類。用戶和開發(fā)方對于軟件項目內(nèi)容的描述，是以需求規(guī)格說明書作為基礎(chǔ)的；用戶驗收的標(biāo)準(zhǔn)則是依據(jù)需求規(guī)格說明書中的內(nèi)容來制訂，所以評審需求文檔時用戶的意見是第一位的。而同行評審的目的，是在軟件項目初期發(fā)現(xiàn)那些潛在的缺陷或錯誤，避免這些錯誤和缺陷遺漏到項目的后續(xù)階段。

　3、管理需求

  圖1 需求變更流程

　需求的變更是不可避免的，如何以可控的方式管理軟件的需求，對于項目的順利進行有著重要的意義。如果匆匆忙忙地完成用戶調(diào)研與分析，則往往意味著不穩(wěn)定的需求。所以需求管理要保證需求分析各個活動都得