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 (→原則) |
||
| (3 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 23: | Line 27: | ||
範例1: 瀏覽器支援範圍 | 範例1: 瀏覽器支援範圍 | ||
* | * 不建議寫法：「不支援 IE」 (<strike>IE 必須死</strike>) | ||
* 問題說明：僅列出不支援的瀏覽器（負面表列），沒有明確說明支援範圍 (正面表列) | * 問題說明：僅列出不支援的瀏覽器（負面表列），沒有明確說明支援範圍 (正面表列) | ||
* 建議寫法：明確指定支援的瀏覽器版本與功能，例如「支援 Chrome 90+、Firefox 88+、Safari 14+ 等符合 HTML5 標準的瀏覽器」。可參考 [https://html5test.com/ HTML5test] 確認各瀏覽器對特定功能的支援度。如果已經知道網站目標使用者的常用瀏覽器，也可以明確指定。 | * 建議寫法：明確指定支援的瀏覽器版本與功能，例如「支援 Chrome 90+、Firefox 88+、Safari 14+ 等符合 HTML5 標準的瀏覽器」。可參考 [https://html5test.com/ HTML5test] 確認各瀏覽器對特定功能的支援度。如果已經知道網站目標使用者的常用瀏覽器，也可以明確指定。 | ||
| Line 39: | Line 43: | ||
** 無障礙設計：具體說明「字體最小 16px、按鈕最小觸控區域 44x44px、對比度符合 WCAG AA 標準」等可驗收項目 | ** 無障礙設計：具體說明「字體最小 16px、按鈕最小觸控區域 44x44px、對比度符合 WCAG AA 標準」等可驗收項目 | ||
範例4: | 範例4: 將模糊功能拆解為明確子項 | ||
* | * 不建議寫法：「網站資料分析要具備機器學習功能」 | ||
* | * 問題說明：「機器學習功能」範圍過大且模糊，包含預測、分類、分群等多種領域 | ||
* | * 建議寫法：明確列出需要的子功能及驗收標準，例如「提供商品推薦功能：根據使用者瀏覽紀錄推薦 10 項相關商品，點擊率達 15% 以上」、「提供使用者分群功能：依消費行為分為 3-5 個客群並產生特徵報表」 | ||
範例5: 資料匯出功能 | 範例5: 資料匯出功能 | ||
| Line 50: | Line 54: | ||
範例6: 模糊的體驗感受改成可量化的指標 | 範例6: 模糊的體驗感受改成可量化的指標 | ||
* | * 不建議寫法：「網站要好用」 | ||
* | * 問題說明：「好用」是主觀感受，無法作為驗收標準 | ||
* | * 建議寫法：明確定義可測量的指標，例如「會員註冊流程不超過 5 個步驟，平均完成時間少於 2 分鐘」或「經 30 位使用者測試，SUS 滿意度量表平均分數達 70 分以上」 | ||
範例7: 保留技術方案的探索彈性，但是驗收標準維持明確 | |||
* 不建議寫法：「使用 TF-IDF、TextRank 技術分析社群文章內容，取出排名前 10 名的熱門關鍵字」 | |||
* 問題說明：技術快速迭代，現在可行的技術不一定一直是最佳方案，建議保留不同方案的彈性；而且缺少明確的功能驗收標準 | |||
* 建議寫法：「分析社群文章內容，自動萃取排名前 10 名的熱門關鍵字。驗收標準：(1) 輸入：每日 1000 篇以上的社群文章 (2) 輸出：前 10 名關鍵字、權重分數及數據報表，每日更新 (3) 準確度：經人工抽樣驗證，關鍵字相關性達 80% 以上 (4) 技術方案：由廠商提案並經甲方確認後執行」 | |||
== 相關資料 == | == 相關資料 == | ||
| Line 80: | 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]] | |||