使用範例描述需求(3) - 範例可能的來源

這篇文章將會探討如何從不同的來源撰寫範例，範例的好壞直接影響了開發團隊對需求的理解與執行，我們無法靠靈感瞬間寫出一個完美無缺的User Story，但透過從各種情境中提取範例，可以讓需求更加具體明確。這次，我們將介紹六種常見的範例來源，讓你在撰寫需求時，不再只靠感覺，而是有條有理地描繪每一個場景。

1. 正常狀況

在正常狀況下，系統或功能按照預期執行，使用者能夠順利完成操作，這種範例最常見，也最容易理解，是一個系統正常運作時的標準流程。

範例：

• Given 使用者輸入正確的登入憑證，
• When 使用者按下登入按鈕，
• Then 系統會成功登入並顯示首頁。

2. 異常的狀況

異常狀況是指系統在某些情況下無法按照正常流程執行，可能因為錯誤輸入、系統崩潰等原因，在這種狀況下，範例可以幫助描述如何處理錯誤情況。

範例：

• Given 使用者輸入錯誤的登入密碼，
• When 使用者按下登入按鈕，
• Then 系統顯示「密碼錯誤」訊息。

3. 和他人互動的狀況

這種狀況描述系統如何與其他系統或使用者互動，範例可以幫助我們了解系統之間如何交換數據、資訊，以及不同角色之間的互動流程。

範例：

• Given 一位 HR 管理員要核准員工的請假申請，
• When 員工提交請假申請，並且 HR 登入系統查看，
• Then HR 可以核准或拒絕該請求，系統將通知員工結果。

4. 曖昧的狀況

曖昧的狀況是指需求可能不明確或可能存在多種解讀的情況，範例的目的是為了釐清那些不確定的部分，避免在開發過程中出現誤會或歧義。

範例：

• Given 使用者選擇多個篩選條件查詢資料，
• When 系統發現沒有符合條件的結果，
• Then 系統應顯示「無符合條件的資料」，而不是顯示錯誤訊息或返回所有資料。

5. 非功能性的需求

這類需求通常指的是系統的性能、可靠性、安全性等非功能性需求，範例可以用來說明在特定非功能性需求下的表現。

範例：

• Given 同時有 500 名使用者在系統上操作，
• When 每個使用者進行查詢操作，
• Then 系統應在 2 秒內返回查詢結果。

6. 限制或約束

限制或約束指的是系統必須遵守的****特定規則或條件，可能來自於法律規範、公司政策或技術限制，範例可以幫助團隊理解這些約束如何影響需求實現。

範例：

• Given 系統中的敏感數據，
• When 使用者嘗試匯出資料，
• Then 只有有權限的使用者才能下載加密版本的數據檔案。

透過這六種範例來源，你可以更有效地從不同角度來描述需求，無論是正常運作的情況、異常狀況，還是非功能性需求與限制，這些範例都能幫助你減少需求溝通中的誤會，當你能夠靈活地運用這些範例描述，你的User Story不僅將更加清晰，團隊間的溝通效率也會大幅提升。

參考資料：
敏捷三叔公課程 – 如何寫出人人有共識的需求
阿塔的故事歲月之寫過無數故事