用例與需求

解決需求問題需要考慮的地方

1、 為什麼要開發這個系統？

a)         這個系統的目标（visions）是什麼？這個目标可以衡量嗎？比如用具體的時間或金錢來衡量。

b)        目前的業務狀況如何？系統必須達到什麼程度才算沒有白上？

c)        客戶對使用系統前和使用系統後的不同或應有的差別心裡是否有數？

2、 系統涉及到的人員對系統分别有何要求？（銷售系統為例）

a)         客戶，沒有該系統，客戶也可以正常送出購買請求，那該系統到底帶給他們什麼？

b)        銷售者，希望系統為他們解決什麼問題？

c)        管理者，系統是否幫助他們更好地決策？

3、 需求分析是否寫出有價值的東西？是否捕獲到真正需求？

a)         文檔規範不規範不是主要問題，需求是否正确捕獲？

b)        所有假設出來的角色，是否有存在真正價值？

c)        所有隐含的系統需求是否都是為visions服務？

d)        用例是否有存在的理由？防止需求的蔓延。

e)         所有“非必要的需求”是否都已經得到充分驗證？（如一些“權限管理”）

4、 用例的确定。

a)         所有的“前置條件”和“後置條件”是否可以判斷？這2個條件都應該是一種“狀态的描述”而不是“動作的描述”。比如應該使用“使用者已經被登出”而不是“使用者退出系統”來描述“退出登陸”。

b)        所有的“涉衆利益”是否都考慮到？如果系統突然無法正常運作，哪些人的利益将受損害？

c)        用例是否能夠形成一份所有相關人員就系統的行為所應達成的“契約”？

d)        “涉衆利益”是否是真實的？必須是涉衆自己提供的才是真實的，由設計者“假設”的涉衆利益是不真實的。

e)         隻要滿足前置條件，按路徑走，是否一定會達成最終的後置條件？

f)         路徑描述中是否存在無法驗證的詞彙，如“明顯的”，“美觀的”？

g)        每一步是否都包括了“執行者做什麼”和“系統做什麼”并區分開來？

h)        是否正确區分開“設計”和“需求”？“如果不這麼做，涉衆的利益将受到損害”，那麼這個就是需求，隻有“需求”需要和使用者讨論，“設計”不應該與使用者讨論。如果使用者明确提出該如何“設計”，那麼該“設計”應被列為“需求”而不是“設計”。

i)          不要在任何路徑描述中帶有“暗示性需求”，比如“使用者點選一條記錄”，暗示了“使用者要用‘點選’來選擇”，應該使用“使用者選擇一條記錄”，即使使用者明确表明要用“點選”，也不應該寫在這裡。

j)          讨論用例應該多詳細沒有意義，用例應該盡可能“真實”，而不是盡可能“抽象”或盡可能“具體”。

每個用例是否提供了完整的價值？如果沒有，那它應該是其他用例的一個部分而不是單獨一個用例，如“檢視任務”作為一個用例隻有當員工可以對老闆說：“今天我的工作是一共檢視了n個任務”時才成立，否則它必須作為其他用例的一部分。

<a href="http://syeerzy.netyi.net/blog/user1/16/archives/2005/255.html">http://syeerzy.netyi.net/blog/user1/16/archives/2005/255.html</a>