http://www.caixiaodong.com/archives/56.html

需求分析活動解決軟件開發(fā)“做什么”的問題?？蛻魧τ谛枨蟮恼J知并不清晰，且經(jīng)常同時包含了幾個層次的需求概念，提交給軟件項目組，要求按需求實現(xiàn)。需求分析活動的目標，是為后續(xù)各活動提供一個穩(wěn)定的需求文檔，作為軟件開發(fā)的“輸入”。

一、需求的層次

需求通常分為3個層次：業(yè)務需求、用戶需求、功能需求。業(yè)務需求即客戶希望通過該系統(tǒng)實現(xiàn)的業(yè)務目標，例如通過該系統(tǒng)運行某種業(yè)務獲得收入，以及與 其它應用系統(tǒng)在概念層次上的分工等。業(yè)務需求描述的是業(yè)務領域的問題，應當向客戶方負責人或業(yè)務專家收集獲得。業(yè)務需求一般最穩(wěn)定，不會發(fā)生顯著變更。

用戶需求是指具體的“用戶”希望如何使用該系統(tǒng)。行業(yè)應用系統(tǒng)都有很多類別的用戶，例如：采編錄入信息的采編員、面向公眾客戶的業(yè)務受理員、班組 長、使用報表的各級領導?？梢酝ㄟ^向各個用戶走訪獲取用戶需求，匯總成文檔后，再向客戶負責人進行確認。由于各個用戶對于系統(tǒng)應當如何使用系統(tǒng)的想法是不 同的，有時甚至是沖突的，因此，用戶需求比較容易發(fā)生變更。

功能需求是指軟件系統(tǒng)應實現(xiàn)的功能。功能需求的視角不是用戶，而是軟件開發(fā)者。確保功能需求盡可能不發(fā)生變更，是需求分析的目標之一。

二、需求分析活動

縱觀50年軟件工程史，無數(shù)失敗的項目與需求的不確定有關。在項目之初，確定了一個需求范疇，而當項目深入，需求的反復變更耗盡了所有人的心力，最 終草率收場或是不了了之。軟件開發(fā)是對真實世界的模擬，行業(yè)應用軟件則模擬了客戶企業(yè)的業(yè)務流程。這就需要一個先抽象，再具象的過程。需求分析，是將客戶 企業(yè)實際運作的流程，以及各個用戶所希望運作的流程抽象出來，成為軟件開發(fā)者可以理解的文本。之后，再由軟件開發(fā)者通過設計、編碼實現(xiàn)等活動，將其具體 化，成為可操作的軟件系統(tǒng)。

因此，需求分析活動，重在分析?？蛻艨陬^或書面提出的需求文本，可能包括業(yè)務需求，也包括用戶需求，甚至還會對功能模塊的查詢條件、作出指定。這些 不同層次的需求應當分類整理。對于業(yè)務需求，應當充分理解，勾勒出客戶的業(yè)務流程圖，盡管這個業(yè)務流程可能超出了本系統(tǒng)的范圍。對于用戶需求，應仔細鑒 別，各個用戶的要求是否存在沖突，是否與業(yè)務需求沖突？對于功能需求，應當理清用戶到底想要什么，實際上，他們并不真的關心功能需求，而只是在表述時將其 表達為功能需求。例如，對于報表需求，可能表述為需要哪幾張報表，報表的格式是什么。實際上，他們真正想要的，是那些特點列的業(yè)務數(shù)據(jù)能夠被方便的獲得。

三、需求的概念完整性

一份完整的需求，應是一個完整的體系，即《人月神話》一書中反復出現(xiàn)的一個詞匯：概念完整性。業(yè)務需求，體現(xiàn)了 客戶高層對系統(tǒng)的目標和定位；從業(yè)務需求層次看來，系統(tǒng)與周邊系統(tǒng)的關系清晰，使用一張數(shù)據(jù)流圖，能夠清晰的看到數(shù)據(jù)從周邊系統(tǒng)如何流入該系統(tǒng)，如何加 工，再如何流出到周邊系統(tǒng)。如果一類數(shù)據(jù)不是由本系統(tǒng)錄入的，也沒有其他數(shù)據(jù)來源，卻能夠直接流向周邊系統(tǒng)，那么一定是哪里遺漏了。系統(tǒng)能夠表述的很簡單，這就是業(yè)務需求層面的概念完整性。

在用戶需求層次，各個用戶使用系統(tǒng)的方式都被充分表述，同一個業(yè)務功能被多個用戶使用，在操作權(quán)限上或有不同，但不存在明顯沖突。用戶需求與業(yè)務需 求一致，也可以認為用戶需求是業(yè)務需求的一種實現(xiàn)（具體化）。業(yè)務需求的各個數(shù)據(jù)流都在各個用戶節(jié)點上充分表達，即體現(xiàn)為具體用戶對業(yè)務數(shù)據(jù)的操作。

功能需求是軟件開發(fā)者視角的需求，由于功能需求的側(cè)重點在于系統(tǒng)功能，而非業(yè)務屬性，因此對概念完整性的要求是：不丟失用戶需求信息。由于大多數(shù)開發(fā)者不可能直接接觸用戶，因此要求功能需求的表述規(guī)格化。

特別需要說明的一點，在我看來，業(yè)務需求、用戶需求、功能需求實際上是一樣事物的三個視圖，分別反映了三個不同視角所看到的景象。例如一個圓柱體， 業(yè)務需求是從上向下看，用戶需求則從外往內(nèi)看，功能需求則是從圓柱體內(nèi)部向外看。業(yè)務需求、用戶需求、功能需求是對同一個事物的表述，因此天然具備概念完 整性的特點。當然，需要在我們的需求分析活動中描述出來。

四、需求分析活動的文檔

在軟件項目組接觸到這個項目的時候，通常業(yè)務需求已經(jīng)明確，但用戶需求還是非?；靵y的?？蛻籼峤坏男枨竺枋鑫臋n混雜有業(yè)務需求、用戶需求和功能需 求。對大多數(shù)需求分析活動來說，首先分析用戶需求，輸出《用戶需求說明書》，并提交給客戶確認。在《用戶需求說明書》中，建議加上對業(yè)務需求的理解，例如 數(shù)據(jù)流圖，讓客戶一并確認，并及時糾正理解不當?shù)牟糠帧?/p>

一般的，《用戶需求說明書》已經(jīng)可以作為設計活動的輸入，但還不能作為編碼實現(xiàn)活動的輸入?！缎枨笠?guī)格說明書》主要表述功能需求。按照標準說法，《需求規(guī)格說明書》還應當表述非功能性需求，但在實踐中，這部分很少被關注，非功能性指標往往到了測試階段才真正被重視。

《需求規(guī)格說明書》之“規(guī)格”，即要求格式化的表述，以便在軟件開發(fā)過程中不產(chǎn)生歧義。一般使用表格方式，以強制文檔作者必須填寫所有內(nèi)容：用例編號（唯一確定需求）、用例操作簡要說明、前置條件、操作結(jié)果（分為成功、失?。?、操作者（角色）。