Writing suggestion of request for proposal - Revision history

Planetoid: /* 原則 */

2026-01-15T14:53:57Z

原則

← Older revision		Revision as of 22:53, 15 January 2026
Line 10:		Line 10:
	* '''明確負責人'''：具體說明誰要負責這件項目，例如網站前期分析，是由業主負責、還是接案單位負責。		* '''明確負責人'''：具體說明誰要負責這件項目，例如網站前期分析，是由業主負責、還是接案單位負責。
	* '''避免過度承諾'''：避免承諾無法實現的功能，以免導致無法驗收或預算估計失誤。		* '''避免過度承諾'''：避免承諾無法實現的功能，以免導致無法驗收或預算估計失誤。
	* '''~~避免過早限定技術解決方案~~'''：保留技術細節的彈性，由施工廠商來決定，而不一定需要寫死在規格書文字。例如 (1) 規格需完成購物車推薦系統，規格書也許可以提到數種演算法，但是不限定只使用已知的演算法。 (2) 規格需完成自動 AI 生成圖片的資訊系統，規格書也許可以規範預期的資料輸入與輸出，與資料保護相關錯誤，但是不限定只使用已知的 AI 技術方案。		* '''避免技術綁定，保留技術方案彈性'''：保留技術細節的彈性，由施工廠商來決定，而不一定需要寫死在規格書文字。例如 (1) 規格需完成購物車推薦系統，規格書也許可以提到數種演算法，但是不限定只使用已知的演算法。 (2) 規格需完成自動 AI 生成圖片的資訊系統，規格書也許可以規範預期的資料輸入與輸出，與資料保護相關錯誤，但是不限定只使用已知的 AI 技術方案。
	* '''問題導向的規格定義'''：檢視規格與原本的問題情境的對應，是否規格有解決原本問題，但避免造成過度設計 (over design)		* '''問題導向的規格定義'''：檢視規格與原本的問題情境的對應，是否規格有解決原本問題，但避免造成過度設計 (over design)
	* '''保留根據測試調整的彈性'''：如果合約可行的話，保留功能規格可依據使用測試結果再調整的彈性。如果無法採用[https://rsg.taipei/2022/09/pick-the-right-contract_2/ 敏捷合約]（Agile Contracting），而是傳統的瀑布流開發方式，還是可以透過合約方式保留開發有限度的彈性。		* '''保留根據測試調整的彈性'''：如果合約可行的話，保留功能規格可依據使用測試結果再調整的彈性。如果無法採用[https://rsg.taipei/2022/09/pick-the-right-contract_2/ 敏捷合約]（Agile Contracting），而是傳統的瀑布流開發方式，還是可以透過合約方式保留開發有限度的彈性。
			* '''避免負面表列，改用正面表列'''
			* '''明確定義範圍，避免專案範疇擴大'''

	== 資訊系統軟體專案交付項目 ==		== 資訊系統軟體專案交付項目 ==

Planetoid at 14:51, 15 January 2026

2026-01-15T14:51:30Z

← Older revision		Revision as of 22:51, 15 January 2026
Line 1:		Line 1:
	避免這樣寫 RFP (Request For Proposal) 需求建議書 (又稱需求規格書、SPEC)		避免這樣寫 RFP (Request For Proposal) 需求建議書 (又稱需求規格書、SPEC)

			{{LanguageSwitcher \| content = [[Best Practices for Request for Proposal Documentation \| English]], [[Writing suggestion of request for proposal \| 漢字]] }}

	== 原則 ==		== 原則 ==

Planetoid: /* 相關資料 */

2026-01-15T14:43:17Z

相關資料

← Older revision		Revision as of 22:43, 15 January 2026
Line 85:		Line 85:
	{{Template:Build a website in Mandarin}}		{{Template:Build a website in Mandarin}}

	[[Category: Design]] [[Category: Programming]] [[Category: Communication]]		[[Category: Design]]
			[[Category: Programming]]
			[[Category: Communication]]
			[[Category: Revised with LLMs]]

Planetoid: /* 需求規格撰寫建議 */

2026-01-15T14:42:48Z

需求規格撰寫建議

← Older revision		Revision as of 22:42, 15 January 2026
Line 23:		Line 23:

	範例1: 瀏覽器支援範圍		範例1: 瀏覽器支援範圍
	* ~~不建議寫法：~~<strike>IE 必須死</strike> ~~或「不支援 IE」~~		* 不建議寫法：「不支援 IE」 (<strike>IE 必須死</strike>)
	* 問題說明：僅列出不支援的瀏覽器（負面表列），沒有明確說明支援範圍 (正面表列)		* 問題說明：僅列出不支援的瀏覽器（負面表列），沒有明確說明支援範圍 (正面表列)
	* 建議寫法：明確指定支援的瀏覽器版本與功能，例如「支援 Chrome 90+、Firefox 88+、Safari 14+ 等符合 HTML5 標準的瀏覽器」。可參考 [https://html5test.com/ HTML5test] 確認各瀏覽器對特定功能的支援度。如果已經知道網站目標使用者的常用瀏覽器，也可以明確指定。		* 建議寫法：明確指定支援的瀏覽器版本與功能，例如「支援 Chrome 90+、Firefox 88+、Safari 14+ 等符合 HTML5 標準的瀏覽器」。可參考 [https://html5test.com/ HTML5test] 確認各瀏覽器對特定功能的支援度。如果已經知道網站目標使用者的常用瀏覽器，也可以明確指定。
Line 39:		Line 39:
	** 無障礙設計：具體說明「字體最小 16px、按鈕最小觸控區域 44x44px、對比度符合 WCAG AA 標準」等可驗收項目		** 無障礙設計：具體說明「字體最小 16px、按鈕最小觸控區域 44x44px、對比度符合 WCAG AA 標準」等可驗收項目

	範例4: ~~支援的軟體功能範圍~~		範例4: 將模糊功能拆解為明確子項
	* ~~不建議寫法:網站資料分析要具備機器學習功能~~		* 不建議寫法：「網站資料分析要具備機器學習功能」
	* ~~問題說明：機器學習功能用字太模糊，會造成專案範疇擴大而不容易完成~~		* 問題說明：「機器學習功能」範圍過大且模糊，包含預測、分類、分群等多種領域
	* ~~建議寫法：因為機器學習包含預測、分類、分群等領域，建議展開為子項功能，才能收斂為日後交付的功能範圍。~~		* 建議寫法：明確列出需要的子功能及驗收標準，例如「提供商品推薦功能：根據使用者瀏覽紀錄推薦 10 項相關商品，點擊率達 15% 以上」、「提供使用者分群功能：依消費行為分為 3-5 個客群並產生特徵報表」

	範例5: 資料匯出功能		範例5: 資料匯出功能
Line 50:		Line 50:

	範例6: 模糊的體驗感受改成可量化的指標		範例6: 模糊的體驗感受改成可量化的指標
	* ~~不建議寫法：網站要好用~~		* 不建議寫法：「網站要好用」
	* ~~問題說明：好用的文字難以驗收，需要改寫成可量化的指標~~		* 問題說明：「好用」是主觀感受，無法作為驗收標準
	* ~~建議寫法：網站某某功能，操作步驟不超過~~ 3 ~~次、或經數字使用者研究，達到多少滿意度~~		* 建議寫法：明確定義可測量的指標，例如「會員註冊流程不超過 5 個步驟，平均完成時間少於 2 分鐘」或「經 30 位使用者測試，SUS 滿意度量表平均分數達 70 分以上」

			範例7: 保留技術方案的探索彈性，但是驗收標準維持明確
			* 不建議寫法：「使用 TF-IDF、TextRank 技術分析社群文章內容，取出排名前 10 名的熱門關鍵字」
			* 問題說明：技術快速迭代，現在可行的技術不一定一直是最佳方案，建議保留不同方案的彈性；而且缺少明確的功能驗收標準
			* 建議寫法：「分析社群文章內容，自動萃取排名前 10 名的熱門關鍵字。驗收標準：(1) 輸入：每日 1000 篇以上的社群文章 (2) 輸出：前 10 名關鍵字、權重分數及數據報表，每日更新 (3) 準確度：經人工抽樣驗證，關鍵字相關性達 80% 以上 (4) 技術方案：由廠商提案並經甲方確認後執行」

	== 相關資料 ==		== 相關資料 ==

Planetoid: /* 範例建議 */

2026-01-15T14:33:12Z

範例建議

← Older revision		Revision as of 22:33, 15 January 2026
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 次、或經數字使用者研究，達到多少滿意度

	== 相關資料 ==		== 相關資料 ==

Planetoid: /* 範例建議 */

2025-10-18T10:07:57Z

範例建議

← Older revision		Revision as of 18:07, 18 October 2025
Line 35:		Line 35:
	範例5: 資訊圖表提供匯出功能、下載功能		範例5: 資訊圖表提供匯出功能、下載功能
	* 建議: 匯出或下載什麼的檔案格式，例如 CSV, PNG 檔案？以 CSV 檔案格式為例，資料來源與資料輸出的欄位可以進一步定義。		* 建議: 匯出或下載什麼的檔案格式，例如 CSV, PNG 檔案？以 CSV 檔案格式為例，資料來源與資料輸出的欄位可以進一步定義。

			範例6: 網站要好用
			* 建議: 網站某某功能，操作步驟不超過 3 次

	== 相關資料 ==		== 相關資料 ==

Planetoid: /* 原則 */

2025-10-18T10:04:04Z

原則

← Older revision		Revision as of 18:04, 18 October 2025
Line 2:		Line 2:

	== 原則 ==		== 原則 ==
	原則: ~~功能規格的文字，需要可以準確作為驗收或交付的項目~~ ([https://en.wikipedia.org/wiki/Deliverable Deliverables])。例如		原則: 功能規格的文字，需要可以準確作為驗收、可審查或可交付的項目 ([https://en.wikipedia.org/wiki/Deliverable Deliverables])。例如

	* '''細分大功能為子項功能'''：將模糊的大功能，展開為子項功能。一個項目（一句話）只處理一件事情、一項功能。例如：登陸頁包含那些功能模組、視覺設計、數據追蹤、顧客聯繫表單		* '''細分大功能為子項功能'''：將模糊的大功能，展開為子項功能。一個項目（一句話）只處理一件事情、一項功能。例如：登陸頁包含那些功能模組、視覺設計、數據追蹤、顧客聯繫表單

Planetoid at 16:34, 16 October 2024

2024-10-16T16:34:11Z

← Older revision		Revision as of 00:34, 17 October 2024
Line 62:		Line 62:
	{{Template:Build a website in Mandarin}}		{{Template:Build a website in Mandarin}}

	[[Category:Design]]		[[Category: Design]] [[Category: Programming]] [[Category: Communication]]

Planetoid: /* 相關資料 */

2024-10-16T16:24:18Z

相關資料

← Older revision		Revision as of 00:24, 17 October 2024
Line 48:		Line 48:

	* [https://www.facebook.com/sokingwang/posts/pfbid07Ay7UFZxRzeZidYP2sNwCgSYBrAYJisefgJUYjaqL1uZdFRvQgxM7bteQr8q3pQbl 王彥博 - ▋8個產品設計文件 PRD 的 SPEC 書寫原則小技巧 ▋ ⠀⠀ 你曾經寫過所謂的「規格文件」要提供給開發人員實作嗎？... \| Facebook]		* [https://www.facebook.com/sokingwang/posts/pfbid07Ay7UFZxRzeZidYP2sNwCgSYBrAYJisefgJUYjaqL1uZdFRvQgxM7bteQr8q3pQbl 王彥博 - ▋8個產品設計文件 PRD 的 SPEC 書寫原則小技巧 ▋ ⠀⠀ 你曾經寫過所謂的「規格文件」要提供給開發人員實作嗎？... \| Facebook]

			* [https://www.atlassian.com/work-management/project-management/acceptance-criteria Acceptance Criteria Explained (+ Examples & Tips)]

	相關概念		相關概念

Planetoid: add link to https://en.wikipedia.org/wiki/Deliverable

2024-07-17T03:53:24Z

add link to https://en.wikipedia.org/wiki/Deliverable

← Older revision		Revision as of 11:53, 17 July 2024
Line 2:		Line 2:

	== 原則 ==		== 原則 ==
	原則: ~~功能規格的文字，需要可以準確作為驗收或交付的項目。例如~~		原則: 功能規格的文字，需要可以準確作為驗收或交付的項目 ([https://en.wikipedia.org/wiki/Deliverable Deliverables])。例如

	* '''細分大功能為子項功能'''：將模糊的大功能，展開為子項功能。一個項目（一句話）只處理一件事情、一項功能。例如：登陸頁包含那些功能模組、視覺設計、數據追蹤、顧客聯繫表單		* '''細分大功能為子項功能'''：將模糊的大功能，展開為子項功能。一個項目（一句話）只處理一件事情、一項功能。例如：登陸頁包含那些功能模組、視覺設計、數據追蹤、顧客聯繫表單