建模知識(shí)在需求分析、梳理中的應(yīng)用(中)

3 評論 10432 瀏覽 83 收藏 9 分鐘

文接上篇《數(shù)據(jù)庫建模知識(shí):在需求獲取與分析中的應(yīng)用(上)》,本文詳述如何將建模知識(shí)應(yīng)用到需求梳理和需求設(shè)計(jì)中。

1. 模型建立后如何呈現(xiàn)

想要將腦海中的實(shí)體-聯(lián)系表達(dá)、呈現(xiàn)出來,能讓開發(fā)、測試、客戶看的明白,我一般會(huì)使用實(shí)體-聯(lián)系圖和角色權(quán)限矩陣來表達(dá)。

1.1 實(shí)體-聯(lián)系圖

(1)業(yè)余畫法

專業(yè)性要求不高的情況下,一般的畫圖軟件都可以實(shí)現(xiàn),比如Axure、Visio、word、ppt,就連系統(tǒng)自帶的畫圖軟件都可以。雖然這種畫法比較隨意,也會(huì)忽略在數(shù)據(jù)庫階段建模要考慮的其他屬性,但對于產(chǎn)品來說,這個(gè)業(yè)余畫法也夠用了。

以下是方法:

  1. 確定實(shí)體A和B,用長方形的方框表示,方框內(nèi)填入實(shí)體名稱。
  2. 用一條直線將兩個(gè)實(shí)體連接起來。
  3. 確定兩個(gè)實(shí)體之間的聯(lián)系,插入文本,填入聯(lián)系,注意方向性,不要搞反了。

如下圖,以word示例:

注:建議每個(gè)實(shí)體-聯(lián)系都加上解釋,避免查看的人因?yàn)椴欢霈F(xiàn)二次解釋場景。

(2)專業(yè)繪制

專業(yè)繪制,是指技術(shù)/開發(fā)人員在進(jìn)行數(shù)據(jù)庫設(shè)計(jì)之前會(huì)根據(jù)系統(tǒng)業(yè)務(wù)需求而進(jìn)行的建模工作,一般會(huì)使用專業(yè)的數(shù)據(jù)庫建模工具,這樣的話,后面的表結(jié)構(gòu)是可以直接由這個(gè)模型進(jìn)行轉(zhuǎn)化的。

注:對于產(chǎn)品來說,可以稍作了解,無需太深入研究。感興趣而且有時(shí)間那另算。答主本人是學(xué)軟件工程出身,所以這塊還是略有接觸,但由于實(shí)習(xí)+工作都是關(guān)于需求方面的工作,所以專業(yè)程度僅限于大學(xué)老師講的基礎(chǔ)(攤手)。

1.2? 角色權(quán)限矩陣

角色權(quán)限矩陣,顧名思義,就是看系統(tǒng)中有哪些角色,這些角色有哪些權(quán)限。這個(gè)是一定要去思考并表達(dá)出來的,一個(gè)系統(tǒng)在被提出來時(shí),就應(yīng)該考慮系統(tǒng)的若干 “干系人”,就是將來使用這個(gè)系統(tǒng)的人員角色定義。

在與用戶詳細(xì)溝通需求后,這個(gè)系統(tǒng)是以什么方式去做,我們大概是清楚的,即使不清楚,在整理需求時(shí),我們也會(huì)去思考適合的方式。

問題圍繞:

  1. 系統(tǒng)基于什么方案、平臺(tái)實(shí)現(xiàn),后臺(tái)+前端;
  2. 前端的角色實(shí)體有哪些,后端的角色實(shí)體有哪些;
  3. 前端各角色通過系統(tǒng)想要實(shí)現(xiàn)什么,即對物實(shí)體的操作;
  4. 后端角色需要做哪些模塊來配合前端完成這件事情;
  5. 各角色對實(shí)體的管理有何限制(包括操作和實(shí)體屬性),如增、刪、改、查,再加上系統(tǒng)特有的功能。

一個(gè)系統(tǒng)對應(yīng)抽離出角色實(shí)體、物實(shí)體后,這個(gè)基本就可以歸納出來。

以下內(nèi)容由Excel繪制,X軸(橫軸)代表角色實(shí)體,Y軸(縱軸)代表物實(shí)體,其中1級為功能模塊,2級為功能,3級為對該功能的操作,有差異請以實(shí)際情況為準(zhǔn)。

下圖為例:

角色權(quán)限矩陣不像UML中的用例圖那樣,一千個(gè)人眼中有一千個(gè)哈姆雷特,粒度隨心。角色權(quán)限矩陣建議盡量細(xì)化,有時(shí)候甚至可以細(xì)化到具體的某個(gè)字段,這樣做的好處是,在設(shè)計(jì)階段,我們可以不用再文字累述哪些人員可見哪些人員不可見。

2. 如何將模型轉(zhuǎn)化為流程,流程梳理

主要介紹系統(tǒng)主流程及實(shí)體狀態(tài)圖轉(zhuǎn)化的畫法。

2.1 系統(tǒng)主流程

角色權(quán)限矩陣確定后,基本上系統(tǒng)的主流程是可以確定下來;

我一般使用Axure或者Visio來繪制流程圖,如只是業(yè)務(wù)較簡單的圖,我會(huì)用Axure直接畫;如查看的人對美觀度要求比較高且業(yè)務(wù)較復(fù)雜的,建議用Visio的跨職能流程,方便閱覽系統(tǒng)-人員,人員-人員的流程扭轉(zhuǎn)和關(guān)鍵步驟的銜接。

跨職能流程圖,繪制要點(diǎn)如下,后續(xù)會(huì)持續(xù)追加;

  1. 跨職能流程圖的泳道,一般是系統(tǒng)(平臺(tái)涉及到的系統(tǒng),包括對接平臺(tái))、系統(tǒng)角色(即上篇中說的角色實(shí)體),要根據(jù)流程圖的側(cè)重點(diǎn)來選取不同的角度;
  2. 跨職能流程圖的分隔符,一般是系統(tǒng)模塊,或者自定義的一個(gè)流程范圍;
  3. 從人員數(shù)據(jù)、基礎(chǔ)數(shù)據(jù)的初始化開始,再到后面的業(yè)務(wù);
  4. 務(wù)必做到每個(gè)環(huán)節(jié)的銜接、貫通,如做不到,嘗試從實(shí)體的狀態(tài)或增加規(guī)則邏輯來實(shí)現(xiàn);
  5. 如果暫時(shí)沒有辦法將應(yīng)該串聯(lián)起來的環(huán)節(jié)銜接,先把有問題的環(huán)節(jié)填充為紅色,嘗試從狀態(tài)圖入手;

下圖為例,主流程中的一小部分:

2.2 實(shí)體狀態(tài)圖

系統(tǒng)中涉及到的實(shí)體,包括物實(shí)體、角色實(shí)體都可以有狀態(tài)的,只是有時(shí)候可能系統(tǒng)用不到,就不會(huì)設(shè)置狀態(tài);我一般在業(yè)務(wù)較復(fù)雜,或者主流程梳理出現(xiàn)卡殼、斷掉的情況下,會(huì)來重新設(shè)計(jì)下這塊業(yè)務(wù)涉及到的實(shí)體的狀態(tài)轉(zhuǎn)化圖;

狀態(tài)圖3要素介紹:

  1. 實(shí)體:并非所有的實(shí)體都要考慮,而是針對此狀態(tài)圖涉及到的關(guān)鍵實(shí)體;如上圖中的兩個(gè)狀態(tài)OFF和ON,其實(shí)是基于燒水壺這個(gè)實(shí)體的;
  2. 狀態(tài):描述一個(gè)實(shí)體基于事件反應(yīng)的動(dòng)態(tài)行為,顯示了該實(shí)體如何根據(jù)當(dāng)前所處的狀態(tài)對不同的事件做出反應(yīng);如上圖中的OFF和ON;
  3. 轉(zhuǎn)化操作:即刺激狀態(tài)轉(zhuǎn)化的事件;如上圖中的turnOn和turnOff。

實(shí)體狀態(tài)圖,繪制要點(diǎn)如下,后續(xù)會(huì)持續(xù)追加;

  1. 列出該狀圖涉及到的實(shí)體以及實(shí)體的初始狀態(tài);如涉及到的實(shí)體超過1個(gè),應(yīng)標(biāo)明狀態(tài)是屬于哪個(gè)實(shí)體,如下面的示例圖,橘色是報(bào)備的狀態(tài),藍(lán)色是價(jià)格申請的狀態(tài),綠色是合同的狀態(tài);
  2. 歸納出刺激實(shí)體狀態(tài)轉(zhuǎn)化的事件,分類歸納,即有可能這兩類事件對狀態(tài)的轉(zhuǎn)化是一致的,那他們就是屬于一類事件,但記得要將兩類事件都標(biāo)注出來;
  3. 檢查當(dāng)前實(shí)體的狀態(tài)是否滿足業(yè)務(wù)流程,如狀態(tài)缺失滿足不了,增加狀態(tài)或限制條件;說的過于籠統(tǒng),但只要只要有實(shí)際案例的經(jīng)驗(yàn),應(yīng)該都能了解我說的是個(gè)啥,攤手;
  4. 當(dāng)狀態(tài)圖梳理完成,貼合業(yè)務(wù)后,再去適當(dāng)?shù)恼{(diào)整系統(tǒng)流程圖;

先寫到這,后面會(huì)再開一篇寫寫建模知識(shí)在實(shí)際設(shè)計(jì)中的應(yīng)用。

【未完待續(xù)】

相關(guān)閱讀

數(shù)據(jù)庫建模知識(shí):在需求獲取與分析中的應(yīng)用(上)

 

作者:Andy。放松玩,專注思考的B端產(chǎn)品經(jīng)理。

本文由 @Andy 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載。

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號(hào)或下載App
評論
評論請登錄
  1. 后面不是講的流程圖嗎,跟建模有什么關(guān)系。求問作者

    來自廣東 回復(fù)
  2. 個(gè)人感覺StarUML非常好用,狀態(tài)機(jī)圖最終的狀態(tài)最好結(jié)束符表示,這樣給觀看的人更清晰,狀態(tài)名稱最好用動(dòng)賓來名稱比較好

    來自上海 回復(fù)
    1. 文中貼出的狀態(tài)圖只有一部分,因?yàn)槭菍?shí)際的項(xiàng)目,所以沒有貼出完整的;StarUML我在大學(xué)的時(shí)候也用過,工具用著順手就行,主要是能把意思表達(dá)出來即可;

      來自江蘇 回復(fù)