Editing Writing suggestion of request for proposal (section)

== 原則 ==
原則: 功能規格的文字，需要可以準確作為驗收、可審查或可交付的項目 ([https://en.wikipedia.org/wiki/Deliverable Deliverables])。例如

* '''細分大功能為子項功能'''：將模糊的大功能，展開為子項功能。一個項目（一句話）只處理一件事情、一項功能。例如：登陸頁包含那些功能模組、視覺設計、數據追蹤、顧客聯繫表單
* '''可交付與驗收'''：將模糊的描述，改成可以具體操作與驗收的功能文字。
* '''明確負責人'''：具體說明誰要負責這件項目，例如網站前期分析，是由業主負責、還是接案單位負責。
* '''避免過度承諾'''：避免承諾無法實現的功能，以免導致無法驗收或預算估計失誤。
* '''避免技術綁定，保留技術方案彈性'''：保留技術細節的彈性，由施工廠商來決定，而不一定需要寫死在規格書文字。例如 (1) 規格需完成購物車推薦系統，規格書也許可以提到數種演算法，但是不限定只使用已知的演算法。 (2) 規格需完成自動 AI 生成圖片的資訊系統，規格書也許可以規範預期的資料輸入與輸出，與資料保護相關錯誤，但是不限定只使用已知的 AI 技術方案。
* '''問題導向的規格定義'''：檢視規格與原本的問題情境的對應，是否規格有解決原本問題，但避免造成過度設計 (over design)
* '''保留根據測試調整的彈性'''：如果合約可行的話，保留功能規格可依據使用測試結果再調整的彈性。如果無法採用[https://rsg.taipei/2022/09/pick-the-right-contract_2/ 敏捷合約]（Agile Contracting），而是傳統的瀑布流開發方式，還是可以透過合約方式保留開發有限度的彈性。
* '''避免負面表列，改用正面表列'''
* '''明確定義範圍，避免專案範疇擴大'''