本書描述了一種編寫問題陳述部分的方法，即使用案例方法。
這是什麼？ 這是對使用者與系統（或與業務）互動場景的描述。 在這種情況下，系統充當黑盒子（這使得可以將複雜的設計任務劃分為設計互動並確保這種互動）。 同時，引入了符號標準，這確保了閱讀的方便性（包括非參與者），並允許對完整性和是否符合利益相關者的目標進行一些檢查。
用例範例
以透過電子郵件在網站上授權為例，該場景是什麼樣的：
（系統）登入網站存取您的個人帳戶。 ~~（海平面）
情境: 未經授權的客戶使用電子郵件作為登入名稱登入網站，以便網站識別他並顯示他的個人資訊：瀏覽記錄、購買歷史記錄、當前獎勵積分數等。
級別： 使用者目標
主要人物： 顧客（我們線上商店的訪客）
範圍： 客戶與線上商店網站的交互
利害關係人和利益：
- 行銷人員希望識別最大數量的網站訪客，以擴大個人郵件的覆蓋範圍，
- 安全專家希望確保不存在未經授權存取訪客個人資料的情況，包括嘗試猜測帳戶的密碼或搜尋密碼較弱的帳戶，
- 攻擊者想要獲得受害者的獎金，
- 競爭對手希望對產品留下負面評論，
- 殭屍網路想要取得商店的客戶群並利用攻擊使網站無法運作。
前提條件： 訪客不得獲得授權。
最低保證： 訪客將知道授權嘗試是成功還是失敗。
成功的保證： 訪客已獲得授權。
主要場景：
- 客戶端發起授權。
- 系統根據「安全規則第23條」確認用戶端未獲得授權，且不超過給定會話（搜尋多個帳戶的弱密碼）的不成功授權嘗試次數。
- 系統增加授權嘗試次數的計數器。
- 系統向客戶端顯示授權表。
- 客戶輸入他的電子郵件和密碼。
- 根據“安全規則第 24 條”，系統會確認系統中存在具有此類電子郵件的用戶端，且密碼匹配，且該帳戶的登入嘗試次數未超過。
- 系統對客戶進行授權，並將本次會話的瀏覽記錄和購物籃添加到該客戶帳戶的最後一次會話中。
- 系統顯示授權成功訊息，並移至用戶端因授權而中斷的腳本步驟。 在這種情況下，頁面上的資料將根據個人帳戶資料重新載入。
擴展：
2.a. 客戶端已獲得授權：
2.a.1. 系統通知客戶端先前執行的授權的事實，並提出中斷腳本或轉到步驟 4，如果步驟 6 成功完成，則執行步驟 7 並進行說明：
2.a.7. 系統解綁舊帳戶下的客戶端，對新帳戶下的客戶端進行授權，而本次交互會話的瀏覽記錄和購物車保留在舊帳戶中，不會轉移到新帳戶中。 接下來，轉到步驟 8。
2.b 授權嘗試次數已超過「安全規則第 23 條」規定的門檻：
2.b.1 轉到步驟4，授權表上額外顯示驗證碼
2.b.6 系統確認驗證碼輸入正確
2.b.6.1 驗證碼輸入錯誤：
2.b.6.1.1。 系統也會增加該帳戶的不成功授權嘗試的計數器
2.b.6.1.2。 系統顯示失敗訊息並返回步驟2
6.a. 未找到包含此電子郵件的帳號：
6.a.1 系統顯示一條有關失敗的訊息，並提供一個選擇：前往步驟 2 或前往「使用者註冊」場景並儲存輸入的電子郵件，
6.b. 此電子郵件帳號的密碼與輸入的密碼不符：
6.b.1 系統增加此帳號登入嘗試失敗的計數器。
6.b.2 系統顯示失敗的訊息，並提供進入「密碼恢復」場景或進入步驟 2 的選擇。
6.c：此帳戶的登入嘗試計數器已超過「安全規則 24」的閾值。
6.c.1 系統顯示帳號登入被封鎖 X 分鐘的訊息，然後繼續步驟 2。
有什麼很棒的
檢查完整性和是否符合目標，也就是說，您可以將需求交給另一位分析師進行驗證，從而減少在問題制定階段出現的錯誤。
使用黑盒子系統可以讓您將自動化內容的開發和與客戶的協調與實施方法分開。
它是分析師路徑的一部分，也是可用性的主要部分之一。 使用者的場景定義了他運動的主要路徑，這大大減少了設計師和客戶的選擇自由度，有助於提高設計開發的速度。
我對描述中標識每個交互步驟的例外情況的地方感到非常滿意。 一個完整的 IT 系統必須提供某種異常處理，有些是手動的，有些是自動的（如上例所示）。
經驗表明，考慮不周的異常處理很容易使系統變得非常不方便。 我記得在蘇聯時期的故事，為了做出決定，你必須獲得不同服務部門的多次批准，當最後一個服務部門說 - 但你的申請名稱錯誤或其他錯誤時，這是多麼痛苦標點符號，重做一切並重新協調一切。
我經常遇到這樣的情況：沒有考慮到異常的系統的操作邏輯需要對系統進行大量的重新設計。 因此，分析師的大部分工作都花在異常處理上。
與圖表相反，文本表示法允許識別和涵蓋更多例外情況。
從實踐中加入方法
與使用者故事不同，用例不是聲明中獨立確定優先順序的部分。
在上述場景中，考慮異常“6.a.” 未找到包含此電子郵件的帳戶。” 以及下一步「6.a.1 系統顯示失敗訊息並繼續執行步驟 2」。 幕後留下了哪些負面的東西？ 對客戶來說，任何回報都等於他輸入資料所做的所有工作都被丟進了垃圾掩埋場。 （只是在腳本中看不到！）可以做什麼？ 重建腳本以避免這種情況發生。 是否有可能做到這一點？ 作為範例，您可以查看 Google 授權腳本。
場景最佳化
這本書討論了形式化，但很少談到優化此類場景的方法。
但是可以透過優化場景來加強該方法，並且用例形式化方法允許做到這一點。 具體來說，您需要考慮發生的每個異常，確定原因並重建腳本，以消除異常或最小化客戶旅程。
從網上商店下訂單時，您必須輸入送貨城市。 可能會出現商店無法將貨物運送到客戶選擇的城市的情況，因為沒有運送到那裡，或者由於尺寸限制，或者由於相應倉庫缺貨。
如果簡單描述註冊階段的互動場景，我們可以寫「通知客戶無法送貨，並提出更換城市或購物車內容」（許多新手分析師就到此為止）。 但如果這樣的情況很多，那麼場景就可以優化了。
您需要做的第一件事就是讓您只選擇我們可以送貨的城市。 什麼時候做這個？ 在網站上選擇產品之前（透過 IP 自動偵測城市並進行說明）。
其次，我們只需要選擇我們可以交付給客戶的貨物。 什麼時候做這個？ 選擇時 - 在產品圖塊和產品卡上。
這兩項變更對於消除此異常大有幫助。
測量和指標的要求
當考慮最小化異常處理的任務時，可以設定報告任務（未描述用例）。 有多少個異常，在什麼情況下發生，加上有多少傳入場景成功通過。
可惜。 經驗表明，這種形式的場景報告要求是不夠的；有必要考慮主要不以用例形式描述的流程的報告要求。
獲得可用性
在我們的實踐中，我們擴展了用例描述形式，對實體和資料的特定屬性進行描述，供客戶端做出決策，從而增強了後續的可用性。
為了可用性設計，我們新增了一個輸入部分 - 顯示資料。
在有授權的場景下，這是客戶端在系統中被授權的事實。 如果用戶端已預先授權，則在成功授權後顯示有關將導航記錄和購物車切換到新帳戶的警告。
一般來說，這是向客戶展示必要的信息，以便他可以根據場景做出他進一步行動的決定（你可以問客戶這些數據是否足夠，還需要什麼，信息有什麼作用）客戶需要做出決定） 。
如果輸入的資訊被單獨處理並且形成不同的異常，那麼將輸入的資訊劃分到輸入欄位中也是值得的。
在客戶端授權的範例中，如果將輸入的資訊分為登入名稱和密碼，那麼值得更改授權腳本以突出顯示輸入單獨的登入名稱和單獨的密碼的階段（這是在 Yandex、Google 中完成的，但大多數在線商店都沒有這樣做）。
達到所需的資料轉換
您也可以從腳本中提取資料轉換演算法的要求。
Примеры：
- 為了做出在網上商店購買產品的決定，客戶需要在產品卡上了解該產品到他所在城市的可能性、成本、交貨時間（這些是根據該產品在該城市的可用性通過演算法計算出來的）倉庫和供應鏈參數）。
- 當在搜尋行中輸入短語時，客戶端會根據演算法顯示搜尋建議（由演算法產生...）。
在總
總的來說，不幸的是，讀完這本書後，並不清楚如何從分析師到業務問題，再到開發人員的正式技術規格。 書上只講述了部分流程，輸入步驟不清楚，後續步驟也不清楚。 用例本身通常並不是開發人員的完整陳述。
儘管如此，當互動導致主體中的某些內容發生變化時，這是一種形式化和處理物件與主體之間的互動場景的非常好的方法。 它是少數允許具有顯式異常搜尋點的可驗證需求的編寫方法之一。
這本書是分析師開始編寫可測試策略的必讀之書。
來源： www.habr.com