Writing suggestion of request for proposal: Difference between revisions

Jump to navigation Jump to search

Writing suggestion of request for proposal (edit)

Revision as of 22:33, 15 January 2026

923 bytes added ,  15 January
→‎範例建議
Line 18: Line 18:
# 商業軟體授權書：當軟體專案使用到第三方軟體，需要註明軟體授權條款，是否允許商業使用、以及相關軟體授權條款的文件，詳細說明使用者權利、限制和責任。
# 商業軟體授權書：當軟體專案使用到第三方軟體，需要註明軟體授權條款，是否允許商業使用、以及相關軟體授權條款的文件，詳細說明使用者權利、限制和責任。


== 範例建議 ==
== 需求規格撰寫建議 ==
範例1:  <strike>IE 必須死</strike> 不支援 IE
* 建議: 因為 IE 對於 HTML5 支援度不佳，但是儘管是其他瀏覽器支援度也有差異，可參考 [https://html5test.com/ HTML5test - How well does your browser support HTML5?]。用字建議改成「支援哪個功能，哪個版本的瀏覽器」


範例2:  支援 HTML5 的新版瀏覽器 C, F ... 等
以下範例列出常見的模糊需求用字及建議的改善方法，修改為明確可驗收的規格文件。
* 建議: 由於瀏覽器版本一直更新，無法確定最新版本是否會出問題。建議確認哪個版本瀏覽器是沒有問題後，將用字改成「支援哪個版本以上的瀏覽器」


範例3: 後台資料庫填報要符合RWD精神，讓老人家使用 (來源: AMOS 推坑賴群祖)
範例1: 瀏覽器支援範圍
* 建議:
* 不建議寫法：<strike>IE 必須死</strike> 或 「不支援 IE」
** (1) 符合 「RWD精神」、「老人家使用」的用字過於模糊，不是功能規格文字，連帶造成日後無法驗收。RWD 建議改成可以準確作為驗收的項目，例如參考 [[Research_surveys#.E5.85.A8.E7.90.83.E7.80.8F.E8.A6.BD.E5.99.A8.E3.80.81.E4.BD.9C.E6.A5.AD.E7.B3.BB.E7.B5.B1.E3.80.81.E8.9E.A2.E5.B9.95.E8.A7.A3.E6.9E.90.E5.BA.A6.E3.80.81.E6.90.9C.E5.B0.8B.E5.BC.95.E6.93.8E.E5.B8.82.E5.8D.A0.E7.8E.87.E7.B5.B1.E8.A8.88.E8.A1.A8 | 全球瀏覽器、作業系統、螢幕解析度、搜尋引擎市占率統計表]]，研究哪些是目前是市佔率高的裝置或者是專案需求，再改成「支援哪個螢幕尺寸的哪種行動裝置」
* 問題說明：僅列出不支援的瀏覽器（負面表列），沒有明確說明支援範圍 (正面表列)
** (2) 釐清「老人家使用」的需求：需求端可以再與廠商溝通確認關於字體大小、按鈕大小、內容版面等設計細節，
* 建議寫法：明確指定支援的瀏覽器版本與功能，例如「支援 Chrome 90+、Firefox 88+、Safari 14+ 等符合 HTML5 標準的瀏覽器」。可參考 [https://html5test.com/ HTML5test] 確認各瀏覽器對特定功能的支援度。如果已經知道網站目標使用者的常用瀏覽器，也可以明確指定。


範例4: 網站資料分析要具備機器學習功能
範例2: 瀏覽器版本指定
* 建議: 因為機器學習包含預測、分類、分群等領域，建議展開為子項功能，才能收斂為日後交付的功能範圍。
* 不建議寫法：「支援 HTML5 的新版瀏覽器 Chrome、Firefox 等」
* 問題說明：「新版瀏覽器」定義不明確，無法作為驗收標準
* 建議寫法：「支援 Chrome 90 以上版本、Firefox 88 以上版本」，具體說明版本號


範例5: 資訊圖表提供匯出功能、下載功能
範例3: 響應式設計與使用者體驗
* 建議: 匯出或下載什麼的檔案格式，例如 CSV, PNG 檔案？以 CSV 檔案格式為例，資料來源與資料輸出的欄位可以進一步定義。
* 不建議寫法:「後台資料庫填報要符合 RWD 精神,讓老人家使用」 (來源: AMOS 推坑賴群祖)
* 問題說明：「RWD 精神」、「老人家使用」過於模糊，無法量化驗收
* 建議寫法：
** RWD 規格：明確定義支援的螢幕尺寸，例如「支援 1920x1080、1366x768、375x667 等主流解析度，可參考[[Research_surveys#.E5.85.A8.E7.90.83.E7.80.8F.E8.A6.BD.E5.99.A8.E3.80.81.E4.BD.9C.E6.A5.AD.E7.B3.BB.E7.B5.B1.E3.80.81.E8.9E.A2.E5.B9.95.E8.A7.A3.E6.9E.90.E5.BA.A6.E3.80.81.E6.90.9C.E5.B0.8B.E5.BC.95.E6.93.8E.E5.B8.82.E5.8D.A0.E7.8E.87.E7.B5.B1.E8.A8.88.E8.A1.A8 | 全球瀏覽器、作業系統、螢幕解析度、搜尋引擎市占率統計表]]，研究哪些是目前是市佔率高的裝置或者是專案需求，再改成「支援哪個螢幕尺寸的哪種行動裝置」
** 無障礙設計：具體說明「字體最小 16px、按鈕最小觸控區域 44x44px、對比度符合 WCAG AA 標準」等可驗收項目


範例6: 網站要好用
範例4: 支援的軟體功能範圍
* 建議: 網站某某功能，操作步驟不超過 3 次
* 不建議寫法:網站資料分析要具備機器學習功能
* 問題說明：機器學習功能用字太模糊，會造成專案範疇擴大而不容易完成
* 建議寫法：因為機器學習包含預測、分類、分群等領域，建議展開為子項功能，才能收斂為日後交付的功能範圍。
 
範例5: 資料匯出功能
* 不建議寫法：「資訊圖表提供匯出功能、下載功能」
* 問題說明：未說明匯出格式、欄位範圍
* 建議寫法：「提供 CSV 格式匯出，包含欄位：日期、類別、數值、備註；提供 PNG 格式圖表下載，解析度 1200x800px」
 
範例6: 模糊的體驗感受改成可量化的指標
* 不建議寫法：網站要好用
* 問題說明：好用的文字難以驗收，需要改寫成可量化的指標
* 建議寫法：網站某某功能，操作步驟不超過 3 次、或經數字使用者研究，達到多少滿意度


== 相關資料 ==
== 相關資料 ==
Retrieved from "https://wiki.planetoid.info/index.php/Special:MobileDiff/26179"

Navigation menu