14,954
edits
Writing suggestion of request for proposal: Difference between revisions
Jump to navigation
Jump to search
m
Writing suggestion of request for proposal (edit)
Revision as of 22:53, 15 January 2026
, 15 January→原則
m (→原則) |
|||
| (2 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
避免這樣寫 RFP (Request For Proposal) 需求建議書 (又稱需求規格書、SPEC) | 避免這樣寫 RFP (Request For Proposal) 需求建議書 (又稱需求規格書、SPEC) | ||
{{LanguageSwitcher | content = [[Best Practices for Request for Proposal Documentation | English]], [[Writing suggestion of request for proposal | 漢字]] }} | |||
== 原則 == | == 原則 == | ||
| Line 8: | Line 10: | ||
* '''明確負責人'''：具體說明誰要負責這件項目，例如網站前期分析，是由業主負責、還是接案單位負責。 | * '''明確負責人'''：具體說明誰要負責這件項目，例如網站前期分析，是由業主負責、還是接案單位負責。 | ||
* '''避免過度承諾'''：避免承諾無法實現的功能，以免導致無法驗收或預算估計失誤。 | * '''避免過度承諾'''：避免承諾無法實現的功能，以免導致無法驗收或預算估計失誤。 | ||
* ''' | * '''避免技術綁定，保留技術方案彈性'''：保留技術細節的彈性，由施工廠商來決定，而不一定需要寫死在規格書文字。例如 (1) 規格需完成購物車推薦系統，規格書也許可以提到數種演算法，但是不限定只使用已知的演算法。 (2) 規格需完成自動 AI 生成圖片的資訊系統，規格書也許可以規範預期的資料輸入與輸出，與資料保護相關錯誤，但是不限定只使用已知的 AI 技術方案。 | ||
* '''問題導向的規格定義'''：檢視規格與原本的問題情境的對應，是否規格有解決原本問題，但避免造成過度設計 (over design) | * '''問題導向的規格定義'''：檢視規格與原本的問題情境的對應，是否規格有解決原本問題，但避免造成過度設計 (over design) | ||
* '''保留根據測試調整的彈性'''：如果合約可行的話，保留功能規格可依據使用測試結果再調整的彈性。如果無法採用[https://rsg.taipei/2022/09/pick-the-right-contract_2/ 敏捷合約]（Agile Contracting），而是傳統的瀑布流開發方式，還是可以透過合約方式保留開發有限度的彈性。 | * '''保留根據測試調整的彈性'''：如果合約可行的話，保留功能規格可依據使用測試結果再調整的彈性。如果無法採用[https://rsg.taipei/2022/09/pick-the-right-contract_2/ 敏捷合約]（Agile Contracting），而是傳統的瀑布流開發方式，還是可以透過合約方式保留開發有限度的彈性。 | ||
* '''避免負面表列，改用正面表列''' | |||
* '''明確定義範圍，避免專案範疇擴大''' | |||
== 資訊系統軟體專案交付項目 == | == 資訊系統軟體專案交付項目 == | ||
| Line 85: | Line 89: | ||
{{Template:Build a website in Mandarin}} | {{Template:Build a website in Mandarin}} | ||
[[Category: Design]] [[Category: Programming]] [[Category: Communication]] | [[Category: Design]] | ||
[[Category: Programming]] | |||
[[Category: Communication]] | |||
[[Category: Revised with LLMs]] | |||