寫在前面

終于寫到這個(gè)系列的最后一篇了……
讓我算算，第一篇是上個(gè)月發(fā)的還是上上個(gè)月發(fā)的？

因?yàn)闀r(shí)間太長(zhǎng)，所以我們先來(lái)回顧一下為什么要寫這個(gè)系列。

我認(rèn)識(shí)的很多團(tuán)隊(duì)都是在敏捷的方法，近些年來(lái)，這類快速迭代的開發(fā)流程在整個(gè)圈子里面迅速的流行起來(lái)。
不管是出于為了快速交付、快速驗(yàn)證、還是不寫文檔等諸多原因。
不知道大家在執(zhí)行敏捷過(guò)程中，特別是作為BA或者產(chǎn)品經(jīng)理，發(fā)現(xiàn)有個(gè)問(wèn)題。
這么多用戶故事，這么多高內(nèi)聚低耦合的用戶故事，你有辦法組織在一起嗎？

其實(shí)我一直在考慮一個(gè)問(wèn)題，就是敏捷執(zhí)行一段時(shí)間后，如何能保證不偏離當(dāng)初設(shè)定好的目標(biāo)。
有人說(shuō)，我們就沒(méi)目標(biāo)。
是，可能剛開始做產(chǎn)品并沒(méi)有一個(gè)非常清晰的目標(biāo)，比如我要做個(gè)共享單車，比如我要做個(gè)共享女友。
但是總會(huì)有個(gè)愿景或者是想要解決的問(wèn)題。
我想要解決從家到地鐵的500米距離的問(wèn)題，我想要結(jié)束單身狗的命運(yùn)……

而且在評(píng)估一個(gè)需求或者用戶故事是否重要的時(shí)候，也很糾結(jié)。
因?yàn)槟繕?biāo)和問(wèn)題不明確，所以也不知道到底重不重要。
于是最后很可能演變成功能的堆砌。

連產(chǎn)品經(jīng)理或者需求負(fù)責(zé)人都有這種感受的話，就更別說(shuō)其他干系人了。
這種只見樹木，不見森林的方法，想想可能引發(fā)的后果，就有點(diǎn)“不寒而栗”。

我不是來(lái)抨擊敏捷的，因?yàn)槲野l(fā)現(xiàn)即便你用瀑布，可能也會(huì)有同樣的問(wèn)題。
你同樣會(huì)進(jìn)行需求的拆分，類似拆故事一樣。
形成需求矩陣或者需求樹進(jìn)行管理。
但是頂層需求之間有什么樣的關(guān)系，和你的整體目標(biāo)以及要解決的問(wèn)題有什么樣的關(guān)系，這個(gè)估計(jì)也會(huì)有欠缺考慮的時(shí)候。

最近很巧的，看了三本書，介紹了三種方法，從三個(gè)不同的角度，都是為了解決同樣的這個(gè)問(wèn)題：
“只見樹木，不見森林”。
第一本：用戶故事地圖
第二本：軟件需求設(shè)計(jì)
第三本：軟件需求可視化模型

軟件需求可視化模型概述

一提到模型，大家可能會(huì)想到UML。
但是正如《軟件需求可視化模型》提到的，UML還是會(huì)有點(diǎn)偏向技術(shù)的視角來(lái)進(jìn)行建模。
優(yōu)點(diǎn)是面向?qū)ο螅O(shè)計(jì)的考慮比較全面和清晰。
缺點(diǎn)就是，很容易在業(yè)務(wù)還沒(méi)有弄清楚的情況下，陷入技術(shù)細(xì)節(jié)，并且缺乏應(yīng)對(duì)業(yè)務(wù)價(jià)值等方面的建模。

在系統(tǒng)工程領(lǐng)域，模型分為：概念模型、邏輯模型、物理模型。
我的理解，UML更加偏向于邏輯模型。
而從UML衍生出來(lái)的SYSML，也更加偏向于邏輯模型。

需求可視化模型使用RML（需求建模語(yǔ)言），主要是針對(duì)軟件需求分析使用的，而且便于業(yè)務(wù)干系人理解，便于快速轉(zhuǎn)化為UML等開發(fā)設(shè)計(jì)人員可以理解的模型。
而RML的模型覆蓋比較廣，使用的面向?qū)ο蠛兔嫦蜻^(guò)程兩種分析方法的融合。

模型分類

RML主要分為四類OPSD，從四個(gè)視角對(duì)需求進(jìn)行分析和描述。

O： Object 目標(biāo)模型

主要用于描述系統(tǒng)的業(yè)務(wù)價(jià)值，并且根據(jù)系統(tǒng)的價(jià)值設(shè)置功能和需求的優(yōu)先級(jí)。
它比較特別的地方在于將功能與業(yè)務(wù)目標(biāo)聯(lián)系起來(lái)。
通過(guò)建模，理清WHY，為什么要做這個(gè)功能，是要實(shí)現(xiàn)什么目標(biāo)，帶來(lái)什么價(jià)值……

目標(biāo)模型中包括：業(yè)務(wù)目標(biāo)模型、目標(biāo)鏈、關(guān)鍵績(jī)效指標(biāo)模型、特性樹、需求映射矩陣。
目標(biāo)模型的主要思路是：
通過(guò)業(yè)務(wù)目標(biāo)模型進(jìn)行業(yè)務(wù)問(wèn)題分析，為了解決這個(gè)問(wèn)題，我們想要達(dá)成的目標(biāo)是什么。

有了目標(biāo)之后，我們通過(guò)目標(biāo)鏈模型定義衡量目標(biāo)成功的指標(biāo)有哪些，這些指標(biāo)可否量化計(jì)算，數(shù)據(jù)怎么捕獲。

為了捕獲這些數(shù)據(jù)，我們所需要建立的特性是什么。
有了高級(jí)別的特性，我們通過(guò)特性樹（其實(shí)展示出來(lái)就是魚骨圖）來(lái)進(jìn)行特性樹的分解。

特性關(guān)聯(lián)了功能、關(guān)聯(lián)了需求，從而建立需求映射矩陣。

這一整套分析下來(lái)，你會(huì)很有底氣的說(shuō)，我們?yōu)槭裁匆鲞@個(gè)需求。
在未來(lái)進(jìn)行解決方案效果評(píng)估的時(shí)候，你也有相應(yīng)的指標(biāo)以及數(shù)據(jù)支撐。
到底這個(gè)解決方案能否解決問(wèn)題，能解決多少問(wèn)題等等。

P：Person人員模型

主要用于描述干系人以及他們的業(yè)務(wù)流程和目的。
我們常見的組織結(jié)構(gòu)圖（Org Chart）就可以歸為其中的一個(gè)模型。

RML提到一個(gè)非常重要的觀點(diǎn)，就是模型的相互驗(yàn)證。
比如我通過(guò)Org Chart去識(shí)別干系人，角色。

那么在進(jìn)行處理流程模型建立時(shí)，我需要對(duì)照著Org Chart進(jìn)行檢查，有沒(méi)有角色和人員的遺漏。
在進(jìn)行用例編寫的時(shí)候，通過(guò)OrgChart和處理流程，相互檢查是否有過(guò)度的設(shè)計(jì)或者遺漏。
包括后面的角色權(quán)限矩陣都可以利用之前模型的數(shù)據(jù)進(jìn)行項(xiàng)目的校驗(yàn)。

跨模型也可以進(jìn)行需求的校驗(yàn)。
比如上面提到的目標(biāo)模型里面有個(gè)需求映射矩陣，可以關(guān)聯(lián)驗(yàn)證我們的OrgChart，用例，角色權(quán)限以及處理流程。

S：System系統(tǒng)模型

主要用于描述存在什么系統(tǒng)，用戶界面是怎樣的，如何交互，如何響應(yīng)。
這類模型在UML中有部分對(duì)應(yīng)的上下文圖、組件圖。
但是還有很多模型在UML中是沒(méi)有涉及的。

比如，決策樹和決策表，可以分別用來(lái)處理復(fù)雜的判斷和業(yè)務(wù)規(guī)則。

打個(gè)比方，我們要實(shí)現(xiàn)一個(gè)業(yè)務(wù)邏輯，里面有很多的if else。
你可以想象一下，如果你使用用例來(lái)進(jìn)行描述，分支可能會(huì)有6、7層。
寫的人暈，估計(jì)看的人更暈。
而使用決策樹就可以很好的解決這個(gè)問(wèn)題。
非常清晰的展示先校驗(yàn)什么，什么校驗(yàn)結(jié)果走哪條分支等等。

D：Data數(shù)據(jù)模型

主要用來(lái)描述從最終用戶的角度看待業(yè)務(wù)數(shù)據(jù)對(duì)象之間的關(guān)系。
注意，不是數(shù)據(jù)庫(kù)設(shè)計(jì)，而是從最終用戶，從業(yè)務(wù)的角度進(jìn)行分析。
干系人想要用數(shù)據(jù)來(lái)做什么，數(shù)據(jù)是怎么傳遞和計(jì)算的。
干系人關(guān)心的數(shù)據(jù)方面的信息，通過(guò)這個(gè)模型進(jìn)行分析、展示和說(shuō)明。

一提到數(shù)據(jù)模型，大家想到的無(wú)外乎數(shù)據(jù)流圖、數(shù)據(jù)字典、實(shí)體關(guān)系圖（E-R)。
這里我想要分享的是BDD，業(yè)務(wù)數(shù)據(jù)對(duì)象模型。
這個(gè)模型其實(shí)是E-R的簡(jiǎn)化版。
我們都知道E-R是用來(lái)進(jìn)行數(shù)據(jù)庫(kù)設(shè)計(jì)的必備工具，而UML的類圖其實(shí)也有類似的功效。
但是，對(duì)于我們BA來(lái)說(shuō)，我們的設(shè)計(jì)其實(shí)并不會(huì)涉及到數(shù)據(jù)庫(kù)表以及相應(yīng)的操作設(shè)計(jì)。
我們對(duì)這方面不專業(yè)。
數(shù)據(jù)庫(kù)設(shè)計(jì)是一門很專業(yè)的很深的學(xué)科。
不同的表設(shè)計(jì)會(huì)影響性能、可擴(kuò)展、可維護(hù)等等方面。
我們BA很難做到很專業(yè)，而且這也不是我們的強(qiáng)項(xiàng)和職責(zé)范圍。
專業(yè)的事情留給專業(yè)的人員去完成。
我們需要做的是，從業(yè)務(wù)的角度進(jìn)行對(duì)象的分析和闡述。

BDD最終看上去很像簡(jiǎn)化版的E-R，但是BDD只會(huì)作為數(shù)據(jù)庫(kù)設(shè)計(jì)的輸入，而不會(huì)作為最終數(shù)據(jù)庫(kù)設(shè)計(jì)的方案。
我們只是在描述，有哪些業(yè)務(wù)數(shù)據(jù)對(duì)象，他們的關(guān)系，他們可能出現(xiàn)在什么處理流程，什么系統(tǒng)流程，哪些界面上。
而至于具體的實(shí)現(xiàn)以及技術(shù)設(shè)計(jì)，BA不會(huì)做決策。

需求架構(gòu)

這個(gè)詞我倒是第一次看到。
在BABOK里面其實(shí)有提到過(guò)，BA需要在開展工作前進(jìn)行一些規(guī)劃，以便指導(dǎo)后續(xù)的相關(guān)工作。

需求架構(gòu)其實(shí)就是策劃需求工作如何開展的過(guò)程。
比如RML這么多模型，是否在這個(gè)產(chǎn)品，這個(gè)項(xiàng)目中全都使用？

如果要使用一部分模型，那么順序是怎樣的？輸入有哪些？

模型的相關(guān)性

在前面也有提到，RML的諸多模型是可以相互驗(yàn)證的。
這樣更有利于讓我們從整體到部分，從一個(gè)角度到另外一個(gè)角度進(jìn)行需求的透徹理解和分析。

幾乎每個(gè)模型都和其他多個(gè)模型有關(guān)聯(lián)、驗(yàn)證關(guān)系。
我覺得這正是我們作為需求分析目前很欠缺的，又十分重要的部分。
使用RML，你可以從不同的角度看待問(wèn)題，并且保證自己的整個(gè)解決方案是說(shuō)的圓的。

只是說(shuō)，建模是需要耗費(fèi)精力和時(shí)間的。
但我覺得十分值得。

寫在最后：

其實(shí)這三本書正如我開篇提到的，側(cè)重點(diǎn)是不一樣的。
用戶故事地圖我覺得比較適用于從0到1的小型項(xiàng)目。
軟件需求設(shè)計(jì)更側(cè)重于需求過(guò)渡到架構(gòu)的設(shè)計(jì)。
而軟件需求可視化模型適用于中型、大型的項(xiàng)目，經(jīng)過(guò)裁剪后也適用于一些小型的項(xiàng)目。
但是軟件需求可視化模型更加適合于目標(biāo)比較明確的項(xiàng)目，對(duì)于探索性項(xiàng)目可能不會(huì)太合適。

另外，吐槽一下《軟件需求設(shè)計(jì)可視化模型》的翻譯。
感覺前半部分和后半部分就是兩個(gè)人翻譯的。后半部分的章節(jié)層次錯(cuò)亂，并且就像是翻譯軟件翻譯出來(lái)的那樣生硬。