關于功能詳細設計的討論
1令狐沖問：我感覺自己找不到太準確的衡量標準，我寫到什么程度算深淺適中，我不知道如何下手，好像有些東西不在寫代碼之前想不出來，有現成的模板嗎？
風清揚答：我們也想找個模板，可是網上的都是站著不腰疼，都是什么CMM，ISO9000
寫個故事，比如你去客戶那調查完了，你模擬一下客戶的工作過程，然后寫下來，不就成了？
不過可不要寫成客戶以后怎么使用你的軟件的過程，比如按一個按鈕然后….。寫成流水帳也沒關系，你看看你會有什么感覺。往往是正式做而真不知道該怎么做了，在自己閑暇時卻偏偏做好了，你說怪不怪？
然后交給其他同事閱讀，看他是否理解，把他的想法再填加到你的文檔中，你的文檔才會一點一點完善和趨于合理，羅馬不是一天建成的，想集中一段時間搞一個完善的東西是不可能的，事物是迭代進步的。
把事情你覺得說清楚了，別人看了也覺得清楚了，并且可以按照你的思路復述一遍，這就可以了。
如果還是不太明確你想做的事，搭一個小程序，按你的現有描述實現一個簡單的例子，在過程中想想有哪些你寫的代碼卻沒有描述，或者代碼與你的描述兩張皮，然后再試著修改文檔。
如果還是不清楚，如果你做過代碼維護工作，你想你在維護別人的代碼的時候最需要看到什么，這樣你就會知道你寫些什么
在寫文檔時沒必要我們想破腦子把所有的情況都想到都寫下來，那不可能，我們大家都憎恨這種不現實的東西。設計時描述不清楚的就不要描述，咱們干嗎非要固定不可能固定的東西呢？
但是有沒有一種方法，什么是可以描述清楚的，什么是不可描述清楚的呢？
2令狐沖問：為什么要寫呀，未來變化多端，你非要固定下來按這樣去做，這是軟件工程早就證明了的一種死辦法，我們應該寫了客戶有什么問題，我們怎么解決的記錄下來，具體怎么實現，就由程序員決定，開發完了再寫詳細設計文檔，這樣的文檔才是真正的設計文檔。
風清揚答：》開發文檔就是把你的開發過程包括你的開發思想和各種問題的解決方法都記錄下來，
這是我們的需求分析文檔
》只是告訴要實現什么功能，
這是我們的功能概要描述呀
》程序員就記錄在開發文檔里面
這是我們的功能詳細描述和數據流詳細描述
》但以前我都是先寫程序再寫開發文檔，程序沒出來以前只有一份設計文檔
先寫程序再寫開發文檔，是為了以后人員的維護，來理解現在這個軟件是怎么回事。我們的這個詳細設計文檔也就是說清楚每個功能的大致流程，流程中涉及到的一些異常業務，業務中的術語，讓我們在編碼前好知道我們做出來的這個東西大致是什么樣，而不是我們就試著寫吧，遇到問題再說。那樣就不是商業的軟件開發。商業的軟件開發必須對進度，風險，成本有相當的預測。當然我們寫完詳細設計文檔也不是什么問題都沒了，我們也會在遇到問題時商討，但至少我們對我們要干的事的輕重緩急有一個大致的預測。
我們寫的也不是培訓文檔。培訓文檔是對照一個軟件，有什么DBGRID，有什么下拉框，先點什么按鈕。如果你的詳細設計文檔寫成了這樣，就出了問題。不是詳細設計的大思路錯了，就是你的功能概要設計劃分的太細了
3令狐沖問：那我們該寫些什么文檔，我們可忙著呢，別費了好大勁，寫出來也沒人看，沒人檢查，格式也不知道，各有各的寫法，最后不了了之。
風清揚答：我們不是為了文檔漂亮，給客戶看，給老板看，那樣是出不來好產品的，我們的文檔給我們是給我們在編碼期自己看的，看你對業務的了解是否用文字可以描寫清楚，如果能用文字描述清楚，你們寫代碼我們也就不擔心了。
就是怕：我們不知道你們理解不理解，你們自己也不知道是不是理解了，于是大家就開始瞎做吧，做到哪算哪，好壞也不是我一個人的錯。如果造成那樣的后果，我們現在所做也就沒有什么意義了
反正就是不要讓我們在做每一個工程時都思考我該怎么寫，以告戒其他同志正確的思考方向，不要重復思考別人思考過的問題；并且整理出一份你希望的詳細功能描述文檔的格式，以有個草案讓我們逐步改進它使它合理
所以我們準備寫這幾個文檔：
需求文檔
模塊進度文檔 為了估計最后的出品日期和每個模塊的工作量
功能概要文檔 為了在編碼期制定每周工作計劃，編制每個功能的詳細設計和數據流設計
表結構文檔
|
|
資源大小：9.99 KB 
