Can you summarize the following document?
        
  順利地完成需求分析是一個艱鉅的挑戰。首先要確認所有持有關鍵資訊的人本身就不容易,然後還要從這些人獲得可用的資訊,把這些資訊轉化為清晰的和完整的形式。同時分析者還要考慮到可能的限制。除此之外他們還要考慮一個專案的  一個新專案開始的時候人們往往還非常興奮,往往試圖輕視需求分析的必要性。但對過去專案的分析證明一個徹底的和無情的需求分析可以降低一個專案的耗費和降低其技術風險。

  隨著工程師對需求分析的越來越重視,今天我們對需求分析的主要困難也理解得比較清楚:

  顧客有可能妨礙需求分析順利進行,有以下幾種可能性:

  但是軟體開發者也有他們的責任。由於軟體開發者收錢來開發他們的軟體,他們的責任就更加不可推脫了。由軟體開發者導致的困難有:

  解決這些困難的一個方法是使用專業的作業或系統分析員,這些專業人員通過專門訓練來填補商業和電腦世界之間的鴻溝的。這個方法可以達到一定的效果,但從顧客方面來說要找到相應的有類似技巧的人就相當困難了。此外今天為需求分析所使用的方法依然還有很大的缺陷,它們還不夠有效。  1990年代以來,新的技術有製作原型、統一建模語言(UML)、用例(英語:Use case)和敏捷軟體開發等方法。

  需求分析有可能在一個專案中成為一個漫長、艱鉅的工作。需求分析專家與他們的顧客交談、記錄他們的交談結果、分析他們收集的資訊,從中提取互相矛盾的地方,總結出一個總體觀念,然後再與顧客交談他們發現的問題。這個過程可以不斷重複,在有些專案中這個過程可以伴隨著整個生命週期。  新系統很可能改變人之間的關係和人的工作環境,因此認定誰是重要的資訊持有者是非常重要的。只有這樣在需求分析的過程中才能夠將顧客所有的需要都紀錄下來,只有這樣才能保證他們認識到新的系統對他們來說帶來怎樣的變化。出於下述原因這個要求往往達不到:  為了使所有這些討論有條理、有組織和有效地被記錄下來,這些討論的過程和其內容的演化也必須被記錄下來。  分析員可以使用不同的技術來從顧客手中獲得需求。比較老的方式有采訪顧客,或者與顧客一起開座談會,列舉顧客的需求。比較新的技術有建立模型和使用用例。在最佳狀態下在採納了不同的技術後他們可以完全理解顧客的需要和與持重要資訊的人建立了必要的聯絡。

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

  出於上述原因一般假如一個系統非常複雜的話需求分析最常用的方法是召開需求工作會,在需求工作會上分析員和持重要資訊的人一起分析系統的需要和發展解決方案。  這樣的工作會最好不要在採訪物件的工作場進行,這樣採訪物件才不會被打擾。工作會有一個負責人來保持會議的程序,一個記錄員來記錄會議的討論,投影儀和相應的軟體是常用的工具。一般需要進行多次會議後才能得到最終結果。  一般認為需求工作會可以節省不少時間,因此是一個非常有用的工具,但是往往很難同時將所有的持重要資訊的人聚集到一起。  一個常見的缺陷是一些持重要資訊者在這樣的會議上不十分積極,因此他們的需求沒有獲得必要的重視。這樣得到的解決方案必然有限。此外需求工作會是一個很好的分析現有系統的工具,但用它來尋求解決方案就不是十分有用了。

  最常見的紀錄需求分析的方式是將顧客需求列入一個合同式的表。對於一個複雜的系統, 該檔案可以長達數百頁。現代的分析員不願使用這樣的列表,因為它們被證明相當無用,但它們依然相當常見。  優點:  缺點:

  從1980年代中開始,越來越多的人將作原型看作是解決需求分析困難的辦法。原型模擬最終軟體的螢幕顯示,這樣使用者可以看到最終軟體將是什麼樣,而實際上在這些螢幕顯示的背後還一切都空著呢。這樣顧客可以在系統還沒有建立之前就做出設計決定。當原型首次被使用的時候它們的效果被視為非常驚人。引入原型往往提高顧客與開發者之間的資訊交換。原型的螢幕顯示後來往往很少被改變,因此可以大大地降低費用。  但此後十多年的實際應用,證明雖然原型是一種有用的技術,但它也有它的缺陷:

  參見用例  用例是一種記錄新系統或軟體更換時的需求的技術。每個用例包含一個系統在作業時與使用者或與其它系統之間交換資訊的場景。一般用例避免使用術語,而儘量使用顧客、使用者或他們的專家的語言。一般用例由軟體開發者和顧客一起寫成。  在1990年代中用例很快地成為了記錄需求分析的最主要的方式。尤其在它的發源地,在物件導向的程式設計中它的普及性非常高。但用例不僅可以用在物件導向的程式設計系統中,實際上用例本身並非物件導向的。  每個用例集中於描寫如何來完成一個作業目標或任務。對傳統的軟體工程來說每個用例描寫系統的一個特點。對大多數軟體專案來說一個新的系統有多個(往往十幾個)用例。不同的軟體專案的格式或專案的進展都可能影響用例的細節性。  用例描述系統在執行時與外部執行者之間的資訊交換。外部執行者是任何系統外的、與系統交換資訊的物件或人物。它們可以是使用者、使用者的角色或其它系統。  用例將系統當作一個“黑匣子”,它從外部來看與系統之間的資訊交換(包括系統的回答)。這樣它簡化對系統的需求的描寫而且防止對系統的工作方式作任何過早的假設。  每個用例應該符合下述條件:  在描寫功能需求時用例非常好用,但它們不適合描寫非功能需求。

  從1990年代開始確認持關鍵資訊者被確定為一個非常關鍵的過程。它同時也是需求分析的第一步。此前經理人員往往被認為是持關鍵資訊者。許多系統是按照這些經理人員的設想設計的,而實際的使用者很少或根本沒有對設計做任何貢獻。這樣的系統往往是大失敗。因此在1970年代和1980年代在軟體工程師中漸漸地持關鍵資訊者的概念擴充套件到主要使用者,後來還擴充套件到次要使用者。在1990年代中工程師們更加從一個系統整體的觀念上來確定持關鍵資訊者。他們漸漸認識到不但在僱傭他們的顧客中有持關鍵資訊者,其他持關鍵資訊者包括:  成功地確認持關鍵資訊者是完整地完成需求分析的基礎。
在系統工程及軟體工程中,需求分析指的是在建立一個新的或改變一個現存的系統或產品時,確定新系統的目的、範圍、定義和功能時所要做的所有工作。需求分析是軟體工程中的一個關鍵過程。在這個過程中,系統分析員和軟體工程師確定顧客的需要。只有在確定了這些需要後他們才能夠分析和尋求新系統的解決方法。