快到年末，又是案量的高峰期，這一週不約而同遇到三位來信的陌生客戶，都很困擾不知道該如何整理需求讓我理解，而我的回覆都是只要用你們自己方便的方式即可，不管是文字描述、截圖說明，甚至是錄製影片都可以，但後來想想這樣的解釋似乎太籠統了，於是順手紀錄一下如何表達案件需求讓執行者可以快速理解，進而減少 Email 的往返時間。
事實上關於需求規格書我之前有寫過「企劃人員如何撰寫有效的軟體需求規格文件」這一篇文章，內容比較偏向企劃或是專案經理該如何與團隊中各種不同角色溝通，如果你的案件規模比較大、參與的角色很多，並且是從無到有全新專案，我建議參考這篇文章會比較完整。本篇偏向初步的需求訪談，主要目的是了解客戶在既有網站下需要進行的修改以及新功能的加入，我透過以下五個步驟進行說明：
需求名稱？
一句話描述需求，盡可能具體並簡要的說明該需求的意圖，可以從希望改善的頁面或是增加想功能來描述，像是「修改結帳流程」、「增加商品的顯示欄位」，也可以從另一個角度來形容，像是「簡化結帳步驟」、「提升商品資訊呈現完整度」，關鍵是讓我們能夠初步理解該需求是跟哪方面的系統相關，範例如下：
- 最佳化網站購買流程，以增進訂單轉換率
使用者是誰？
加入使用者描述是必要的資訊，因為可能同個頁面、同個功能，換了使用者之後就會有完全不同的結果，像是有些網站會區分已登入、未登入會員，或是依照不同消費等級區分 VIP、VVIP 以及一般顧客，如果是後台的需求也會因為不同的角色而有不同的顯示畫面，像是編輯者跟商店經理能夠操作的功能就不一樣，因此這個需求是要做給誰的、有哪些使用者角色可以使用、或只是限定單一類型的使用者，範例如下：
- 未登入顧客、已登入會員
需求相關頁面？
該需求會呈現在哪些頁面上是客戶常常會遺漏的資訊，有些功能可能會橫跨多個頁面或是同時牽涉到前後台的操作，因此得知該資訊對於評估整個需求是很關鍵的部分，但有時候客戶會不清楚原來這個需求會關係到其他頁面，而這就需要我們再協助客戶進行釐清。
所在頁面的資訊可提供網址、頁面名稱，如果有截圖並附上圖示再好也不過，更清楚的方式可以使用 Markup.io 這種視覺化工具來標記現行網站的修改需求，範例如下：
- 商品銷售頁、購物車頁、結帳頁
目前網站行為
描述目前在現行網站與需求相關的部分是如何運作的，具體說明操作的步驟與流程，可以讓我們知道該需求會牽涉到哪些環節，並且提前預知可能會產生哪些問題或是衍生新需求的地方，範例如下：
- 潛在顧客透過網路廣告進到商品銷售頁，點擊畫面中央的加入購物車按鈕後，需要再點選前往購物車頁面，註冊或登入會員後再進入結帳頁，輸入完付款資訊後進行結帳。
- 已登入會員透過網路廣告進到商品銷售頁，點擊畫面中央的加入購物車按鈕後，需要再點選前往購物車頁面與前往結帳頁，輸入完付款資訊後進行結帳。
預期網站行為
描述目前的網站行為發生了什麼問題以及希望可以改進的方式，這部分主要讓我們知道客戶在意的點以及他們想要達成的目標，至於要採用哪種解決方式就是後續跟客戶一起討論，我們不一定要採取客戶提供的方法，畢竟要爬到山頂有很多條不同的路可以走，範例如下：
- 希望潛在顧客在購買的過程中，可以省去登入會員、進入購物車頁，直接點擊加入加入購物車後就能跳轉到結帳頁，進而增加訂單的轉換率。
透過以上五個問題我們可以初步得知客戶想要開發的功能，但這只能算是需求的草稿，我們還需要進行二次確認與彙整才能提供一個估價範圍，在這階段重點放在大方向就好，千萬不要開始著眼於開發細節，像是資料庫欄位要開哪些、介面的互動操作效果等等，這些都是等到案件確認執行後再利用使用者故事來跟客戶逐一確認。
此外，我們要跟客戶理解到這樣的估價範圍並非最終的規格與價格，在確認開發細節以及實際執行時都可能會有許多當初沒有預期到的狀況會出現，這種合作過程就像我們跟客戶一起爬山一樣，隨時查看天氣與路況來調整行進路線，而非我們爬我們的而客戶坐直升機到山頂等，常遇到很多客戶會覺得外包就是可以省下時間與金錢來解決問題，而忽略了傳達需求的過程，因此務必要讓客戶理解「溝通」是外包的最大成本。
