Writing suggestion of request for proposal

From LemonWiki共筆
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

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

原則

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

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

範例建議

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

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

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

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

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

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

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

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

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

相關資料

相關資料

相關概念

相關討論

網站設計和開發流程