案例分析: UML大戰(zhàn)需求分析
本文會(huì)借著一個(gè)小的案例分析,來(lái)簡(jiǎn)單的說(shuō)明下會(huì)常用到的幾個(gè)UML圖,主要包括順序圖、用例圖、活動(dòng)圖以及狀態(tài)機(jī)圖,另外文章的最后部分會(huì)將這些UML的圖例和我們平日工作里用到的泳道圖、流程圖做一些簡(jiǎn)單的對(duì)比總結(jié)。
以前的文章中也寫(xiě)過(guò)一些需求分析的內(nèi)容,但是更多的其實(shí)是偏向于需求挖掘的理論知識(shí),可實(shí)踐性并不是很強(qiáng),不管最終需求分析的結(jié)果如何,最終都是由相關(guān)人員去實(shí)現(xiàn)的。面向設(shè)計(jì)師的部分的主要產(chǎn)出物就是我們通常說(shuō)的線框圖,那面向開(kāi)發(fā)測(cè)試人員的產(chǎn)出物呢?
給到開(kāi)發(fā)測(cè)試人員的需求產(chǎn)出物常見(jiàn)的組合形式就是需求說(shuō)明書(shū)+流程圖…而UML可以幫助我們更好的完成需求分析以及流程梳理這部分的工作,換言之,也就是線框圖之前的部分工作。UML即Unified Modeling Language 叫做統(tǒng)一建模語(yǔ)言,適用于數(shù)據(jù)建模,業(yè)務(wù)建模,對(duì)象建模和組件建模。
之前就有朋友給我安利過(guò)產(chǎn)品經(jīng)理應(yīng)該懂點(diǎn)UML,后來(lái)我就去補(bǔ)了一下相關(guān)的知識(shí),覺(jué)得是受益匪淺,尤其是在業(yè)務(wù)邏輯比較復(fù)雜的情況下,這套方法真的是很實(shí)用。雖然說(shuō)UML的方法有些已經(jīng)不太適用了,但是UML的思想?yún)s是仍然適用的,在我們平時(shí)畫(huà)流程圖的時(shí)候,很多都體現(xiàn)著UML的思想,可能我們自己都并不是很清楚罷了。
首先說(shuō)明一下,我自己對(duì)UML的理解也并不是很深,只是將自己的一點(diǎn)理解和看法和大家分享一下,只是為了拋磚引玉,文中有不正確的地方望加以指正。而且文中只提到了UML中常用到的幾種圖例,關(guān)于更多的內(nèi)容感興趣的小伙伴可自行學(xué)習(xí)查閱相關(guān)資料…
另外文章的案例相關(guān)的部分是行文過(guò)程中初步考慮的,可能會(huì)存在考慮不周全的地方,而且相關(guān)流程圖也只考慮了主線流程,未考慮分支流程和異常流程,不足以達(dá)到直接指導(dǎo)開(kāi)發(fā)的程度。因?yàn)楸疚闹饕雮鬟f的是一種方法論,一種思考方式,下面我們開(kāi)始正文部分。
本文會(huì)借著一個(gè)小的案例分析,來(lái)簡(jiǎn)單的說(shuō)明下會(huì)常用到的幾個(gè)UML圖,主要包括順序圖、用例圖、活動(dòng)圖以及狀態(tài)機(jī)圖,另外文章的最后部分會(huì)將這些UML的圖例和我們平日工作里用到的泳道圖、流程圖做一些簡(jiǎn)單的對(duì)比總結(jié)。
一.背景說(shuō)明
平時(shí)在公司附近吃飯的時(shí)候,經(jīng)常會(huì)和一些店鋪的收銀員、服務(wù)員以及老板打交道,這就是文中案例的靈感來(lái)源,沒(méi)有詳細(xì)的市場(chǎng)行業(yè)調(diào)研,也沒(méi)有詳細(xì)的用戶訪談和數(shù)據(jù)支撐,只是簡(jiǎn)單的實(shí)地觀察和部分訪談,以及主觀的YY。
接下來(lái)為會(huì)大家展現(xiàn)一款點(diǎn)餐系統(tǒng)從0到0.5的思考全過(guò)程,該點(diǎn)餐系統(tǒng)主要的目標(biāo)就是為了能夠提高店鋪的運(yùn)營(yíng)效率,提升顧客的就餐體驗(yàn)。之所以是0.5,是因?yàn)榉治鲞^(guò)程到原型設(shè)計(jì)之前就截至了,但是個(gè)人覺(jué)得原型是處于最表現(xiàn)層的東西,背后的支撐系統(tǒng)以及流程才是更重要的東西。
二. 用戶及產(chǎn)品分析
產(chǎn)品是解決問(wèn)題的手段,而不是說(shuō)一定需要做產(chǎn)品,一定要切記這一點(diǎn),最本質(zhì)的其實(shí)是解決問(wèn)題,產(chǎn)品只是一種手段。用戶則是產(chǎn)品的最終使用人,可能會(huì)有一個(gè)或多個(gè)類型的用戶群體。
1. 用戶分析
經(jīng)過(guò)這段時(shí)間在該店面的觀察得知,該店面的角色主要分為4種,分別是收銀員、服務(wù)員、廚師以及老板, 這幾種角色可能都是需要使用點(diǎn)餐系統(tǒng)的,也可能只是部分需要使用。
2. 場(chǎng)景分析
在沒(méi)有點(diǎn)餐系統(tǒng)之前,該店面是這樣運(yùn)轉(zhuǎn)的,老板負(fù)責(zé)和顧客進(jìn)行交流,確定點(diǎn)餐之后就記下來(lái),然后將原件給到收銀員,服務(wù)員拿著手抄的復(fù)印版給到后廚,后廚做好菜之后,由服務(wù)員進(jìn)行上菜,最后由服務(wù)員進(jìn)行結(jié)算,收銀員進(jìn)行記賬。
這樣的一個(gè)整體流程的弊端就不再贅述,除了在一些很小的門店,應(yīng)該也會(huì)較少見(jiàn)到這種模式了。我們平時(shí)在其他地方的點(diǎn)餐流程基本都是收銀員完成點(diǎn)餐、下單、收銀的流程,然后通知到后廚,最后由服務(wù)員進(jìn)行上菜,經(jīng)過(guò)簡(jiǎn)單加不嚴(yán)謹(jǐn)?shù)姆治隹梢缘贸鱿嚓P(guān)的需求如下:
3. 產(chǎn)品分析
接下來(lái)就到了需求分析和排優(yōu)先級(jí)的時(shí)候了,是所有用戶的需求都要滿足么?肯定不是,即使是目標(biāo)用戶的合理的需求也肯定不會(huì)都滿足,可以看到在這個(gè)點(diǎn)餐系統(tǒng)里的主要角色有老板和收銀員,其余兩個(gè)則屬于支撐性的次要角色。
也就是說(shuō)保證老板和收銀員能夠正常使用的話,這個(gè)點(diǎn)餐系統(tǒng)就能夠正常的運(yùn)轉(zhuǎn),只需要將相關(guān)的訂單信息傳遞到服務(wù)員和后廚處即可,老板和收銀員使用的肯定是兩個(gè)不同的系統(tǒng),經(jīng)過(guò)分析之后可以得出,一個(gè)點(diǎn)餐系統(tǒng)+一個(gè)后臺(tái)管理系統(tǒng)即能夠初步滿足大部分受眾的需求。
三. 業(yè)務(wù)分析
因?yàn)楸疚牡那疤峋褪抢肬ML來(lái)進(jìn)行分析的,所以這部分的分析會(huì)通過(guò)順序圖來(lái)完成,順序圖和我們平時(shí)使用的泳道圖很像,說(shuō)實(shí)話,我平常在這塊也是用泳道圖來(lái)進(jìn)行相關(guān)業(yè)務(wù)分析的,只在某次涉及到系統(tǒng)之間對(duì)接的時(shí)候用過(guò)一次順序圖。
順序圖主要適用于多角色之間的交互,角色可以指人也可以指系統(tǒng),主要是通過(guò)時(shí)間和順序來(lái)表明發(fā)生的事情以及相應(yīng)的信息傳遞,適用于對(duì)時(shí)效性要求較高且不太復(fù)雜的全局流程,不太適合用來(lái)表達(dá)分支流程和異常流程較多的情況。
在我們上述的案例中,比較核心的一個(gè)業(yè)務(wù)流程就是下單環(huán)節(jié),在該環(huán)節(jié)中,系統(tǒng)的外部角色就是顧客,內(nèi)部的角色會(huì)涉及到收銀員、服務(wù)員以及后廚,經(jīng)過(guò)梳理之后得到的順序圖如下:
梳理清楚業(yè)務(wù)流程能夠讓我們有更全局的認(rèn)知,從而更好的展開(kāi)后續(xù)的工作,后續(xù)就是需要確定我們的點(diǎn)餐系統(tǒng)需要做什么了。
四. 功能分析
功能分析就是通過(guò)在第二步的時(shí)候分析過(guò)程中,根據(jù)用戶的角色、使用的場(chǎng)景、需要解決的問(wèn)題來(lái)進(jìn)行相應(yīng)的功能設(shè)計(jì),這個(gè)時(shí)候就需要考慮優(yōu)先級(jí)與性價(jià)比了,通??勺鳛榉治龅木S度的指標(biāo)有使用人數(shù)、使用頻次、重要程度。
在UML中是通過(guò)用例圖來(lái)進(jìn)行系統(tǒng)范圍的界定的,這個(gè)用例圖其實(shí)是可以直接轉(zhuǎn)化成我們平常用來(lái)進(jìn)行產(chǎn)品分析的產(chǎn)品結(jié)構(gòu)圖,而這個(gè)產(chǎn)品結(jié)構(gòu)圖也就是我們后續(xù)迭代時(shí)候的產(chǎn)品的Roadmap。
接上文的案例分析,在該點(diǎn)餐系統(tǒng)中主要包含著兩個(gè)端,分別是后臺(tái)管理系統(tǒng)和收銀員用的點(diǎn)餐系統(tǒng),在此我僅以后臺(tái)管理系統(tǒng)為例,繪制了對(duì)應(yīng)的用例圖。
用例圖,其實(shí)就是說(shuō)明XX用戶能夠利用XX產(chǎn)品做什么事情,一個(gè)圈圈加文字表示一個(gè)用例,文字為動(dòng)賓短語(yǔ),線條的箭頭指示數(shù)據(jù)流向。用例中常用的父用例與子用例之間的關(guān)系主要有兩種,一種是include,一種是extend。
大多數(shù)的情況下父用例與子用例的關(guān)系都是前者,只有是在父用例的基礎(chǔ)上進(jìn)行的用例才是extend,比如上文中提到的查看統(tǒng)計(jì)報(bào)表,在查看的基礎(chǔ)上,需要進(jìn)行數(shù)據(jù)的導(dǎo)出,那就是extend。另外還有一種關(guān)系就是繼承,用到的機(jī)會(huì)較少,就不再展開(kāi)。
五. 功能設(shè)計(jì)
經(jīng)過(guò)市場(chǎng)行業(yè)競(jìng)品分析、用戶分析、業(yè)務(wù)流程分析最終會(huì)框定產(chǎn)品的邊界,之后才是具體的功能設(shè)計(jì), 最終會(huì)轉(zhuǎn)化為一個(gè)個(gè)具體的功能點(diǎn),一個(gè)個(gè)具體的頁(yè)面,一個(gè)個(gè)具體的頁(yè)面元素。戰(zhàn)術(shù)上的勤奮是掩蓋不了戰(zhàn)略上的懶惰的,貼心的功能,優(yōu)秀的交互也只能錦上添花,不足以決定產(chǎn)品的成敗。
通常情況下在進(jìn)行功能設(shè)計(jì)的時(shí)候,我們會(huì)繪制任務(wù)流程圖來(lái)梳理流程并指導(dǎo)開(kāi)發(fā),在UML中也有著兩種這樣功能相似的圖,分別是活動(dòng)圖以及狀態(tài)機(jī)圖。
活動(dòng)圖和我們通常畫(huà)的流程圖非常的相像,主要是用來(lái)描述任務(wù)流程的,適用于流程較復(fù)雜的情況,活動(dòng)圖通常會(huì)細(xì)化到每一個(gè)不可繼續(xù)細(xì)分的動(dòng)作上,以點(diǎn)餐系統(tǒng)中的點(diǎn)餐流程為例,繪制活動(dòng)圖如下:
狀態(tài)機(jī)圖顧名思義就是針對(duì)狀態(tài)的圖,通常情況適用于流程圍繞著某個(gè)事物的狀態(tài)展開(kāi)的情況,比如電商產(chǎn)品中訂單的狀態(tài)就非常適合用狀態(tài)機(jī)圖表達(dá),以點(diǎn)餐系統(tǒng)中的點(diǎn)餐狀態(tài)為例,繪制狀態(tài)機(jī)圖如下:
經(jīng)過(guò)層層的分析,層層的分解,最終這些東西會(huì)轉(zhuǎn)化為看得見(jiàn)摸得著的東西,也就是我們最常看到的線框圖。
六. 原型設(shè)計(jì)
略
這部分就是我們熟知的東西了,然而中間的思考過(guò)程才是更重要的,這部分只是最終結(jié)果的展現(xiàn)部分罷了,所以原型設(shè)計(jì)略過(guò)。
七. 小結(jié)
可以看到UML圖中的這幾個(gè)圖雖然我們并不常用,也可能并沒(méi)有聽(tīng)說(shuō)過(guò),但實(shí)際工作中,我們卻是在用其他的形式來(lái)做著相似的事情,比如用泳道圖來(lái)做著順序圖的事情,用產(chǎn)品結(jié)構(gòu)圖來(lái)做著用例圖的事情,用任務(wù)流程圖來(lái)做著活動(dòng)圖的事情,這些其實(shí)都是在利用UML的思想。
不管說(shuō)采用哪種形式,只要能夠?qū)崿F(xiàn)你想達(dá)到的目的即可,形式本身并不重要,比如我在工作中也沒(méi)有刻意的去畫(huà)活動(dòng)圖與狀態(tài)機(jī)圖,而是用畫(huà)活動(dòng)圖和狀態(tài)機(jī)圖的思想來(lái)畫(huà)流程圖,用泳道圖來(lái)進(jìn)行業(yè)務(wù)分析,一樣能夠取得比較好的效果。
以上就是本文的主要內(nèi)容,歡迎斧正、指點(diǎn)、拍磚…
作者: 王家郴 ,喜歡網(wǎng)球和騎行的產(chǎn)品汪。公眾號(hào)(產(chǎn)品經(jīng)理從0到1)。目前奔走在產(chǎn)品的道路上,漫漫產(chǎn)品路,與君共勉。
本文系起點(diǎn)學(xué)院廣州1509期優(yōu)秀學(xué)員@王家郴 原創(chuàng)發(fā)布,未經(jīng)許可,禁止轉(zhuǎn)載。
活動(dòng)圖畫(huà)錯(cuò)了,并行匯合那個(gè)節(jié)點(diǎn)
Uml
給樓主推薦一本朋友推薦的書(shū)感覺(jué)不錯(cuò),潘加宇的軟件上方法。樓主可以看看
軟件方法
請(qǐng)問(wèn)競(jìng)品調(diào)研要在那個(gè)步驟中實(shí)現(xiàn)呢
不是我杠精啊。。。他媽的開(kāi)發(fā)會(huì)看嗎????????????????我真的被開(kāi)發(fā)氣死
以我目前在移動(dòng)互聯(lián)網(wǎng)行業(yè)的經(jīng)歷來(lái)看,很少用到UML,流程圖就夠用了,用例圖用腦圖簡(jiǎn)化了。我們開(kāi)發(fā)一般自己會(huì)畫(huà)狀態(tài)機(jī)圖和時(shí)序圖…
會(huì)看,他們喜歡先看圖,不喜歡看大段的文字
UML相關(guān)的書(shū)籍,有推薦嗎?
現(xiàn)在有些人會(huì)一點(diǎn)原型工具就自稱為產(chǎn)品經(jīng)理,這是很搞笑的
UML在互聯(lián)網(wǎng)產(chǎn)品設(shè)計(jì)和需求分析中的重要地位是不可動(dòng)搖的
我從來(lái)沒(méi)用過(guò)UML
你從來(lái)沒(méi)用過(guò)不代表UML不重要 ??
用例劃分的不對(duì),用例之間的關(guān)系也不對(duì)。如果你想把某個(gè)具體的場(chǎng)景作為父用例的一個(gè)子用例,應(yīng)該使用繼承關(guān)系或者實(shí)現(xiàn)關(guān)系,而不是包含關(guān)系。包含關(guān)系,是指因?yàn)檫@個(gè)用例可以被多個(gè)用例共享,而抽取出來(lái)的一組公共用例。典型的例子,就是 查找訂單 這個(gè)用例, 這是 退訂單、改訂單 用例的公共部分,因此可以提取出來(lái)作為公共用例,這時(shí)候可以使用包含關(guān)系。 擴(kuò)展關(guān)系也說(shuō)的不對(duì),唉,打字太累,你還是重新學(xué)習(xí)UML吧。
兄弟,你行你畫(huà)一個(gè)唄。不是挑釁,純好奇你能畫(huà)成什么樣
UML,請(qǐng)問(wèn)你是通過(guò)什么渠道學(xué)習(xí)的呢
我就是看幾本UML相關(guān)的書(shū)籍,自己找?guī)讉€(gè)案例畫(huà)畫(huà),再不懂的就找人問(wèn)問(wèn)
還可以
感謝支持~
學(xué)員不錯(cuò)啊
感謝支持哈