軟體需求最佳實踐(3)

用例是一種紀錄新系統或軟體更換時的需求的技術。每個用例包含一個系統在作業時與使用者或與其它系統之間交換資訊的場景。一般用例避免使用術語，而儘量使用顧客、使用者或他們的專家的語言。一般用例由軟體開發者和顧客一起寫成。用例之道：

• 不是系統完成的動作行為，而應該是有價值的業務活動的分解。
• 用例是需求分析的新視角-》業務視角。用例也可以是需求管理的基本單元。
• 用例價值的測試包括兩方面，一是業務活動的原子性，一是Boss測試。
• 用例的粒度可能會取決於企業內業務的分工。
• 對於用例的CRUD原則，更加重點的標準是是否是一系列隨機操作，是否由一個Actor完成。
• 用例需要避免功能分解，而應該是使用者業務場景驅動。

在用例中常用的關係是擴充套件(Extend)，包含(Include)和泛化。對於擴充套件和包含區別如下：

• 擴充套件：在某種條件是會被執行，也可能不執行。所以它有可能是一種可以劃到下個迭代的。
• 包含：包含的是子事件流，必然會呼叫到，而且是呼叫完後還會會到基用例。

對於獲取用例的方法主要有兩種，一種是自頂向下的流程派生法，跨職能流程圖和泳道就是參與者，其中的業務活動就是用例；另外一種就是自底向上的合併法，比如可以從條目化的使用者需求進行合併。在第一種方法中派生用例的時候需要注意：

• 去除掉非EndUser的泳道。
• 對泳道進行角色化的抽象。
• 判斷活動與系統是否有關係。

對於用例分析重點是事件和業務流程，而對於資料分析則重點是在業務資料上面。用例分析代替不了資料分析。資料分析常用的就是業務實體分析，通過資料分析可以建立系統的領域模型。資料分析的目標就是理解業務領域中的業務術語和實體，包括語義關係，數量關係和主要內容。資料分析的要點就是要識別出具體的業務實體，以及這些業務實體間的關係。在FDD中的領域建模是基於資料和行為的綜合分析，包括Together之父PeterCoad發明的菜色建模法。他將資料類分為了行為，參與角色，人事物，通用描述四個方面的內容。

在用例模板中有幾個關鍵點，包括前置條件應該是系統必須能夠檢測和驗證的。在用例描述中應該拒絕太多的實現細節；用例本身無法展示很多介面互動，因此需求建模還應該包括介面和互動建模的內容。而對於報表等需求往往並不太適合用例的表達方式，可以根據企業情況來確定具體的報表類需求的描述方法。

在用例模板中還有干係人利益的內容，在這裡特別說明的是分析干係人利益可以幫助我們挖掘潛在的需求。雖然關係人不是Action事件的之間操作者，但是干係人的利益往往會影響到用例本身的需求。

另外關於這次培訓後的具體感悟後續還會繼續寫，徐鋒老師提供了一個書單我會整理到豆瓣上。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/15027599/viewspace-563289/，如需轉載，請註明出處，否則將追究法律責任。