1、怎麼寫設計思路及網站功能（靜態的）
需要先確定網站欄目，然後再進行設計功能，最開始做的時候可能麻煩些，做多了就簡單了，像我們連草稿都不用打了 呵呵
--五年專業網站建設 萍緣網站工作室 希望對你有幫助！
2、求一份Web開發的詳細設計文檔
```````自己寫吧。。難找。誰會把公司用的文檔給你啊。``
3、搞開發的技術文檔有那些啊
一般是：需求文檔(需求規格說明書) - 設計文檔(概要設計說明書、詳細設計說明書、資料庫設計說明書(不是必需的)) - 開發文檔(模塊開發任務書等)
4、求一份個人網站開發文檔。1000字左右
沒寫過，給你個範例。 開發文檔範例 一.需求規格說明書 １。引言 １）編寫目的：闡明保險需求說明書的目的,指明讀者對象。 ２）項目背景：包括 a 項目的委託單位、開發單位和主管部門。 b 該軟體系統與其他系統的關系。 ３）定義：列出文檔中所用到的專業術語的定義和縮寫的原文。 ４）參考資料：包括 a 項目經核準的計劃任務書、合同或上級機關的批文。b 項目開發計劃。 c 文檔所引用的資料、標准和規范。列出這些資料的作者、標題、編號、發表日期、出版單位或資料來源。 ２。任務概述 １）目標。 ２）運行環境。 ３）條件與限制。 ３。數據描述 １）靜態數據。 ２）動態數據。包括輸入數據與輸出數據。 ３）資料庫描述。給出使用資料庫的名稱和類型。 ４）數據詞典。 ５）數據採集。 ４。功能需求 １）功能劃分。 ２）功能描述。 ５。性能需求 １）數據精確度。 ２）時間特性。如響應時間、更新時間、數據轉換與傳輸時間、運行時間等。 ３）適應性。如操作方式、運行環境、與其他軟體的介面以及開發計劃等發生變化時、應具有的適應能力。 ６。運行需求 １）用戶界面。如屏幕格式、報表格式、彩單格式、輸入輸出時間等 ２）硬體介面。 ３）軟體介面。 ４）故障處理。 ７。其他需求 如可使用性、安全保密、可維護性、可移植性等。 二、概要設計說明書 １。引言 １）編寫目的：闡明保險需求說明書的目的,指明讀者對象。 ２）項目背景：包括 a 項目的委託單位、開發單位和主管部門。 b 該軟體系統與其他系統的關系。 ３）定義：列出文檔中所用到的專業術語的定義和縮寫的原意。 ４）參考資料：列出有關資料的作者、標題、編號、發表日期、出版單位或資料來源。可包括 a 項目經核準的計劃任務書、合同或上級機關的批文。b 項目開發計劃。 c 需求規格說明書。d 測試計劃（初稿）e 用戶操作手冊（初稿）。f 文檔所引用的資料、採用的標准和規范。 ２。任務概述 １）目標。 ２）運行環境。 ３）需求概述。 ４）條件與限制。 ３。總體設計 １）處理流程。 ２）總體結構和模塊外部設計。 ３）功能分配。表明各項功能與程序結構的關系。 ４。介面設計 １）外部介面。包括用戶介面、軟體介面與硬體介面。 ２）內部介面。模塊之間的介面。 ５。數據結構設計 １）邏輯結構設計。 ２）物理結構設計。 ３）數據結構與程序的關系。 ６。運行設計 １）運行模塊的組合。 ２）運行控制。 ３）運行時間。 ７。出錯處理設計 １）出錯輸出信息。 ２）出錯處理對策。如設置任務、性能將級、恢復及再啟動等。 ８。安全保密設計 ９。維護設計 應說明為方便維護工作的設施。如維護模塊等。 三、詳細設計說明書 １。引言 １）編寫目的：闡明編寫概要設計說明書的目的，指明讀者對象。 ２）項目背景：應包括項目的來源和主管部門等。 ３）定義：列出文檔中使用到的專門術語和縮寫詞的願意。 ４）參考資料：列出有關資料的作者、標題、編號、發表日期、出版單位或資料來源。可包括 a 項目經核準的計劃任務書、合同或上級機關的批文。b 項目開發計劃。 c 需求規格說明書。d 測試計劃（初稿）e 用戶操作手冊（初稿）。f 文檔所引用的資料、採用的標准和規范。 ２。總體設計 １）需求概述 ２）軟體結構：如給出軟體系統的結構圖。 ３。程序描述 逐個給出模塊的以下說明： １）功能。 ２）性能。 ３）輸入項目。 ４）輸出項目。 ５）演算法：模塊所選用的演算法。 ６）程序邏輯：詳細描述模塊實現的演算法。可採用：a.標准流程圖 b.PDL語言 c.N-S圖 d.PAD e.判定表與描述演算法的圖表。 ７）介面。 ８）存儲分配。 ９）限制條件。 １０）測試要點：給出測試模塊的主要測試要求。
5、網站開發文檔怎麼寫
?
6、一個好的網站開發文檔主要應該包括哪些內容
好的網站開發文檔主要應該包括以下內容：
一、網站定位
包括網站服務類型、受眾群體分析、基本風格選擇等，旨在確定一個大體的開發方向。這里主要是確定網站是展示型還是有商城功能、所提供的是具體產品還是服務、網站風格基調是高端還是簡潔等等。
二、內容規劃
包括網站的詳細結構、欄目設計以及功能需求等。這其中的需求就要和客戶詳細溝通，看看對方需要哪些功能以及網站所需的欄目個數，怎樣排版等。至於功能實現，就包括常用的開發語言、開發環境等。這部分主要是給前端設計師和程序工程師看的。
三、形象設計
包括網站的整體形象、美工創意、色彩搭配、網站VI規劃、logo設計等。這部分主要是給美術設計師看的，考驗設計師如何進行美術策劃來實現客戶所要求的網站的構想藍圖
四、技術解決方案
根據網站功能來決定網站使用技術的方案。尤其是對於大型網站來說，技術方面是一個重要的問題。 這部分要說明網站開發使用的軟體環境、硬體環境;採用自建伺服器，還是租用虛擬主機，以及相關的管理分配、費用支出;有關程序開發，選用ASP、JSP、PHP、CGI、XML等哪種語言;網站的安全性措施、防黑、防毒方案等。
五、開發進度及人員
網站開發時間進度表，整體上對網站開發有個時間把握，根據進度進行對應的內容開發建設。網站開發需要哪些部門的人，以及他們的工作項目安排計劃等。
六、測試及上線
對開發完成的項目進行測試，並與客戶對接需求，客戶驗收通過後進行網站上線。
7、如何寫詳細設計文檔
在大多數軟體項目中，要末不作詳細設計，要麼開發完成後再補詳細設計文檔，質量也不容樂觀，文檔與系統往往不能同步，使詳細設計文檔完全流於形式，對工作沒有起到實際的幫助。
·
詳細設計是相對概要設計而言的，是瀑布開發流程的一個重要環節，在概要設計的高層設計的基礎上，從邏輯上實現了每一模塊的功能，是編碼階段的主要參考資料，是從高層到低層、逐步精化思想的具體實現。
詳細設計文檔的內容包括各個模塊的演算法設計，
介面設計，
數據結構設計，交互設計等。必須寫清楚各個模塊/介面/公共對象的定義，列明各個模塊程序的
各種執行條件與期望的運行效果，還要正確處理各種可能的異常。
·
在開發過程中，由需求及設計不正確、不完整所導致的問題是項目進度拖延、失敗的一個主要因素，而軟體系統的一個重要特性就是需求和設計的不斷構建和改進，在寫詳細設計文檔過程中，
詳細設計實際上是對系統的一次邏輯構建，可以有效驗證需求的完整性及正確性。
如果不寫詳細設計文檔，一般就從概設直接進入編碼階段，這時開發人員所能參考的資料就是需求規格說明書及頁面原型、資料庫設計等，不能直接進行開發，需要進行信息的溝通，把頁面原型不能體現的設計講清楚，這樣既容易遺忘，也容易發生問題，詳細設計文檔可以作為需求人員、總體設計人員與開發人員的溝通工具，把靜態頁面無法體現的設計體現出來，包含整體設計對模塊設計的規范，體現對設計上的一些決策，例如選用的演算法，對一些關鍵問題的設計考慮等等，使開發人員能快速進入開發，提高溝通效率，減少溝通問題。
對於系統功能的調整，後期的維護，詳設文檔提供了模塊設計上的考慮、決策，包括模塊與整體設計的關系、模塊所引用的資料庫設計、重要操作的處理流程、重要的業務規則實現設計等等信息，提供了對模塊設計的概述性信息，闡明了模塊設計上的決策，配合代碼注釋，可以相對輕松讀懂原有設計。
·存在的問題要由專門的人寫，是比較麻煩的，也是很需要時間的，會對進度造成壓力，也容易形成工作瓶頸，使設計人員負擔過重，而開發人員無事可作。對於現在一般的以資料庫為中心的管理系統而言，這個工作始終是要作的，區別只不過是不是形成專門文檔，形成文檔可能會多花一兩周時間，但相對於規避的風險和問題來說，也是值得的，另外由於現在高級語言的流行，所以更詳細的設計應該直接體現在代碼的設計上，而文檔則只體現設計上的一些決策，協調整體設計與模塊設計的關系，把頁面原型所不能體現的設計情況文檔化，所以所花費的時間是有限的。
設計內容容易過細，但設計階段是不能考慮特別清楚地，時間也不允許。
對於這個問題，一個對策是上邊所提到的，文檔只體現設計上的決策，頁面原型所不能反映的信息，詳細設計只體現總體設計對模塊設計的一些考慮，例如對功能的資料庫設計等等，而具體的實現實現，則到代碼中再去實現，相關的設計也僅體現在代碼中。
需求、設計需要不斷的被更新、構建，則設計文檔需要不斷的重新調整，文檔的維護需要跟上，否則文檔和系統的同步就很難得到保障了，且造成多餘的工作量。文檔的內容易流於形勢，質量糟糕，不能成為開發人員的參考手冊，一是要建立起相關制度，如有修改，先改文檔，後作開發，從工作流程上切實保障文檔與系統的同步，二是要規範文檔質量，對文檔該寫什麼，不該寫什麼，標準是什麼，粒度是什麼，語法應該如何組織，有明確的標准和考慮，同時，建立審計文檔評審、審核制度，充分保障系統的使用。·
首先是文檔的內容，根據項目和團隊的不同，詳細設計文檔的內容也有所不同，一般說來，粒度不宜過細，不能代替開發人員的設計和思考，但要把有關設計的決策考慮進去，包括與其他模塊、整體設計的關系、操作的處理流程，對業務規則的設計考慮等，有一個標准為，凡是頁面原型、需求規格說明書所不能反映的設計決策，而開發人員又需要了解的，都要寫入文檔。
其次是文檔所面向的讀者，主要為模塊開發人員、後期維護人員，模塊開發人員通過詳細設計文檔和頁面原型來了解所開發的功能，後期維護人員通過實際系統、模塊代碼、詳細設計文檔來了解一個功能。
再有就是誰來寫文檔，因為文檔主要考慮的是設計上的決策，所以寫文檔的人應該為負責、參加設計的技術經理、資深程序員，根據團隊情況和項目規模、復雜度的不同，也有所不同。
還需要保證文檔的可讀性、准確性、一致性，要建立嚴格的文檔模板及標准，保證文檔的可讀性及准確性，同時建立審核及設計評審制度，來保障設計及文檔的質量，另外在工作流程中要強調，要先設計、先寫文檔，再進行開發。