Can you summarize the following document?
        
  每個用例集中描述如何獲得一個業務目標或任務。從傳統的軟體工程視角來看,用例只是描述了系統的一個特徵。所以對大部分軟體專案來說,這就意味著需要很多(有可能是數十個)用例來完整的描述新系統。一個特殊軟體專案的正規度和專案的不同階段將會影響每一用例需要的詳細程度。  一個用例定義了外部執行者和被考慮的系統之間的互動來實現一個業務目標。執行者是在系統外部和系統互動的人;一個執行者可以是一類使用者,使用者可以扮演的角色或者其它系統。  用例把系統看作"黑盒",同系統的互動,包括系統的響應都是可以在系統外部感知的。它是一個deliberate policy,因為它簡化了需求的描 述,避免了對功能如何實現做出假設的陷阱。  用例應該:

  用例圖並不是畫成了圖形的用例。用例圖包含一組用例。每一用例用橢圓表示,放置在矩形框中;矩形框表示整個系統。矩形框外畫如圖所示的小人,表示參與者。參與者不一定是人,可以是其他軟體、硬體等等。某一參與者與某一用例用線連起來,表示該參與者和該用例有互動。  許多人通過UML認識了用例,UML定義為展現用例的圖形符號。UML並沒有為描述用例定義書寫格式的標準,因此許多人誤認為這些圖形符號就是用例本身;然而,圖形符號只能給出最簡單的一個或一組用例的概要。  UML是用例圖形符號最流行的標準。但是,還有一些其它的可選擇的標準。

  

  Alistair Cockburn在編寫有效用例一書中確定了三種書寫用例的細度。

  摘要用例有很少的句子組成來總結的用例。它十分適合在電子表格中計劃軟體開發。一個摘要用例能夠簡單插入電子表格的單元格中並且用表格中的其它列記述業務優先順序,技術複雜度,版本號等。

  一個非正式的用例由文字段落組成,包括了上面提到的那些列,用總結或故事的形式詳細的描述了用例。

  一個完整正式或者複雜的用例是一個以包含了不同部分的長模板為基礎的正規的文件。該用例在下面的用例模板部分進行討論。

  一些軟體開發方法學只需要非正式的用例來定義需求。然而,開發方法學需要完整正式或詳細的用例來定義需求。較大且較複雜的專案更需要使用完整正式的用例。

  編寫詳細的或完整的用例,尚無通用的模板(英語:template)。現在存在很多相互競爭的模板。同時,程式設計師們也被鼓勵用那些適合於他們的工作或者他們所做專案的模板,相對於某個指定模板的細節來說,專案的標準化要重要的多,但是這些模板的關鍵部分都是大體相同的,所以,雖然在某些術語上或者其他一些方面上存在不同,但是這些用例從本質上來說,是大同小異的。  典型部分包括:  不同的模板經常有其它部分,如,假設,異常流,建議,技術要求。也會有行業細節部分。

  用例名稱為用例提供了一個唯一標識。它要用動/賓格式書寫,並且要充分,達到終端使用者能夠明白用例中描述的是什麼。

  迭代部分通常需要告知讀者用例完成的階段。最初,為業務分析和確定範圍的用例和用於軟體開發的用例肯定會有許多不同。老版本的用例可能還在當前文件中,因為它們對不同的使用者群可能會有價值。

  "描述"部分用於在主體完成之前捕獲基本場景。它提供了快速的總結,避免了讀者瀏覽全部內容,能夠很快的理解該用例的用途。

  "前置條件"部分用來表達當使用者開始用例時某些條件必須為真。但是它們不是啟動用例的觸發器。

  最低限度,每一個用例都需要描述一個"主場景"或者典型事件流。主事件流一般是一組有編號的步驟,如:......其他

  用例可能包含第二條路徑,或者和主題不同的備選場景。異常或當出錯時會發生什麼事情也需要描述出來,這種描述可以在備選路徑中或者在它本身的部分。備選路徑使用基本事件流中的序號來標示在哪一點上同基本場景不同,並且如果合適它從哪一點回到基本場景中。目的是避免不必要的重複資訊。  備選流的例子: 異常路徑的例子:

  "後置條件"部分總結了在場景結束後事務的狀態。

  業務規則是一些成文的或未成文的規則,對於用例來說它決定了一個組織是如何執行業務的。業務規則是一個特殊種類的假定。它可能適用於某一個用例或者整個用例,甚至整個業務。

  說明對於本用例的非功能性要求,典型的是併發情況下的響應時間要求,還有易用性要求等等

  用例是一個較新的,比較敏捷的捕獲軟體需求的形式。用例經常和大的,統一的文件形成對比。這些大文件想要在新系統開始構成前,完整的表達出所有可能的需求,但這種做法通常都是失敗的。  用例的幾點優勢:

  用例不是沒有侷限性:
用例(英語:use case),或譯使用案例、用況,是軟體工程或系統工程中對系統如何反應外界請求的描述,是一種通過使用者的使用場景來獲取需求的技術。每個用例提供了一個或多個"場景",該場景說明了系統是如何和終端使用者或其它系統互動,也就是誰可以用系統做什麼,從而獲得一個明確的業務目標。編寫用例時要避免使用技術術語,而應該用終端使用者或者"領域專家"的語言。用例一般是由軟體開發者和終端使用者共同創作的。