怎樣做需求分析

        如果將需求分析階段的工作歸結為編寫需求規格說明書，這種簡化的做法往往是導致項目後期層出不窮問題的罪魁禍首。建議採用以下步驟形成軟體需求：擷取使用者需求→分析使用者需求→編寫需求文檔→評審需求文檔→管理需求。下面我們先來討論前兩個步驟（擷取使用者需求、分析使用者需求）的做法。

　　擷取使用者需求

　　這是該階段的一個最重要的任務。以下為擷取使用者需求需要執行的活動（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所示。

　　

　　圖2 需求跟蹤矩陣

　　常見問題及建議

　　Q、客戶與終端使用者的區別是什嗎？

　　A、可以藉助圖3來說明它們之間的區別。

　　

　　圖3 需求萃取渠道

　　軟體需求來自系統工程與客戶兩個方面，其中客戶是主要的需求提供者（系統工程需求也來自於客戶）。客戶需要搜集其終端使用者的需求並考慮自身的需求，然後再提供給開發方。假如客戶並未去認真搜集終端使用者的需求，開發方便需要做到這一點，因為系統最終要滿足終端使用者的需求。

　　Q、如何進行使用者訪談？

　　A、首先，一定要事先確定訪談的目的和提綱。其次，因為使用者往往並不知道應該提供哪些方面的需求，所以需要開發人員引導。

　　Q、使用者訪談內容是什嗎？

　　A、首先，請使用者描述他們如何完成自己當前的工作，並與使用者一起抽象出一個工作流程或工作模型。然後，在得到使用者的認可後，向使用者解釋自己是怎樣來實現這些功能的，並說明哪些環節可以用自動化方式實現等。

　　Q、採用哪一種方式做需求分析最好？

　　A、不同的需求分析有不同的特點。還沒有哪一種方法可以完全替代別的方法，否則，現在就不會存在不同的需求建模方式了。一般來說，可以使用DFD＋ERD來描述那些功能層次比較清晰的需求；而USE CASE則適於描述功能結構複雜的需求。做需求分析的目的是為了建立需求的模型，不同的子系統有可能使用不同的建模方法。

　　Q、怎樣做原型，原型的目的是什嗎？

　　A、通常使用原型分析方法來協助開發方進一步擷取使用者需求或讓使用者確認需求。開發方往往先向使用者提供一個視覺化介面作為原型，並在介面上布置必要的元素以示範使用者所需要的功能。可以使用第四代語言（例如Visual Basic、Delphi等）來快速產生使用者介面，也可以使用FrontPage等網頁製作工具來產生使用者可視的頁面流。

　　原型的目的往往是擷取需求。但有時也使用原型的方式來驗證關鍵技術或技術痛點。對於技術原型，介面則往往被忽略掉。