1.政府採購策略（以美國政府為參考）希望專案需求明確以易於估價，所以通常PM需要在發RFP之前將需求弄清楚。因此在Traditional Requirement Engineering中介於買方Acquirer與發展方Developer或Supplier中間有一道透明牆(Wall)，在Wall的上游是甲方要執行完整的Requirements Development，在Wall的下游是乙方要進行需求變更管理的Requirements Management。Acquirer要在RFP中敘述Specification，Specification用以說明專案所要採購的Goods (當然，要有Specification之前，先要有WBS)，也就是所謂的“What”。等於是邀請Supplier由Waterfall mode的“System Requirements Analysis/Design”開始執行（參考DoD-STD-2167）。1998年之後美國政府希望用Performance Based Specification，也就是PM要敘述所謂的“How Well”方式。有了正確且完整的Specification，接下來就可以敘述需要那些工“works”方可以完成Goods的Statement of Works (SOW)文件，SOW用以說明“Where”、“When”與 “How many”、“ How long”。有了完整的SOW與Specification，同時參考WBS以及當作附件用以說明“Why”的Needs (參考12207 - 5.1.1)，乙方Supplier就可以依據甲方要採購的品項CLIN，進行估價。以上所敘述的都是基於PM能夠完成需求確認的假設，因此在執行RFP之前要進行Requirements Elicitation、Requirements Analysis、Requirements Documentation、Requirements Validation等Requirements Development的程序以完成Specification；Elicitation就可以包括Interview、Prototyping、Meeting、Questionary、…等技巧。因為RFP的需求明確所以在採購合約之價金方式(Contract Type)通常會選用對於乙方最不利的固定價金契約（Firm-Fixed-Price，FFP，國內採購法並無相對應之名辭，較接近的是“總包價方式”加上“禁止調整”），這對於甲方是最有保障的。所以對於甲方最有利的採購方式是要完整且正確的在RFP中提供SOW、Specification，以便乙方不需要有任何“Assumption”之下進行報價。
2.但事實上以系統複雜性日增、科技產品生命週期日漸縮短環境下要在發RFP之前完成Specification與SOW已日漸困難，因此已演進為需求不明確之下進行採購，RFP Package中不說明Specification，通常僅說明尚未達到system level的高層次構想文件Requirements Documentation，因為無specification所以通常也無SOW，改以提供Statement of Object，前面所提的requirements development就交給developer去做，乙方要代甲方完成specification與SOW。在Requirements不完整下要乙方估價，是屬於高方風險的合約，因此在計價方面就必須採用成本價金補償方式cost reimbursement，國內採購法有相近似的“成本加公費”。此種採購方式就是Evolutional Acquisition and Spiral Development Model，其特徵是 “I can not tell you what I want, but I’ll know it when I see it.”。
3.因此需求明確與否皆可執行採購作業之RFP Release程序，但採購人員最重要的是依據當時需求是否明確狀態選擇適當之契約價金方式，PM選定適當的Life Cycle Model。如同軟體工程一般教科書所提到的life cycle中由Conception phase至production phase，其risk由最高降至最低，因此如果甲方不能於RFP完整敘述Specification，較佳的避險方式是合約應採取多階段計價方式。風險高的階段要採用成本價金補償方式，風險低的階段要採用固定價金方式。選錯契約價金方式與Life Cycle Model將導致合約最高風險，此就是所謂的Cost Risk。
4.需求明確且採用固定價金契約在專案管理方面有極大之影響，例如美國政府即明定FFP類型合約不得以實獲值工程EVMS進行計畫成本與時程分析，同時要盡量減少履約監控，否則會提高乙方的風險。