文件貫穿軟體工程的始終，從前期的專案準備，中期的開發到後期的維護、培訓，無不以文件作為工作的依據。那麼在軟體專案中，都包括哪些文件呢，它們的作用又是什麼呢?

《可行性研究報告》：這是客戶在進行專案調研階段所編寫的，具有兩重意義，其一，指明專案的必要性和緊迫性，並從業務角度闡述大概的功能需求，注 意，只是大概，可能與最後的結果有很大出入；其二，最重要的一點就是為了要錢，向財政部要錢，將最終實現的功能寫得天花亂墜，包括決策支援、全文檢索、商 業智慧、遠端報表等，但最後開發的可能僅僅是融合簡單業務流程的資訊輸入和輸出而已，但這已無關緊要，最重要的是我要到了錢。但是嚴格來說，這不是專案組 所需的文件，於軟體開發也意義不大。

《建設方案》：或者是《實施方案》，當客戶從財政部申請到資金後，就要著手進行詳細的調研和分析了，這裡有兩種情況，其一，客戶自己從各個產品廠家 進行相關的調研，進行彙總後，編寫方案，這樣，聰明、細心的軟體公司就會從方案的技術環節，挖掘出客戶所選擇的產品，最後和這個產品公司合作來中標；其 二，讓和其關係很好的一家或兩家軟體公司（不會超過三家）編寫，客戶進行稽核，客戶最後選擇了誰的方案那麼最後這個專案就是這家公司的，這樣很多情況並不 是公開招標。

《招標書》：將《建設方案》或《實施方案》進行摘取，並附帶上技術問題以及招標時的細節、注意事項，構成《招標書》，這個檔案也是由客戶寫得，軟體公司在投標前需要購買《招標書》。

《投標書》：與《招標書》所呼應，對技術問題進行相應的技術應答，包括技術標和商務標兩部分。

上面幾份文件，是專案前期準備時需要的，是側重於售前方面的；而下面的文件是軟體開發過程中必不可少的，我們按開發工作的時間順序一一介紹。

《需求分析說明書》：對於軟體開發來說，《需求分析說明書》就好像是蓋樓時所用的圖紙，是最重要的文件，由專案經理對客戶相關部門進行業務調研後編 寫，語言側重於從業務的角度描述功能需求。內容涉及三大部分，其一，編寫目的、背景、目標任務等公共性語言；其二，功能性需求，將業務梳理成幾大功能模 塊，一級功能下細分二級功能，依次類推，將最終細化的功能按描述、輸入、處理和輸出進行詳細描述；其三，非功能性需求，包括效能、處理能力、進度、介面設 計和執行環境的規定。

《資料庫設計說明書》：我是做資料庫出身，因此這部分的工作也是由我這個專案經理來做，根據《需求分析說明書》在Erwin建模工具中設計好邏輯模型和物理模型，然後將其整理到此文件中，文件還包含資料庫所有的表結構和相關的欄位說明。

《概要設計說明書》：說實話，在我做過的專案中，沒有編寫過此文件，因為我覺得《需求分析說明書》和《詳細設計說明書》就足矣了。甚至如果專案簡單或時間緊急，《詳細設計說明書》都會省略：）。

《詳細設計說明書》：主要包含兩部分內容，其一，體系結構的設計，也就是專案所採用的幾層架構，以及層與層之間的通訊機制，還有就是基礎框架所採用 的技術；其二，是本文件的核心部分，包括每個細分模組的詳細設計說明，包括程式描述、功能、效能、輸入項、輸出項、演算法、流程邏輯、介面、儲存分配、註釋 設計、限制條件、測試計劃和尚未解決的問題等內容。本說明書對專案所採用的技術和介面都做了詳細的規定，是指導程式設計師開發的直接工具。但需要說明的是，很 多專案由於時間原因，都忽略了此說明書的編寫，包括本人目前在做的專案也是如此，因此本文件並不是必須的。但如果作為給客戶的交付物，需要在專案完成後補 全。

《計劃進度》：這個不用多說，由專案經理編寫，實現對專案進度的嚴格把控，是專案必須的文件，可用project編寫。

《測試用例》：測試用例（Test Case）目前沒有經典的定義。比較通常的說法是：指對一項特定的軟體產品進行測試任務的描述，體現測試方案、方法、技術和策略。內容包括測試目標、測試 環境、輸入資料、測試步驟、預期結果、測試指令碼等，並形成文件。它是將軟體測試的行為活動做一個科學化的組織歸納．目的是能夠將軟體測試的行為轉化成可管 理的模式；同時測試用例也是將測試具體量化的方法之一。由此可見，《測試用例》非常重要，是對專案或產品質量的嚴格保證，但由於測試人員和專案組的規範 性、時間進度等限制，本文件在本地區的實際專案中也很少應用，至少我認識的很多測試人員中，只有極少數的專案中會編寫此文件。

《測試結果》：在專案開發階段使用，也就是交付客戶之前。文件為Excel格式，並提供關鍵欄位的資料篩選，內容包括描述、缺陷型別（Bug、需 求）、開發人員、狀態、關閉時間、所屬模組、提交人、解決人、備註等。其中狀態包含提交、解決和確認解決，測試人員將問題提交（紅色），當程式設計師解決後就 置為解決（黃色），測試人員再次確認無誤後，就修改狀態為確認解決（綠色），並且添寫關閉時間。

《需求變更文件》：產品交付客戶之後使用。任何一個好軟體，不是在第一個版本就把這些標準全部實現，而是有步驟有重點地實現，逐步成為一個好軟體。 因此《需求變更文件》是不必可少的，同樣作個Excel表格，量化解決。包括下列幾項：客戶名稱、需求提出人、提出日期、需求關閉時間，功能模組名，客戶 現在版本號，需求描述，需求分類（需求、Bug）等。每次釋出新版本都把從上一版本釋出之日關閉的需求列表都單獨摘成一個檔案，附帶到這次新發布的版本之 後。

此舉有兩個好處，其一，能夠清楚的列出客戶以往所提的需求，因為有一些客戶提出的改動總是反反覆覆，一個問題一會要改成A,然後覺得不好要改成B， 之後覺得還不如A好，便又要求改回去，這樣給公司的進度和安排帶來很大的不便，如果因為這個耽誤了其他的工作，便可以有此根據和客戶進行溝通，防止客戶賴 賬；其二，可以評判技術支援和相關程式設計師的工作量。此文件為EXCEL格式，但最好還有一個word型別的文件，每次客戶提出修改意見時，將此文件打印出 來交由客戶簽字，作為憑證，此方法實際中並不是次次可行，一些強權客戶或不敢承擔責任的就不簽字，那也沒轍。

《測試結果》和《需求變更文件》要定期（可一週或一個月）給老闆一份。這表明了你的工作量，讓他看看你確實一直很辛苦地在工作，另外，也能看出你的認真負責態度。

《使用者使用手冊》：按標準說，應該由文案寫，但在大多數的軟體公司中都不設這個職位，因此要麼由專案經理寫要麼由測試人員寫，關鍵看是誰給客戶做培 訓。在目前我做的這個專案中，並沒有專職測試，所以這個工作還是專案經理來做。《使用者使用手冊》可根據實際情況寫成三種版本，其一，chm型別檔案，適用 於C/S的專案，就像微軟的產品中，都會有此幫助手冊；其二，做成網頁形式的幫助檔案，適用於B/S專案；其三，就是做成word文件，雖然可儲存至本 地，但使用起來沒有前二者方便。

餘者還有《開發任務書》、《專案總結報告》、《軟體驗收評審》等，並不是必須的，可根據客戶需要和實際的專案來選擇使用，再次並不一一贅述。

並且，以上所有文件，雖然有些是必須的，比如《需求分析說明書》、《測試結果》、《使用者使用手冊》等，但根據不同的行業、不同的地區以及不同的專案 和團隊規模，文件的具體內容都會有所不同，不必較真。只要能抓到老鼠，白貓黑貓都是好貓，況且，沒必要的多餘的文件會浪費時間和成本等資源。