在rup當中稱為用例示意板。
在實際操作當中往往用介面原型進行描述，
如您的產品以web為主，
那麼使用靜態html配合用例規約就是比較適合的方法。
在你所描述的情況當中，互動資訊、
異常情況是應當盡量考慮清楚的，但是不論如何仔細，
永遠都不可能做到事事具備。
如果花費過於大的精力去描述用例的各個方面，
把爭持認為是用例規約沒有描述清楚，
很容易走入過度設計的死胡同。
我不相信誰能夠保證把用例規約寫到沒有萬一的地步，
那不符合軟體規律。
所以，我們要接受現實，不是用例規約出了問題，
而是實施方法出了問題。用例不僅是分析人員的事，
也是測試人員的事，也是開發人員的事。在實施上，
他們都應當參與進來，而不是等待分析員的結果。
在決定乙個用例規約的時候，測試人員就應當能夠產生測試用例，
對於模糊地帶，在討論用例的過程當中來進行澄清。
rup之所以使用迭代的開發方法，
就是要在每乙個迭代時重新審視、修改用例規約，
讓各方都參與進來，把模糊地帶搞清楚。
請告訴你的同事們，用例規約的責任不僅僅是產品設計人員的事，
也是開發，測試的事，他們也是責任者而不僅僅是使用者和旁觀者。
爭執是不可避免的，
但是爭執如果發生在用例討論過程當中而不是產品開發和測試時，
爭執就是好事情而不是委屈了。
最後再做一點補充：
在乙個敏捷的團隊裡，乙個用例就相當於乙個work item，或者乙個task，或者乙個userstory，不論叫什麼名字，這個用例是由整個團隊來維護的討論的，不同職責的成員關心它的不同部分，但大家討論的是同乙個用例。在迭代的過程中，這些討論被不斷的深入，乙個乙個的模糊地帶被不斷的澄清，大家對同乙個問題越來越清楚。當必要的改變發生時，大家分別負責改變自己的部分。最後，需求部分、分析部分、設計部分、**、測試用例、測試**、測試結果、缺陷紀錄、變更紀錄....所有圍繞用例產生的東西都成為了用例的乙個組成部分。
可見，用例規約不是一開始就事無鉅細的。這位網友的問題其實是在軟體過程中產生的，非常普遍，方法好講，解決起來並不容易。關鍵是要建立乙個自驅動的團隊，大家都意識到用例是所有人的，軟體過程是迭代的而不是瀑布的，這樣，用例驅動的意義才能夠體現出來。
描述用例規約
描述用例規約 應該避免這樣一種誤解 認為由參與者和用例構成的用例圖就是用例模型，用例圖只是在總體上大致描述了系統所能提供的各種服務，讓我們對於系統的功能有乙個總體的認識。除此之外，我們還需要描述每乙個有例的詳細資訊，這些資訊包含在用例規約中，用例模型是由用例圖和每乙個用例的詳細描述 用例規約所組成的...
UML2用例描述以及需求用例規約文件生成
初學uml者，應該避免這樣一種誤解 認為就是由參與者和用例構成的用例圖就是用例模型，用例圖只是在總體上大致描述了系統所能提供的各種服務，讓我們對於系統的功能有乙個總體的認識。但用例圖並非如此，在用例圖中我們還需要針對每乙個用例描述它的詳細資訊，這些資訊包含在用例規約中，因此用例模型應該是由用例圖和每...
需求用例分析之三 補充規約
補充規約在rup 中是記錄那些在用例模型的用例中不容易體現出來的系統需求。這些需求包括 補充規約是對用例模型的重要補充。補充規約和用例模型應該一起獲取對系統的一整套需求。通過以上文字可以知道，補充規約是全域性性的要求，與上述c文中的 全域性規則 極為接近。而中文中 補充規約 的說法讓不少人以為這是不...