在軟體開發中，最困擾的通常就是開發出來的成果與需求方想要的不一樣。在昨天有提到我們應該盡量透過暸解目的去實作，而不是單純暸解要去實作什麼。在講述〈MVP 與 Product〉的時候，也有提到雙方要對目前開發的軟體是處於哪一種有共同認知，畢竟兩者在功能性與非功能性的規格差異都很大。但是到目前為止，離解決這個問題似乎還差了點什麼，我想就是我們必須在開發前確認好要驗收的項目與規格的滿足條件。

所謂的滿足條件，可以將其視為驗收方式，也就是要怎麼進行驗收（How to test?）。透過釐清滿足條件的時候，也會強迫我們在針對需求去進一步思考，因為當需求沒有被釐清完全時，是寫不出可以被視為驗收方式的滿足條件的。我們必須針對每個需求項目去訂定一到數個滿足條件，當確認滿足這些條件時，這個項目才算完成，作為雙方對「完成」認知的共識。

然而，這部份對於多數的需求方是既沒有經驗，也沒有足夠的領域知識知道怎麼去提出。所以我們就要透過昨天提到的先去暸解他的目的，在釐清需求後，協助需求方去訂定一個個滿足條件。在討論時，也可以嘗試透過這部分的過程，讓需求方好好審視他是不是已經暸解自己要的是什麼，避免其提出過多到最後既不知道要幹嘛、也不知道怎要叫完成的抽象地帶，成為兩邊討價還價的爭端。

在需求上，如前面提到會分有功能性與非功能性兩種差異，這兩個名詞可能有些人比較不清楚，所以在這邊順帶解釋一下。功能性需求就是只該軟體實際操作上的任何能解決問題的項目，也就是我們一般認知上的需求。而非功能性需求就是比較攸關於軟體品質或是背後運作環境的相關規格。

因為非功能性需求可能比較難暸解，所以這邊做個舉例。假設這套軟體是一個線上服務，那麼非功能性需求可能就是這個服務在怎樣的環境下，可以同時承載多少的訪問連線，並且反應速度在幾秒之內；或是為了之後之後的部署，希望這套軟體必須能運作在 Linux 上。諸如此類與軟體實際功能無關，卻必須明訂的各種規格。在非功能性需求的訂定和驗收方式上，由於比較技術導向，可能必須在協助需求方暸解。比如說可以寫出比較詳細的驗收方式，但用對方能暸解的案例去做解釋，讓其暸解這樣的滿足條件大概和哪種案例是相似的，以前面的連線數舉個簡單了例子，可能就是這種條件可以承受一個的大學圖書館日常的訪問量、或是這種條件可以承受 PCHome 那樣的大型服務等級的訪問量，這兩種在成本上就有很大的差異。

透過這樣在暸解需求後，再進行滿足條件的釐清，不但可以幫助雙方建立起「完成」的共識，也可以在討論的過程中再一次審視需求，讓實作起來更沒疑慮、更能專注在開發上，可以說是對兩方都是有好處的。