Writing suggestion of request for proposal

From LemonWiki共筆
Jump to navigation Jump to search

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

原則[edit]

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

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

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

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

範例建議[edit]

範例1: IE 必須死 不支援 IE

範例2: 支援 HTML5 的新版瀏覽器 C, F ... 等

  • 建議: 由於瀏覽器版本一直更新，無法確定最新版本是否會出問題。建議確認哪個版本瀏覽器是沒有問題後，將用字改成「支援哪個版本以上的瀏覽器」

範例3: 後台資料庫填報要符合RWD精神，讓老人家使用 (來源: AMOS 推坑賴群祖)

  • 建議:
    • (1) 符合 「RWD精神」、「老人家使用」的用字過於模糊，不是功能規格文字，連帶造成日後無法驗收。RWD 建議改成可以準確作為驗收的項目，例如參考 全球瀏覽器、作業系統、螢幕解析度、搜尋引擎市占率統計表，研究哪些是目前是市佔率高的裝置或者是專案需求，再改成「支援哪個螢幕尺寸的哪種行動裝置」
    • (2) 釐清「老人家使用」的需求：需求端可以再與廠商溝通確認關於字體大小、按鈕大小、內容版面等設計細節，

範例4: 網站資料分析要具備機器學習功能

  • 建議: 因為機器學習包含預測、分類、分群等領域，建議展開為子項功能，才能收斂為日後交付的功能範圍。

範例5: 資訊圖表提供匯出功能、下載功能

  • 建議: 匯出或下載什麼的檔案格式，例如 CSV, PNG 檔案？以 CSV 檔案格式為例，資料來源與資料輸出的欄位可以進一步定義。

相關資料[edit]

相關資料

相關概念

相關討論

網站設計和開發流程
Retrieved from "https://wiki.planetoid.info/index.php?title=Writing_suggestion_of_request_for_proposal&oldid=24885"