二、Needs、Requirements、Wishes 的差別？
我們指的「需求」，英文是 Needs 而非 Requirements；Requirements 的正確說法是「要求」，但兩者非常容易混淆！在 Jeff Nielsen 的 “Requirements” vs. Needs 一文裡解釋的 Needs 非常適切：
Let’s talk all we want about “ideas for what to build” or “deciding what to build”.
另外，他也詮釋了 Requirements 的定義：
We usually think of as “requirements” are ideas for how to meet the user’s needs.
而 Wishes 呢？它更泛指希望與慾望（Want），但想要不一定需要，舉例來說，喝水對人類來說是一種基本需求，相對來說，喝星巴克則是一種慾望；水與星巴克，若對應 馬斯洛的需求層次理論 的金字塔而論，一如溫飽 vs. 安全、安全 vs. 愛與歸屬感。
三、什麼是需求訪談？
需求訪談並非專案經理的專屬職責，而是泛指從事規劃設計、系統分析、商業開發等工作者，都會接觸到的一項重要功課。
需求訪談的精隨是「理解、發現以及釐清真正的業務問題」，並且能為客戶提出一個適時、適地以及適性的解決方案，同時體現超越成本的利益價值，這些就是需求訪談的核心所在。
需求訪談的過程中，不僅僅是紀錄客戶的所言所述，而是時而說服、時而創新、時而從客戶傳達部分事實的情況下去推敲其內心真實的需求，所以像是一場你來我往的刺探恰恰。
需求的分類：
1) 功能型
2) 非功能型
3) 限制條件
功能型需求通常都會用「動詞」來定義，例如搜尋、計算、發佈等等。非功能型需求乃指使用者的感受性、易用性以及安全感等。限制條件往往扮演影響整體的因素，例如時程、預算以及指定載具等。
需求訪談的框架如下：
1) 需求的目的、動機、利益？
2) 現有的資源是什麼？
3) 目標用戶是誰？
4) 利益相關人有哪些？
5) 工作範圍是什麼？
6) 產品或服務的範疇到哪？（功能需求、使用環境、數據採集）
7) 產品或服務帶來的感受是什麼？（非功能性需求）
8) 可擴充性、可維護性、安全性。
9) 限制條件（時程、預算、政策與法規因素等）
10) 備案與風險控管
四、利益關係人與啟動會議
在需求訪談後，我們會招集專案裡所涉及的利益相關人。利益相關人泛指在「專案裡具有利益關係的人，或擁有該領域相關知識的人，或對該產品或服務有所求的人。」
因此，可能是客戶、老闆、業務、開發團隊、顧問、專家以及關鍵用戶等，都有可能列入利益相關人的範疇。
將利益相關人聚集在一起後，接著進行啟動會議（Blastoff Meeting），如同一個專案的開案儀式。
在會議裡，我們必須要確認以下重點：
1) 業務需求的範圍（做什麼？不做什麼？）
2) 利益相關人的共識達成（達成一致的意見）
3) 成本初估
4) 風險評估
經歷了啟動會議之後，不但所有利益相關人都清楚整個專案的內容與方向，同時，亦可評估是否具有獲利的可能性與進行下一步的決策方案哦！
最後，歡迎大家上我的「UX UX 雞蛋糕」臉書粉絲團按讚、分享啦 :)
延伸閱讀：
如何撰寫產品需求文件1：發展藍圖
{ UX 雞蛋糕 } 問卷調查法 Questionnaire Survey
{ UX 雞蛋糕 } 人物誌 Persona
{ UX 雞蛋糕 } 焦點團體研究法（理論篇）
