在軟件工程中，需求分析指的是在建立一個新的或改變一個現存的電腦系統時描寫新系統的目的、范圍和定義時所要做的所有的工作。需求分析是軟件工程中的一個關鍵過程。

在這個過程中，系統分析員和軟件工程師確定顧客的需要。只有在確定了這些需要后他們才能夠分析和尋求新系統的解決方法。在軟件工程的歷史中，很長時間里人們一直認為需求分析是整個軟件工程中最簡單的一個步驟，但在過去十年中越來越多的人認識到它是整個過程中最關鍵的一個過程。假如在需求分析時分析者們未能正確地認識到顧客的需要的話，那么最后的軟件實際上不可能達到顧客的需要，或者軟件無法在規(guī)定的時間里完工。

目錄

1 挑戰(zhàn)

1.1 主要困難

1.2 持有關鍵信息的人

1.3 軟件開發(fā)者

1.4 解決方法

2 主要技術

2.1 采訪持重要信息的人

2.2 需求工作會

2.3 將需求列成合同式的文件

2.4 原型（Prototype）

2.5 用例（Use Case）

2.6 確認持關鍵信息者

挑戰(zhàn)

除此之外他們還要考慮一個項目的

·是否可行

·是否在規(guī)定的時間里可以完成

·價格上是否負擔得起

·是否合法

·是否符合道德

一個新項目開始的時候人們往往還非常興奮，往往試圖輕視需求分析的必要性。但對過去項目的分析證明一個徹底的和無情的需求分析可以降低一個項目的耗費和降低其技術風險。

主要困難

隨著工程師越來越對需求分析的重視今天我們對需求分析的主要困難也理解得比較清楚： 需求分析需要由有充分的經驗、技術知識和語言技巧的專家來完成；顧客一開始所提出的需要往往不完全、太樂觀以及過分受老的系統或過程的影響；使用復雜的工具和不同的技術來進行需求分析往往會打消獲得一個完整的和細致的結果的希望。

持有關鍵信息的人

顧客有可能防止需求分析順利進行有以下幾種可能性：

·顧客不明白他自己需要什么

·顧客不愿將他們的需要固定在一系列寫在紙上的條例中

·在價格和時間確定后顧客堅持要求新的需要

·分析者與顧客的通訊太緩慢

·顧客不參加回顧或無法參加回顧

軟件開發(fā)者

但是軟件開發(fā)者也有他們的責任。由于軟件開發(fā)者收錢來開發(fā)他們的軟件，他們的責任就更加不可推脫了。由軟件開發(fā)者導致的困難有：

·軟件工程師與他們的顧客往往使用不同的詞匯。有時他們以為互相之間完全達成協議，但是在展示最終結果時卻發(fā)現并非如此。開發(fā)者有義務克服這個困難，他們拿了顧客的錢，因此有這個義務。

·軟件開發(fā)者往往喜歡將顧客的需要改變得能使它們符合一個已存在的系統或模式，而不愿按照顧客的需要來發(fā)展一個新的系統。

·需求分析往往是由程序員完成的，而不是由作業(yè)分析員完成的。程序員往往缺乏理解實際事物的運行過程和商業(yè)過程的技巧。

解決方法

解決這些困難的一個方法是使用專業(yè)的作業(yè)或系統分析員，這些專業(yè)人員通過專門訓練來填補商業(yè)和電腦世界之間的鴻溝的。這個方法可以達到一定的效果，但從顧客方面來說要找到相應的有類似技巧的人就相當困難了。此外今天為需求分析所使用的方法依然還有很大的缺陷，它們還不夠有效。

1990年代以來新的技術有制作原型、統一建模語言、用例和敏捷軟件開發(fā)等方法。

主要技術

需求分析有可能在一個項目中成為一個漫長、艱巨的工作。需求分析專家與他們的顧客交談、記錄他們的交談結果、分析他們收集的信息，從中提取互相矛盾的地方，總結出一個總體觀念，然后再與顧客交談他們發(fā)現的問題。這個過程可以不斷重復，在有些項目中這個過程可以伴隨著整個在有些項目中這個過程可以伴隨著整個生命周期。

·與顧客的交談不夠多和不夠徹底，一些重要的需求被忽視；

·顧客的反應不說明問題，顧客對新系統的特征不滿。

·為了使所有這些討論有條理、有組織和有效地被記錄下來，這些討論的過程和其內容的演化也必須被記錄下來。

分析員可以使用不同的技術來從顧客手中獲得需求。比較老的方式有采訪顧客，或者與顧客一起開座談會，列舉顧客的需求。比較新的技術有建立模型和使用用例。在最佳狀態(tài)下在采納了不同的技術后他們可以完全理解顧客的需要和與持重要信息的人建立了必要的聯系。

采訪持重要信息的人

采訪持重要信息的人是需求分析中一個必不可少的過程。但在一個大的系統中許多人必須被采訪，這需要許多時間和金錢，但最重要的是這個過程最可能顯示現有的業(yè)務流程與新系統中的業(yè)務流程之間的差別。不同的顧客有可能有不同的或甚至相對的需求，在這種情況下分析員必須協調各方的需要。

需求工作會

出于上述原因一般假如一個系統非常復雜的話需求分析最常用的方法是召開需求工作會，在需求工作會上分析員和持重要信息的人一起分析系統的需要和發(fā)展解決方案。

這樣的工作會最好不要再采訪對象的工作場進行，這樣采訪對象不會被打擾。工作會有一個負責人來保持會議的進程，一個記錄員來記錄會議的討論，投影儀和相應的軟件是常用的工具。一般需要進行多次會議后才能得到最終結果。

一般認為需求工作會可以節(jié)省不少時間，因此是一個非常有用的工具，但是往往很難同時將所有的持重要信息的人聚集到一起。

將需求列成合同式的文件

最常見的紀錄需求分析的方式是將顧客需求列入一個合同式的表。一個復雜的系統的文件可以數百頁長?，F代的分析員不愿使用這樣的列表，因為它們被證明相當無用，但它們依然相當常見。

優(yōu)點：

·提供一份需求的清單。

·提供一份顧客和開發(fā)者間的合同。

·對一個大的系統來說它提供了一份高級的描寫。

缺點：

·這些列表可以長達上百頁，實際上沒有人能夠完整地閱讀這樣的文件來獲得一個完整的系統理解。

·列表中的需求一般都很抽象和缺乏列出的需求互相之間的關聯

·這樣的列表一般表示不出列出的需求之間怎樣組成一個整體。

·從列表中很難看出哪些需求更重要。

·抽象后的列表為讀者提供了許多理解的余地，因此不同的讀者對文件的理解可能不同。一個項目越大，讀者越多，理解的方式就越多。

·從抽象后的列表中很難看出它是否完全。它們往往忽視了許多細節(jié)。

·顧客和開發(fā)者對這個列表的理解往往完全不同。

·這樣的合同式的列表給顧客一個錯誤的安全的感覺，好像他們的要求都已列入了。但是由于這些列表本身對細節(jié)問題不能細述因此許多關鍵的細節(jié)問題實際上并未列出和解決。這些問題一直到后來軟件開發(fā)時才被發(fā)現。那時開發(fā)者一般要與顧客再次討論這些問題并試圖按他們的意愿和條件來解決這些問題。

·這個列表對此后的系統設計不提供任何幫助，它們的結構無法直接進入新軟件。

從1980年代中開始，越來越多的人將作原型看作是解決需求分析的困難的辦法。原型模擬最終軟件的屏幕顯示，這樣用戶可以看到最終軟件將是什么樣，而實際上在這些屏幕顯示的背后還一切都空著呢。這樣顧客可以在系統還沒有建立之前就做出設計決定。當原型首次被使用的時候它們的效果被視為非常驚人。引入原型往往提高顧客與開發(fā)者之間的信息交換。原型的屏幕顯示后來往往很少被改變，因此可以大大地降低費用。

但此后十多年的實際應用證明雖然原型是一種有用的技術，但它也有它的缺陷：

·經理人員在看到原型后往往不理解為什么到還要一段時間后最終設計才能完成。

·設計師往往將拼湊在一起的原型碼用到后來真正的系統中，因為他們怕在再次編碼時“浪費時間”。

·原型幫助解決設計決定和用戶界面的設計，但是它們并不提供任何關于需求的信息。

·設計師和顧客有可能花費太多的時間和精力來設計用戶界面，而忽視對作業(yè)過程的關心。

用例（Use Case）

用例是一種紀錄新系統或軟件更換時的需求的技術。每個用例包含一個系統在作業(yè)時與用戶或與其它系統之間交換信息的場景。一般用例避免使用術語，而盡量使用顧客、用戶或他們的專家的語言。一般用例由軟件開發(fā)者和顧客一起寫成。

在1990年代中用例很快地成為了紀錄需求分析的最主要的方式。尤其在它的發(fā)源地，在面向對象的程序設計中它的普及性非常高。但用例不僅可以用在面向對象的程序設計系統中，實際上用例本身并非面向對象的。

每個用例集中于描寫如何來完成一個作業(yè)目標或任務。對傳統的軟件工程來說每個用例描寫系統的一個特點。對大多數軟件項目來說一個新的系統有多個（往往十幾個）用例。不同的軟件項目的格式或項目的進展都可能影響用例的細節(jié)性。

用例描述系統在運行時與外部執(zhí)行者之間的信息交換。外部執(zhí)行者是任何系統外的、與系統交換信息的物件或人物。它們可以是用戶、用戶的角色或其它系統。

用例將系統當作一個“黑匣子”，它從外部來看與系統之間的信息交換（包括系統的回答）。這樣它簡化對系統的需求的描寫而且防止對系統的工作方式作任何過早的假設。

每個用例應該符合下述條件：

·描寫完成作業(yè)目標的作業(yè)任務

·不包含任何編程碼

·有一定的細致性

·足夠短，一個程序員應該可以在一個版本的工作中獨立完成這個用例所描寫的作業(yè)過程。