政府採購中最大的問題之一是解決 需求 與 目標的問題。 過度專注於需求而對目標關注不夠，通常會導致解決方案雖然功能很多，但並不總是完全滿足採購機構的需求。需求通常高度具體地描述應用程式中的硬性功能或特性。例如：
用戶應能夠更改應用程式中所有標籤的文字顏色
應用程式應使用 Fortran 作為其伺服器端語言
乍一看，其中一些似乎是合理的。更改文字顏色增 波蘭客戶電子郵件列表 加了靈活性，嘿， Fortran 在世界上仍然佔有一席之地。值得注意的是，關注需求與目標並不是該機構的錯。需求是高度客觀的，將實現非常具體的結果，並且不會給供應商太大的犯錯空間。但是，也有缺點。
讓我們更深入地了解這些功能中的每一個，了解它們為什麼可能會出現問題，並猜測用戶真正的要求是什麼（提示：讓我們確定 用戶的目標 ，而不是讓用戶規定要求 ）。
範例 1：使用者應能夠更改應用程式中所有標籤的文字顏色
用戶希望錯誤訊息明亮且一般文字易於閱讀。也許用戶將錯誤文字從預設的深粉紅色更改為刺眼的紅色，並為所有其他應用程式文字選擇平靜的淺藍色。
在每種情況下，雖然變化看起來很明顯，但 應用程式的整體可用性可能會降低。亮紅色文字可能本能地暗示錯誤，但在嚴重依賴持久錯誤訊息傳遞的應用程式中，粉紅色可能更容易長時間閱讀 - 因此最初決定使用更精緻的色調。
也許淺藍色讓人 平靜，但在白色背景上很難閱讀 - 如果應用程式不允許背景顏色變化怎麼辦？在第一種情況下，聽起來用戶希望確保“應用程式應使用不同的風格技術（顏色、字體、大小等）來提高應用程式不同文字段的可讀性。”在第二種情況下，用戶可能會要求「代表該機構人口的一組用戶應認為該應用程式可以在很長一段時間內可讀」。
在這兩種情況下，我們都採取了嚴格的限制性 要求 ，並將其提升到假定的 目標。當然，我們必須與用戶確認，但現在供應商可以利用他們的專業知識提出一個優雅的、設計良好的解決方案——這就是你付錢給他們的目的——而不是引入可能對部門產生負面影響的功能在未經訓練的用戶手中。
範例 2：應用程式應使用 Fortran 作為伺服器端語言
也許某個機構的資料倉儲可以很好地插入 Fortran。或者他們可能關心應用程式速度，這是一個重要的考慮因素 - 在少數情況下，Fortran 非常快。然而如今，Fortran 在科學計算領域佔有一席之地，除此之外就沒有什麼了。然後，回應的供應商將僅限於極少量的庫、資源和人才，這些庫、資源和人才可能可以 幫助 他們建立一些基於 Fortran 的應用程序，因此採購機構可以擁有一個插入資料倉儲並且 速度可能 很快的應用程式。相反，該機構應該描述其 目標：
應用程式應提供一些明確定義的標準方法來接收和傳輸資料給其他應用程式
應用程式應具有高效能，以便所有函數的平均執行時間少於 200 毫秒
有了目標導向的目標（而不是硬性要求），機構可以期望供應商提供可互通的應用程式（可能是基於 REST 的），其速度與機構需要的一樣快。同時，供應商可以使用廣泛支持的現代化技術，最終降低該機構的成本，同時幫助該機構保持現代化。
這是一個全面的勝利——該機構在啟動後將擁有一個完全符合其要求的應用程序，而供應商能夠利用其專業知識為該機構提供一個強大且成本較低的應用程式。
更好的技術解決方案始於更好的採購策略。發布 RFP 絕非易事，我們剛剛觸及瞭如何改善您機構的 RFP 流程的全面內容。然而，透過遵循上述指導，您可以確信您的採購流程將更具前瞻性、低風險且令您的機構滿意。
