Writing suggestion of request for proposal: Difference between revisions

Jump to navigation Jump to search
m
Tags: Mobile edit Mobile web edit
Tags: Mobile edit Mobile web edit
Line 3: Line 3:
== 原則 ==
== 原則 ==
原則: 功能規格的文字,需要可以準確作為驗收或交付的項目。例如
原則: 功能規格的文字,需要可以準確作為驗收或交付的項目。例如
* 將模糊的大功能,展開為子項功能。
 
* 將模糊文字敘述,改成可以具體操作的功能文字。
* 將模糊的大功能,展開為子項功能。一個項目(一句話)只處理一件事情、一項功能。例如:登陸頁包含那些功能模組、視覺設計、數據追蹤、顧客聯繫表單
* 將模糊文字敘述,改成可以具體操作與驗收的功能文字。
* 具體說明誰要負責這件項目,例如網站前期分析,是由業主還是接案單位負責。
* 具體說明誰要負責這件項目,例如網站前期分析,是由業主還是接案單位負責。
* 避免過度承諾或過多規格,造成過度設計或無法驗收
* 避免太早展開技術解決方案的細節,例如規格需完成購物車推薦系統,規格書也許可以提到數種演算法,但是不限定只使用已知的演算法。
* 如果合約可行的話,保留功能規格依據使用測試調整的彈性。


== 範例建議 ==
== 範例建議 ==
Anonymous user

Navigation menu