引言
之前在看一些需求建模的文章或者書籍時，常常看到用例分析法，根據用例裏的主謂賓來構建模型、模型的方法以及模型之間的關係等。但是在工作中遇到的一個問題是拿到的需求往往只有一份PRD，只是對於需求的功能進行了簡單的描敘，那如何才能對PRD或者需求進行分解，得到用例或者模型與業務規則呢？之前參加一個培訓裏，談到了一些需求分析的常用方法，例如事件風暴、實例化需求、用例分析、用戶故事地圖、影響地圖、用戶旅程地圖。在網上簡單瞭解了一下幾個方法，發現實例化需求的可實踐價值挺高的，於是對實例化需求做個簡單梳理。
實例化需求簡介
顧名思義，實例化需求就是通過一個個業務的實例case來對需求進行澄清與說明，這些業務實例case也就是業務的規則，可以被用來作爲自動化測試的用例，對系統進行自動化的驗證以及活文檔進行使用。
之所以認爲實例化需求可實踐價值高主要基於以下兩點：
1. 事件風暴、用戶故事地圖等方法更加適合團隊協作來對需求進行分析與拆解，實例化需求當然也是團隊分析方法，但是也可以用來個人對於需求進行分析，並且日常會議（例如電話會議）來使用也比較方便。
2. 實例化需求可以作爲活文檔來使用，系統功能的顯示化對於系統的維護與交接非常重要，而在團隊中又很難實現。
實例化需求步驟
實例化需求的步驟重要分爲目標、流程、規則三步。
目標：目標是對於業務目標達成一致，可以通過質疑目標的價值（不做會怎樣）與可替代方法來進行。
操作流程：最關鍵的操作流程，MECE中最難的是如何做到不遺漏，個人認爲這需要一些經驗的積累，例如之前在工作中會把支付相關的業務流程與特殊點都整理成xmind，當有新需求來時會去對照之前的xmind去看看有沒有一些場景遺漏的。不過對於沒有積累過的場景可以通過PRD描述出發，通過梳理流程圖來思考與完善，以及與業務方進行討論，來逐步完善操作流程。通過流程就可以大致得到系統的用例（可以通過UML用例圖或者xmind來標識），以及通過時序圖或者流程圖來描述業務流程。
業務規則：業務規則是對於操作流程中的節點進行業務規則的描述，最終形成的一條條描述準確的，無歧義的業務case。
在實施過程中流程基本爲：瞭解/介紹背景 => 理清目標 => 列用戶操作 => 畫流程圖 => 列業務規則
對於個人使用來說，經過了這些步驟後，基本就可以理清一個需求中的用例，至少有了可以進行需求建模的原材料，可以幫助梳理領域模型。
其他
實例化需求方法涉及的概念與步驟都不多，簡單易學，對於個人平時拆解分析PRD也很有幫助。經過實例化需求幾步之後就需要用到用例分析法（需求建模）了，而且實例化的業務case也可以用來進行自動化測試（活文檔），這兩部分在後面文章進行總結。