本來想把這專案的過程全部記錄下來的,可惜.....實言了!這次來講一下用例吧..
我這公司是**公司.和公司打交道的就是客戶和**商(其實**商也是客戶~~).客戶買.公司向**商買.所以呢.其實我就只有二個業務用例.
好了,最外圍的邊界已經確定了.這二個用例就是'買產品'和'賣產品'.圖我就不畫了,大家發揮想像力吧.(要記住這個用用例的參照物!'買產品'是客戶,'賣產品'是**商.角度先要搞清楚!)
那好,我們再對'買產品'這個用例進行分析.首先,在分析之前來了解一下公司具體的業務吧.公司提供給客戶的產品有很多種型別,比如訂貨,代檢測,代驗貨,代交收.......現在出來了,假設是四種,那麼用例就有四個場景圖的.
經過對業務的了解我們發現業務的開始與結束是訂貨----收錢.另外,公司是通過單據來體現業務過程的.再經過分析,這四個用例中,需要經過的部門是:銷售,採購,倉庫,財務協作而成的,業務工人有,客專(業務員),銷售主管,銷售總監,總監助理;採購主管,採購經理,倉庫主管,倉管員,會計員.財務主管.那麼,現在用協作圖完成場景分析就達到了.
業務用例和系統用例
拋開前一篇文章談的總體思路，我們今天來談一下需求分析工作實質性的做些什麼。在這裡，我們，將主要關注於分析層面，也即 uml中的用例模型和邏輯模型。在這裡要申明的是邏輯模型並不能完全算需求分析階段的工作，因為它包含了設計模型的概念，但是我又把它歸納了一塊到需求分析階段，原因在於邏輯模型中存在了業務物件...
業務用例和系統用例
業務用例與系統用例具有同樣的特徵，因此編寫和評審用例的方法對兩者都適用。在業務用例中說明的東西，也會在系統用例中說明。這形成了系統用例和使用者用例之間的合作。但這樣帶來了兩個壞訊息。第乙個壞訊息 編寫者和讀者經常把二者弄混，可能把系統行為放入業務用例中，也可能把業務操作歸於系統用例。如果能夠商量著去...
用例與業務建模
盡可能識別外部系統，並用色彩標註新的外部系統和服務 我使用的是馬蜂窩預定酒店的流程 c.對比兩個時代 不同地區產品的用例圖，總結在專案早期，發現創新的思路與方法 兩個用例圖基本的功能差別不大，在搜尋酒店 選擇酒店這方面都大同小異，不過新時代的酒店支付功能有所變化。創新的思路與方法在於，要發現早期專案...