軟體開發中文件的編寫是乙個不可缺少的環節，常見的如《需求分析》、《概要分析》、《資料庫設計》等。在「軟體人」的陣營裡向來存在兩種觀點，注重文件還是關心**。一直爭論多少年了，好像都沒有乙個真正的定亂。如果大專案且開發周期相對合理，很多時候專案組一定會安排進行相關開發文件的編寫；但對於周期短工作量又多的時候，可能很多專案組就會選擇**編寫為第一的原則，相應的文件編寫很多時候被安排在專案演示甚至交付後才進行補救式的操作，而且這樣的文件很多都是歸於應付客戶要求的形式罷了。
專案週期與質量保證向來是相矛盾的，如果為了保證質量消耗時間去編寫文件，必將壓縮系統開發的時間；不進行開發文件的編寫，又沒法進行開發質量的保證。那問題就來了，開發文件是否需要編寫？怎麼寫？誰來寫？
首先，我們來討論下開發文件編寫的必要性，即要不要編寫開發文件；這些開發文件是否就一定能在開發中指導我們的程式設計師編寫**；在運維中支撐維護人員解決問題等。
「高樓萬丈平地起」，這裡告訴我們，一座高樓是否可以建？怎麼建？建多高？最終由地基來決定。沒有地基的牢固支撐，你建的樓就會變成「低樓」、「危樓」、「爛尾樓」。高樓需要地基的存在，需要地基的支撐，沒有這兩樣又想要高樓，那只有去找「空中樓閣」了。那這個地基的牢固與否又是靠什麼東西決定呢？「設計圖紙」，對就是設計圖紙，沒有圖紙上專業化的設計和演算規劃，建立牢固的地基那就是天方夜譚、痴人說夢。
回到我們的軟體專案中來，乙個專案的成功同樣需要乙個牢靠的地基，有了這個地基才能裝載那些各付其職的功能模組。這個地基就是我們軟體的《架構設計》和《概要設計》，沒有架構的設計就不能確保整個系統穩定的執行與統一處理方式等；沒有概要設計，客戶怎麼知道當前需要能完成那些功能，程式設計師又如何得知自己編寫的功能模組針對的業務處理流程，當然更不可能保證資料邏輯處理的正確性、完整性。不用再討論下去了吧，光這兩個問題，就能足以說明文件編寫的重要性了。
看到這裡你可能會裡面跳出來駁斥我的謬論，理直氣壯般告訴我，我們的專案沒有《架構設計》和《概要設計》也做的很好啊。我們是沒有《架構設計》，因為我們壓根兒就不需要它，我們的架構已經是多年成型的東西，很完美，進行了不同層次的封裝，提供了豐富多樣的擴充套件介面。有了這樣成熟的系統架構而且是已經實現的東西，為什麼我們還需要《架構設計》，莫名其妙。我相信你說的這些，你們的架構很完美，相當健壯，可擴充套件性又豐富，我承認這些都是好框架必須具備的，你們的框架也是好框架。但我能否問下，你們的這個完美是如何誕生的？如果是公司內部自行研發的，那敢肯定一定存在設計文件；如果是某個牛人自己磨練出來的，那就有點擔心了，萬一這個牛人走了如何是好？難道你們告訴客戶，我們的架構有問題，不做這個專案了？誇張！！！我又問，你們的這個完美是否存在缺陷？如果你說不存在，那我只能伸手擺個pose，鄙視你的年幼無知，如果你說存在但是不知道，那我只能送你兩個字——「杯具」；我最後問，你們的這個完美是否可以相容所有的企業運用？是否能支援j2ee、j2me、j2se的解決方案？要是你告訴我說僅支援j2ee，因為我們只作j2ee的專案。你是老闆嗎？說這樣的要負責任的，不然被老闆聽見，小心砸你飯碗。
說完文件編寫的必要性，那就來說說如何寫的問題。其實很多時候乙個成熟的軟體公司或專案組都會有一套成型的文件模板，當然這些模板很多可能是從化為、東軟等大型軟體公司變種出來的。有了這些定型的模板，那編寫文件的工作就會輕鬆很多，我們需要做的就是在相應的模板中填充自己的相關描述，即可形成針對當前專案的開發文件。
還是舉例說下吧，看上面的文字多少有點空泛，我這裡寫乙個《使用者資訊模組的概要設計文件》，只列舉主要內容了(僅供參考)。
1 功能描述：用於完成系統使用者資訊的新增、刪除、修改、查詢；
2 功能用例：乙個主用例使用者資訊，附加新增、刪除、修改、查詢4個子用例，操作人員為管理員，圖形就不畫了，很簡單的；
3 業務流程：查詢有效範圍使用者資訊——》新增使用者資訊——》判斷當前帳號是否存在——》存在給出提示，反之儲存成功提示。（簡單的說下，圖形就不畫了）
4 約束限制：
超級管理員可操作所有（包含刪除，我這裡考慮僅是邏輯刪除、非物理刪除）的使用者資訊；
系統管理員可操作除系統管理員、超級管理員外的全部使用者資訊；
單位管理員可操作本單位使用者資訊；
使用者帳號資訊系統內全域性唯一；
5 系統效能：
要求同時支援500個併發操作；
頁面操作響應時間小於1s；
頁面大小小於1kb；
當前使用者所屬員工資訊不存在時，可直接進行員工資訊的新增，並完成使用者資訊的同步儲存，確保事務的完整性；
6 執行環境：依賴系統整體執行環境為準（存在特殊需要註明）；
7 操作實體：使用者資訊、員工資訊、系統日誌等（我不知道，大夥在除概要設計時候是否已完成資料庫/實體設計了。）；
9 外部介面：輸入——使用者id，輸出——使用者資訊；
11 注意事項：使用者帳號不能為空，不能存在空格，不能超過6位；超級使用者資訊僅在系統初始化中完成其資訊寫入操作，其他使用者無權對其進行修改；
羅列幾個文件的要素，這些我覺得是你的模板一定需要定義的：
1 變更版本記錄、參考文獻、編寫人員、審核人員等；
2 製作背景、使用範圍、文件作用；
3 文件結構描述、綱要描述、目錄描述；
4 輔助編寫工具（如viso/rose等建模工具都可以畫用例圖，但只能選擇一種）、文件格式（word、 pdf還是其他）統一。
專案組中也不是所有人都必須參與文件的編寫，通常業務需求人員、設計人員、架構師、專案經理、小組長佔大多數，而且這些人中很多也不是專注於寫**的角色。這就是專案組內部分工協作的事情了，畢竟最大限度地發揮專案組各成員的綜合能力才是最主要的，「各司其職，各負其責」方是上策。
因為我這裡說的僅是開發文件，所以像《使用者手冊》、《培訓計畫》、《驗收計畫》、《安裝步驟》等就沒羅列了。不是說它們不重要，只因為它們不屬於開發文件的範疇罷了。實際開發中，需要完成什麼樣的文件完全取決於當前專案的開發、實施背景和使用者需求，有些文件本就是做給客戶驗收的。（我曾經做乙個電子政務系統，甲方請了監理公司在實施過程中參與，結果搞得各式各樣的文件都需要完成，儘管其中很多都是些形式東西，但沒法子，客戶就是上帝。）對於客戶要求這型別的文件我們不一定要做細、做專，做體面才是最有效的。反之，對於專案開發中特別是**編寫的指導文件，就必須要求編寫得簡單明瞭，面面俱到。
專案開發文件編寫規範
在開發專案的過程中，我深刻的意識到，文件存在的意義並不是無用的報告，簡潔明瞭的文件不光能記錄你當下所做的，還能在繁重的工作中分神思考下一步該做什麼時為你節約精力，並且在專案週期內，使整個專案保持一致性。所以，軟體開發文件的編寫是很有必要的。我參考網上的資料，結合自己專案開發時的心得，分享一些經驗。在...
專案開發文件編寫規範 附文件模板
在開發專案的過程中，我深刻的意識到，文件存在的意義並不是無用的報告，簡潔明瞭的文件不光能記錄你當下所做的，還能在繁重的工作中分神思考下一步該做什麼時為你節約精力，並且在專案週期內，使整個專案保持一致性。所以，軟體開發文件的編寫是很有必要的。我參考網上的資料，結合自己專案開發時的心得，分享一些經驗。在...
專案評審文件的編寫
個人所得稅計算需求 tax srs 001 輸入 引數1 稅率列舉型別，取值範圍 5 10 15 引數2 個人收入，1600 100000000000 處理過程 全月應納稅所得額 稅率 1600 2500元的部分 5 2500 3500元的部分 10 3500 100000000000元的部分 15...