1500802034呂占英

usecase的局限性

對于系統發展而言，Use Case的范圍限制一個單一的系統，這是Use Cases最通常的形式，我們稱之為System Use Case，它把整個系統看作是一個黑盒，它不指定任何內部結構并且僅受限于問題域的語言描述。 因此，.故事/人物/場景非常適合交互式的系統，但是對于其他類型的需求（算法，速度，擴展性，安全性，以及和系統技術相關的需求）則不適用。并且故事的粒度沒有統一的標準，和每個具體項目有關。初學者比較難以掌控。如果軟件的關鍵在于用戶體驗的細節，那么如何把這些UI的細節嵌入每個故事中，并仍然保持故事的簡明性這是一個難題。有些團隊把目前的技術擴展為Use CaseStoryboard，當一個簡明的故事加上很多附加說明和圖畫的時候，這事實上就成為了功能說明書（Function Specification）以及各種幫助建模的圖形工具。

1.故事/人物/場景非常適合交互式的系統，但是對于其他類型的需求（算法，速度，擴展性，安全性，以及和      系統技術相關的需求）則不適用。

2.故事的粒度沒有統一的標準，和每個具體項目有關。初學者比較難以掌控。

3.如果軟件的關鍵在于用戶體驗的細節，那么如何把這些UI的細節嵌入每個故事中，并仍然保持故事的簡明     性？這是一個難題。有些團隊把目前的技術擴展為Use Case        Storyboard，當一個簡明的故事加上很多附加    說明和圖畫的時候，這事實上就成為了功能說明書（Function Specification）以及各種幫助建模的圖形工具。

Use Case在文檔系統和軟件需求領域成為一 項越來越受歡迎的技術。Use Case對開發小組極具吸引力，即使小組成員對正式的需求文檔沒有經驗，但這些簡單性卻具有欺騙性，即使項目小組在開始使用Use Case 時沒有任何麻煩，當他們將其應用于大項目時常常會遇到許多同樣的問題。

Use Case 圖形符號已經被標準化并作為對象管理小組UML的一部分，但自然語言的Use Case 說明書還沒有被標準化。為了成功書寫Use Case 說明書，我們需要一個標準模板來保證Use Case 的一致性。