轉載-撰寫使用案例規格（情節描述）的一些問題與建議

因為工作上會用到,在此做個紀錄


原文出處:
撰寫使用案例規格（情節描述）的一些問題與建議

在 review 一些高抽象層次的系統分析文件時，我發覺經常出現的問題其實跟懂不懂 OO 沒有太大關係，反而跟一些基本的分析技巧以及文件撰寫技巧有關。

先解釋一下，這裡的高抽象層次的系統分析文件，指的是在跟使用者訪談會議結束後，根據使用者描述的需求，以使用者目標為出發點所撰寫的初步分析文件。其中應包含使用者的角色定義、主要的事流程、情節描述等等。為了表達這些內容，我們傾向使用 UML 的使用案例圖（use case diagram）和使用案例規格（use case specification）來描述，以求表達方式的一致性。喔，對了，還有活動圖，而且是比較高階的活動圖，主要用來捕捉事務流程。這些都和 OO 沒有甚麼關係。

在撰寫高階的系統分析文件（或者說初步的系統分析產出）時，我所碰過的一些常見問題包括：

• 虛應故事的心態。沒有弄清楚使用案例圖和使用案例規格（use case specification）的真正用途，而只是交差了事（有做文件就好）；或者實際上進行系統設計時根本不以目前撰寫的系統分析文件為基礎，而是在系統分析時一邊用自己慣用的規格書格式來撰寫，因為將來實際使用的是這份文件（真是浪費時間啊！）。
  
• 沒有想清楚抽象層次，分析文件的內容不是太粗就是太細（太快描述太多實作細節）。
• 文字表達能力不足，無法清楚描述使用者的意圖和操作流程。

前兩個問題彼此互有關聯：如果撰寫使用案例規格（或者說情節描述）只是為了應付驗收，文件內容的抽象層次不太可能拿捏得當（適當的抽象層次不會憑空出現，你得時刻想著這個問題，直到它成為習慣）。如果不了解寫這份文件的目的為何，恐怕也很難分得清楚內容要寫多細。

何謂適當的抽象層次？

文件內容的抽象層次該多細並沒有甚麼明確的標準，要看 SA 對系統的了解程度而定。剛開始，SA 從使用者那邊得到一些線索，此時記錄下來的東西可能是非常粗略的，因為是剛從需求（what）進入到分析（how）的層次。隨著 SA 對欲設計的系統有更多瞭解，文件內容也會越來越細。而當細到某種程度，SA 認為可以開始進行更細部的設計時（例如：需要開始思考資料庫欄位的設計、類別的設計與關聯），此時大概可界定為進入系統設計的階段（儘管這兩個階段中間的界線仍不十分明顯）。

舉例來說，在初步的分析文件中把使用案例和將來要實作的系統功能選單項目做一對一的對應，這種描述方式就明顯不當。對一個複雜系統來說，剛開始應該要描述使用者的意圖，以及如何達成這些目標，而不是直接就設想好將來操作介面的選單會有哪些功能項目。畢竟，使用者都還沒確認你寫的東西對不對，還不知道你是否真正了解她要什麼，怎麼能一下子就完成「功能分解」呢？太快做功能分解也會導致使用案例的粒度切得不恰當，當然寫出來的使用案例規格也就很難讓人滿意。

雛型畫面到底要不要先做？

曾聽過一些建議，說在進行 OOA 時不要先想到資料庫欄位和操作畫面（UI ），個人認同前者。UI 的部分我覺得可以先做一些簡略的畫面雛型，以便和 end users 確認。

完成初步的系統分析文件之後，我們通常會拿去跟 end users 討論。也許有些人會質疑：「user 怎麼可能看得懂你那些橢圓形圖案和活動圖？他們也不可能有時間去看那一堆情節描述吧？」

不見得。但確實有許多使用者沒辦法逐一細看你寫的分析文件，而且使用者大都比較喜歡看圖說故事，因為總是要看到實際的畫面才比較有感覺。如果光看文字描述，一方面比較花時間、一方面也比較累。

因此我贊成在完成初步的分析文件時，也先製作粗略的 UI 雛型，方便讓 end users 了解我們所知道的東西，以及我們打算要怎麼來設計系統以完成他們的需求（功能、作業流程等）。可是，這樣不就會開始出現前面提到的「功能選單」和「資料庫欄位」了嗎？這不要緊，當它們需要出現在畫面中時就讓它們出現吧。我的意思是，我們是為了要讓細節逐漸浮現而表達這些東西－－就像讓冰山在水面下隱藏的部分逐漸顯現出來－－而不是刻意先去思考整個系統的功能選單長什麼樣子。此外，UI 雛型上面的輸入欄位也不見得就是對應到資料庫欄位；它們還是有差別，而且你也不用在設計 UI 雛型時把全部可能需要的欄位全畫上去，只要關鍵的欄位就夠了。

就像《軟體工程與 Microsoft Visual Studio Team System》書中所建議的：

與人物代表（persona）一樣，情節也應該儘早明確。你會在其中加入操作畫面的簡圖，並顯示從一個畫面切到下一個畫面時的資料流。如果是以使用案例來分析，這些明確的資訊通常會拖到細部設計的步驟時才會出現。不要拖──你應該立刻針對這些明確的需求進行初步的測試。(p.65)

如何確定使用案例規格已經夠細了？

在撰寫使用案例規格時，可以問自己一些問題，來檢驗這份文件的內容是否已經完備：

• End users 看了這些內容之後，能否確認當初他們所題的需求已獲得充分了解？以及他們是否能提出更進一步的具體需求或建議？
• 此文件是否包含足夠的資訊，可讓系統分析師或設計師進行下一個層次的分析設計工作（找出互動、介面、關聯性等等）？
  
• 現在寫這些細節會不會太快了？萬一下次訪談時使用者更改了部分需求或增加一些功能，會不會導致這個部分要大幅度改寫甚至整個重寫？
• 使用案例規格是否是以 end users 的語言（problem domain languages）撰寫？是否包含太多與實作相關的專業術語（solution domain languages）？
  
• 從這份文件中，能不能抓出將來要測試的項目（測試案例）？

最重要的，我想還是 SA 要有那個心去寫一份讓 user 看得懂的文件，而不是只用自己懂的專業術語來描述，或者敷衍了事。如果出發點正確，剩下的文件撰寫技巧都可以透過相關書籍的建議逐漸改善。