說明？ 好，玩，啊 pj1239.c??n 最難能可貴的就是這兒合法經(jīng)營(yíng)，并不坑人錢。

一般來說，詳細(xì)設(shè)計(jì)是在需求定下來之后，代碼開發(fā)之前。從順序也能看出來，是承上（需求）啟下（開發(fā)）的一步。簡(jiǎn)單來說，目標(biāo)就是：根據(jù)需求，把代碼開發(fā)階段需要的東西，全部想好。比如：需求是做一個(gè)新浪博客需要定義web站點(diǎn)的域名是形式，怎么解析，有哪些頁面，每個(gè)頁面的訪問方式（post、get）、數(shù)據(jù)如何緩存，這么大的訪問量怎么滿足？系統(tǒng)分幾層？每層做什么？用什么數(shù)據(jù)庫？用戶軌跡記錄在哪里？系統(tǒng)主要的類怎么交互，數(shù)據(jù)庫結(jié)構(gòu)（ER圖）等等可以參考下網(wǎng)上的詳設(shè)模板，就知道需要定義哪些東西，但是很多情況下，會(huì)根據(jù)實(shí)際情況增加、減少內(nèi)容。你說的任務(wù)我沒太明白，我認(rèn)為只要詳設(shè)的產(chǎn)物拿給開發(fā)人員，他能明白怎么寫代碼就算任務(wù)完成了，并沒有特定的標(biāo)準(zhǔn)。如果一定要標(biāo)準(zhǔn)，還是參考模板吧。以上是我的個(gè)人見解，供參考

現(xiàn)在公司是CMMI4認(rèn)證的，最近我項(xiàng)目組在開始新產(chǎn)品，我負(fù)責(zé)了大部分文檔編寫。。人員流動(dòng)是項(xiàng)目進(jìn)行中比較讓人頭疼的事情。做好規(guī)范文檔，可以讓代碼看起來比較像出自同一人之手。要做java開發(fā)文檔得做不少功夫，有需求規(guī)格說明書、詳細(xì)設(shè)計(jì)說明書、軟件功能規(guī)格說明書、數(shù)據(jù)庫設(shè)計(jì)說明書、編碼規(guī)范等。比較重要的是 軟件功能描述、數(shù)據(jù)庫設(shè)計(jì)、編碼規(guī)范，這樣，及時(shí)有人員流動(dòng)的話，新人看了文檔，也能比較快的了解功能需求、數(shù)據(jù)庫設(shè)計(jì)、編碼規(guī)范，更快的上手項(xiàng)目。先看看你需要什么文檔，然后去文庫里搜索，就有相應(yīng)的模板，找個(gè)適合自己項(xiàng)目的模板

面向?qū)ο筌浖O(shè)計(jì)說明書模板 1 概述 1.1 系統(tǒng)簡(jiǎn)述 對(duì)系統(tǒng)要完成什么，所面向的用戶以及系統(tǒng)運(yùn)行的環(huán)境的簡(jiǎn)短描述，這部分主要來源于需求說明書的開始部分。 1.2 軟件設(shè)計(jì)目標(biāo) 這部分論述整個(gè)系統(tǒng)的設(shè)計(jì)目標(biāo)，明確地說明哪些功能是系統(tǒng)決定實(shí)現(xiàn)而哪些時(shí)不準(zhǔn)備實(shí)現(xiàn)的。同時(shí)，對(duì)于非功能性的需求例如性能、可用性等，亦需提及。需求規(guī)格說明書對(duì)于這部分的內(nèi)容來說是很重要的參考，看看其中明確了的功能性以及非功能性的需求。 這部分必須說清楚設(shè)計(jì)的全貌如何，務(wù)必使讀者看后知道將實(shí)現(xiàn)的系統(tǒng)有什么特點(diǎn)和功能。在隨后的文檔部分，將解釋設(shè)計(jì)是怎么來實(shí)現(xiàn)這些的。 1.3 參考資料 列出本文檔中所引用的參考資料。（至少要引用需求規(guī)格說明書） 1.4 修訂版本記錄 列出本文檔修改的歷史紀(jì)錄。必須指明修改的內(nèi)容、日期以及修改人。 2 術(shù)語表 對(duì)本文檔中所使用的各種術(shù)語進(jìn)行說明。如果一些術(shù)語在需求規(guī)格說明書中已經(jīng)說明過了，此處不用再重復(fù)，可以指引讀者參考需求說明。 3 用例 此處要求系統(tǒng)用用例圖表述（UML），對(duì)每個(gè)用例（正常處理的情況）要有中文敘述。 4 設(shè)計(jì)概述 4.1 簡(jiǎn)述 這部分要求突出整個(gè)設(shè)計(jì)所采用的方法（是面向?qū)ο笤O(shè)計(jì)還是結(jié)構(gòu)化設(shè)計(jì)）、系統(tǒng)的體系結(jié)構(gòu)（例如客戶/服務(wù)器結(jié)構(gòu)）以及使用到的相應(yīng)技術(shù)和工具（例如OMT、Rose） 4.2 系統(tǒng)結(jié)構(gòu)設(shè)計(jì) 這部分要求提供高層系統(tǒng)結(jié)構(gòu)的描述，使用方框圖來顯示主要的組件及組件間的交互。最好是把邏輯結(jié)構(gòu)同物理結(jié)構(gòu)分離，對(duì)前者進(jìn)行描述。別忘了說明圖中用到的俗語和符號(hào)。 4.2.1 頂層系統(tǒng)結(jié)構(gòu) 4.2.2 子系統(tǒng)1結(jié)構(gòu) 4.2.3 子系統(tǒng)2結(jié)構(gòu) 4.3 系統(tǒng)界面 各種提供給用戶的界面以及外部系統(tǒng)在此處要予以說明。如果在需求規(guī)格說明書中已經(jīng)對(duì)用戶界面有了敘述，此處不用再重復(fù)，可以指引讀者參考需求說明。如果系統(tǒng)提供了對(duì)其它系統(tǒng)的接口，比如說從其它軟件系統(tǒng)導(dǎo)入/導(dǎo)出數(shù)據(jù)，必須在此說明。 4.4 約束和假定 描述系統(tǒng)設(shè)計(jì)中最主要的約束，這些是由客戶強(qiáng)制要求并在需求說明書寫明的。說明系統(tǒng)是如何來適應(yīng)這些約束的。 另外如果本系統(tǒng)跟其它外部系統(tǒng)交互或者依賴其它外部系統(tǒng)提供一些功能輔助，那么系統(tǒng)可能還受到其它的約束。這種情況下，要求清楚地描述與本系統(tǒng)有交互的軟件類型（比如某某某數(shù)據(jù)庫軟件，某某某EMail軟件）以及這樣導(dǎo)致的約束（比如只允許純文本的Email）。 實(shí)現(xiàn)的語言和平臺(tái)也會(huì)對(duì)系統(tǒng)有約束，同樣在此予以說明。 對(duì)于因選擇具體的設(shè)計(jì)實(shí)現(xiàn)而導(dǎo)致對(duì)系統(tǒng)的約束，簡(jiǎn)要地描述你的想法思路，經(jīng)過怎么樣的權(quán)衡，為什么要采取這樣的設(shè)計(jì)等等。 5 對(duì)象模型 5.1 系統(tǒng)對(duì)象模型 提供整個(gè)系統(tǒng)的對(duì)象模型，如果模型過大，按照可行的標(biāo)準(zhǔn)把它劃分成小塊，例如可以把客戶端和服務(wù)器端的對(duì)象模型分開成兩個(gè)圖表述。 對(duì)象圖應(yīng)該包含什么呢？ 在其中應(yīng)該包含所有的系統(tǒng)對(duì)象。這些對(duì)象都是從理解需求后得到的。要明確哪些應(yīng)該、哪些不應(yīng)該被放進(jìn)圖中。 所有對(duì)象之間的關(guān)聯(lián)必須被確定并且必須指明聯(lián)系的基數(shù)（一對(duì)一、一對(duì)多還是多對(duì)多，0..1，*，1..*）。聚合和繼承關(guān)系必須清楚地確定下來。每個(gè)圖必須附有簡(jiǎn)單的說明。 可能經(jīng)過多次反復(fù)之后才能得到系統(tǒng)的正確的對(duì)象模型。 6 對(duì)象描述 在這個(gè)部分?jǐn)⑹雒總€(gè)對(duì)象的細(xì)節(jié)，它的屬性、它的方法。在這之前必須從邏輯上對(duì)對(duì)象進(jìn)行組織。你可能需要用結(jié)構(gòu)圖把對(duì)象按子系統(tǒng)劃分好。 為每個(gè)對(duì)象做一個(gè)條目。在系統(tǒng)對(duì)象模型中簡(jiǎn)要的描述它的用途、約束（如只能有一個(gè)實(shí)例），列出它的屬性和方法。如果對(duì)象是存儲(chǔ)在持久的數(shù)據(jù)容器中，標(biāo)明它是持久對(duì)象，否則說明它是個(gè)臨時(shí)對(duì)象（transient object）。 對(duì)每個(gè)對(duì)象的每個(gè)屬性詳細(xì)說明：名字、類型，如果屬性不是很直觀或者有約束（例如，每個(gè)對(duì)象的該屬性必須有一個(gè)唯一的值或者值域是有限正整數(shù)等）。 對(duì)每個(gè)對(duì)象的每個(gè)方法詳細(xì)說明：方法名，返回類型，返回值，參數(shù)，用途以及使用的算法的簡(jiǎn)要說明（如果不是特別簡(jiǎn)單的話）。如果對(duì)變量或者返回值由什么假定的話，Pre-conditions和Post-conditions必須在此說明。列出它或者被它調(diào)用的方法需要訪問或者修改的屬性。最后，提供可以驗(yàn)證實(shí)現(xiàn)方法的測(cè)試案例。 6.1 子系統(tǒng)1中的對(duì)象 6.1.1 對(duì)象：對(duì)象1 用途： 約束： 持久性： 6.1.1.1 屬性描述： 1. 屬性：屬性1 類型： 描述： 約束： 2. 屬性：屬性2 6.1.1.2 方法描述： 1. 方法：方法1 返回類型： 參數(shù)： 返回值： Pre-Condition： Post-Condition： 讀取/修改的屬性： 調(diào)用的方法： 處理邏輯： 測(cè)試?yán)河檬裁磪?shù)調(diào)用該方法，期望的輸出是什么…… 7 動(dòng)態(tài)模型 這部分的作用是描述系統(tǒng)如何響應(yīng)各種事件。例如，可以建立系統(tǒng)的行為模型。一般使用順序圖和狀態(tài)圖。 確定不同的場(chǎng)景（Scenario）是第一步，不需要確定所有可能的場(chǎng)景，但是必須至少要覆蓋典型的系統(tǒng)用例。不要自己去想當(dāng)然地創(chuàng)造場(chǎng)景，通常的策略是描述那些客戶可以感受得到的場(chǎng)景。 7.1 場(chǎng)景（Scenarios） 對(duì)每個(gè)場(chǎng)景做一則條目，包括以下內(nèi)容： 場(chǎng)景名：給它一個(gè)可以望文生義的名字 場(chǎng)景描述：簡(jiǎn)要敘述場(chǎng)景是干什么的以及發(fā)生的動(dòng)作的順序。 順序圖：描述各種事件及事件發(fā)生的相對(duì)時(shí)間順序。 7.1.1 場(chǎng)景：場(chǎng)景1 描述： 動(dòng)作1 動(dòng)作2 7.2 狀態(tài)圖 這部分的內(nèi)容包括系統(tǒng)動(dòng)態(tài)模型重要的部分的狀態(tài)圖?？赡苣阆霝槊總€(gè)對(duì)象畫一個(gè)狀態(tài)圖，但事實(shí)上會(huì)導(dǎo)致太多不期望的細(xì)節(jié)信息，只需要確定系統(tǒng)中一些重要的對(duì)象并為之提供狀態(tài)圖即可。 7.2.1 狀態(tài)圖1： 8 非功能性需求 在這個(gè)部分，必須說明如何處理需求文檔中指定的非功能性需求。盡可能客觀地評(píng)估系統(tǒng)應(yīng)付每一個(gè)非功能性的需求的能力程度。如果某些非功能性需求沒有完全在設(shè)計(jì)的系統(tǒng)中實(shí)現(xiàn)，請(qǐng)務(wù)必在此說明。另外，你也需要對(duì)系統(tǒng)將來的進(jìn)化作一個(gè)估計(jì)并描述本設(shè)計(jì)如何使系統(tǒng)能夠適應(yīng)這些可預(yù)見的變化。 9 輔助文檔 提供能幫助理解設(shè)計(jì)的相應(yīng)文檔。 10 詞匯索引 文章錄入

需求規(guī)格說明書：主要從用戶角度（需求或市場(chǎng)人員根據(jù)用戶要求編寫）描述軟件需要實(shí)現(xiàn)的功能，各個(gè)功能模塊，各個(gè)功能模塊的重要性，以及業(yè)務(wù)流程等。系統(tǒng)設(shè)計(jì)說明書：主要從軟件開發(fā)（程序員）角度描述軟件需要實(shí)現(xiàn)功能，如何劃分這些功能模塊，各個(gè)功能模塊的關(guān)系，軟件的業(yè)務(wù)流程等。總結(jié)：內(nèi)容基本都一樣！只是表現(xiàn)形式不一樣！閱讀對(duì)象不一樣！