需求分析的一個不錯的FANCY方法

前ThoughtWorks進階業務分析師李默提出的FANCY方法，為創新性的業務分析指明了一個更為清晰的路徑：

功能性需求（functional requirement）；

假設（assumption）；

非功能性需求（non-functional requirement）；

限制（constraint）；

線框圖（y-wireframe）。

（1）功能性需求

整個需求分析中，首當其沖和最基本的方面就是功能的部分。功能性指的是業務邏輯和流程。需求分析師必須把使用者故事拆分成更小顆粒度的包含細節的驗收條件，抑或更小的故事卡。為了得到綜合和透徹的細節，我們需要遵循5W1H進行故事卡的細化。

在這個階段，需求分析師應該已經知道了這個使用者故事的目标使用者以及為什麼需要這個故事：

誰（who，目标使用者）——使用者角色或使用者畫像；

為什麼（why）——業務價值和使用者的目标。

我們還應該考慮下面這些方面：

什麼時候（when）——前提條件或先決條件；

位置（where）——界面的入口；

什麼東西（what）——輸入的資料；

什麼東西（what）——功能中的業務規則和邏輯；

什麼東西（what）——輸出物；

如何做（how）——正常路徑；

如何做（how）——異常路徑和邊界情況；

如何做（how）——對其他功能的影響。

（2）假設

掌握使用者故事基于的開發的基本假設是很重要的。這些假設通常産生于産品概念試驗的開始階段和需求分析的前期。一些技術的和架構的假設會在團隊估算故事卡的時候提出來。當我們團隊對于一個問題不能馬上得到一個回答時，我們會提出一個假設，然後團隊會繼續前進。

比如，一個故事卡可以有這樣的假設：資料庫表已經建好，或者開發之前接口API已經完成或者定義好。注意，一旦一個假設成立，這個假設需要持續地監控和驗證。例如，我們可以安排一個調研任務去驗證假設，如果假設不成立，這個故事卡需要重新估算，疊代計劃也需要進行相應的調整。

一些常見的需要假設的地方是：

基礎的技術架構或架構；

第三方API或者應用是否可用；

一些不确定的輸入或輸出。

（3）非功能性需求

每個項目都應該有一個非功能性需求的檢查清單，非功能性需求通常是一些建立在使用者故事更高一層的跨功能子產品的場景。每個公司内部都應該有一個推薦的非功能性需求檢查對照表，如果沒有，我建議盡快出一個标準的針對異常處理的規範。

這裡還需要強調的是，一些非功能性需求也可以拆分成獨立的使用者故事卡，安排在後期的某個疊代中。但是，我們在動筆寫一個使用者故事的時候就應該考慮到相關的非功能性需求，而不是在後來的疊代中才考慮，考慮不及時可能會造成返工的後果。

（4）限制

限制指的是一個使用者故事的限制條件和邊界，它突出的是這個使用者故事不會做的和不能做的功能。例如，我們在這個使用者故事中不會做一些關聯的功能，這些相關的功能在另外一個使用者故事卡中，或者我們在這個使用者故事中不會解決某個相關的生産環境的缺陷。這給團隊其他人員，比如測試人員，一個清楚的範圍次元的指導。

一些典型的限制需要包含以下兩個方面。

内部限制——一個使用者故事卡應該包含的功能，但是由于一些其他原因，這些功能暫時不會被實作。比如，技術選型的時候出現失誤、技術架構不支援等。使用者需要使用這個帶着局限性的功能，直到利用某一次大型重構的機會，通過改變技術架構解決這個問題。

外部限制——一個使用者故事卡應該包含的功能，但是被拆分到另外一個使用者故事卡中。使用者需要有一個臨時的替代方案，或者是體驗稍差的方案，直到那個另外的使用者故事完成。

（5）線框圖

雖然名字是線框圖，但是這裡我用來表示一個使用者故事

中包含的所有與前端或者使用者體驗相關的内容。

從廣義上講，這部分需要包含以下内容。

使用者互動的流程：使用者怎樣與系統互動。

使用者體驗設計：確定頁面的樣式、業務流程、資訊架構，還有導航設計合乎規範和邏輯。

裝置相容性：是否有使用者會在移動裝置中使用。

浏覽器的相容性：還需要支援IE8？為什麼？

輔助性：在易用性上考慮多少設計。