網站詳細設計說明書

1、軟體開發詳細設計說明書中的功能設計怎麼寫?請詳述.

詳細設計就來是把項目里每個功能點源都要完完整整列出來。
好比用戶注冊：在XX頁面輸入用戶名、密碼、電話、地址。
提交之後會返回什麼樣消息。出錯會提示什麼情況。
最後還要加個流程圖。

而需求只需要寫明大概功能點要達到什麼要的目的就可以了。沒這么細。

2、系統需求說明書與詳細設計說明的區別

需求規格說明書在前,詳細設計說明書在後.
需求規格說明書要界定用戶的最終需求,.
詳細設計說明書在概要設計的基礎上要深化設計,

3、如何寫詳細設計文檔

在大多數軟體項目中，要末不作詳細設計，要麼開發完成後再補詳細設計文檔，質量也不容樂觀，文檔與系統往往不能同步，使詳細設計文檔完全流於形式，對工作沒有起到實際的幫助。
·
詳細設計是相對概要設計而言的，是瀑布開發流程的一個重要環節，在概要設計的高層設計的基礎上，從邏輯上實現了每一模塊的功能，是編碼階段的主要參考資料，是從高層到低層、逐步精化思想的具體實現。
詳細設計文檔的內容包括各個模塊的演算法設計，
介面設計，
數據結構設計，交互設計等。必須寫清楚各個模塊/介面/公共對象的定義，列明各個模塊程序的
各種執行條件與期望的運行效果，還要正確處理各種可能的異常。
·
在開發過程中，由需求及設計不正確、不完整所導致的問題是項目進度拖延、失敗的一個主要因素，而軟體系統的一個重要特性就是需求和設計的不斷構建和改進，在寫詳細設計文檔過程中，
詳細設計實際上是對系統的一次邏輯構建，可以有效驗證需求的完整性及正確性。
如果不寫詳細設計文檔，一般就從概設直接進入編碼階段，這時開發人員所能參考的資料就是需求規格說明書及頁面原型、資料庫設計等，不能直接進行開發，需要進行信息的溝通，把頁面原型不能體現的設計講清楚，這樣既容易遺忘，也容易發生問題，詳細設計文檔可以作為需求人員、總體設計人員與開發人員的溝通工具，把靜態頁面無法體現的設計體現出來，包含整體設計對模塊設計的規范，體現對設計上的一些決策，例如選用的演算法，對一些關鍵問題的設計考慮等等，使開發人員能快速進入開發，提高溝通效率，減少溝通問題。
對於系統功能的調整，後期的維護，詳設文檔提供了模塊設計上的考慮、決策，包括模塊與整體設計的關系、模塊所引用的資料庫設計、重要操作的處理流程、重要的業務規則實現設計等等信息，提供了對模塊設計的概述性信息，闡明了模塊設計上的決策，配合代碼注釋，可以相對輕松讀懂原有設計。
·存在的問題要由專門的人寫，是比較麻煩的，也是很需要時間的，會對進度造成壓力，也容易形成工作瓶頸，使設計人員負擔過重，而開發人員無事可作。對於現在一般的以資料庫為中心的管理系統而言，這個工作始終是要作的，區別只不過是不是形成專門文檔，形成文檔可能會多花一兩周時間，但相對於規避的風險和問題來說，也是值得的，另外由於現在高級語言的流行，所以更詳細的設計應該直接體現在代碼的設計上，而文檔則只體現設計上的一些決策，協調整體設計與模塊設計的關系，把頁面原型所不能體現的設計情況文檔化，所以所花費的時間是有限的。
設計內容容易過細，但設計階段是不能考慮特別清楚地，時間也不允許。
對於這個問題，一個對策是上邊所提到的，文檔只體現設計上的決策，頁面原型所不能反映的信息，詳細設計只體現總體設計對模塊設計的一些考慮，例如對功能的資料庫設計等等，而具體的實現實現，則到代碼中再去實現，相關的設計也僅體現在代碼中。
需求、設計需要不斷的被更新、構建，則設計文檔需要不斷的重新調整，文檔的維護需要跟上，否則文檔和系統的同步就很難得到保障了，且造成多餘的工作量。文檔的內容易流於形勢，質量糟糕，不能成為開發人員的參考手冊，一是要建立起相關制度，如有修改，先改文檔，後作開發，從工作流程上切實保障文檔與系統的同步，二是要規範文檔質量，對文檔該寫什麼，不該寫什麼，標準是什麼，粒度是什麼，語法應該如何組織，有明確的標准和考慮，同時，建立審計文檔評審、審核制度，充分保障系統的使用。·
首先是文檔的內容，根據項目和團隊的不同，詳細設計文檔的內容也有所不同，一般說來，粒度不宜過細，不能代替開發人員的設計和思考，但要把有關設計的決策考慮進去，包括與其他模塊、整體設計的關系、操作的處理流程，對業務規則的設計考慮等，有一個標准為，凡是頁面原型、需求規格說明書所不能反映的設計決策，而開發人員又需要了解的，都要寫入文檔。
其次是文檔所面向的讀者，主要為模塊開發人員、後期維護人員，模塊開發人員通過詳細設計文檔和頁面原型來了解所開發的功能，後期維護人員通過實際系統、模塊代碼、詳細設計文檔來了解一個功能。
再有就是誰來寫文檔，因為文檔主要考慮的是設計上的決策，所以寫文檔的人應該為負責、參加設計的技術經理、資深程序員，根據團隊情況和項目規模、復雜度的不同，也有所不同。
還需要保證文檔的可讀性、准確性、一致性，要建立嚴格的文檔模板及標准，保證文檔的可讀性及准確性，同時建立審核及設計評審制度，來保障設計及文檔的質量，另外在工作流程中要強調，要先設計、先寫文檔，再進行開發。

4、詳細設計說明書到底怎麼寫？

詳細設計，這是考驗技術專家設計思維的重要關卡，詳細設計說明書應當把具體的模塊以最』干凈』的方式(黑箱結構）提供給編碼者，使得系統整體模塊化達到最大；一份好的詳細設計說明書，可以使編碼的復雜性減低到最低，實際上，嚴格的講詳細設計說明書應當把每個函數的每個參數的定義都精精細細的提供出來，從需求分析到概要設計到完成詳細設計說明書，一個軟體項目就應當說完成了一半了。換言之，一個大型軟 件系統在完成了一半的時候，其實還沒有開始一行代碼工作。

那些把作軟體的程序員簡單理解為寫代碼的，就從根子上犯了錯誤了。

5、IT標書、需求規格說明書、概要設計說明書、詳細設計說明書的內容，之間的區別是什麼？分別由誰完書寫？

IT標書是總的一本完整標書。
其中的章節分別是：需求規格說明書、概要設計說明書、詳細設計說明書的內容，它們之間的區別是分別完成不同的任務。分別由公司IT相關人員書寫完成。

6、求一份個人網站開發文檔。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.判定表與描述演算法的圖表。 ７）介面。 ８）存儲分配。 ９）限制條件。 １０）測試要點：給出測試模塊的主要測試要求。

7、詳細設計說明書的參考資料

列出有關的參考資料，如：
a．本項目的經核準的計劃任務書或合同、上級機關的批文；
b．屬於本項目的其他已發表的文件；
c.本文件中各處引用到的文件資料，包括所要用到的軟體開發標准。 列出這些文件的標題、文件編號、發表日期和出版單位，說明能夠取得這些文件的來源。
F.2程序系統的結構
用一系列圖表列出本程序系統內的每個程序（包括每個模塊和子程序）的名稱、標識符和它們之間 的層次結構關系。
F.3程序1（標識符）設計說明
從本章開始，逐個地給出各個層次中的每個程序的設計考慮。以下給出的提綱是針對一般情況的。 對於一個具體的模塊，尤其是層次比較低的模塊或子程序，其很多條目的內容往往與它所隸屬的上一層 模塊的對應條目的內容相同，在這種情況下，只要簡單地說明這一點即可。
F.3.1程序描述
給出對該程序的簡要描述，主要說明安排設計本程序的目的意義，並且，還要說明本程序的特點（如 是常駐內存還是非常駐？是否子程序？是可重入的還是不可重入的？有無覆蓋要求？是順序處理還是並發 處理卜…..等）。
F.3.2功能
說明該程序應具有的功能，可採用IPO圖（即輸入一處理一輸出圖）的形式。
F.3.3性能
說明對該程序的全部性能要求，包括對精度、靈活性和時間特性的要求。
F.3.4輸入項
給出對每一個輸入項的特性，包括名稱、標識、數據的類型和格式、數據值的有效范圍、輸入的方式。 數量和頻度、輸入媒體、輸入數據的來源和安全保密條件等等。
F. 3. 5輸出項
給出對每一個輸出項的特性，包括名稱、標識、數據的類型和格式，數據值的有效范圍，輸出的形式、 數量和頻度，輸出媒體、對輸出圖形及符號的說明、安全保密條件等等。
F．3．6演算法
詳細說明本程序所選用的演算法，具體的計算公式和計算步驟。
F．3．7流程邏輯
用圖表（例如流程圖、判定表等）輔以必要的說明來表示本程序的邏輯流程。
F．3.8介面
用圖的形式說明本程序所隸屬的上一層模塊及隸屬於本程序的下一層模塊、子程序，說明參數賦值和調用方式，說明與本程序相直接關聯的數據結構（資料庫、數據文卷）。
F．3.9存儲分配
根據需要，說明本程序的存儲分配。
F．3．10注釋設計

8、詳細設計說明書 介面 是什麼意思

介面可以認為是用戶與伺服器之間交互的地方，就像一扇門。例如在網上購物，支付寶之類的就是介面。

9、軟體系統設計說明書 軟體功能設計說明書 軟體詳細設計說明書 簡單說一下，三者有什麼不一樣

我們不這么叫，你可以參考一下：
軟體任務書：軟體完成那些功能？具備哪些性能，以及交付條件、維護條件等，通常是提出方做的。
軟體需求說明書：為了完成上面的功能，如何設計，包括對任務書的理解，功能劃分、模塊劃分等，關鍵的流程，也是給下一級軟體編寫人員的要求，軟體管理人員寫的；
軟體設計說明書：碼農自己寫的，為了測試、維護等等，看的人就不多了。