如何把系統需求變成明確、可實作的規格是我們首先要處理問題，規格實例化( specification by example )和驗收測試導向開發( acceptance-test-driven development) 是兩種常見的方法，有興趣的朋友可以參考Gojko Adzic的《Specification by Example-How successful teams deliver the right software?》, Harry J.W. Percival 的《Test-Driven Development with Python》以及Jeff Patton的《User Story Mapping》。
首先透過對話建立使用者故事：需求的細節是透過開發團隊、產品負責人以及利害關係人之間的對話而建立的，而我們將各個需求寫在卡片上，成為使用者故事，卡片是一個抽象的概念，它可以是一個虛擬的線上工具或者是便利貼等等，端視你的狀況或喜好而定。
身為產品負責人，你必須讓開發團隊與利害關係人了解撰寫故事的規則與格式：
作為一個〈使用者角色〉，我想要〈目標〉，這樣我才可以〈好處〉。
按照此格式來撰寫使用者故事，同時遵循以下原則：
- 避免在開發前期鉅細靡遺的撰寫需求，Scrum不要求嚴謹的需求，而是保留彈性與空間
- 文件容易被誤解，頻繁且持續的溝通是必須的，以確保需求被每個人正確解讀
需求確認初期，我會使用Trello來建立使用者故事，如下圖所示：
此時產品負責人負責邀請開發團隊與利害關係人，一同撰寫這個故事看板，看板會將故事簡單的分成三個區塊：
- 必須有(must-have)的項目：客戶與開發團隊溝通後覺得相當重要的需求項目。
- 可有可無(nice-to-have)的項目：客戶與開發團隊溝通後覺得有待商榷或沒那麼重要的項目。
- 不會有(won’t have)的項目：客戶與開發團隊溝通後確定不使用的項目。
利用這三個分類，我們可以很容易地瞭解客戶的需求，以及排定優先順序，以便決定要先針對哪個故事做精練，以得到更詳細的需求定義。
有些使用者故事可能與其他故事相關，這時有必要寫下相關聯的故事是什麼，方便往後檢索：
由於這個階段的需求是透過對話建立的，因此溝通、提問、協調都是確保初期需求正確性很重要的因素，所謂的正確性是指在合理的成本下將資源花費在有價值的項目上，開發團隊應該給予技術面的諮詢並提供專案經驗，幫助客戶釐清需求、排除盲點與誤解。
這個階段，我們也可以撰寫一些操作介面草圖、筆記紀錄等補充資料，根據我實際的經驗，由於溝通有時得花不少時間討論，其中涉及各種需求與文件，所以最好立刻把會影響到需求的對話記錄下來，否則很容易因為忘記修改了什麼，又或者過程中討論了多種版本，時間久了，客戶自己也忘了最終定稿的版本是什麼，資訊不對稱導致開發上的浪費與損失是相當惱人的。
產品負責人需常常瀏覽相關需求，確保需求與資訊保持一致：
善用Activity，可以幫助我們檢視近期的修改紀錄，加了哪些需求，做了什麼修改與補充
Trello這套工具相當簡單直覺，可以很容易的與客戶進行溝通（遠端或面談都很方便），初期需求不確定時，我們不需要太多細節的描述(規格、功能、時間成本評估等等），這也是我在做初步需求開發時會使用它的原因，他幫助客戶與產品負責人回憶起需求的細節，容易將對話形式的需求及修改記錄下來，且跨平台，可隨時隨地進行溝通。
有關使用者故事的確認與滿足條件，將留到下一篇做介紹，我們會使用JIRA這套工具來完成產品代辦事項清單、精煉使用者故事以及撰寫滿足條件，其中會使用到故事地圖(user mapping)，使用者故事對照(user story mapping)、規格實例化(specification by example)、測試驅動開發(test-driven development)等概念。
JIRA這套工具提供了驗收確認、到期日、使用者故事類型分類等各種設定，相當適合用於管理產品代辦事項清單。也因此JIRA比Trello複雜許多，這也是我為什麼我要使用Trello做初步分析的關係，客戶比較容易理解Trello，且初期的使用者故事清單都有很大的修改空間，往往經過討論後，發生重大的改變，如果一開始就使用Trello，會浪費很多時間在設定到期日、故事類型等各種屬性。
補充：
有時客戶並不知道使用者想要什麼，這時我們必須使用一些搜集故事以及探索故事的技巧，藉以得到正確的需求，這樣的問題時常發生在新創企業中。Osterwalder, Alexander/ Pigneur, Yves/ Smith, Alan (ILT)/ Clark, Tim (EDT)等人合著的《Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers》一書提供了多種方法去處理這樣的問題，本文聚焦在系統開發的部分，僅透過人物誌和同理心地圖這兩個工具，讓團隊成員能對使用者有個概括性的認識，這有助於介面設計、內容設計、功能設計。
工具一：人物誌(personas)
藉由描述使用者的基本屬性，使大家對使用者有更具體的認知。
工具二：同理心地圖(Empathy Map)
粗略的描述你的目標客層：
See? 描述顧客在他的環境中所看到的
- 整個環境看起來如何？
- 他周圍有些什麼？
- 他的朋友有誰？
- 他每天接觸到的是哪些產品或服務？（不是整個市場所提供的全部產品或服務）？
- 他遭遇到什麼難題？
Hear?描述環境如何影響顧客
- 他的朋友說些什麼？
- 他的配偶說些什麼？
- 真正影響他的是誰？
- 如何影響？
- 哪些媒體管道對他有影響力
Think & Fell? 試著勾勒出這個顧客心裡的想法
- 對他來說，真正重要的(但他可能不會公然說出來）是什麼？
- 想像她的情緒，什麼會令他感動？
- 他可能會為了什麼通宵熬夜？
- 試著描述一下他的夢想與渴望。
Pain ：顧客的痛苦是什麼？
- 他最大的挫折是什麼？
- 什麼障礙讓他無法得到自己想要或需求的？
- 他害怕冒什麼風險？
Gain：顧客得到什麼？
- 他真正想要或需要達到的是什麼？
- 他衡量成功的指標是什麼？
- 想出一些他可能用來達成目標的策略
