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