Writing suggestion of request for proposal: Difference between revisions

From LemonWiki共筆
Jump to navigation Jump to search
mNo edit summary
No edit summary
Line 19: Line 19:
相關資料
相關資料
* [https://legacy.gitbook.com/book/masonwu1762/bakerystorespec/details 軟體需求與功能規格書-以線上糕餅網站為例 · GitBook]
* [https://legacy.gitbook.com/book/masonwu1762/bakerystorespec/details 軟體需求與功能規格書-以線上糕餅網站為例 · GitBook]
* [http://www.gaya.org.tw/journal/m2/2-main1.htm gaya/佛教圖書館館訊/第二期/圖書館自動化之路－－經由建議需求書 RFP]「因為 RFP與日後合約的內容有相當密切的關係（甚至，國外有些 RFP的範本，中間有一段落就是要求廠商的建議書中要提供合約的草約），所以，撰寫 RFP需要花相當的心思，小心謹慎，力求文字清楚嚴謹，儘量用量化、具體的數據與敘述，避免有模稜兩可或者任何彈性釋意的空間或機會。 」


{{Template:Draft}}
{{Template:Draft}}


[[Category:WebDesign]]
[[Category:WebDesign]]

Revision as of 21:33, 21 April 2018

避免這樣寫 RFP (Request For Proposal) 需求建議書

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

  • (1) 將模糊的大功能，展開為子項功能。
  • (2) 將模糊文字，改成可以操作的功能文字。

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

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

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

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

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

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

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

相關資料


icon_scale_pencil.png This article "Writing suggestion of request for proposal" is still being written. If there are any incomplete parts, you are welcome to directly edit them. 這篇文章「Writing suggestion of request for proposal」內容還在撰寫中，如果有不完整的部分，歡迎你直接動手修改。


Retrieved from "https://wiki.planetoid.info/index.php?title=Writing_suggestion_of_request_for_proposal&oldid=19366"