又見樹木，又見森林——軟體需求可視化模型

寫在前面

終於寫到這個系列的最後一篇了……

我們先來回顧一下為什麼要寫這個系列。

我認識的很多團隊都是在敏捷的方法，近些年來，這類快速迭代的開發流程在整個圈子裡面迅速的流行起來。

不管是出於為了快速交付、快速驗證、還是不寫文檔等諸多原因。不知道大家在執行敏捷過程中，特別是作為BA或者產品經理，發現有個問題。

這麼多用戶故事，這麼多高內聚低耦合的用戶故事，你有辦法組織在一起嗎？

其實我一直在考慮一個問題，就是敏捷執行一段時間後，如何能保證不偏離當初設定好的目標。

有人說，我們就沒目標。是，可能剛開始做產品並沒有一個非常清晰的目標，比如我要做個共享單車，比如我要做個共享女友。但是總會有個願景或者是想要解決的問題。我想要解決從家到地鐵的500米距離的問題，我想要結束單身狗的命運……

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

因為目標和問題不明確，所以也不知道到底重不重要。於是最後很可能演變成功能的堆砌。

連產品經理或者需求負責人都有這種感受的話，就更別說其他幹係人了。

這種只見樹木，不見森林的方法，想想可能引發的後果，就有點「不寒而慄」。

我不是來抨擊敏捷的，因為我發現即便你用瀑布，可能也會有同樣的問題。

你同樣會進行需求的拆分，類似拆故事一樣。形成需求矩陣或者需求樹進行管理。但是頂層需求之間有什麼樣的關係，和你的整體目標以及要解決的問題有什麼樣的關係，這個估計也會有欠缺考慮的時候。

最近很巧的，看了三本書，介紹了三種方法，從三個不同的角度，都是為瞭解決同樣的這個問題：

「只見樹木，不見森林」。第一本：用戶故事地圖第二本：軟體需求設計第三本：軟體需求可視化模型

軟體需求可視化模型概述

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

但是正如《軟體需求可視化模型》提到的，UML還是會有點偏向技術的視角來進行建模。優點是面向對象，設計的考慮比較全面和清晰。缺點就是，很容易在業務還沒有弄清楚的情況下，陷入技術細節，並且缺乏應對業務價值等方面的建模。

在系統工程領域，模型分為：概念模型、邏輯模型、物理模型。

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

需求可視化模型使用RML（需求建模語言），主要是針對軟體需求分析使用的，而且便於業務幹係人理解，便於快速轉化為UML等開發設計人員可以理解的模型。

而RML的模型覆蓋比較廣，使用的面向對象和麪向過程兩種分析方法的融合。

模型分類

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

O： Object 目標模型

主要用於描述系統的業務價值，並且根據系統的價值設置功能和需求的優先順序。

它比較特別的地方在於將功能與業務目標聯繫起來。通過建模，理清WHY，為什麼要做這個功能，是要實現什麼目標，帶來什麼價值……

目標模型中包括：業務目標模型、目標鏈、關鍵績效指標模型、特性樹、需求映射矩陣。

目標模型的主要思路是：通過業務目標模型進行業務問題分析，為瞭解決這個問題，我們想要達成的目標是什麼。

有了目標之後，我們通過目標鏈模型定義衡量目標成功的指標有哪些，這些指標可否量化計算，數據怎麼捕獲。

為了捕獲這些數據，我們所需要建立的特性是什麼。

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

特性關聯了功能、關聯了需求，從而建立需求映射矩陣。

這一整套分析下來，你會很有底氣的說，我們為什麼要做這個需求。

在未來進行解決方案效果評估的時候，你也有相應的指標以及數據支撐。到底這個解決方案能否解決問題，能解決多少問題等等。

P：Person人員模型

主要用於描述幹係人以及他們的業務流程和目的。

我們常見的組織結構圖（Org Chart）就可以歸為其中的一個模型。

RML提到一個非常重要的觀點，就是模型的相互驗證。

比如我通過Org Chart去識別幹係人，角色。

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

在進行用例編寫的時候，通過OrgChart和處理流程，相互檢查是否有過度的設計或者遺漏。包括後面的角色許可權矩陣都可以利用之前模型的數據進行項目的校驗。

跨模型也可以進行需求的校驗。

比如上面提到的目標模型裡面有個需求映射矩陣，可以關聯驗證我們的OrgChart，用例，角色許可權以及處理流程。

S：System系統模型

主要用於描述存在什麼系統，用戶界面是怎樣的，如何交互，如何響應。

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

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

比如，決策樹和決策表，可以分別用來處理複雜的判斷和業務規則。

打個比方，我們要實現一個業務邏輯，裡面有很多的if else。

你可以想像一下，如果你使用用例來進行描述，分支可能會有6、7層。寫的人暈，估計看的人更暈。而使用決策樹就可以很好的解決這個問題。非常清晰的展示先校驗什麼，什麼校驗結果走哪條分支等等。

D：Data數據模型

主要用來描述從最終用戶的角度看待業務數據對象之間的關係。

注意，不是資料庫設計，而是從最終用戶，從業務的角度進行分析。

幹係人想要用數據來做什麼，數據是怎麼傳遞和計算的。

幹係人關心的數據方面的信息，通過這個模型進行分析、展示和說明。

一提到數據模型，大家想到的無外乎數據流圖、數據字典、實體關係圖（E-R)。

這裡我想要分享的是BDD，業務數據對象模型。這個模型其實是E-R的簡化版。我們都知道E-R是用來進行資料庫設計的必備工具，而UML的類圖其實也有類似的功效。但是，對於我們BA來說，我們的設計其實並不會涉及到資料庫表以及相應的操作設計。我們對這方面不專業。資料庫設計是一門很專業的很深的學科。不同的表設計會影響性能、可擴展、可維護等等方面。

我們BA很難做到很專業，而且這也不是我們的強項和職責範圍。

專業的事情留給專業的人員去完成。我們需要做的是，從業務的角度進行對象的分析和闡述。