第十一章 用例格式
1、完整正式的用例格式：（1）單列文字（不是乙個**）（2）步驟編號（3）沒有條件語句（4）擴充套件部分的編號規則是數字和字母的組合
完整正式的用例模板《名字》
《用例名應該是乙個用主動語態動詞短語來表示的用例目標》
使用語境：《目標較長的描述，如果需要，還包括觸發事件》
範圍：《設計範圍，在設計時將系統作為乙個黑盒來考慮》
級別：《概要、使用者目標、子功能三者之一》
主執行者：《主執行這的角色名稱或主執行者的描述》
前置條件：《我們所希望的，周圍環境已經達到的狀態》
最小保證：《在所有退出操作前，如何保證得到必須的資訊》
成功保證：《目標完成時環境的狀態》
觸發事件：《什麼引發了用例，可能是時間事件》
主成功場景：
《在這裡寫出從觸發事件到目標完成以及清楚的步驟》
《步驟編號#>《動作描述》
擴充套件：《在這裡寫出擴充套件，每次寫乙個擴充套件，每乙個擴充套件都指向主場景中的特定步驟》
《被改變步驟》《條件》：《動作或子用例》
《被改變步驟》《條件》：《動作或子用例》
技術和資料變化列表：
《在這裡寫出場景中因技術或資料變化而引起的可能分支》
《步驟或變化編號#>《變化列表》
《步驟或變化編號#>《變化列表》
相關資訊
《專案所需要的所有附加資訊》
2、圖形符號有兩個可用性方面的問題，第一，終端使用者和業務執行者不可能熟悉這些符號，也不會有耐心來學習這些符號；第二，圖形不能完全表示你所需要的意思。用例本身就是文字的，任何圖形都只是為了幫助讀者找到他們所要閱讀的文字。
3、影響用例書寫格式的因素
（1）矛盾的因素：業務環境、社會作用、不同文化
這個列為第一因素真的不為過，特別在中國，地大物博，很多專案可能是北方公司的人到南方做專案，文化背景不同，語言也不是很一致，這個會直接影響需求獲取的精確度
（2）理解層次
本來開發人員和業務人員就存在理解層次不一致的問題，開發人員沒業務人員懂業務知識，業務人員沒開發人員懂軟體開發知識，所以要降低這個因素的影響必須找到乙個共同的具有標準格式的「語言」（如通用的用例格式）和很好的分工與協作方式。
（3）專案相關人員的要求
每個涉眾（即專案相關人員）都有自己關心的方面，所以他們的要求也不相同，所謂眾口難調，在這裡體現的淋漓盡致。
（4）經驗與格式
（5）覆蓋面
（6）一致性
（7）複雜度
（8）完整性
（9）目標與任務——完成什麼與怎樣完成
（10）資源
（11）其他因素
存在著這麼多因素，所以需求調研就不能以一種固定的模式推廣，只能在乙個比較大的框架上，通過調研人員發揮主觀能動性與涉眾一起完成需求的調研，但這些因素是提醒人們在需求調研過程中應該注意的問題。
4、五種專案型別的標準，五種情況：
（1）了解需求，甚至包括用例根本不在最後的需求文件中使用的情況（模板見p108）
你的用例通常作為乙個黑盒，大多數都是使用者目標級別。你可以用乙個較高層的用例來描述語境，但是你最好不要經常使用海平面級別以下的用例。
（2）業務過程建模（模板見p108）
閱讀這些用例的人往往是一些高層人員、部門經理和高階執行官，因此盡量使這些用例可讀性強，減少細節的內容。步驟的編號突出了活動的時間順序。一定要在擴充套件中描述錯誤的處理，這樣才能揭示重要的業務規則。
（3）設計和量化系統需求（模板見p109）
當你為估計系統大小和結構而分析需求時，使用這個模板。以後，你可以細化需求知道完成這個完整的用例。
（4）在乙個短期、高強度的專案中編寫功能需求（模板見p110）
由於時間和經濟的原因，需要避免編碼的開銷和編寫完整模板；因此你可以使用非正式的格式。但你還是必須了解前置條件、保證條件和擴充套件。
（5）在乙個長期、大型專案中，在增量式開發開始時編寫詳細的功能需求。（模板見p110）
當你收集行為需求，並且需要完整正式的用例格式中的所有資訊時，可以使用上述模板。這種模板可能應用在大型、關鍵、昂貴的專案中；或者應用在有固定預算的專案中；或者應用在開發組分步在不用地方，在增量式開發的開始階段需要擴充和檢查以前設計的量化用例時；或者這樣做時你的習慣（最後一句有意思，呵呵，「我就是喜歡」）
總結：這一章就是把之前10章所闡述的用例體各個部分彙總起來，然後根據不用的專案提出不同的用例模板，這樣是科學的，因為每個專案都不同，不能用一種不變的用例格式來對付，要因專案而異。到這章為止，這本書的第一部分——用例體部分，已經結束。
編寫有效的業務用例 讀書筆記03
第五章 三個命名的目標層次 1 使用者目標 藍色，海平面 user goal 它是主執行者努力使工作得以完成的目標，或是使用者使用系統的目標。它相當於業務過程工程中的 基本業務過程 2 概要層次目標 白色，雲朵，風箏，summary level goal 包含多個使用者目標。在描述系統時，他們有如下...
編寫有效的業務用例 讀書筆記02
第三章 範圍 1 範圍 scope 一詞用來描述專案開發人員負責的設計工作的邊界，以便與應由其他人負責的設計工作或已經完成的設計工作相區別 2 與被討論系統的功能範圍和設計範圍相關的主題都可以使用 內 外 列表，內 外表示在專案內還是在專案外。主 題內外 以任意形式開發票 外產生請求報告 請求可能由...
編寫有效的業務用例 讀書筆記01
第一章 引言 1 用例是代表系統中各個專案相關人員之間就系統的行為所達成的契約。用例描述了在不同條件下，系統對某一專案相關人員的請求所作出的響應。舉個例子 某人在atm機提款，這個本身就可以看作乙個用例，只是它的層次比較高，細分下去，人可以在atm上做什麼？粗略一想，就有幾條 1 查詢餘額 2 提款...