1、.軟件開發文檔標準一、計算機軟件產品開發文件編制指南1二、可行性研究報告5三、項目開發計劃9四、軟件需求說明書11五、數據要求說明書13六、概要設計說明書14七、詳細設計說明書16八、數據庫設計說明書17九、用戶手冊18十、操作手冊21十一、模塊開發卷宗23十二、測試計劃23十三、測試分析報告25十四、開發進度月報26十五、項目開發總結報告27一、計算機軟件產品開發文件編制指南1目的一項計算機軟件的籌劃、研制及實現，構成一個軟件開發項目。一個軟件開發項目的進行，一般需要 在人力和自動化資源等方面作重大的投資。為了保證項目開發的成功，最經濟地花費這些投資，并且便 于運行和維護，在開發工作的每一階

2、段，都需要編制二定的文件。這些文件連同計算機程序及數據一起， 構成為計算機軟件。文件是計算機軟件中不可缺少的組成部分，它的作用是：a.作為開發人員在一定階段內的工作成果和結束標志；b.向管理人員提供軟件開發過程中的進展和情況，把軟件開發過程中的一些“不可見的”事物轉換成“可見”的文字資料，以便管理人員在各個階段檢查開發計劃的實施進展，使之能夠判斷原定目標是否已達到，還將繼續耗用資源的種類和數量；c.記錄開發過程中的技術信息，便于協調以后的軟件開發、使用和修改；d.提供對軟件的有關運行、維護和培訓的信息，便于管理人員、開發人員、操作人員和用戶之間相互了解彼此的工作；e.向潛在用戶報導軟件的功能和

3、性能，使他們能判定該軟件能否服務于自己的需要。換言之，本指南認為：文件的編制必須適應計算機軟件整個生存周期的需要。計算機軟件所包含的文件有兩類：一類是開發過程中填寫的各種圖表，可稱之為工作表格；另一類 則是應編制的技術資料或技術管理資料，可稱之為文件。本指南規定軟件文件的編制形式，并提供對這 些規定的解釋。本指南的目的是使得所編制的軟件文件確實能夠起到軟件文件應該發揮的作用。2范圍本指南是一份指導性文件。本指南建議，在一項計算機軟件的開發過程中，一般地說，應該產生十四種文件。這十四種文件是：可行性研究報告；項目開發計劃；軟件需求說明書；數據要求說明書；概要設計說明書；詳細設計說明書；數據庫設計

4、說明書；用戶手冊；操作手冊；模塊開發卷宗；測試計劃；測試分析報告；開發進度月報；本指南將給出開發過程中建議產生的這十四種文件的編制指導，同時，本指南也是這十四種文件的編寫質量的檢驗準則。但是，本指南并未涉及軟件開發過程中如何填寫工作表格的問題。一般地說，一個軟件總是一個計算機系統（包括硬件、固件和軟件）的組成部分。鑒于計算機系統的多樣性，本指南一般不涉及整個系統開發中的文件編制問題，本指南僅僅是軟件開發過程中的文件編制指南。3文件的使用者對于使用文件的人員而言，他們所關心的文件的種類，隨他們所承擔的工作而異。管理人員：可行性研究報告，項目開發計劃，模塊開發卷宗，開發進度月報，項目開發總結報告；

5、開發人員：可行性研究報告，項目開發計劃，軟件需求說明書，數據要求說明書， 概要設計說明書，詳細設計說明書，數據庫設計說明書，測試計劃，測試分析報告；維護人員：設計說明書，測試分析報告，模塊開發卷宗；用戶：用戶手冊， 操作手冊。盡管本指南提出了在軟件開發中文件編制的要求，但并不意味著這些文件都必須交給用戶。一項軟件的用戶應該得到的文件的種類由供應者與用戶之間簽訂的合同規定。4軟件生存周期與各種文件的編制一項計算機軟件，從出現一個構思之日起，經過這項軟件開發成功投入使用，直到最后決定停止使 用，并被另一一項軟件代替之時止，被認為是該軟件的一個生存周期。一般地說這個軟件生存周期可以分成以下六個階段：

6、可行性與計算機研究階段需求分析階段設計階段實現階段測試階段運行與維護階段在可行性研究與計劃階段內，要確定該軟件的開發目標和總的要求，要進行可行性分析、投資一收益分析、制訂開發計劃，并完成應編制的文件。在需求分析階段內，由系統分析人員對被設計的系統進行系統分析，確定對該軟件的各項功能、性能需求和設計約束，確定對文件編制的要求，作為本階段工作的結果，一般地說，軟件需求說明書、數據要求說明書和初步的用戶手冊應該編寫出來。在設計階段內，系統設計人員和程序設計人員應該在反復理解軟件需求的基礎上，提出多個設計，分析每個設計能履行的功能并進行相互比較，最后確定一個設計，包括該軟件的結構、模塊的劃分、功能的分

7、配以及處理流程。在被設計系統比較復雜的情況下，設計階段應分解成概要設計階段和詳細設計階段兩個步驟。在一般情況下，應完成的文件包括：概要設計說明書、詳細設計說明書和測試計劃初稿。在實現階段內，要完成源程序的編碼、編譯（或匯編）和排錯調試得到無語法錯的程序清單，要開始編寫模塊開發卷宗，并且要完成用戶手冊、操作手冊等面向用戶的文件的編寫工作，還要完成測試計劃的編制。在測試階段，該程序將被全面地測試，已編制的文件將被檢查審閱。一般要完成模塊開發卷宗和測試分析報告，作為開發工作的結束，所生產的程序、文件以及開發工作本身將逐項被評價，最后寫出項目開發總結報告。在整個開發過程中（即前五個階段中），開發集體要

8、按月編寫開發進度月報。在運行和維護階段，軟件將在運行使用中不斷地被維護，根據新提出的需求進行必要而且可能的擴充和刪改。對于一項軟件而言，其生存周期各階段與各種文件編寫工作的關系可見表，其中有些文件的編寫工作可能要在若干個階段中延續進行。5文件編制中的考慮因素文件編制是一個不斷努力的工作過程。是一個從形成最初輪廓，經反復檢查和修改，直到程序和文件正式交付使用的完整過程。其中每一步都要求工作人員做出很大努力。要保證文件編制的質量，要體現每個開發項目的特點，也要注意不要花太多的人力。為此，編制中要考慮如下各項因素。5.1文件的讀者第一種文件都具有特定的讀者。這些讀者包括個人或小組、軟件開發單位的成員

9、或社會上的公眾、從事軟件工作的技術人員、管理人員或領導干部。他們期待著使用這些文件的內容來進行工作，例如設計、編寫程序、測試、使用、維護或進行計劃管理。因此，這些文件的作者必須了解自己的讀者，這些文件的編寫必須注意適應自己的特定讀者的水平、特點和要求。5.2重復性本指南第二篇中將列出的這十四種文件的內容要求中，顯然存在某些重復。較明顯的重復有兩類。引言是第一種文件都要包含的內容，以向讀者提供總的梗概。第二類明顯的重復是各種文件中的說明部分，如對功能性能的說明、對輸入和輸出的描述、系統中包含的設備等。這是為了方便每種文件各自的讀者，每種產品文件應該自成體系，盡量避免讀一種文件時又不得不去參考另一

10、種文件。當然，在每一種文件里，有關引言、說明等同其他文件相重復的部分，在行文上、在所用的術語上、在詳細的程度上，還是應該有一些差別，以適應各種文件的不同讀者的需要。5.3靈活性鑒于軟件開發是具有創造性的腦力勞動，也鑒于不同軟件在規模上和復雜程序上差別極大，本指南認為在文件編制工作中應允許一定的靈活性。這種靈活性表現在如下各款。5.3.1應編制的文件種類盡管本指南認為在一般情況下，一項軟件的開發過程中，應產生的文件有十四種，然而針對一項具體的軟件開發項目，有時不必編制這么多的文件，可以把幾種文件合并成一種。一般地說，當項目的規模、復雜性和成敗風險增大時，文件編制的范圍、管理手續和詳細程度將隨之增

11、加。反之，則可適當減少。為了恰當地掌握這種靈活性，本指南要求貫徹分工負責的原則，這意味著：a.一個軟件開發單位的領導機構應該根據單位經營承包的應用軟件的專業領域和本單位的管理能力，制定一個對文件編制要求的實施規定，主要是：在不同的條件下，應該形成哪些文件.這些文件的詳細程序.該開發單位的每一個項目負責人，必須認真執行這個實施規定。這種規定的兩個例子可看本指南的附錄；b.對于一個具體的應用軟件項目，項目負責人應根據上述實施規定，確定一個文件編制計劃，主要包括：（1）應該編制哪幾種文件，詳細程序如何.（2）各個文件的編制負責人和進度要求；（3）審查、批準的負責人和時間進度安排；（4）在開發時期內，

12、各文件的維護、修改和管理的負責人，以及批準手續。每項工作必須落實到人。這個文件編制計劃是整個開發計劃的重要組成部分；c.有關的設計人員則必須嚴格執行這個文件編制計劃。5.3.2文件的詳細程序從同一份提綱起草的文件的篇幅大小往往不同，可以少到幾頁，也可以長達幾百頁。對于這種差別本指南是允許的。此詳細程序取決于任務的規模、復雜性和項目負責人對該軟件的開發過程及運行環與所需要的詳細程度的判斷。5.3.3文件的擴展當被開發系統的規模非常大（例如源碼超過一百萬行）時，一種文件可以分成幾卷編寫，可以按其。 每一個系統分別編制，也可以按內容劃分成多卷，例如：項目開發計劃可能包括：質量保證計劃，配置管理計劃，

13、用戶培訓計劃，安裝實施計劃；系統設計說明書可分寫成：系統設計說明書，子系統設計說明書；程序設計說明書可分寫成：程序設計說明書，接口設計說明書，版本說明；操作手冊可分寫成：操作手冊，安裝實施過程；測試計劃可分寫成：測試計劃，測試設計說明，測試規程，測試用例；測試分析報告可分寫成：綜合測試報告，驗收測試報告；項目開發總結報告亦可分寫成項目開發總結報告和資源環境統計。5.3.4節的擴張與縮并在有些文件中，可以使用本指南所提供的章、條標題，但在條內又存在一系列需要分別討論的因素 本指南認為，所有的條都可以擴展，可以進一步細分，以適應實際需要。反之，如果章條中的有些細節； 非必需，也可以根據實際情況縮并

14、。此時章條的編號應相應地改變。5.3.5程序設計的表現形式本指南對于程序的設計表現形式并未作出規定或限制，可以使用流程圖的形式、判定表的形式，可以使用其他表現形式，如程序設計語言（PDL）、問題分析圖（PAD）等。5.3.6文件的表現形式本指南對于文件的表現形式亦未作出規定或限制，可以使用自然語言，也可以使用形式化語言。5.3.7文件的其他種類當本指南中規定的文件種類尚不能滿足某些應用部門的特殊需要時，他們可以建立一些特殊的文件種類要求，例如軟件質量保證計劃、軟件配置管理計劃等，這些要求可以包含在本單位的文件編制實施規定中。6文件編制的管理工作文件編制工作必須有管理工作的配合，才能使所編制的文

15、件真正發揮它的作用。文件的編制工作實際上貫穿于一項軟件的整個開發過程，因此，對文件的管理必須貫穿于整個開發過程。在開發過程中必須進行的管理工作是以下四條。6.1文件的形成開發集體中的每個成員，尤其是項目負責人，應該認識到：文件是軟件產品的必不可少的組成部分；在軟件開發過程的各個階段中，必須按照規定及時地完成各種產品文件的編寫工作；必須把在一個開發步驟中作出的決定和取得的結果及時地定文件；開發集體必須及時地對這些文件進行嚴格的評審；這些文件的形成是各個階段開發工作正式完成的標志。這些文件上必須有編寫者、評審者和批準者的簽字，必須有編寫、評審完成的日期和批準的日期。6.2文件的分類與標識在軟件開發

16、的過程中，產生的文件是很多的，為了便于保存、查找、使用和修改，應該對文件按層次地加以分類組織。一個軟件開發單位應該建立一個對本單位文件的標識方法，使文件的每一頁都具有明確的標識。例如可以按如下四個層次對文件加以分類和標識。a.文件所屬的項目的標識；b.文件種類的標識；c.同一種文件的不同版本號；d.頁號。此外，對每種文件還應根據項目的性質，劃定它們各自的保密級別，確定他們各自的發行范圍。6.3文件的控制在一項軟件的開發過程中，隨著程序的逐步形成和逐步修改，各種文件亦在不斷地產生、不斷地修改或補充。因此，必須加以周密的控制，以保持文件與程序產品的一致性，保持各種文件之間的一致性和文件的安全性。這

17、種控制表現為：a.就從事一項軟件開發工作的開發集體而言，應設置一位專職的文件管理人員（接口管理工程師或文件管理員）；在開發集體中，應該集中保管本項目現有全部文件的主文本兩套，由該文件管理人員負責保管；b.每一份提交給文件管理人員的文件都必須具有編寫人、審核人和批準人的簽字；c.這兩套主文本的內容必須完全一致；其中有一套是可供出借的，另一套是絕對不能出借的，以免發生萬一；可出借的主文本在出借時必須辦理出借手續，歸還時辦理注銷出借手續；d.開發集體中的工作人員可以根據工作的需要，在本項目的開發過程中持有一些文件，即所謂個人文件，包括為使他完成他承擔的任務所需要的文件，以及他在完成任務過程中所編制的

18、文件；但這種個人文件必須是主文本的復制品，必須同主文本完全一致，若要修改，必須首先修改主文本；e.不同開發人員所擁有的個人文件通常是主文本的各種子集；所謂子集是指把主文本的各個部分根據承擔不同任務的人員或部門的工作需要加以復制、組裝而成的若干個文件的集合；文件管理人員。應該列出一份不同子集的分發對象的清單，按照清單及時把文件分發給有關人員或部門； f.一份文件如果已經被另一份新的文件所代替，則原文件應該被注銷；文件管理人中要隨時整理主文本，及時反映出文件的變化和增加情況，及時分發文件；g.當一個項目的開發工作臨近結束時，文件管理人員應逐個收回開發集體內每個成員的個人文 件，并檢查這些個人文件的

19、內容；經驗表明，這些個人文件往往可能比主文本更詳細，或同主文本的內容 有所不同，必須認真監督有關人員進行修改，使主文本能真正反映實際的開發結果。6.4文件的修改管理在一個項目的開發過程中的任何時刻，開發集體內的所有成員都可能對開發工作的已有成果- 文件，提出進行修改的要求。提出修改要求的理由可能是各種各樣的，進行修改而引起的影響可能很小， 也可能會牽涉到本項目的很多方面。因此，修改活動的進行必須謹慎，必須對修改活動的進行加以管理， 必須執行修改活動的規程，使整個修改活動有控制地進行。修改活動可分如下五個步驟進行：a.提議開發集體中的任何一個成員都可以向項目負責人提出修改建議，為此應該填寫一份修

20、 改建議表，說明修改的內容、所修改的文件和部位、以及修改理由；b.評議由項目負責人或項目負責人指定的人員對該修改建議進行評議，包括審查該項修改的必要、確定這一修改的影響范圍、研究進行修改的方法、步驟和實施計劃；c.審核一般由項目負責人進行審核，包括核實修改的目的和要求、核實修改活動將帶來的影響、審核修改活動計劃是否可行；d.批準在一般情況下，批準權屬于該開發單位的部門負責人；在批準時，主要是決斷修改工作中各項活動的先后順序及各自的完成日期，以保證整個開發工作按原定計劃日期完成；e.實施由項目負責人按照已批準的修改活動計劃，安排各項修改活動的負責人員進行修改，建立修改記錄、產生新的文件以取代原有

21、文件、最后把文件交文件管理人員歸檔，并分發給有關的持有者。二、可行性研究報告可行性研究報告的編寫目的是：說明該軟件開發項目的實現在技術、經濟和社會條件方面的可行性；評述為了合理地達到開發目標而可能選擇的各種方案；說明并論證所選定的方案。可行性研究報告的編寫內容要求如下：1引言1.1編寫目的說明編寫本可行性研究報告的目的，指出預期的讀者。1.2背景說明：a.所建議開發的軟件系統的名稱；b.本項目的任務提出者、開發者、用戶及實現該軟件的計算中心或計算機網絡；c.該軟件系統同其他系統或其他機構的基本的相互來往關系。1.3定義列出本文件中用到的專門術語的定義和外文首字母組詞的原詞組。1.4參考資料列出

22、用得著的參考資料，如：a.本項目的經核準的計劃任務書或合同、上級機關的批文；b.屬于本項目的其他已發表的文件；c.本文件中各處引用的文件、資料，包括所需用到的軟件開發標準。列出這些文件資料的標題、文件編號、發表日期和出版單位，說明能夠得到這些文件資料的來源。2可行性研究的前提說明對所建議的開發項目進行可行性研究的前提，如要求、目標、假定、限制等。2.1要求說明對所建議開發的軟件的基本要求，如：a.功能；b.性能；c.輸出如報告、文件或數據，對每項輸出要說明其特征，如用途、產生頻度、接口以及分發對象；d.輸入說明系統的輸入，包括數據的來源、類型、數量、數據的組織以及提供的頻度；e.處理流程和數據

23、流程用圖表的方式表示出最基本的數據流程和處理流程，并輔之以敘述；f.在安全與保密方面的要求；g.同本系統相連接的其他系統；h.完成期限。2.2目標說明所建議系統的主要開發目標，如：a.人力與設備費用的減少；b.處理速度的提高；c.控制精度或生產能力的提高；d.管理信息服務的改進；e.自動決策系統的改進；f.人員利用率的改進。 2.3條件、假定和限制說明對這項開發中給出的條件、假定和所受到的限制，如：a所建議系統的運行壽命的最小值；b進行系統方案選擇比較的時間； c經費、投資方面的來源和限制； d法律和政策方面的限制；e硬件、軟件、運行環境和開發環境方面的條件和限制；f可利用的信息和資源；g.系

24、統投入使用的最晚時間。2.4進行可行性研究的方法說明這項可行性研究將是如何進行的，所建議的系統將是如何評價的。摘要說明所使用的基本方法和策略，如調查、加權、確定模型、建立基準占或仿真等。2.5評價尺度說明對系統進行評價時所使用的主要尺度，如費用的多少、各項功能的優先次序、開發時間的長短及使用中的難易程序。3對現有系統的分析這里的現有系統是指當前實際使用的系統，這個系統可能是計算機系統，也可能是一個機械系統甚至是一個人工系統。分析現有系統的目的是為了進一步闡明建議中的開發新系統或修改現有系統的必要性。3.1處理流程和數據流程說明現有系統的基本的處理流程和數據流程。此流程可用圖表即流程圖的形式表示

25、，并加以敘述。3.2工作負荷列出現有系統所承擔的工作及工作量。3.3費用開支列出由于運行現有系統所引起的費用開支，如人力、設備、空間、支持性服務、材料等項開支以及開 支總額。3.4人員列出為了現有系統的運行和維護所需要的人員的專業技術類別和數量。3.5設備列出現有系統所使用的各種設備。3.6局限性列出本系統的主要的局限性，例如處理時間趕不上需要，響應不及時，數據存儲能力不足，處理功能 不夠等。并且要說明，為什么對現有系統的改進性維護已經不能解決問題。4所建議的系統本章將用來說明所建議系統的目標和要求將如何被滿足。4.1對所建議系統的說明概括地說明所建議系統，并說明在第A2章中列出的那些要求將如

26、何得到滿足，說明所使用的基本方法及理論根據。4.2處理流程和數據流程給出所建議系統的處理流程和數據流程。4.3影響說明在建立所建議系統時，預期將帶來的影響，包括：4.4.1對設備的影響說明新提出的設備要求及對現存系統中尚可使用的設備須作出的修改。4.4.2對軟件的影響說明為了使現存的應用軟件和支持軟件能夠同所建議系統相適應。而需要對這些軟件所進行的修改和補充。4.4.3對用戶單位機構的影響說明為了建立和運行所建議系統，對用戶單位機構、人員的數量和技術水平等方面的全部要求。4.4.4對系統運行過程的影響說明所建議系統對運行過程的影響，如：a用戶的操作規程；b運行中心的操作規程； c運行中心與用戶

27、之間的關系；d源數據的處理； e數據進入系統的過程；f對數據保存的要求，對數據存儲、恢復的處理；g輸出報告的處理過程、存儲媒體和調度方法；h系統失效的后果及恢復的處理辦法。 4.4.5對開發的影響說明對于開發的影響，如：a為了支持所建議系統的開發，用戶需進行的工作；b為了建立一個數據庫所要求的數據資源；c為了開發和測驗所建議系統而需要的計算機資源；d所涉及的保密與安全問題。4.4.6對地點和設施的影響說明對建筑物改造的要求及對環境設施的要求。4.4.7對經費開支的影響扼要說明為了所建議系統的開發，設計和維持運行而需要的各項經費開支。4.5局限性說明所建議系統尚存在的局限性以及這些問題未能消除的

28、原因。4.6技術條件方面的可行性本節應說明技術條件方面的可行性，如：a在當前的限制條件下，該系統的功能目標能否達到；b利用現有的技術，該系統的功能能否實現；c對開發人員的數量和質量的要求并說明這些要求能否滿足；d在規定的期限內，本系統的開發能否完成。5可選擇的其他系統方案 扼要說明曾考慮過的每一種可選擇的系統方案，包括需開發的和可從國內國外直接購買的，如果沒 有供選擇的系統方案可考慮，則說明這一點。 51可選擇的系統方案1  參照第4章的提綱，說明可選擇的系統方案1，并說明它未被選中的理由。52可選擇的系統方案2 按類似 5 1條的方式說明第2個乃至第。個可選擇的系統方案。6投資及效

29、益分析 61支出對于所選擇的方案，說明所需的費用。如果已有一個現存系統，則包括該系統繼續運行期間所需的費用。 611基本建設投資包括采購、開發和安裝下列各項所需的費用，如： a房屋和設施；bADP設備； c數據通訊設備；d環境保護設備；e安全與保密設備；fADP操作系統的和應用的軟件； g數據庫管理軟件。612其他一次性支出包括下列各項所需的費用，如：a研究（需求的研究和設計的研究）；b開發計劃與測量基準的研究；c數據庫的建立；dADP軟件的轉換；e檢查費用和技術管理性費用；f培訓費、旅差費以及開發安裝人員所需要的一次性支出； g人員的退休及調動費用等。613非一次性支出列出在該系統生命期內按

30、月或按季或按年支出的用于運行和維護的費用，包括： a設備的租金和維護費用； b.軟件的租金和維護費用；c數據通訊方面的租金和維護費用；d人員的工資、獎金；e房屋、空間的使用開支；f公用設施方面的開支；g保密安全方面的開支； h其他經常性的支出等。62收益 對于所選擇的方案，說明能夠帶來的收益，這里所說的收益，表現為開支費用的減少或避免、差錯的減少、靈活性的增加、動作速度的提高和管理計劃方面的改進等，包括；621一次性收益說明能夠用人民幣數目表示的一次性收益，可按數據處理、用戶、管理和支持等項分類敘述，如：a開支的縮減包括改進了的系統的運行所引起的開支縮減，如資源要求的減少，運行效率的改進，數據

31、進入、存貯和恢復技術的改進，系統性能的可監控，軟件的轉換和優化，數據壓縮技術的采用，處理的集中化分布化等； b價值的增升包括由于一個應用系統的使用價值的增升所引起的收益，如資源利用的改進，管理和運行效率的改進以及出錯率的減少等；c其他如從多余設備出售回收的收入等。622非一次性收益 說明在整個系統生命期內由于運行所建議系統而導致的按月的、按年的能用人民幣數目表示的收益，包括開支的減少和避免。 623不可定量的收益 逐項列出無法直接用人民幣表示的收益，如服務的改進，由操作失誤引起的風險的減少，信息掌握情況的改進，組織機構給外界形象的改善等。有些不可捉摸的收益只能大概估計或進行極值估計（按最好和最

32、差情況估計）。 63收益投資比求出整個系統生命期的收益投資比值。 64投資回收周期 求出收益的累計數開始超過支出的累計數的時間。65敏感性分析所謂敏感性分析是指一些關鍵性因素如系統生命期長度、系統的工作負荷量、工作負荷的類型與這些不同類型之間的合理搭配、處理速度要求、設備和軟件的配置等變化時，對開支和收益的影響最靈敏的范圍的估計。在敏感性分析的基礎上做出的選擇當然會比單一選擇的結果要好一些。7社會因素方面的可行性 本章用來說明對社會因素方面的可行性分析的結果，包括：71法律方面的可行性 法律方面的可行性問題很多，如合同責任、侵犯專利權、侵犯版權等方面的陷井，軟件人員通常是不熟悉的，有可能陷入，

33、務必要注意研究。 72使用方面的可行性 例如從用戶單位的行政管理、工作制度等方面來看，是否能夠使用該軟件系統；從用戶單位的工作人員的素質來看，是否能滿足使用該軟件系統的要求等等，都是要考慮的。8結論在進行可行性研究報告的編制時，必須有一個研究的結論。結論可以是：a可以立即開始進行；b需要推遲到某些條件（例如資金、人力、設備等）落實之后才能開始進行；c需要對開發目標進行某些修改之后才能開始進行；d不能進行或不必進行（例如因技術不成熟、經濟上不合算等）。三、項目開發計劃編制項目開發計劃的目的是用文件的形式，把對于在開發過程中各項工作的負責人員、開發進度、 所需經費預算、所需軟、硬件條件等問題作出的

34、安排記載下來，以便根據本計劃開展和檢查本項目的開 發工作。編制內容要求如下：1引言1.1編寫目的說明編寫這份項目開發計劃的目的，并指出預期的讀者。1.2背景說明：a.待開發的軟件系統的名稱；b.本項目的任務提出者、開發者、用戶及實現該軟件的計算中心或計算機網絡；c.該軟件系統同其他系統或其他機構的基本的相互來往關系。1.3定義列出本文件中用到的專門術語的定義和外文首字母組詞的原詞組。1.4參考資料列出用得著的參考資料，如：a.本項目的經核準的計劃任務書或合同、上級機關的批文；b.屬于本項目的其他已發表的文件；c.本文件中各處引用的文件、資料，包括所要用到的軟件開發標準。 列出這些文件資料的標題

35、、文件編號、發表日期和出版單位，說明能夠得到這些文件資料的來源。2項目概述2.1工作內容簡要地說明在本項目的開發中須進行的各項主要工作。2.2主要參加人員扼要說明參加本項目開發工作的主要人員的情況，包括他們的技術水平。2.3產品2.3.1程序列出需移交給用戶的程序的名稱、所用的編程語言及存儲程序的媒體形式，并通過引用有關文件，逐項說明其功能和能力。2.3.2文件列出需移交給用戶的每種文件的名稱及內容要點。2.3.3服務列出需向用戶提供的各項服務，如培訓安裝、維護和運行支持等，應逐項規定開始日期、所提供支持 的級別和服務的期限。2.3.4非移交的產品說明開發集體應向本單位交出但不必向用戶移交的產

36、品（文件甚至某些程序）。2.4驗收標準對于上述這些應交出的產品和服務，逐項說明或引用資料說明驗收標準。2.5完成項目的延遲用限2.6本計劃的批準者和批準日期3實施計劃3.1工作任務的分門與人員分工對于項目開發中需完成的各項工作，從需求分析、設計、實現、測試直到維護，包括文件的編制、審批、打印、分發工作，用戶培訓工作，軟件安裝工作等，按層次進行分解，指明每項任務的負責人和參加人員。3.2接口人員說明負責接口工作的人員及他們的職責，包括：a.負責本項目同用戶的接口人員；b.負責本項目同本單位各管理機構，如合同計劃管理部門、財務部門、質量管理部門等的接口人員；c.負責本項目同各分合同負責單位的接口人

37、員等。3.3進度對于需求分析、設計、編碼實現、測試、移交、培訓和安裝等工作，給出每項工作任務的預。定開始日期、完成日期及所需資源，規定各項工作任務完成的先后順序以及表征每項工作任務完成的標志性事件（即所謂"里程碑"）。3.4預算逐項列出本開發項目所需要的勞務（包括人員的數量和時間）以及經費的預算（包括辦公費、差旅費、機時費、資料費、通訊設備和專用設備的租金等）和來源。3.5關鍵問題逐項列出能夠影響整個項目成敗的關鍵問題、技術難點和風險，指出這些問題對項目的影響。4支持條件說明為支持本項目的開發所需要的各種條件和設施。4.1計算機系統支持逐項列出開發中和運行時所需的計算機系統

38、支持，包括計算機、外圍設備、通訊設備、模擬器、編譯 （或 匯編）程序、操作系統、數據管理程序包、數據存儲能力和測試支持能力等，逐項給出有關到貨日期、 使用時間的要求。4.2需由用戶承擔的工作逐項列出需要用戶承擔的工作和完成期限。包括需由用戶提供的條件及提供時間。4.3由外單位提供的條件逐項列出需要外單位分合同承包者承擔的工作和完成的時間，包括需要由外單位提供的條件和提 供的時間。5專題計劃要點說明本項目開發中需制訂的各個專題計劃（如分合同計劃、開發人員培訓計劃、測試計劃、安全保密 計劃、質量保證計劃、配置管理計劃、用戶培訓計劃、系統安裝計劃等）的要點。四、軟件需求說明書軟件需求說明書的編制是為

39、了使用戶和軟件開發者雙方對該軟件的初始規定有一個共同的理解， 使之成為整個開發工作的基礎。編制軟件需求說明書的內容要求如下：1引言1.1編寫目的說明編寫這份軟件需求說明書的目的，指出預期的讀者。1.2背景說明：a.待開發的軟件系統的名稱；b.本項目的任務提出者、開發者、用戶及實現該軟件的計算中心或計算機網絡；c.該軟件系統同其他系統或其他機構的基本的相互來往關系。1.3定義列出本文件中用到的專門術語的定義和外文首字母組詞的原詞組。1.4參考資料列出用得著的參考資料，如：a.本項目的經核準的計劃任務書或合同、上級機關的批文；b.屬于本項目的其他已發表的文件；c.本文件中各處引用的文件、資料、包括

40、所要用到的軟件開發標準。 列出這些文件資料的標題、文件編號、發表日期和出版單位，說明能夠得到這些文件資料的來源。2任務概述2.1目標敘述該項軟件開發的意圖、應用目標、作用范圍以及其他應向讀者說明的有關該軟件開發的背景材料。解釋被開發軟件與其他有關軟件之間的關系。如果本軟件產品是一項獨立的軟件，而且全部內容自含，則說明這一點。如果所定義的產品是一個更大的系統的一個組成部分，則應說明本產品與該系統中其他各組成部分之間的關系，為此可使用一張方框圖來說明該系統的組成和本產品同其他各部分的聯系和接口。2.2用戶的特點列出本軟件的最終用戶的特點，充分說明操作人員、維護人員的教育水平和技術專長，以及本軟件的

41、預期使甩頻度。這些是軟件設計工作的重要約束。2.3假定和約束列出進行本軟件開發工作的假定和約束，例如經費限制、開發期限等。3需求規定3.1對功能的規定用列表的方式（例如IPO表即輸入、處理、輸出表的形式），逐項定量和定性地敘述對軟件所提出的功能要求，說明輸入什么量、經怎樣的處理、得到什么輸出，說明軟件應支持的終端數和應支持的并行操作的用戶數。3.2對性能的規定3.2.1精度說明對該軟件的輸入、輸出數據精度的要求，可能包括傳輸過程中的精度。3.2.2時間特性要求說明對于該軟件的時間特性要求，如對：a.響應時間；b.更新處理時間；c.數據的轉換和傳送時間；d.解題時間； 等的要求。3.2.3靈活性

42、說明對該軟件的靈活性的要求，即當需求發生某些變化時，該軟件對這些變化的適應能力，如：a.操作方式上的變化；b.運行環境的變化；c.同其他軟件的接口的變化；d.精度和有效時限的變化；e.計劃的變化或改進。對于為了提供這些靈活性而進行的專門設計的部分應該加以標明。3.3輸入輸出要求解釋各輸入輸出數據類型，并逐項說明其媒體、格式、數值范圍、精度等。對軟件的數據輸出及必須標明的控制輸出量進行解釋并舉例，包括對硬拷貝報告（正常結果輸出、狀態輸出及異常輸出）以及圖形或顯示報告的描述。3.4數據管理能力要求說明需要管理的文卷和記錄的個數、表和文卷的大小規模，要按可預見的增長對數據及其分量的存儲要求作出估算。

43、3.5故障處理要求列出可能的軟件、硬件故障以及對各項性能而言所產生的后果和對故障處理的要求。3.6其他專門要求如用戶單位對安全保密的要求，對使用方便的要求，對可維護性、可補充性、易讀性、可靠性、運行環境可轉換性的特殊要求等。4運行環境規定4.1設備列出運行該軟件所需要的硬設備。說明其中的新型設備及其專門功能，包括： a.處理器型號及內在容量；b.外存容量、聯機或脫機、媒體及其存儲格式，設備的型號及數量；c.輸入及輸出設備的型號和數量，聯機或脫機；d.數據通信設備的型號和數量；e.功能鍵及其他專用硬件。4.2支持軟件列出支持軟件，包括要用到的操作系統、編譯（或匯編）程序、測試支持軟件等。4.3接

44、口說明該軟件同其他軟件之間的接口、數據通信協議等。4.4控制說明控制該軟件的運行的方法和控制信號，并說明這些控制信號的來源。五、數據要求說明書1引言1.1編寫目的說明編寫這份數據要求說明書的目的，指出預期的讀者。1.2背景說明：a.待開發的軟件系統的名稱；b.列出本項目的任務提出者、開發者、用戶以及將運行該項軟件的計算站（中心）或計算機網絡系統。1.3定義列出本文件中用到的專門術語的定義和外文首字母組詞的原詞組。1.4參考資料列出用得著的參考資料，如：a.本項目的經核準的計劃任務書或合同、上級機關的批文；b.屬于本項目的其他已發表的文件；c.本文件中各處引用的文件、資料、包括所要用到的軟件開發

45、標準。 列出這些文件資料的標題、文件編號、發表日期和出版單位，說明能夠得到這些文件資料的來源。2數據的邏輯描述對數據進行邏輯描述時可把數據分為動態數據和靜態數據。所謂靜態數據，指在運行過程中主要作 為參考的數據，它們在很長的一段時間內不會變化，一般不隨運行而改變。所謂動態數據包括所有在運 行中要發生變化的數據以及在運行中要輸入、輸出的數據。進行描述時應把各數據元素邏輯地分成若干 組，列如函數、源數據或對于其應用更為恰當的邏輯分組。給出每一數據元的名稱（包括縮寫和代碼）、定 義（或物理意義）度量單位、值域、格式和類型等有關信息。2.1靜態數據列出所有作為控制或參考用的靜態數據元素。2.2動態輸入

46、數據列出動態輸入數據元素（包括在常規運行中或聯機操作中要改變的數據）。2.3動態輸出數據列出動態輸出數據元素（包括在常規運行中或聯機操作中要改變的數據）。2.4內部生成數據列出向用戶或開發單位中的維護調試人員提供的內部生成數據。2.5數據約定說明對數據要求的制約。逐條列出對進一步擴充或使用方面的考慮而提出的對數據要求的限制（容量、文卷、記錄和數據元的個數的最大值）。對于在設計和開發中確定是臨界性的限制更要明確指出。3數據的采集3.1要求和范圍按數據元的邏輯分組來說明數據采集的要求和范圍，指明數據的采集方法，說明數據采集工作的承擔者是用戶還是開發者。具體的內容包括：a.輸入數據的來源，例如是單個

47、操作員、數據輸入站，專業的數據輸入公司或它們的一個分組；b.數據輸入（指把數據輸入處理系統內部）所用的媒體和硬設備。如果只有指定的輸入點的輸入才是合法的，則必須對此加以說明；c.接受者說明輸出數據的接受者；d.輸出數據的形式和設備列出輸出數據的形式和硬設備。無論接受者將接收到的數據是打印輸出，還是CRT上的一組字符、一幀圖形，或一聲警鈴，或向開關線圈提供的一個電脈沖，或常用介質如磁盤、磁帶、穿孔卡片等，均應具體說明；    e.數據值的范圍給出每一個數據元的合法值的范圍；f.量綱給出數字的度量單位、增量的步長、零點的定標等。在數據是非數字量的情況下，要給出每一種合

48、法值的形式和含意；g.更新和處理的頻度給出預定的對輸入數據的更新和處理的頻度。如果數據的輸入是隨機的，應給出更新處理的頻度的平均值，或變化情況的某種其他度量。3.2輸入的承擔者說明預定的對數據輸入工作的承擔者。如果輸入數據同某一接口軟件有關，還應說明該接口軟件的來源。3.3預處理對數據的采集和預處理過程提出專門的規定，包括適合應用的數據格式、預定的數據通信媒體和對輸入的時間要求等。對于需經模擬轉換或數字轉換處理的數據量，要給出轉換方法和轉換因子等有關信息，以便軟件系統使用這些數據。3.4影響說明這些數據要求對于設備、軟件、用戶、開發單位所可能產生的影響，例如要求用戶單位增設某個機構等。六、概要

49、設計說明書1引言1.1編寫目的說明編寫這份概要設計說明書的目的，指出預期的讀者。1.2背景說明：a.待開發的軟件系統的名稱；b.列出本項目的任務提出者、開發者、用戶以及將運行該項軟件的計算站（中心）。1.3定義列出本文件中用到的專門術語的定義和外文首字母組詞的原詞組。1.4參考資料列出用得著的參考資料，如：a.本項目的經核準的計劃任務書或合同、上級機關的批文；b.屬于本項目的其他已發表的文件；c.本文件中各處引用的文件、資料、包括所要用到的軟件開發標準。 列出這些文件資料的標題、文件編號、發表日期和出版單位，說明能夠得到這些文件資料的來源。2總體設計2.1需求規定說明對本系統的主要的輸入輸出項

50、目、處理的功能性能要求，詳細的說明可參見附錄C。2.2運行環境簡要地說明對本系統的運行環境（包括硬件環境和支持環境）的規定，詳細說明參見附錄C。2.3基本設計概念和處理流程說明本系統的基本設計概念和處理流程，盡量使用圖表的形式。 2.4結構用一覽表及框圖的形式說明本系統的系統元素（各層模塊、子程序、公用程序等）的劃分，扼要說明每個系統元素的標識符和功能，分層次地給出各元素之間的控制與被控制關系。2.5功能要求與程序的關系本條用一張如下的矩陣圖說明各項功能需求的實現同各塊程序的分配關系。2.6人工處理過程說明在本軟件系統的工作過程中不得不包含的人工處理過程（如果有的話）。2.7尚未解決的問題說明

51、在概要設計過程中尚未解決而設計者認為在系統完成之前必須解決的各個問題。3接口設計3.1用戶接口說明將向用戶提供的命令和它們的語法結構，以及軟件的回答信息。3.2外部接口說明本系統同外界的所有接口的安排包括軟件與硬件之間的接口、本系統與各支持軟件之間的接口關系。3.3內部接口說明本系統之內的各個系統元素之間的接口的安排。4運行設計 4.1運行模塊組合 說明對系統施加不同的外界運行控制時所引起的各種不同的運行模塊組合，說明每種運行所歷經的內部模塊和支持軟件。 4.2運行控制 說明每一種外界的運行控制的方式方法和操作步驟。 4.3運行時間 說明每種運行模塊組合將占用各種資源的時間。 5系統數據結構設

52、計 5.1邏輯結構設計要點 給出本系統內所使用的每個數據結構的名稱、標識符以及它們之中每個數據項、記錄、文卷和系的標識、定義、長度及它們之間的層次的或表格的相互關系。 5.2物理結構設計要點 給出本系統內所使用的每個數據結構中的每個數據項的存儲要求，訪問方法、存取單位、存取的物理關系（索引、設備、存儲區域）、設計考慮和保密條件。 5.3數據結構與程序的關系 說明各個數據結構與訪問這些數據結構的形式。 6系統出錯處理設計 6.1出錯信息 用一覽表的方式說朗每種可能的出錯或故障情況出現時，系統輸出信息的形式、含意及處理方法。 6.2補救措施 說明故障出現后可能采取的變通措施，包括： a.后備技術說

53、明準備采用的后備技術，當原始系統數據萬一丟失時啟用的副本的建立和啟動的技術，例如周期性地把磁盤信息記錄到磁帶上去就是對于磁盤媒體的一種后備技術； b.降效技術說明準備采用的后備技術，使用另一個效率稍低的系統或方法來求得所需結果的某些部分，例如一個自動系統的降效技術可以是手工操作和數據的人工記錄； c.恢復及再啟動技術說明將使用的恢復再啟動技術，使軟件從故障點恢復執行或使軟件從頭開始重新運行的方法。 6.3系統維護設計 說明為了系統維護的方便而在程序內部設計中作出的安排，包括在程序中專門安排用于系統的檢查與維護的檢測點和專用模塊。七、詳細設計說明書1引言1.1編寫目的說明編寫這份詳細設計說明書的目的，指出預期的讀者。1.2背景說明：a.待開發的軟件系統的名稱；b.列出本項目的任務提出者、開發者、用戶以及將運行該項軟件的計算中心。1.3定義列出本文件中用到的專門術語的定義和外文首字母組詞的原詞組。1.4參考資料列出用得著的參考資料，如：a.本項目的經核準的計劃