需求收集心智圖：分析員免費範本
需求收集心智圖範本：持份者、業務需要、用戶需要、功能同非功能需求以及限制，集中喺一個可編輯畫布。
需求收集心智圖將邊個想要乜、點解要、受咩限制放喺同一頁，令持份者之間嘅缺口同衝突喺設計開始前就浮現。
需求收集心智圖：分析員免費範本
The interactive MindMap canvas for this explanation — every lane, row and arrow above is a real QueryChart diagram you can open and edit.
點樣閱讀呢張心智圖
- 由 「持份者」 同 「業務需要」 開始，睇有邊個參與同點解。「用戶需要」 從用戶角度描述需要，「功能需求」 同 「非功能需求」 再將之轉化為系統必須做乜同做得幾好。
- 虛線箭嘴追蹤推理。例如 「優先次序」 下嘅功能由 「目標成果」 嘅成功量度支持，而 「保安同私隱」 嘅保安需要可能同 「技術限制」 嘅技術限制相撞。
持份者
「持份者」 係心智圖嘅起點，因為每項需求背後都有人。喺 「贊助人」 列出出錢嘅人，「最終用戶」 列出會用成果嘅人，「批准者同支援」 列出必須批准或支持嘅人。
要訪問 「最終用戶」 內每一個人，而唔止係佢哋嘅經理。常見錯誤係根據贊助人對佢已經唔再做嘅工作嘅描述去寫需求。
業務需要
「業務需要」 解釋項目點解存在。「要解決嘅問題」 係問題或機會，「目標成果」 係算得上成功嘅成果，「成功量度」 係證明成功嘅量度。
圖上其他位置嘅每項需求都應該追溯到呢度某樣嘢。如果追溯唔到，就問佢滿足咩需要，否則刪除。
用戶需要
「用戶需要」 記錄人們需要完成嘅事。將 「要完成嘅任務」 寫成從用戶角度出發嘅任務，並喺 「現有痛點」 記下現行做法嘅痛點。
「使用情境」 放用戶工作時嘅情境，例如用手機、喺嘈吵嘅地方，或者時間緊迫。呢啲細節往往比任務本身更影響設計。
功能需求
「功能需求」 列出系統必須做到乜。「核心功能」 係主要功能，「業務規則」 係必須套用嘅規則，「介面」 係同其他系統或團隊嘅介面。
每項都寫成可以測試嘅講法，例如：系統喺一分鐘內發出確認。以 「可測試嘅陳述」 作為點樣撰寫細節嘅範例。
非功能需求
「非功能需求」 涵蓋系統必須運作得幾好。「效能」 訂明速度同容量，「保安同私隱」 涵蓋保安同私隱，「易用性同無障礙」 涵蓋易用性同無障礙。
呢啲係人們忘記問，然後喺上線後爭論嘅需求。盡可能為每項寫一個數字或標準。
限制
「限制」 列出解決方案不能越過嘅限制。「預算同時間」 係預算同時間，「技術限制」 係技術限制，例如現有系統，「法律同政策」 係法律或政策責任。
及早用 「技術限制」 檢查每項需求。同硬性限制有衝突嘅需求，係贊助人要作出嘅決定，而唔係團隊嘅任務。
分支點樣連繫
需要由上向下流動。「業務需要」 提供理由，「用戶需要」 提供用戶觀點，「功能需求」 同 「非功能需求」 係由此衍生嘅需求。喺頭三個分支找唔到來源嘅需求，可以考慮刪除。
「限制」 向上反推。限制可能令某項需要負擔唔起，令你要返去 「業務需要」 問較小嘅成果是否可以接受，並同 「持份者」 達成共識。
心智圖到邊度為止，其他圖表由邊度開始
用心智圖收集同整理。要描述工作現時同理想嘅流程，就畫流程圖；當需求依賴團隊之間嘅交接，就用泳道圖。
組織架構圖可以記錄持份者同批准架構，而當需求變成有時間表嘅交付，就由甘特圖接手。
Key relationships and takeaways
- 每項需求都應該追溯到一項業務需要同一位持份者。
- 用戶需要寫成任務，功能需求寫成可測試嘅行為。
- 非功能需求係早期草稿最常欠缺嘅部分。
- 限制由人決定，所以亦會出現喺持份者之下。
- 冇優先次序嘅需求，會被當成同其他需求一樣緊急。
When to use this visual
- 準備持份者訪談，並將答案記錄喺共用心智圖。
- 喺簽核前檢視需求文件草稿有冇欠缺類別。
- 界定小型內部工具嘅範圍，完整規格會過於繁重。
運作方式
找出相關人士
重新命名 「項目需求」，然後喺 「持份者」 列出持份者，標示你仲未傾過嘅人。先訪談，再填其他分支。
按聽到嘅內容記錄需要
原因放喺 「業務需要」，用戶任務放喺 「用戶需要」，系統行為放喺 「功能需求」。每個節點都註明來源，方便日後核對。
檢查限制同衝突
將每項需求同 「非功能需求」 及 「限制」 比較，喺有衝突處畫上連結，並將未解決嘅衝突帶俾 「持份者」 列出嘅持份者。
常見問題
功能需求同非功能需求有咩分別？
功能需求講系統做乜，例如開發票或發出警示。非功能需求講要做得幾好：速度、保安、可用性、無障礙。兩者都需要，而非功能需求通常除非直接去問，否則好遲先發現。
點解由持份者而唔係功能開始？
因為每項需求都有負責人，可以解釋佢，需要時亦可以更改。由功能開始只會得到一份冇人能夠辯護或排優先次序嘅清單。由人開始就知道訪問邊個，以及兩項需求相撞時邊個要同意。
心智圖上嘅需求應該寫得幾詳細？
詳細到可以辨識同討論，簡短到可以掃視。用想法寫簡短陳述，用備註寫來源或測試條件。當分支變得擠迫，就搬入需求規格或用戶故事待辦清單。
持份者可以直接審閱心智圖嗎？
可以。同審閱者分享圖表，讓佢哋就特定需求留言，並用版本記錄保存每輪審閱之間嘅改動。咁樣簽核會比來回電郵文件更可靠。
由呢張需求圖開始
將範本開成你自己嘅畫布，寫上項目名稱，然後由列出你需要傾談嘅持份者開始。