Editing Writing suggestion of request for proposal (section)

== 需求規格撰寫建議 ==

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

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

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

範例3: 響應式設計與使用者體驗
* 不建議寫法:「後台資料庫填報要符合 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 標準」等可驗收項目

範例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) 技術方案：由廠商提案並經甲方確認後執行」