樓主,請教一個問題:
我現在在做一個項目,把所有的涉及到的業務都細分成添加、刪除、瀏覽等等類似的一個個小的用例,這應該都是業務用例了,那請問我的系統用例是哪些呢?應該怎麼寫?或者說有必要寫嗎?(你可以拿一個電子商務的系統作例子指導一下,多謝了!)
你列舉出的那些用例實際上都是系統用例了,你還怎麼再細分呢?業務用例是指的營運目標,例如說維護人員檔案,這是一個完整的營運目標,也是一個業務用例。至於維護辦法,有手工的,有自動的,有的只能加不能刪,有的只能修改,有的只能看....這些,是實現營運目標的方法。在這些方法中,打算納入軟體開發範圍的,才叫做系統用例。
樓主,多謝你的指教
那我是不是可以這樣理解呢,如果把業務用例進行功能上的細分的話,分成若干個小的用例,那麼這些小的用例是不是就是系統用例?
就象維護人員檔案,如果細分成添加檔案,修改檔案,刪除檔案,查看檔案等等。。。
如果你的答案是肯定的話,那我是不是可以繼續這樣理解:一般情況下,業務用例實際上是在一個比較高的層面上來看商務邏輯,更接近於使用者的直接需求,而系統用例則是商務邏輯的詳細的劃分,更接近與程式的設計了?
多謝你的賜教!!!!!
不大對喔。系統用例和業務用例的區別並非是細分。
請注意理解:業務用例是用來捕獲功能性需求的,功能性需求是由actor的營運目標來體現的。也就是對於actor來說,他所負責的業務需要由一系列的營運目標組成。比如一個檔案管理員,他的營運目標就是維護檔案。比如論壇管理員,他的營運目標有維護使用者,維護文章等..這些營運目標構成actor職責的全部。業務用例體現了需求。
而需求的實現有多種方式。如何?它,是由系統用例來體現的,它們並不是一個簡單的細分關係,雖然看上去象。就說維護檔案吧,這樣一個營運目標,會有多種不同的用例情境去完成它,這些情境包括如何增加檔案,如何修改檔案,如何刪除檔案....對於系統用例來說,就是通過分析這些情境,來決定哪些情境中的哪些部分是要納入系統建設範圍的。比如維護檔案業務用例中,假設由於某個原因,修改檔案很困難,只能通過先刪除,再全部重建的方式來實現,那麼系統用例就增加檔案,刪除檔案,而沒有修改檔案。
業務用例和系統用例是分別站在客戶的業務視角和系統建設視角來規劃的。業務用例不是接近,而是完全的直接需求,系統用例也不是商務邏輯的詳細劃分,而是系統對需求的實現方式,但不是與程式設計無關,它只是說,要建設的系統功能性需求由這些系統用例構成。
所以業務用例和系統用例都是需求範疇,它們分別代表了業務範圍和系統範圍。