Writing suggestion of request for proposal

避免這樣寫 RFP (Request For Proposal) 需求建議書 (又稱需求規格書、SPEC)

🌐 Switch language: English, 漢字

原則

原則: 功能規格的文字，需要可以準確作為驗收、可審查或可交付的項目 (Deliverables)。例如

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

資訊系統軟體專案交付項目

1. 軟體專案的程式碼：程式碼檔案，包括程式原始碼檔案、函示庫 (library) 等檔案。
2. 功能測試報告：交付完整的功能測試報告，包括測試案例、執行狀況、發現的問題以及測試覆蓋範圍。測試報告應該清晰地指出哪些功能已經達到預期的標準，哪些尚需改進。
3. 軟體安裝手冊：如果資訊系統日後需要移交，則需要提供詳細的安裝手冊，包括安裝前的準備工作、步驟說明、必要的系統配置，以及如何處理常見的安裝問題。
4. 商業軟體授權書：當軟體專案使用到第三方軟體，需要註明軟體授權條款，是否允許商業使用、以及相關軟體授權條款的文件，詳細說明使用者權利、限制和責任。

需求規格撰寫建議

以下範例列出常見的模糊需求用字及建議的改善方法，修改為明確可驗收的規格文件。

範例1: 瀏覽器支援範圍

• 不建議寫法：「不支援 IE」 (IE 必須死)
• 問題說明：僅列出不支援的瀏覽器（負面表列），沒有明確說明支援範圍 (正面表列)
• 建議寫法：明確指定支援的瀏覽器版本與功能，例如「支援 Chrome 90+、Firefox 88+、Safari 14+ 等符合 HTML5 標準的瀏覽器」。可參考 HTML5test 確認各瀏覽器對特定功能的支援度。如果已經知道網站目標使用者的常用瀏覽器，也可以明確指定。

範例2: 瀏覽器版本指定

• 不建議寫法：「支援 HTML5 的新版瀏覽器 Chrome、Firefox 等」
• 問題說明：「新版瀏覽器」定義不明確，無法作為驗收標準
• 建議寫法：「支援 Chrome 90 以上版本、Firefox 88 以上版本」，具體說明版本號

範例3: 響應式設計與使用者體驗

• 不建議寫法:「後台資料庫填報要符合 RWD 精神,讓老人家使用」 (來源: AMOS 推坑賴群祖)
• 問題說明：「RWD 精神」、「老人家使用」過於模糊，無法量化驗收
• 建議寫法：
  • RWD 規格：明確定義支援的螢幕尺寸，例如「支援 1920x1080、1366x768、375x667 等主流解析度，可參考 全球瀏覽器、作業系統、螢幕解析度、搜尋引擎市占率統計表，研究哪些是目前是市佔率高的裝置或者是專案需求，再改成「支援哪個螢幕尺寸的哪種行動裝置」
  • 無障礙設計：具體說明「字體最小 16px、按鈕最小觸控區域 44x44px、對比度符合 WCAG AA 標準」等可驗收項目

範例4: 將模糊功能拆解為明確子項

• 不建議寫法：「網站資料分析要具備機器學習功能」
• 問題說明：「機器學習功能」範圍過大且模糊，包含預測、分類、分群等多種領域
• 建議寫法：明確列出需要的子功能及驗收標準，例如「提供商品推薦功能：根據使用者瀏覽紀錄推薦 10 項相關商品，點擊率達 15% 以上」、「提供使用者分群功能：依消費行為分為 3-5 個客群並產生特徵報表」

範例5: 資料匯出功能

• 不建議寫法：「資訊圖表提供匯出功能、下載功能」
• 問題說明：未說明匯出格式、欄位範圍
• 建議寫法：「提供 CSV 格式匯出，包含欄位：日期、類別、數值、備註；提供 PNG 格式圖表下載，解析度 1200x800px」

範例6: 模糊的體驗感受改成可量化的指標

• 不建議寫法：「網站要好用」
• 問題說明：「好用」是主觀感受，無法作為驗收標準
• 建議寫法：明確定義可測量的指標，例如「會員註冊流程不超過 5 個步驟，平均完成時間少於 2 分鐘」或「經 30 位使用者測試，SUS 滿意度量表平均分數達 70 分以上」

範例7: 保留技術方案的探索彈性，但是驗收標準維持明確

• 不建議寫法：「使用 TF-IDF、TextRank 技術分析社群文章內容，取出排名前 10 名的熱門關鍵字」
• 問題說明：技術快速迭代，現在可行的技術不一定一直是最佳方案，建議保留不同方案的彈性；而且缺少明確的功能驗收標準
• 建議寫法：「分析社群文章內容，自動萃取排名前 10 名的熱門關鍵字。驗收標準：(1) 輸入：每日 1000 篇以上的社群文章 (2) 輸出：前 10 名關鍵字、權重分數及數據報表，每日更新 (3) 準確度：經人工抽樣驗證，關鍵字相關性達 80% 以上 (4) 技術方案：由廠商提案並經甲方確認後執行」

相關資料

相關資料

• 軟體需求與功能規格書-以線上糕餅網站為例 · GitBook
• gaya/佛教圖書館館訊/第二期/圖書館自動化之路－－經由建議需求書 RFP「因為 RFP與日後合約的內容有相當密切的關係（甚至，國外有些 RFP的範本，中間有一段落就是要求廠商的建議書中要提供合約的草約），所以，撰寫 RFP需要花相當的心思，小心謹慎，力求文字清楚嚴謹，儘量用量化、具體的數據與敘述，避免有模稜兩可或者任何彈性釋意的空間或機會。 」
• 產品經理 PM 第 3 講：如何開始一個改版專案 [Last visited: 2018-08-17]
• RFP怎麼寫 - iT 邦幫忙::一起幫忙解決難題，拯救 IT 人的一天 [Last visited: 2020-11-16]
• 需求方不是故意的，只是大家都沒經驗 (2021). 王彥博 [Last visited: 2021-12-05]

• 王彥博 - ▋教導實習生寫需求文件，才發現我是個很 GY 的人 ... | Facebook 1. 有沒有在需求建議書裡面過度承諾 2. 寫下來的文字語句，有沒有明確的指向性 3. 一行一述，一句話只講一件事情，不要多重條件子句

• 王彥博 - ▋8個產品設計文件 PRD 的 SPEC 書寫原則小技巧 ▋ ⠀⠀ 你曾經寫過所謂的「規格文件」要提供給開發人員實作嗎？... | Facebook

• Acceptance Criteria Explained (+ Examples & Tips)

相關概念

• Operational Definition - 操作定義 (Operational Definition)
• Software acceptance test plan (使用者驗收測試)

相關討論

• 如何一次把軟體需求講清楚 - iT 邦幫忙::一起幫忙解決難題，拯救 IT 人的一天 [Last visited: 2018-10-17]

網站設計和開發流程

• 規劃： 開始建立網站之前，內容開發策略、 技術選擇 | 註冊域名， 選擇網站主機 | 資訊架構 | 數據模型： 數據類型， 資料流 | 文件： 建議書 | 授權議題
• 設計： CSS工具， 免費字體，美工圖庫， 表情符號和 圖示
• 測試和交付：可用性測試， 檢查瀏覽器相容性 | 網站測試：Web Ping， 軟體接受測試計劃 | 推廣您的網站
• 維護：網站備份與恢復測試，軟體更新（作業系統補丁或CMS安全更新）
• 需要幫助？ 相關社群， 我需要靈感， 網頁設計詞彙表