需求分析
在系統工程及軟體工程中，需求分析指的是在建立一個新的或改變一個現存的系統或產品時，確定新系統的目的、範圍、定義和功能時所要做的所有工作，其中包括考慮來自不同利益相關者的需求，確認是否衝突，在衝突的需求之間進行取捨，並針對軟體需求及系統需求進行分析、記錄、確認以及管理[1]。
需求分析是軟體專案或系統專案中的關鍵過程，關係專案的成敗[2]。理想的需求要整理成檔案、可以執行、可以量測、可以測試、可以追蹤、和識別到的商業的需求或機會有關，而且要有系統設計的相關設計細節。
挑戰
順利地完成需求分析是一個艱巨的挑戰。首先要確認所有持有關鍵資訊的人本身就不容易，然後還要從這些人獲得可用的資訊，把這些資訊轉化為清晰的和完整的形式。同時分析者還要考慮到可能的限制。除此之外他們還要考慮一個專案的
- 是否可行
- 是否在規定的時間裡可以完成
- 價格上是否負擔得起
- 是否合法
- 是否符合道德
一個新專案開始的時候人們往往還非常興奮，往往試圖輕視需求分析的必要性。但對過去專案的分析證明一個徹底的和無情的需求分析可以降低一個專案的耗費和降低其技術風險。
主要困難
隨著工程師對需求分析的越來越重視，今天我們對需求分析的主要困難也理解得比較清楚：
- 需求分析需要由有充分的經驗、技術知識和語言技巧的專家來完成；
- 顧客一開始所提出的需要，往往不完全、太樂觀以及過分受老的系統或過程的影響；
- 軟體工程師與他們的顧客往往使用不同的詞彙。有時他們以為互相之間完全達成協定，但是在展示最終結果時卻發現並非如此。
持有關鍵資訊的人
顧客有可能妨礙需求分析順利進行，有以下幾種可能性：
- 顧客不明白他自己需要什麼
- 顧客不願將他們的需要固定在一系列寫在紙上的條例中
- 在價格和時間確定後，顧客堅持要求新的需要
- 分析者與顧客的通訊太緩慢
- 顧客不參加回顧或無法參加回顧
- 顧客缺乏技術上的知識
- 顧客缺乏對軟體開發的知識
軟體開發者
但是軟體開發者也有他們的責任。由軟體開發者導致的困難有：
- 軟體開發者往往喜歡將顧客的需要改變得能使它們符合一個已存在的系統或模式，而不願按照顧客的需要來發展一個新的系統。
- 需求分析往往是由程式設計師完成的，而不是由作業分析員完成的。程式設計師往往缺乏理解實際事物的執行過程和商業過程的技巧。
解決方法
解決這些困難的一個方法是使用專業的作業或系統分析員，這些專業人員通過專門訓練來填補商業和電腦世界之間的鴻溝的。這個方法可以達到一定的效果，但從顧客方面來說要找到相應的有類似技巧的人就相當困難了。此外今天為需求分析所使用的方法依然還有很大的缺陷，它們還不夠有效。
主要技術
需求分析有可能在一個專案中成為一個漫長、艱巨的工作。需求分析專家與他們的顧客交談、記錄他們的交談結果、分析他們收集的資訊，從中提取互相矛盾的地方，總結出一個總體觀念，然後再與顧客交談他們發現的問題。這個過程可以不斷重複，在有些專案中這個過程可以伴隨著整個生命周期。
新系統很可能改變人之間的關係和人的工作環境，因此認定誰是重要的資訊持有者是非常重要的。只有這樣在需求分析的過程中才能夠將顧客所有的需要都紀錄下來，只有這樣才能保證他們認識到新的系統對他們來說帶來怎樣的變化。出於下述原因這個要求往往達不到：
- 與顧客的交談不夠多和不夠徹底，一些重要的需求被忽視；
- 顧客的反應不說明問題，顧客對新系統的特徵不滿。
為了使所有這些討論有條理、有組織和有效地被記錄下來，這些討論的過程和其內容的演化也必須被記錄下來。
分析員可以使用不同的技術來從顧客手中獲得需求。比較老的方式有採訪顧客，或者與顧客一起開座談會，列舉顧客的需求。比較新的技術有建立模型和使用用例。在最佳狀態下在採納了不同的技術後他們可以完全理解顧客的需要和與持重要資訊的人建立了必要的聯絡。
採訪持重要資訊的人
採訪持重要資訊的人是需求分析中一個必不可少的過程。但在一個大的系統中許多人必須被採訪，這需要許多時間和金錢，但最重要的是這個過程最可能顯示現有的業務流程與新系統中的業務流程之間的差別。不同的顧客有可能有不同的或甚至相對的需求，在這種情況下分析員必須協調各方的需要。
需求工作會議
出於上述原因一般假如一個系統非常複雜的話需求分析最常用的方法是召開需求工作會議，在需求工作會議上分析員和持重要資訊的人一起分析系統的需要和發展解決方案。
這樣的工作會議最好不要在採訪對象的工作場進行，這樣採訪對象才不會被打擾。工作會有一個負責人來保持會議的行程，一個記錄員來記錄會議的討論，投影儀和相應的軟體是常用的工具。一般需要進行多次會議後才能得到最終結果。
一般認為需求工作會議可以節省不少時間，因此是一個非常有用的工具，但是往往很難同時將所有的持重要資訊的人聚集到一起。
一個常見的缺陷是一些持重要資訊者在這樣的會議上不十分積極，因此他們的需求沒有獲得必要的重視。這樣得到的解決方案必然有限。此外需求工作會議是一個很好的分析現有系統的工具，但用它來尋求解決方案就不是十分有用了。
將需求列成合同式的檔案
最常見的紀錄需求分析的方式是將顧客需求列入一個合同式的表。對於一個複雜的系統, 該檔案可以長達數百頁。現代的分析員不願使用這樣的列表，因為它們被證明相當無用，但它們依然相當常見。
優點：
- 提供一份需求的清單。
- 提供一份顧客和開發者間的合同。
- 對一個大的系統來說它提供了一份進階的描寫。
缺點：
- 這些列表可以長達上百頁，實際上沒有人能夠完整地閱讀這樣的檔案來獲得一個完整的系統理解。
- 列表中的需求一般都很抽象和缺乏關聯
- 這樣的列表一般表示不列出需求之間怎樣組成一個整體。
- 從列表中很難看出哪些需求更重要。
- 抽象後的列表為讀者提供了許多理解的餘地，因此不同的讀者對檔案的理解可能不同。一個專案越大，讀者越多，理解的方式就越多。
- 從抽象後的列表中很難看出它是否完全。它們往往忽視了許多細節。
- 顧客和開發者對這個列表的理解往往完全不同。
- 這樣的合同式的列表給顧客一個錯誤的安全感，好像他們的要求都已列入了。但是由於列表本身對細節問題不能細述因此許多關鍵的細節問題實際上並未列出和解決。這些問題一直到後來軟體開發時才被發現。那時開發者一般要與顧客再次討論並試圖按他們的意願和條件來解決。
- 這個列表對此後的系統設計不提供任何幫助，它們的結構無法直接進入新軟體。
原型（Prototype）
從1980年代中開始，越來越多的人將作原型看作是解決需求分析困難的辦法。原型類比最終軟體的螢幕顯示，這樣使用者可以看到最終軟體將是什麼樣，而實際上在這些螢幕顯示的背後還一切都空著呢。這樣顧客可以在系統還沒有建立之前就做出設計決定。當原型首次被使用的時候它們的效果被視為非常驚人。引入原型往往提高顧客與開發者之間的資訊交換。原型的螢幕顯示後來往往很少被改變，因此可以大大地降低費用。
但此後十多年的實際應用，證明雖然原型是一種有用的技術，但它也有它的缺陷：
- 經理人員在看到原型後，往往不理解為什麼還要到一段時間後，最終設計才能完成。
- 設計師往往將拼湊在一起的原型碼用到後來真正的系統中，因為他們怕在再次編碼時「浪費時間」。
- 原型幫助解決設計決定和使用者介面的設計，但是它們並不提供任何關於需求的資訊。
- 設計師和顧客有可能花費太多的時間和精力來設計使用者介面，而忽視對作業過程的關心。
用例（Use Case）
參見用例
用例是一種記錄新系統或軟體更換時的需求的技術。每個用例包含一個系統在作業時與使用者或與其它系統之間交換資訊的場景。一般用例避免使用術語，而儘量使用顧客、使用者或他們的專家的語言。一般用例由軟體開發者和顧客一起寫成。
在1990年代中用例很快地成為了記錄需求分析的最主要的方式。尤其在它的發源地，在物件導向的程式設計中它的普及性非常高。但用例不僅可以用在物件導向的程式設計系統中，實際上用例本身並非物件導向的。
每個用例集中於描寫如何來完成一個作業目標或任務。對傳統的軟體工程來說每個用例描寫系統的一個特點。對大多數軟體專案來說一個新的系統有多個（往往十幾個）用例。不同的軟體專案的格式或專案的進展都可能影響用例的細節性。
用例描述系統在執行時與外部執行者之間的資訊交換。外部執行者是任何系統外的、與系統交換資訊的物件或人物。它們可以是使用者、使用者的角色或其它系統。
用例將系統當作一個「黑匣子」，它從外部來看與系統之間的資訊交換（包括系統的回答）。這樣它簡化對系統的需求的描寫而且防止對系統的工作方式作任何過早的假設。
每個用例應該符合下述條件：
- 描寫完成作業目標的作業任務
- 不包含任何編程碼
- 有一定的細緻性
- 足夠短，一個程式設計師應該可以在一個版本的工作中，獨立完成這個用例所描寫的作業過程。
在描寫功能需求時用例非常好用，但它們不適合描寫非功能需求。
確認持關鍵資訊者
從1990年代開始確認持關鍵資訊者被確定為一個非常關鍵的過程。它同時也是需求分析的第一步。此前經理人員往往被認為是持關鍵資訊者。許多系統是按照這些經理人員的設想設計的，而實際的使用者很少或根本沒有對設計做任何貢獻。這樣的系統往往是大失敗。因此在1970年代和1980年代在軟體工程師中漸漸地持關鍵資訊者的概念擴充到主要使用者，後來還擴充到次要使用者。在1990年代中工程師們更加從一個系統整體的觀念上來確定持關鍵資訊者。他們漸漸認識到不但在僱傭他們的顧客中有持關鍵資訊者，其他持關鍵資訊者包括：
- 與顧客橫向相連（或應該橫向相連）的組織
- 顧客的後勤辦公室或類似的組織
- 進階經理人員
成功地確認持關鍵資訊者是完整地完成需求分析的基礎。
參見
參考文獻
- ^ Kotonya, Gerald; Sommerville, Ian. Requirements Engineering: Processes and Techniques
. Chichester, UK: John Wiley and Sons. 1998. ISBN 9780471972082.
- ^ Alain Abran; James W. Moore; Pierre Bourque; Robert Dupuis (編). Chapter 2: Software Requirements. Guide to the software engineering body of knowledge 2004. Los Alamitos, CA: IEEE Computer Society Press. March 2005 [2007-02-08]. ISBN 0-7695-2330-7. （原始內容存檔於2009-03-23）.
It is widely acknowledged within the software industry that software engineering projects are critically vulnerable when these activities are performed poorly.
延伸閱讀
英文書籍
- Laplante, Phil. Requirements Engineering for Software and Systems 1st. Redmond, WA: CRC Press. 2009. ISBN 1-42006-467-3. （原始內容存檔於2011-07-08）.
- McConnell, Steve. Rapid Development: Taming Wild Software Schedules 1st. Redmond, WA: Microsoft Press. 1996 [2009-04-20]. ISBN 1-55615-900-5. （原始內容存檔於2005-04-20）.
- Wiegers, Karl E. Software Requirements 2: Practical techniques for gathering and managing requirements throughout the product development cycle 2nd. Redmond: Microsoft Press. 2003 [2022-07-29]. ISBN 0-7356-1879-8. （原始內容存檔於2021-05-05）.
- Andrew Stellman and Jennifer Greene. Applied Software Project Management. Cambridge, MA: O'Reilly Media. 2005 [2022-07-29]. ISBN 0-596-00948-8. （原始內容存檔於2021-05-25）.
- Brian Berenbach, Daniel Paulish, Juergen Katzmeier, Arnold Rudorfer. Software & Systems Requirements Engineering: In Practice. New York: McGraw-Hill Professional. 2009 [2022-07-29]. ISBN 0-07-1605479. （原始內容存檔於2021-05-09）.