用戶故事地圖我覺得比較適用于從0到1的小型項(xiàng)目；軟件需求設(shè)計(jì)更側(cè)重于需求過渡到架構(gòu)的設(shè)計(jì)；而軟件需求可視化模型適用于中型、大型的項(xiàng)目，經(jīng)過裁剪后也適用于一些小型的項(xiàng)目。

終于寫到這個系列的最后一篇了……

讓我算算，第一篇是上個月發(fā)的還是上上個月發(fā)的？因?yàn)闀r間太長，所以我們先來回顧一下為什么要寫這個系列。

我認(rèn)識的很多團(tuán)隊(duì)都是在敏捷的方法，近些年來，這類快速迭代的開發(fā)流程在整個圈子里面迅速的流行起來。

不管是出于為了快速交付、快速驗(yàn)證、還是不寫文檔等諸多原因。

不知道大家在執(zhí)行敏捷過程中，特別是作為BA或者產(chǎn)品經(jīng)理，發(fā)現(xiàn)有個問題。

這么多用戶故事，這么多高內(nèi)聚低耦合的用戶故事，你有辦法組織在一起嗎？

其實(shí)我一直在考慮一個問題，就是敏捷執(zhí)行一段時間后，如何能保證不偏離當(dāng)初設(shè)定好的目標(biāo)。

有人說，我們就沒目標(biāo)。

是，可能剛開始做產(chǎn)品并沒有一個非常清晰的目標(biāo)，比如我要做個共享單車，比如我要做個共享女友。

但是總會有個愿景或者是想要解決的問題。

我想要解決從家到地鐵的500米距離的問題，我想要結(jié)束單身狗的命運(yùn)……

而且在評估一個需求或者用戶故事是否重要的時候，也很糾結(jié)。

因?yàn)槟繕?biāo)和問題不明確，所以也不知道到底重不重要。

于是最后很可能演變成功能的堆砌。

連產(chǎn)品經(jīng)理或者需求負(fù)責(zé)人都有這種感受的話，就更別說其他干系人了。

這種只見樹木，不見森林的方法，想想可能引發(fā)的后果，就有點(diǎn)“不寒而栗”。

我不是來抨擊敏捷的，因?yàn)槲野l(fā)現(xiàn)即便你用瀑布，可能也會有同樣的問題。

你同樣會進(jìn)行需求的拆分，類似拆故事一樣。

形成需求矩陣或者需求樹進(jìn)行管理。

但是頂層需求之間有什么樣的關(guān)系，和你的整體目標(biāo)以及要解決的問題有什么樣的關(guān)系，這個估計(jì)也會有欠缺考慮的時候。

最近很巧的，看了三本書，介紹了三種方法，從三個不同的角度，都是為了解決同樣的這個問題：“只見樹木，不見森林”。

• 第一本：用戶故事地圖
• 第二本：軟件需求設(shè)計(jì)
• 第三本：軟件需求可視化模型

軟件需求可視化模型概述

一提到模型，大家可能會想到UML。

但是正如《軟件需求可視化模型》提到的，UML還是會有點(diǎn)偏向技術(shù)的視角來進(jìn)行建模。

• 優(yōu)點(diǎn)是面向?qū)ο螅O(shè)計(jì)的考慮比較全面和清晰。
• 缺點(diǎn)就是，很容易在業(yè)務(wù)還沒有弄清楚的情況下，陷入技術(shù)細(xì)節(jié)，并且缺乏應(yīng)對業(yè)務(wù)價值等方面的建模。

在系統(tǒng)工程領(lǐng)域，模型分為：概念模型、邏輯模型、物理模型。

我的理解，UML更加偏向于邏輯模型。

而從UML衍生出來的SYSML，也更加偏向于邏輯模型。

需求可視化模型使用RML（需求建模語言），主要是針對軟件需求分析使用的，而且便于業(yè)務(wù)干系人理解，便于快速轉(zhuǎn)化為UML等開發(fā)設(shè)計(jì)人員可以理解的模型。

而RML的模型覆蓋比較廣，使用的面向?qū)ο蠛兔嫦蜻^程兩種分析方法的融合。

模型分類

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

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

主要用于描述系統(tǒng)的業(yè)務(wù)價值，并且根據(jù)系統(tǒng)的價值設(shè)置功能和需求的優(yōu)先級。

它比較特別的地方在于將功能與業(yè)務(wù)目標(biāo)聯(lián)系起來。

通過建模，理清WHY，為什么要做這個功能，是要實(shí)現(xiàn)什么目標(biāo)，帶來什么價值……

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

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

為了捕獲這些數(shù)據(jù)，我們所需要建立的特性是什么。

有了高級別的特性，我們通過特性樹（其實(shí)展示出來就是魚骨圖）來進(jìn)行特性樹的分解。

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

這一整套分析下來，你會很有底氣的說，我們?yōu)槭裁匆鲞@個需求。

在未來進(jìn)行解決方案效果評估的時候，你也有相應(yīng)的指標(biāo)以及數(shù)據(jù)支撐。

到底這個解決方案能否解決問題，能解決多少問題等等。

P：Person人員模型

主要用于描述干系人以及他們的業(yè)務(wù)流程和目的。

我們常見的組織結(jié)構(gòu)圖（Org Chart）就可以歸為其中的一個模型。

RML提到一個非常重要的觀點(diǎn)，就是模型的相互驗(yàn)證。

比如我通過Org Chart去識別干系人，角色。

那么在進(jìn)行處理流程模型建立時，我需要對照著Org Chart進(jìn)行檢查，有沒有角色和人員的遺漏。

在進(jìn)行用例編寫的時候，通過OrgChart和處理流程，相互檢查是否有過度的設(shè)計(jì)或者遺漏。

包括后面的角色權(quán)限矩陣都可以利用之前模型的數(shù)據(jù)進(jìn)行項(xiàng)目的校驗(yàn)。

跨模型也可以進(jìn)行需求的校驗(yàn)。

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

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

主要用于描述存在什么系統(tǒng)，用戶界面是怎樣的，如何交互，如何響應(yīng)。

這類模型在UML中有部分對應(yīng)的上下文圖、組件圖。

但是還有很多模型在UML中是沒有涉及的。

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

打個比方，我們要實(shí)現(xiàn)一個業(yè)務(wù)邏輯，里面有很多的if else。

你可以想象一下，如果你使用用例來進(jìn)行描述，分支可能會有6、7層。

寫的人暈，估計(jì)看的人更暈。

而使用決策樹就可以很好的解決這個問題。

非常清晰的展示先校驗(yàn)什么，什么校驗(yàn)結(jié)果走哪條分支等等。

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

主要用來描述從最終用戶的角度看待業(yè)務(wù)數(shù)據(jù)對象之間的關(guān)系。

注意，不是數(shù)據(jù)庫設(shè)計(jì)，而是從最終用戶，從業(yè)務(wù)的角度進(jìn)行分析。

干系人想要用數(shù)據(jù)來做什么，數(shù)據(jù)是怎么傳遞和計(jì)算的。

干系人關(guān)心的數(shù)據(jù)方面的信息，通過這個模型進(jìn)行分析、展示和說明。

一提到數(shù)據(jù)模型，大家想到的無外乎數(shù)據(jù)流圖、數(shù)據(jù)字典、實(shí)體關(guān)系圖（E-R)。

這里我想要分享的是BDD，業(yè)務(wù)數(shù)據(jù)對象模型。

這個模型其實(shí)是E-R的簡化版。

我們都知道E-R是用來進(jìn)行數(shù)據(jù)庫設(shè)計(jì)的必備工具，而UML的類圖其實(shí)也有類似的功效。

但是，對于我們BA來說，我們的設(shè)計(jì)其實(shí)并不會涉及到數(shù)據(jù)庫表以及相應(yīng)的操作設(shè)計(jì)。

我們對這方面不專業(yè)。

數(shù)據(jù)庫設(shè)計(jì)是一門很專業(yè)的很深的學(xué)科。

不同的表設(shè)計(jì)會影響性能、可擴(kuò)展、可維護(hù)等等方面。

我們BA很難做到很專業(yè)，而且這也不是我們的強(qiáng)項(xiàng)和職責(zé)范圍。

專業(yè)的事情留給專業(yè)的人員去完成。

我們需要做的是，從業(yè)務(wù)的角度進(jìn)行對象的分析和闡述。

BDD最終看上去很像簡化版的E-R，但是BDD只會作為數(shù)據(jù)庫設(shè)計(jì)的輸入，而不會作為最終數(shù)據(jù)庫設(shè)計(jì)的方案。

我們只是在描述，有哪些業(yè)務(wù)數(shù)據(jù)對象，他們的關(guān)系，他們可能出現(xiàn)在什么處理流程，什么系統(tǒng)流程，哪些界面上。

而至于具體的實(shí)現(xiàn)以及技術(shù)設(shè)計(jì)，BA不會做決策。

需求架構(gòu)

這個詞我倒是第一次看到。

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

需求架構(gòu)其實(shí)就是策劃需求工作如何開展的過程。

比如RML這么多模型，是否在這個產(chǎn)品，這個項(xiàng)目中全都使用？

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

模型的相關(guān)性

在前面也有提到，RML的諸多模型是可以相互驗(yàn)證的。

這樣更有利于讓我們從整體到部分，從一個角度到另外一個角度進(jìn)行需求的透徹理解和分析。

幾乎每個模型都和其他多個模型有關(guān)聯(lián)、驗(yàn)證關(guān)系。

我覺得這正是我們作為需求分析目前很欠缺的，又十分重要的部分。

使用RML，你可以從不同的角度看待問題，并且保證自己的整個解決方案是說的圓的。

只是說，建模是需要耗費(fèi)精力和時間的。

但我覺得十分值得。

寫在最后

其實(shí)這三本書正如我開篇提到的，側(cè)重點(diǎn)是不一樣的。

用戶故事地圖我覺得比較適用于從0到1的小型項(xiàng)目；軟件需求設(shè)計(jì)更側(cè)重于需求過渡到架構(gòu)的設(shè)計(jì)；而軟件需求可視化模型適用于中型、大型的項(xiàng)目，經(jīng)過裁剪后也適用于一些小型的項(xiàng)目。

但是軟件需求可視化模型更加適合于目標(biāo)比較明確的項(xiàng)目，對于探索性項(xiàng)目可能不會太合適。

小婧是一名行走在實(shí)踐路上的資深業(yè)務(wù)分析師（BA），如果想與我同行，就請關(guān)注我唄！

相關(guān)閱讀

又見樹木，又見森林（1）：用戶故事地圖

又見樹木，又見森林（2）：需求設(shè)計(jì)

作者：小婧，個人公眾號：與小婧同行

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

題圖由作者提供