如果將需求分析階段的工作歸結為編寫(xiě)需求規格說(shuō)明書(shū)，這種簡(jiǎn)化的做法往往是導致項目后期層出不窮問(wèn)題的罪魁禍首。建議采用以下步驟形成軟件需求：獲取用戶(hù)需求→分析用戶(hù)需求→編寫(xiě)需求文檔→評審需求文檔→管理需求。下面我們先來(lái)討論前兩個(gè)步驟（獲取用戶(hù)需求、分析用戶(hù)需求）的做法。
獲取用戶(hù)需求
這是該階段的一個(gè)最重要的任務(wù)。以下為獲取用戶(hù)需求需要執行的活動(dòng)（如圖1所示）。
● 了解客戶(hù)方的所有用戶(hù)類(lèi)型以及潛在的類(lèi)型。然后，根據他們的要求來(lái)確定系統的整體目標和系統的工作范圍。
● 對用戶(hù)進(jìn)行訪(fǎng)談和調研。交流的方式可以是會(huì )議、電話(huà)、電子郵件、小組討論、模擬演示等不同形式。需要注意的是，每一次交流一定要有記錄，對于交流的結果還可以進(jìn)行分類(lèi)，便于后續的分析活動(dòng)。例如，可以將需求細分為功能需求、非功能需求（如響應時(shí)間、平均無(wú)故障工作時(shí)間、自動(dòng)恢復時(shí)間等）、環(huán)境限制、設計約束等類(lèi)型。
● 需求分析人員對收集到的用戶(hù)需求做進(jìn)一步的分析和整理。下面是幾條常見(jiàn)的準則：
?、艑τ谟脩?hù)提出的每個(gè)需求都要知道“為什么”，并判斷用戶(hù)提出的需求是否有充足的理由；
圖1 獲取用戶(hù)需求的活動(dòng)
?、茖⒛欠N以“如何實(shí)現”的表述方式轉換為“實(shí)現什么”的方式，因為需求分析階段關(guān)注的目標是“做什么”，而不是“怎么做”；
?、欠治鲇捎脩?hù)需求衍生出的隱含需求，并識別用戶(hù)沒(méi)有明確提出來(lái)的隱含需求（有可能是實(shí)現用戶(hù)需求的前提條件），這一點(diǎn)往往容易忽略掉，經(jīng)常因為對隱含需求考慮得不夠充分而引起需求變更。
● 需求分析人員將調研的用戶(hù)需求以適當的方式呈交給用戶(hù)方和開(kāi)發(fā)方的相關(guān)人員。大家共同確認需求分析人員所提交的結果是否真實(shí)地反映了用戶(hù)的意圖。需求分析人員在這個(gè)任務(wù)中需要執行下述活動(dòng)：
?、琶鞔_標識出那些未確定的需求項（在需求分析初期往往有很多這樣的待定項）；
?、剖剐枨蠓舷到y的整體目標；
?、潜ＷC需求項之間的一致性，解決需求項之間可能存在的沖突。
分析用戶(hù)需求
在很多情形下，分析用戶(hù)需求是與獲取用戶(hù)需求并行的，主要通過(guò)建立模型的方式來(lái)描述用戶(hù)的需求，為客戶(hù)、用戶(hù)、開(kāi)發(fā)方等不同參與方提供一個(gè)交流的渠道。這些模型是對需求的抽象，以可視化的方式提供一個(gè)易于溝通的橋梁。用戶(hù)需求的分析與獲取用戶(hù)需求有著(zhù)相似的步驟，區別在于分析用戶(hù)需求時(shí)使用模型來(lái)描述，以獲取用戶(hù)更明確的需求。分析用戶(hù)需求需要執行下列活動(dòng)：
● 以圖形表示的方式描述系統的整體結構，包括系統的邊界與接口；
● 通過(guò)原型、頁(yè)面流或其它方式向用戶(hù)提供可視化的界面，用戶(hù)可以對需求做出自己的評價(jià)；
● 系統可行性分析，需求實(shí)現的技術(shù)可行性、環(huán)境分析、費用分析、時(shí)間分析等；
● 以模型描述系統的功能項、數據實(shí)體、外部實(shí)體、實(shí)體之間的關(guān)系、實(shí)體之間的狀態(tài)轉換等方面的內容。
圖2 DFD示意圖
用于需求建模的方法有很多種，最常用的包括數據流圖（DFD）、實(shí)體關(guān)系圖（ERD）和用例圖（Use Case）三種方式。DFD作為結構化系統分析與設計的主要方法，已經(jīng)得到了廣泛的應用，DFD尤其適用于MIS系統的表述。DFD使用四種基本元素來(lái)描述系統的行為，過(guò)程、實(shí)體、數據流和數據存儲。DFD方法直觀(guān)易懂，使用者可以方便地得到系統的邏輯模型和物理模型，但是從DFD圖中無(wú)法判斷活動(dòng)的時(shí)序關(guān)系。圖2描述的是某個(gè)項目的DFD示意圖。
ERD方法用于描述系統實(shí)體間的對應關(guān)系，需求分析階段使用ERD描述系統中實(shí)體的邏輯關(guān)系，在設計階段則使用ERD描述物理表之間的關(guān)系。需求分析階段使用ERD來(lái)描述現實(shí)世界中的對象。ERD只關(guān)注系統中數據間的關(guān)系，而缺乏對系統功能的描述。如果將ERD與DFD兩種方法相結合，則可以更準確地描述系統的需求。
在面向對象分析的方法中通常使用Use Case來(lái)獲取軟件的需求。Use Case通過(guò)描述“系統”和“活動(dòng)者”之間的交互來(lái)描述系統的行為。通過(guò)分解系統目標，Use Case描述活動(dòng)者為了實(shí)現這些目標而執行的所有步驟。Use Case方法最主要的優(yōu)點(diǎn)，在于它是用戶(hù)導向的，用戶(hù)可以根據自己所對應的Use Case來(lái)不斷細化自己的需求。此外，使用Use Case還可以方便地得到系統功能的測試用例。
=============================================
上一期，我們介紹了需求分析五個(gè)步驟中的前兩個(gè)步驟（獲取用戶(hù)需求、分析用戶(hù)需求），本期將繼續介紹后三個(gè)步驟（編寫(xiě)需求文檔、評審需求文檔、管理需求），并與大家討論相關(guān)實(shí)踐問(wèn)題。
1、編寫(xiě)需求文檔
需求文檔可以使用自然語(yǔ)言或形式化語(yǔ)言來(lái)描述，還可以添加圖形的表述方式和模型表征的方式。需求文檔應該包括用戶(hù)的所有需求（功能性需求和非功能性需求）。
2、評審需求文檔
需求文檔完成后，需要經(jīng)過(guò)正式評審，以便作為下一階段工作的基礎。一般的評審分為用戶(hù)評審和同行評審兩類(lèi)。用戶(hù)和開(kāi)發(fā)方對于軟件項目?jì)热莸拿枋?，是以需求規格說(shuō)明書(shū)作為基礎的；用戶(hù)驗收的標準則是依據需求規格說(shuō)明書(shū)中的內容來(lái)制訂，所以評審需求文檔時(shí)用戶(hù)的意見(jiàn)是第一位的。而同行評審的目的，是在軟件項目初期發(fā)現那些潛在的缺陷或錯誤，避免這些錯誤和缺陷遺漏到項目的后續階段。
3、管理需求
圖1 需求變更流程
需求的變更是不可避免的，如何以可控的方式管理軟件的需求，對于項目的順利進(jìn)行有著(zhù)重要的意義。如果匆匆忙忙地完成用戶(hù)調研與分析，則往往意味著(zhù)不穩定的需求。所以需求管理要保證需求分析各個(gè)活動(dòng)都得到了充分的執行。對于需求變更的管理，則主要使用需求變更流程和需求跟蹤矩陣的管理方式。需求變更流程和需求跟蹤矩陣分別如圖1和圖2所示。
圖2 需求跟蹤矩陣
常見(jiàn)問(wèn)題及建議
Q、客戶(hù)與最終用戶(hù)的區別是什么？
A、可以借助圖3來(lái)說(shuō)明它們之間的區別。
圖3 需求獲取渠道示意圖
軟件需求來(lái)自系統工程與客戶(hù)兩個(gè)方面，其中客戶(hù)是主要的需求提供者（系統工程需求也來(lái)自于客戶(hù)）?？蛻?hù)需要搜集其最終用戶(hù)的需求并考慮自身的需求，然后再提供給開(kāi)發(fā)方。假如客戶(hù)并未去認真搜集最終用戶(hù)的需求，開(kāi)發(fā)方便需要做到這一點(diǎn)，因為系統最終要滿(mǎn)足最終用戶(hù)的需求。
Q、如何進(jìn)行用戶(hù)訪(fǎng)談？
A、首先，一定要事先確定訪(fǎng)談的目的和提綱。其次，因為用戶(hù)往往并不知道應該提供哪些方面的需求，所以需要開(kāi)發(fā)人員引導。
Q、用戶(hù)訪(fǎng)談內容是什么？
A、首先，請用戶(hù)描述他們如何完成自己當前的工作，并與用戶(hù)一起抽象出一個(gè)工作流程或工作模型。然后，在得到用戶(hù)的認可后，向用戶(hù)解釋自己是怎樣來(lái)實(shí)現這些功能的，并說(shuō)明哪些環(huán)節可以用自動(dòng)化方式實(shí)現等。
Q、采用哪一種方式做需求分析最好？
A、不同的需求分析有不同的特點(diǎn)。還沒(méi)有哪一種方法可以完全替代別的方法，否則，現在就不會(huì )存在不同的需求建模方式了。一般來(lái)說(shuō)，可以使用DFD＋ERD來(lái)描述那些功能層次比較清晰的需求；而USE CASE則適于描述功能結構復雜的需求。做需求分析的目的是為了建立需求的模型，不同的子系統有可能使用不同的建模方法。
Q、怎樣做原型，原型的目的是什么？
A、通常使用原型分析方法來(lái)幫助開(kāi)發(fā)方進(jìn)一步獲取用戶(hù)需求或讓用戶(hù)確認需求。開(kāi)發(fā)方往往先向用戶(hù)提供一個(gè)可視界面作為原型，并在界面上布置必要的元素以演示用戶(hù)所需要的功能?？梢允褂玫谒拇Z(yǔ)言（例如Visual Basic、Delphi等）來(lái)快速生成用戶(hù)界面，也可以使用FrontPage等網(wǎng)頁(yè)制作工具來(lái)生成用戶(hù)可視的頁(yè)面流。
原型的目的往往是獲取需求。但有時(shí)也使用原型的方式來(lái)驗證關(guān)鍵技術(shù)或技術(shù)難點(diǎn)。對于技術(shù)原型，界面則往往被忽略掉。
聯(lián)系客服
