技術(shù)開發(fā)管理制度

1、技術(shù)開發(fā)管理制度2014（試行）主 題： 軟件開發(fā)管理制度 文檔編號： 版本說明：版本號版本日期作者備注V1.0 2014年10月30日牟寶林創(chuàng)建 V1.0 2014年10月30日牟寶林審批 目錄第一節(jié) 總 則3第二節(jié) 立項管理3第三節(jié) 需求分析4第四節(jié) 項目計劃和監(jiān)控4第五節(jié) 系統(tǒng)設(shè)計5第六節(jié) 系統(tǒng)實現(xiàn)5第七節(jié) 系統(tǒng)測試和用戶測試6第八節(jié) 試運行7第九節(jié) 系統(tǒng)驗收8第十節(jié) 系統(tǒng)上線8第十一節(jié) 合作開發(fā)管理9第十二節(jié) 系統(tǒng)交付10第十三節(jié) 外包開發(fā)管理10第十四節(jié) 附則10附件一 立項分析報告11附件二 業(yè)務(wù)需求說明書14附件三 系統(tǒng)需求規(guī)格說明書17附件四 需求變更申請26附件五 項目計劃書

2、28附件六 項目計劃變更說明32附件七 設(shè)計說明書33附件八 單元測試用例36附件九 設(shè)計評審報告38附件十 系統(tǒng)/用戶測試計劃40附件十一 系統(tǒng)/用戶測試報告43附件十二 試運行計劃44附件十三 數(shù)據(jù)遷移計劃46附件十四 數(shù)據(jù)遷移報告48附件十五 試運行報告50附件十六 系統(tǒng)驗收報告51附件十七 系統(tǒng)上線計劃54附件十八 系統(tǒng)驗收評估報告57附件十九 系統(tǒng)交付申請59第一節(jié) 總 則 第一條 為規(guī)范自有軟件研發(fā)以及外包軟件的管理工作，特制定本制度。本制度適用于公司軟件研發(fā)與管理。 第二條 本制度中軟件開發(fā)指新系統(tǒng)開發(fā)和現(xiàn)有系統(tǒng)重大改造，此類工作均需要以項目制管理。 第三條 本制度中自行開發(fā)是指

3、主要依賴公司自身的管理、業(yè)務(wù)和技術(shù)力量進行系統(tǒng)設(shè)計、軟件開發(fā)、集成和相關(guān)的技術(shù)支持工作，一般僅向外購置有關(guān)的硬件設(shè)備和支撐軟件平臺；合作開發(fā)是公司與專業(yè)IT公司（合作商）共同協(xié)作完成IT應(yīng)用的項目實施和技術(shù)支持工作，一般形式是公司負責提供業(yè)務(wù)框架，合作商提供技術(shù)框架，雙方組成開發(fā)團隊進行項目實施，IT系統(tǒng)的日常支持由技術(shù)研發(fā)部承擔；外包開發(fā)是指將IT應(yīng)用項目的設(shè)計、開發(fā)、集成、培訓等任務(wù)承包給某家專業(yè)公司（可以是專業(yè)的IT公司或咨詢公司等），由該公司（承包商）負責應(yīng)用項目的實施。 第四條 軟件開發(fā)遵循項目管理和軟件工程的基本原則。項目管理涉及立項管理、項目計劃和監(jiān)控、配置管理、合作開發(fā)管理和結(jié)

4、項管理。軟件工程涉及需求管理、系統(tǒng)設(shè)計、系統(tǒng)實現(xiàn)、系統(tǒng)測試、用戶接受測試、試運行、系統(tǒng)驗收、系統(tǒng)上線和數(shù)據(jù)遷移。 第五條 除特別指定，本制度中項目組包括業(yè)務(wù)組（或需求提出組）、開發(fā)組（可能包括網(wǎng)絡(luò)管理員和合作開發(fā)商）。 第二節(jié) 立項管理 第六條 提出項目需求的部門參與公司層面立項，進行立項的技術(shù)可行性分析，編寫立項分析報告（附件一），開展前期籌備工作。立項分析報告應(yīng)明確項目的范圍和邊界。 第七條 需求提出部門將立項分析報告交相關(guān)部門會簽后，上交公司總裁與董事長進行立項審批，以保證系統(tǒng)項目與公司整體策略相一致。 第八條 立項分析報告得到批準后，成立項目組（如果是外包開發(fā)，則成立外包商項目組；如果

5、是合作開發(fā)，則與外包商共同成立合作開發(fā)項目組，以下統(tǒng)稱“項目組”），項目組應(yīng)包括業(yè)務(wù)組（由公司技術(shù)研發(fā)部需求管理組和相關(guān)業(yè)務(wù)部門組成）和開發(fā)組（自行開發(fā)為技術(shù)研發(fā)部開發(fā)組、網(wǎng)絡(luò)管理員；外包開發(fā)為技術(shù)研發(fā)部指定的開發(fā)組長、網(wǎng)絡(luò)管理員和外包商成員；合作開發(fā)為技術(shù)研發(fā)部開發(fā)組指定人員、網(wǎng)絡(luò)管理員和外包商成員）。公司技術(shù)研發(fā)部PMO（項目管理辦公室）委派一名項目經(jīng)理負責監(jiān)督項目的進度，進行項目管理工作，確保開發(fā)能及時完成并能滿足業(yè)務(wù)需要。項目組人員的選擇應(yīng)滿足項目對業(yè)務(wù)及技術(shù)要求，項目組人員應(yīng)有足夠的業(yè)務(wù)和IT技術(shù)方面的專業(yè)知識來勝任項目各方面的工作。 第三節(jié) 需求分析 第九條 立項后業(yè)務(wù)組對用戶需求

6、進行匯總整理，出具業(yè)務(wù)需求說明書（附件二），并確保業(yè)務(wù)需求說明書中包含了所有的業(yè)務(wù)需求。經(jīng)系統(tǒng)使用部門審批確認，作為業(yè)務(wù)需求基線。 第十條 業(yè)務(wù)組在獲得業(yè)務(wù)需求說明書后，提出技術(shù)需求和解決方案，并對系統(tǒng)進行定義，出具系統(tǒng)需求規(guī)格說明書（附件三）。系統(tǒng)需求規(guī)格說明書需詳細列出業(yè)務(wù)對系統(tǒng)的要求（界面、輸入、輸出、管理功能、安全需求、運作模式、關(guān)鍵指標(KPI)等），最好是采用原型方式表達。系統(tǒng)需求規(guī)格說明書需要由業(yè)務(wù)組提交給相關(guān)業(yè)務(wù)部門負責人確認。 第十一條 對于合作開發(fā)的項目，當業(yè)務(wù)需求發(fā)生變更時，業(yè)務(wù)組應(yīng)提交需求變更申請（附件四），項目經(jīng)理審批后交給開發(fā)組長實施。 第十二條 項目組應(yīng)對需求變更

7、影響到的文檔及時更新。 第四節(jié) 項目計劃和監(jiān)控 第十三條 軟件開發(fā)采用項目形式進行管理。項目經(jīng)理負責整個項目的計劃、組織、領(lǐng)導和控制。 第十四條 需求分析過程中，項目經(jīng)理組織制定詳細的項目計劃書（附件五），包括具體任務(wù)描述和項目進度表等。 第十五條 在項目的各個階段，業(yè)務(wù)組組長和開發(fā)組組長需配合項目經(jīng)理制定階段性項目計劃。業(yè)務(wù)組組長和開發(fā)組組長需配合項目經(jīng)理對項目計劃執(zhí)行情況進行監(jiān)控，確保項目按計劃完成。第十六條 第十六條 項目計劃需要變更時，項目經(jīng)理填寫項目計劃變更說明（附件六），并提交公司主管領(lǐng)導審批，通過審批后，交給業(yè)務(wù)組組長和開發(fā)組組長執(zhí)行。 第五節(jié) 系統(tǒng)設(shè)計 第十七條 系統(tǒng)設(shè)計應(yīng)分為

8、概要設(shè)計和詳細設(shè)計，系統(tǒng)設(shè)計要遵循完備性、一致性、擴展性、可靠性、安全性、可維護性等原則。 第十八條 在系統(tǒng)設(shè)計階段中，用戶應(yīng)充分參與，確保系統(tǒng)設(shè)計能滿足系統(tǒng)需求。 第十九條 項目組進行設(shè)計，出具設(shè)計說明書（附件七）和單元測試用例（附件八）。設(shè)計說明書中需要定義系統(tǒng)輸入輸出說明和接口設(shè)計說明。公司主管領(lǐng)導組織相關(guān)人員對概要設(shè)計進行評審，出具設(shè)計評審報告（附件九）。業(yè)務(wù)組組長和開發(fā)組組長應(yīng)參加此評審并對評審意見簽字確認。 第二十條 設(shè)計評審均以業(yè)務(wù)需求說明書和系統(tǒng)需求規(guī)格說明書為依據(jù)，確保系統(tǒng)設(shè)計滿足全部需求。 第二十一條 對已確認通過的系統(tǒng)設(shè)計進行修改需獲得項目經(jīng)理、業(yè)務(wù)組組長和開發(fā)組組長的審

9、批后方可進行。 第二十二條 對系統(tǒng)設(shè)計的修改的文檔須由文檔管理人員進行歸檔管理。 第六節(jié) 系統(tǒng)實現(xiàn) 第二十三條 開發(fā)組根據(jù)設(shè)計說明書制定系統(tǒng)實現(xiàn)計劃，并提交項目經(jīng)理對計劃可行性進行審批。 第二十四條 系統(tǒng)實現(xiàn)包括程序編碼、單元測試。 第二十五條 開發(fā)組保證開發(fā)、測試和生產(chǎn)環(huán)境獨立，為各環(huán)境建立訪問權(quán)限控制機制，并明確項目成員的職責分工。對開發(fā)環(huán)境、測試環(huán)境與生產(chǎn)環(huán)境在物理或邏輯方面應(yīng)該做到隔離；如果環(huán)境的分隔是通過邏輯形式實現(xiàn)的，應(yīng)定期檢查網(wǎng)絡(luò)設(shè)置。項目組對已授權(quán)訪問生產(chǎn)環(huán)境的人員進行詳細記錄，并對該記錄進行定期檢查，確保只有經(jīng)授權(quán)的人員才能訪問到生產(chǎn)環(huán)境。 第七節(jié) 系統(tǒng)測試和用戶測試 第二十

10、六條 測試組制定系統(tǒng)測試計劃（附件十），并提交項目經(jīng)理對計劃可行性進行審批。 第二十七條 系統(tǒng)測試計劃必須定義測試標準，并明確各種測試的測試步驟和需要的系統(tǒng)設(shè)置要求。 第二十八條 開發(fā)組向數(shù)據(jù)擁有部門申請獲取測試用業(yè)務(wù)數(shù)據(jù)的使用權(quán)，對獲取的數(shù)據(jù)進行嚴格的訪問控制，確保只有相關(guān)項目人員才能訪問及使用。 第二十九條 開發(fā)組負責測試數(shù)據(jù)準備，測試用數(shù)據(jù)要足夠模擬生產(chǎn)環(huán)境中的實際數(shù)據(jù)。對已評定為敏感信息的數(shù)據(jù)進行敏感性處理和保護。 第三十條 開發(fā)組或合作開發(fā)商協(xié)助技術(shù)研發(fā)部測試組建立測試環(huán)境進行系統(tǒng)測試。在系統(tǒng)測試中對新系統(tǒng)內(nèi)部各模塊之間的接口和與其他系統(tǒng)的接口進行充分測試。技術(shù)研發(fā)部測試組出具系統(tǒng)測

11、試報告（附件十一），測試人員簽字確認測試結(jié)果。 第三十一條 系統(tǒng)測試通過后，開發(fā)組配合業(yè)務(wù)組建立用戶測試環(huán)境，業(yè)務(wù)組根據(jù)用戶測試用例進行用戶測試，出具用戶測試報告（附件十一），業(yè)務(wù)組組長和開發(fā)組組長應(yīng)在用戶測試報告中簽字確認。 第三十二條 項目組完成系統(tǒng)幫助文檔（其中包括用戶操作手冊和安裝維護手冊）。凡涉及應(yīng)用系統(tǒng)的變更，應(yīng)對系統(tǒng)幫助文檔及時更新。 第八節(jié) 試運行 第三十三條 系統(tǒng)主要使用部門根據(jù)項目規(guī)模及影響決定試運行策略。 第三十四條 項目組制定試運行計劃（附件十二），并制定試運行驗收指標，上報公司主管領(lǐng)導審批。試運行計劃中應(yīng)包含問題應(yīng)對機制，明確問題溝通渠道和職責分工。 第三十五條 項目

12、組聯(lián)合試運行單位進行相關(guān)系統(tǒng)部署工作，準備培訓資料，對相關(guān)用戶和信息技術(shù)人員進行培訓。用戶培訓的完成度應(yīng)為實施后評估的指標之一。 第三十六條 項目組根據(jù)試運行計劃進行系統(tǒng)轉(zhuǎn)換和數(shù)據(jù)遷移。系統(tǒng)轉(zhuǎn)換前，檢查系統(tǒng)環(huán)境，確保運行環(huán)境能滿足新應(yīng)用系統(tǒng)的需要。系統(tǒng)轉(zhuǎn)換時必須詳細記錄原系統(tǒng)中的重要參數(shù)、設(shè)置等系統(tǒng)信息，并填寫試運行報告相關(guān)內(nèi)容。系統(tǒng)參數(shù)、設(shè)置的轉(zhuǎn)換工作作為系統(tǒng)上線的驗收的評估指標之一。 第三十七條 數(shù)據(jù)遷移前，應(yīng)制定詳細的數(shù)據(jù)遷移計劃（附件十三），數(shù)據(jù)遷移計劃中應(yīng)包含遷移方案、測試方案、數(shù)據(jù)定義，新舊數(shù)據(jù)對照表、遷移時間、回退計劃等信息。數(shù)據(jù)遷移計劃需經(jīng)項目經(jīng)理和主管領(lǐng)導簽字審批。 第三十八

13、條 數(shù)據(jù)遷移后，項目組對數(shù)據(jù)遷移的完整性和準確性作出檢查，出具數(shù)據(jù)遷移報告（附件十四），其中包括數(shù)據(jù)來源、轉(zhuǎn)換前狀態(tài)、轉(zhuǎn)換后狀態(tài)，數(shù)據(jù)遷移負責人、對完整性檢查情況、對準確性檢查情況等內(nèi)容。各相關(guān)部門驗收轉(zhuǎn)換結(jié)果后在該報告上簽字確認。第三十九條 系統(tǒng)轉(zhuǎn)換和數(shù)據(jù)遷移由試運行單位業(yè)務(wù)部門和公司主管領(lǐng)導共同監(jiān)督并進行驗收。 第四十條 系統(tǒng)轉(zhuǎn)換和數(shù)據(jù)遷移驗收通過后，正式啟動試運行。在試運行過程中，試運行單位辦公室把系統(tǒng)運行情況（系統(tǒng)資源使用，反應(yīng)速度等）記錄到試運行報告中。必要時，項目組應(yīng)根據(jù)系統(tǒng)運行情況對應(yīng)用系統(tǒng)進行優(yōu)化。 第四十一條 試運行達到試運行計劃規(guī)定的終止條件時，項目組編寫試運行報告（附件十

14、五）。此報告應(yīng)由項目組和試運行單位簽字確認，并提交公司主管領(lǐng)導審閱。公司主管領(lǐng)導審閱試運行結(jié)果，決定試運行結(jié)束或延期。 第九節(jié) 系統(tǒng)驗收 第四十二條 系統(tǒng)主要使用部門及技術(shù)研發(fā)部聯(lián)合組成獨立系統(tǒng)驗收小組，也可授權(quán)原項目組作為驗收小組。驗收小組從功能需求及技術(shù)需求層面對系統(tǒng)進行綜合評估。 第四十三條 驗收小組應(yīng)根據(jù)驗收情況整理形成系統(tǒng)驗收報告（附件十六）提交系統(tǒng)主要使用部門和技術(shù)研發(fā)部審閱。 第四十四條 系統(tǒng)主要使用部門和開發(fā)部門負責人根據(jù)系統(tǒng)測試、試運行情況簽署驗收意見。 第十節(jié) 系統(tǒng)上線 第四十五條 系統(tǒng)上線應(yīng)遵循穩(wěn)妥、可控、安全的原則。 第四十六條 通常情況下，系統(tǒng)上線包含數(shù)據(jù)遷移工作。

15、第四十七條 項目組制定系統(tǒng)上線計劃（附件十七），上報公司主管領(lǐng)導審批。在上線計劃得到批準后才能開始部署上線工作。 第四十八條 系統(tǒng)上線計劃內(nèi)容應(yīng)包括但不限于： （一） 部署方式和資源分配（包括人力資源及服務(wù)器資源）； （二） 上線工作時間表； （三） 上線操作步驟以及問題處理步驟； （四） 項目階段性里程碑和成果匯報（項目執(zhí)行狀態(tài)的審閱、進度安排等）； （五） 數(shù)據(jù)遷移的需求和實施計劃； （六） 完整可行的應(yīng)急預(yù)案和“回退”計劃； （七） 用戶培訓計劃（包括：培訓計劃、培訓手冊、培訓考核等）； （八） 公司下發(fā)的系統(tǒng)標準參數(shù)配置。 第四十九條 上線單位在上線初期需加強日常運行狀態(tài)監(jiān)控，出現(xiàn)問題

16、時應(yīng)及時處理，對重大問題應(yīng)啟動緊急預(yù)案。 第五十條 在完成上線后要填寫系統(tǒng)驗收評估報告（附件十八）。系統(tǒng)驗收評估報告內(nèi)容包括：數(shù)據(jù)準確性、系統(tǒng)性能及穩(wěn)定性、接口問題、權(quán)限問題、業(yè)務(wù)操作影響度、問題處理情況、備份、批處理等。 第五十一條 上線單位管理層要對系統(tǒng)驗收評估報告進行審批簽字。 第五十二條 公司主管領(lǐng)導批準結(jié)項后，業(yè)務(wù)組和開發(fā)組將整理的文檔提交各自部門統(tǒng)一管理。 第十一節(jié) 合作開發(fā)管理 第五十三條 合作開發(fā)商的選擇應(yīng)遵循公司相關(guān)規(guī)定，合作商資質(zhì)認定參見第三方管理制度。 第五十四條 合作開發(fā)商必須遵循公司軟件開發(fā)管理制度。 第五十五條 項目經(jīng)理同合作開發(fā)商明確規(guī)定項目變更的范圍和處理方式，

17、重點關(guān)注需求和設(shè)計變更。 第五十六條 項目經(jīng)理負責監(jiān)控合作開發(fā)商的項目管理及軟件開發(fā)活動。合作開發(fā)商應(yīng)按計劃定期向項目經(jīng)理報告進展狀態(tài)，并提交階段性成果文檔。發(fā)生重大問題時，合作開發(fā)商需及時向項目經(jīng)理匯報。 第五十七條 開發(fā)組組長派專人監(jiān)控合作開發(fā)商的質(zhì)量保證過程。 第五十八條 項目組同合作開發(fā)商商定驗收的標準和方法。 第五十九條 以上各要求需要在開發(fā)合同中明確。 第十二節(jié) 系統(tǒng)交付 第六十條 在系統(tǒng)驗收通過后，項目組對運維組進行系統(tǒng)維護培訓。 第六十一條 項目組提交全部經(jīng)審批的交付物給PMO存檔。 第六十二條 項目組填寫系統(tǒng)交付申請（附件十九），提交主管技術(shù)總裁審批后，交付運維組。 第十三節(jié)

18、 外包開發(fā)管理 第六十三條 立項申請得到公司主管領(lǐng)導的審批后，選定開發(fā)商，簽訂外包開發(fā)合同。 第六十四條 項目經(jīng)理負責監(jiān)控外包開發(fā)商的項目管理及軟件開發(fā)活動。外包開發(fā)商應(yīng)按計劃定期向項目經(jīng)理報告進展狀態(tài)，并提交階段性成果文檔。發(fā)生重大問題時，外包開發(fā)商需及時向項目經(jīng)理匯報。 第六十五條 項目經(jīng)理監(jiān)控外包開發(fā)商的質(zhì)量保證過程。 第六十六條 項目組同外包開發(fā)商商定驗收的標準和方法。 第六十七條 以上各要求需要在開發(fā)合同中明確。 第十四節(jié) 附則 第六十八條 本制度由公司技術(shù)研發(fā)部負責解釋和修訂。 第六十九條 本制度自發(fā)布之日起開始執(zhí)行。 附件一 立項分析報告文件狀態(tài)： 草稿 正式發(fā)布 正在修改文件標

19、識：當前版本：作 者：完成日期：版 本 歷 史版本/狀態(tài)作者參與者起止日期備注項目介紹 1.1. 項目目的 提示：用簡練的語言說明本項目“是什么”，“實現(xiàn)什么目的”。描述簡練且清晰。 1.2. 項目背景 提示：闡述項目背景，重點說明“為什么”會產(chǎn)生本項目。 （1）公司的短期、長期發(fā)展戰(zhàn)略； （2）業(yè)務(wù)需求及發(fā)展趨勢； （3）技術(shù)狀況及發(fā)展趨勢； （4）特殊的業(yè)務(wù)需求等。 1.3. 項目范圍 提示：根據(jù)對現(xiàn)有需求的了解來確定項目基本范圍，說明本系統(tǒng)“應(yīng)當包含的內(nèi)容”和“不包含的內(nèi)容”。 2. 項目計劃 2.1. 項目團隊 提示：說明項目團隊的角色、知識技能要求、建議人選、人數(shù)、工作時間，如下表所

20、示。角色知識技能要求建議人選、人數(shù)工作時間項目經(jīng)理 需求開發(fā)人員 系統(tǒng)設(shè)計人員 編程人員 測試人員 質(zhì)量保證人員 配置管理人員 服務(wù)與維護人員 2.2. 成本估計 內(nèi)容成本（人民幣）備注人力資源 軟硬件資源 差旅費 會議費 接待費 2.3. 進度表 提示：制定項目開發(fā)的進度表（建議給出項目里程碑計劃）。例如：編號里程碑名稱預(yù)計結(jié)束時間備注需求調(diào)研完成 項目計劃完成 需求分析完成 概要設(shè)計完成 詳細設(shè)計完成 實現(xiàn)完成 集成測試完成 系統(tǒng)測試完成 用戶驗收測試完成試運行結(jié)束 項目驗收 3. 總結(jié) 提示：給出清晰的建議結(jié)論，便于上級領(lǐng)導決策。附件二 業(yè)務(wù)需求說明書文件狀態(tài)： 草稿 正式發(fā)布 正在修改

21、 文件標識： ProjectName-當前版本： X.Y作 者： 完成日期： Year-Month-Day 版 本 歷 史版本/狀態(tài)作者參與者起止日期備注1概述 1.1 業(yè)務(wù)調(diào)研人員名單 【可選】序號職能部門姓名主管聯(lián)系電話備注1.2業(yè)務(wù)范圍 此處描寫總體業(yè)務(wù)的概要分類并。 1.3 業(yè)務(wù)目標 從高層或商務(wù)利益的角度提出本業(yè)務(wù)系統(tǒng)的期望目標，以及評價標準。 1.4 相關(guān)文檔 說明：列出本文檔的所有參考文獻（可以是非正式出版物），包括現(xiàn)有規(guī)范、標準、批文、引用到的文件、資料等。 1.5 業(yè)務(wù)詞匯表 說明：列出本文檔的所引用的專屬領(lǐng)域詞匯、術(shù)語等，以便于業(yè)務(wù)需求的提供者和接收者是建立在一致的業(yè)務(wù)理解

22、基礎(chǔ)之上的。 2 組織結(jié)構(gòu)及業(yè)務(wù) 2.1 業(yè)務(wù)相關(guān)組織結(jié)構(gòu)、人員組織結(jié)構(gòu) 說明：如果客戶崗位設(shè)置復雜可分別設(shè)置，業(yè)務(wù)組織結(jié)構(gòu)和人員組織結(jié)構(gòu)2.2 組織機構(gòu)描述 2.3 角色職責 說明：將業(yè)務(wù)涉及的具體人員進行一定程度的分類和抽象，描述該抽象角色的操作職責。 2.4 管理綜述 【可選】 說明：主要描述該業(yè)務(wù)的管理特點和管理模式。例如： 典型按庫存生產(chǎn)模式。生產(chǎn)計劃以年度銷售計劃為指導，并綜合考慮設(shè)備能力、生產(chǎn)天數(shù)、庫存、歷史銷售記錄。采購計劃的制訂以生產(chǎn)計劃為依據(jù)。 2.5 現(xiàn)有業(yè)務(wù)流程清單 【可選】 說明：現(xiàn)有業(yè)務(wù)流程需要考慮，很多新的業(yè)務(wù)是在已有業(yè)務(wù)流程基礎(chǔ)上進行重組的。流程編號流程名稱責任

23、部門輔助部門3 業(yè)務(wù)流程及業(yè)務(wù)處理描述 說明：針對每一項具體的目標業(yè)務(wù)，描述具體的業(yè)務(wù)流程，以及相關(guān)業(yè)務(wù)的具體描述。 3.1 具體業(yè)務(wù)流程（系統(tǒng)名稱+編號） 對于具體業(yè)務(wù)流程的命名有規(guī)范，對具體流程進行編號，便于形成需求矩陣，同時形成需求的管理和跟蹤。 3.1.1業(yè)務(wù)流程 3.1.2業(yè)務(wù)描述 說明：描述具體的業(yè)務(wù)流程。 3.1.3相關(guān)業(yè)務(wù)對象 說明：業(yè)務(wù)對象：業(yè)務(wù)流程中涉及的單據(jù)、報表等。業(yè)務(wù)對象使用部門對應(yīng)電子檔案編號3.1.4業(yè)務(wù)規(guī)則及關(guān)鍵算法 說明：描述業(yè)務(wù)環(huán)節(jié)關(guān)鍵算法體系。 4 假定和約束 說明：列出進行本軟件開發(fā)工作的假定和約束，例如開發(fā)期限等。 4.1 運行環(huán)境約束4.2 設(shè)計約束

24、 【可選】 說明：開發(fā)過程中必須使用的軟件語言、軟件進程需求、主要開發(fā)工具、核心技術(shù)、第三方產(chǎn)品等。 4.3 產(chǎn)品應(yīng)當遵循的標準或規(guī)范 【可選】 說明：闡述本產(chǎn)品應(yīng)當遵循什么標準、規(guī)范或業(yè)務(wù)規(guī)則，違反標準、規(guī)范或業(yè)務(wù)規(guī)則的產(chǎn)品通常不太可能被接受。 5 其他 5.1 目前核心問題和困難 5.2 業(yè)務(wù)對項目實施的需求和期望 【可選】 5.3 其他未盡事宜附件三 系統(tǒng)需求規(guī)格說明書文件狀態(tài)： 草稿 正式發(fā)布 正在修改 文件標識： ProjectName- 當前版本： X.Y 作 者： 完成日期： Year-Month-Day 版 本 歷 史版本/狀態(tài)作者參與者起止日期備注1 引言 1.1 目的 例如

25、：規(guī)定系統(tǒng)的邊界和目標，描述系統(tǒng)的功能性需求和非功能性需求。 1.2讀者對象及閱讀建議 說明：指明本文檔面向的讀者群，及相應(yīng)的閱讀意見。 1.3文檔范圍 【可選】 說明：對本文的范圍做闡述，本文檔改動時，受到影響的范圍，例如，本文引用到的用例模型，系統(tǒng)原型，系統(tǒng)測試用例等文檔。 1.4 參考文檔 說明：列出本文檔的所有參考文獻（可以是非正式出版物），包括計劃任務(wù)書、合同、批文、引用到的文件、資料及軟件開發(fā)標準等。 1.5 術(shù)語與縮寫解釋 說明：列出本文件中用到的專門術(shù)語的定義和縮寫詞的原詞組，并給予解釋，以便于所有讀者達成共識。 2 綜合描述 2.1 系統(tǒng)背景 【可選】 說明：介紹系統(tǒng)的預(yù)期效

26、果、歷史原因。2.2 問題說明 【可選】 提供一段說明，總結(jié)此項目需要解決的問題?？梢圆捎靡韵赂袷剑簡栴}是 對問題進行說明 影響 問題影響的干系人 問題的后果 該問題會導致什么后果 成功的解決方案 應(yīng)列出成功解決方案的一些主要優(yōu)點 2.3系統(tǒng)范圍 說明：闡述本項目“適用的業(yè)務(wù)領(lǐng)域”和“不適用的業(yè)務(wù)領(lǐng)域”，本產(chǎn)品“應(yīng)當包含的內(nèi)容”和“不包含的內(nèi)容”。說清楚系統(tǒng)范圍的好處是：（1）有助于判斷什么是需求，什么不是需求；（2）可以將開發(fā)精力集中在產(chǎn)品范圍之內(nèi)；（3）有助于控制需求的變更。 l 完整而準確的定義本產(chǎn)品的干系人； l 明確本產(chǎn)品所影響到的部門和業(yè)務(wù)； l 用圖表或者文字描述產(chǎn)品的范圍，概要

27、的定義產(chǎn)品的功能。 2.4 干系人與用戶說明 【可選】 2.4.1用戶環(huán)境 【可選】 詳細說明目標用戶的工作環(huán)境。以下是幾項建議： 該任務(wù)由多少人來完成？是否總在變化？ 一個任務(wù)周期需要多長時間？執(zhí)行每項活動要用多長時間？是否總在變化？ 是否有特殊的環(huán)境約束：移動、戶外、乘機旅行等？ 目前使用的是哪些系統(tǒng)平臺？以后會使用哪些平臺？ 還在使用哪些應(yīng)用程序？您的應(yīng)用程序是否需要和這些應(yīng)用程序集成？ 在此處可以從業(yè)務(wù)模型中摘錄一些內(nèi)容來概述所涉及的任務(wù)和角色等等。 2.4.2 干系人簡檔 【可選】 通過在下表中填寫各干系人的相關(guān)信息來說明系統(tǒng)中的各個干系人，詳盡的簡檔應(yīng)包括各種干系人在以下方面的信息

28、：代表 誰是此產(chǎn)品的干系人代表？（如在他處已作記錄，則此處為可選。）此處只需填寫姓名。 說明 對干系人類型的簡要說明。 類型 介紹干系人的技能特長、技術(shù)背景和熟練程度（即權(quán)威用戶、業(yè)務(wù)用戶、專家用戶、初級用戶等） 職責 列出干系人對所開發(fā)的系統(tǒng)負有的關(guān)鍵職責，即他們作為干系人的利益。 使用頻率 該干系人使用系統(tǒng)的頻率 意見/問題 在此處列出會阻礙成功的問題以及任何其他相關(guān)信息。 2.4.3關(guān)鍵的干系人/用戶需要 列出干系人認為現(xiàn)有解決方案存在的關(guān)鍵問題。對于列出的每個問題，需澄清以下要點： 為什么會出現(xiàn)這一問題？ 目前如何解決該問題？ 干系人需要什么樣的解決方案？ 務(wù)必要了解干系人或用戶對解決

29、各個問題的相對重視程度。分級和累積投票方法表明，必須解決的問題與干系人或用戶希望解決的問題大有不同。 2.5 目標業(yè)務(wù)模型 【可選】 說明：新系統(tǒng)業(yè)務(wù)模型描述，如有相應(yīng)業(yè)務(wù)模型材料了，可作為需求規(guī)格說明書的輸入?yún)⒖假Y料。 2.6 功能摘要 總結(jié)該產(chǎn)品將提供的主要優(yōu)點和特性，而不必涉及每個功能的細節(jié)。對功能加以組織，使客戶或初次閱讀該文檔的其他人能夠理解此功能列表。 2.7 功能清單及重要程度說明 說明：功能名稱、功能描述、重要程度。 重要程度，以ABC三類來表示：A：核心功能；B：輔助功能；C：外圍功能； 級別，按照繼承關(guān)系分為：一級，二級，三級；編號級別重要程度功能名稱功能描述備注2.8 功

30、能與業(yè)務(wù)對照關(guān)系表 說明：業(yè)務(wù)組為主編寫業(yè)務(wù)需求，業(yè)務(wù)需求提交至信息技術(shù)組后，由信息技術(shù)組建立目標技術(shù)開發(fā)管理制度 第 17 頁，共 53 頁 系統(tǒng)業(yè)務(wù)模型并與業(yè)務(wù)組進行確認（本操作可選，也可由信息技術(shù)組與開發(fā)商合作建立），目標業(yè)務(wù)模型作為系統(tǒng)需求的輸入，由信息技術(shù)組與開發(fā)商合作撰寫和評審系統(tǒng)需求規(guī)格書明書。業(yè)務(wù)需求目標系統(tǒng)業(yè)務(wù)活動（可選）功能名稱2.9 假定和約束 說明：列出進行本軟件開發(fā)工作的假定和約束，例如：開發(fā)語言、開發(fā)期限等。 格式限制說明：本項將指定由現(xiàn)有的標準或規(guī)則派生的要求。例如： 報表格式；數(shù)據(jù)命名；財務(wù)處理；審計追蹤，等等。 硬件限制說明：本項包括在各種硬件約束下運行的軟件

31、要求，例如，應(yīng)該包括： 硬件配置的特點（接口數(shù)，指令系統(tǒng)等）；內(nèi)存儲器和輔助存儲器的容量。 2.9.1運行環(huán)境約束 說明：硬件設(shè)備、支持軟件、接口、控制等方面的約束名稱詳細要求2.9.2設(shè)計約束 【可選】 說明：開發(fā)過程中必須使用的軟件語言、軟件進程需求、主要開發(fā)工具、核心技術(shù)、第三方產(chǎn)品等。 2.9.3產(chǎn)品應(yīng)當遵循的標準或規(guī)范 說明：闡述本產(chǎn)品應(yīng)當遵循什么標準、規(guī)范或業(yè)務(wù)規(guī)則，違反標準、規(guī)范或業(yè)務(wù)規(guī)則的產(chǎn)品通常不太可能被接受。 3 具體需求 3.1功能需求 3.1.1具體功能 3.1.1.1內(nèi)容 說明：對于每一類功能或者有時對于每一個功能，需要具體描述其輸入、加工和輸出的需求。3.2 非功能

32、需求 3.2.1 外部接口 3.2.1.1用戶接口 說明：提供用戶使用軟件產(chǎn)品時的接口需求。例如，如果系統(tǒng)的用戶通過顯示終端進行操作，就必須指定如下要求： a 對屏幕格式的要求 說明：對界面上的各對象、類型、寬度、取值范圍、數(shù)據(jù)來源、能否為空等屬性進行描述。 b 報表或菜單的頁面打印格式和內(nèi)容 c 輸入輸出的需求 說明：解釋各輸入輸出數(shù)據(jù)類型，并逐項說明其媒體、格式、數(shù)值范圍、精度等。對軟件的數(shù)據(jù)輸出及必須標明的控制輸出量進行解釋并舉例，包括對硬拷貝報告（正常結(jié)果輸出、狀態(tài)輸出及異常輸出）以及圖形或顯示報告的描述。 d 程序功能鍵的可用性 說明：快捷鍵定義等。 3.2.1.2 硬件接口 【可選

33、】 說明：要指出軟件產(chǎn)品和系統(tǒng)硬部件之間每一個接口的邏輯特點。還可能包括如下事宜：支撐什么樣的設(shè)備，如何支撐這些設(shè)備，有何約定。 3.2.1.3軟件接口 【可選】 說明：在此要指定需使用的其他軟件產(chǎn)品（例如，數(shù)據(jù)管理系統(tǒng)、操作系統(tǒng)或數(shù)學軟件包），以及同其他應(yīng)用系統(tǒng)之間的接口。對每一個所需的軟件產(chǎn)品，要提供如下內(nèi)容：名字、助記符、規(guī)格說明號、版本號、來源。 對于每一個接口，這部分應(yīng)說明與軟件產(chǎn)品相關(guān)的接口軟件的目的，并根據(jù)信息的內(nèi)容和格式定義接口，但不必詳細描述任何已有完整文件的接口，只要引用定義該接口的文件即可。 【接口定義】 下表是對一些接口的具體描述:接口名稱 接口描述 填寫接口完成的任務(wù)

34、 接口類型 填寫是輸入接口（inbound）還是輸出接口（outbound） 源系統(tǒng) 填寫接口輸入方系統(tǒng)或部件 目標系統(tǒng) 填寫接口輸出方系統(tǒng)或部件 廠商提供/客戶化開發(fā) 文件類型 填寫文件類型；若通過數(shù)據(jù)庫表來交互，請指明數(shù)據(jù)庫及表名 文件數(shù)量 峰值數(shù)據(jù)量 頻度 填寫數(shù)據(jù)處理的頻度 復雜度 批處理 /人工 填寫接口數(shù)據(jù)的驅(qū)動模式是人工（manual）還是自動(automatic)，還是都支持 接口類型 填寫是實時接口還是批量接口等 【其他系統(tǒng)詳細信息】 說明：列出所有與接口交互的外圍系統(tǒng)的詳細信息。包括輸入、輸出系統(tǒng)等系統(tǒng) 填寫與接口交互的系統(tǒng)名稱 系統(tǒng)類型 填寫是接口的數(shù)據(jù)源系統(tǒng)(sourc

35、e)還是目標系統(tǒng)(object) 數(shù)據(jù)庫 填寫交互系統(tǒng)使用的數(shù)據(jù)庫及版本 軟件 填寫交互系統(tǒng)的軟件名稱 架構(gòu)類型 交互系統(tǒng)的架構(gòu)類型是B/S 還是C/S。 位置 填寫該軟件在交互軟件體系中所出的位置 技術(shù)支持 填寫交互系統(tǒng)的開發(fā)商和支持商 功能支持 填寫具體的支持商或技術(shù)團隊 數(shù)據(jù)歸屬 【接口隸屬系統(tǒng)的詳細信息可選 】系統(tǒng) 填寫接口隸屬系統(tǒng)的名稱 模塊 隸屬于具體的模塊名稱 數(shù)據(jù)庫 隸屬系統(tǒng)的數(shù)據(jù)庫及版本 負責人 控制報告 【接口配置】 （1）接口基礎(chǔ)信息配置 說明：接口基礎(chǔ)信息的配置項目，描述配置的方式。 （2）接口運行參數(shù)配置 說明：接口運行參數(shù)的配置方式和步驟。 【其他配置可選 】 說明

36、：外圍系統(tǒng)或相關(guān)模塊的配置。 3.2.1.4通信接口 【可選】 說明：指定各種通信接口。例如，局部網(wǎng)絡(luò)的協(xié)議等等。 3.2.2 其他非功能性需求 說明：下表中的各種需求，可根據(jù)實際情況進行選擇其中的一種或者幾種進行描述，在表的后面是各種需求的詳細解釋。名稱詳細要求靜態(tài)數(shù)值需求動態(tài)數(shù)值需求精度 時間特性要求可用性 可靠性 可維護性 安全性 可移植性 可擴展性 兼容性 3.2.2.1 靜態(tài)數(shù)值需求 說明：支持的終端數(shù)；支持并行操作的用戶數(shù)。 3.2.2.2 動態(tài)數(shù)值需求說明：欲處理的事務(wù)和任務(wù)的數(shù)量，以及在正常情況下和峰值工作條件下一定時間周期中處理的數(shù)據(jù)總量。 3.2.2.3 精度 說明:對該軟

37、件的輸入、輸出數(shù)據(jù)精度的要求，可能包括傳輸過程中的精度。 3.2.2.4時間特性要求 說明：對于該軟件的時間特性要求，如對： a響應(yīng)時間； b更新處理時間； c數(shù)據(jù)的轉(zhuǎn)換和傳送時間； d解題時間等要求。 3.2.2.5 數(shù)據(jù)管理要求 【可選】 說明：需要管理的文卷和記錄的個數(shù)、表和文卷的大小規(guī)模，要按可預(yù)見的增長對數(shù)據(jù)及其分量的存儲要求做出估算。 3.2.2.6 可用性 指出普通用戶和高級用戶要高效地執(zhí)行特定操作所需的培訓時間，指出典型任務(wù)的可評測任務(wù)次數(shù)或根據(jù)用戶已知或喜歡的其他系統(tǒng)確定新系統(tǒng)的可用性需求 性能 3.2.2.7可靠性 指出可用時間百分比 ( xx.xx%)、使用小時數(shù)、維護訪

38、問權(quán)、降級模式操作等。平均故障間隔時間 (MTBF)。平均修復時間 (MTTR)系統(tǒng)在發(fā)生故障后可以暫停運行的時間。指出系統(tǒng)輸出要求具備的精密度（分辨率）和精確度（按照某一已知的標準）。 3.2.3文檔需求 說明：主要是在線用戶手冊與幫助系統(tǒng)，也包括其他的文檔 3.2.4 第三方產(chǎn)品 【可選】 說明：使用到的第三方產(chǎn)品相關(guān)的 使用許可、使用限制、接口標準。 3.3 數(shù)據(jù)字典 說明：把相關(guān)的數(shù)據(jù)抽取出來統(tǒng)一維護，在其他章節(jié)如有類似信息描述，則關(guān)聯(lián)到數(shù)據(jù)字典的相關(guān)部分并加輔助說明，如：引用到的字段等。 4 補充資料 【可選】4.1待確定的問題列表 【可選】需求標題1 調(diào)查方式 調(diào)查人 調(diào)查對象 時

39、間、地點 需求信息記錄 附件四 需求變更申請 記錄號：項 目： 類 型： 開發(fā)項目 項目負責人： 變更申請人： 申請部門： 申請日期： 變更內(nèi)容變更的內(nèi)容 及其理由 說明變更的內(nèi)容及變更的理由， 如果變更為業(yè)務(wù)組提出，則業(yè)務(wù)組填寫； 如果變更為為信息技術(shù)組提出，則信息技術(shù)組填寫； 變更的系統(tǒng)及版本 說明變更所涉及的工作產(chǎn)品及其當前版本， 如果變更為業(yè)務(wù)組提出，則業(yè)務(wù)組填寫； 如果變更為為信息技術(shù)組提出，則信息技術(shù)組填寫； 對業(yè)務(wù)及其接口的影響 分析需求變更引起的業(yè)務(wù)變更、業(yè)務(wù)接口的變更， 業(yè)務(wù)組填寫 業(yè)務(wù)負責人意見： 同意 不同意 簽字 日期： 變更結(jié)果變更分析對相關(guān)的資源影響 分析需求變更對

40、人員、開發(fā)設(shè)備和目標設(shè)備的影響， 僅信息技術(shù)組填寫 風險分析 分析需求變更的風險， 僅信息技術(shù)組填寫 對其他系統(tǒng)或接口的影響 分析需求變更引起的系統(tǒng)變更、其他系統(tǒng)或接口的變更， 僅信息技術(shù)組填寫 對開發(fā)工作量、進度和成本影響 估計需求變更對開發(fā)工作量和進度的影響，需說明本次變更工作量/成本是否超過本項目總開發(fā)工作量/總成本的1%？ 僅信息技術(shù)組填寫 開發(fā)部審批意見 信息技術(shù)組負責人意見： 同意 不同意指定驗證人員： 簽字： 日期： 處經(jīng)理意見： 同意 不同意 匯報上級 簽字： 日期： 上級經(jīng)理意見： 同意 不同意簽字： 日期： 變更結(jié)果變更的系統(tǒng)及版本 說明變更后的工作產(chǎn)品 簽字： 日期： 變

41、更驗證驗證變更結(jié)果 完整性 是 否 正確性 是 否 是 否附加變更 是 否 版本和名稱 是 否驗證人意見： 符合要求 不符合要求 簽字： 日期：附件五 項目計劃書文件狀態(tài)： 草稿 正式發(fā)布 正在修改 文件標識： ProjectName- 當前版本： X.Y 作 者： 完成日期： Year-Month-Day 版 本 歷 史版本/狀態(tài)作者參與者起止日期備注1 文檔介紹 1.1 文檔目的 1.2文檔范圍 1.3參考文獻 提示： 列出本文檔的所有參考文獻（可以是非正式出版物），格式如下： 標識符 作者，文獻名稱，出版單位（或歸屬單位），日期 例如： AAA 作者，立項建議書，機構(gòu)名稱，日期 1.5

42、術(shù)語與縮寫解釋縮寫、術(shù)語解 釋2 項目介紹 2.1項目范圍 提示： （1）用簡練的語言說明本項目“是什么”，“說明用途”。 （2）說明本項目“應(yīng)當包含的內(nèi)容”和“不包含的內(nèi)容”。2.2項目目標 提示：給出“清晰的”、“可實現(xiàn)”、“可驗證”的目標。 2.3客戶與最終用戶介紹 提示：請說明本項目的客戶、用戶及其相關(guān)責任人是誰，描述最終用戶的特征。 2.4 約束 提示： （1）請說明在項目開發(fā)過程中應(yīng)當遵循的標準或規(guī)范 （2）請說明相關(guān)項目可能對本項目造成的影響。 （3）說明一些假設(shè)和依賴。 3 項目過程定義 3.1軟件生命周期模型 提示：簡要描述、繪制本項目的軟件生命周期模型。 3.2項目規(guī)范 提

43、示：描述項目需遵循的規(guī)范，例如：編碼規(guī)范。此處可以表現(xiàn)為編碼規(guī)范的鏈接。 3.3方法與工具 提示：說明在過程中將采用的方法與工具。例如采用Rational Rose進行面向?qū)ο蠓治雠c設(shè)計，采用Visual SourceSafe進行配置管理，采用Microsoft Office制作文檔。方法與工具用途Visual SourceSafe 配置管理 4 里程碑計劃序號里程碑名稱開始日期結(jié)束日期工作成果備注5 資源計劃 5.1人力資源計劃 提示：制定本項目的角色職責表，并為已知的項目成員分配角色（一個人可以兼多個角色）。角色職責人員姓名工作說明高層領(lǐng)導 項目經(jīng)理 需求分析員 系統(tǒng)設(shè)計員 程序員 測試員

44、 5.2 軟硬件資源計劃 提示：分析項目開發(fā)、測試、運行所需的軟硬件資源和關(guān)鍵計算機資源（會影響軟件產(chǎn)品的性能的CPU、內(nèi)存、帶寬等內(nèi)容），主要內(nèi)容包括： l 資源級別（分為“關(guān)鍵”、“普通”兩種） l 詳細配置 l 方式（如“已經(jīng)存在”、“可以借用”或“需要購買”等）與獲取時間 l 使用說明（如“誰”在“什么”時候使用）軟硬件資源名稱級別詳細配置獲取方式與時間使用說明關(guān)鍵 關(guān)鍵 普通 6 文檔交付列表序號交付文檔名稱交付日期備注7 風險管理計劃 提示：以下是各個列標題的解釋。 約定在項目中的風險管理方案，例如：風險識別頻度、風險跟蹤頻度等。 風險級別：確定風險的嚴重性、可能性、風險系數(shù) 風險

45、描述：緩解方案或者應(yīng)急計劃。風險編號風險級別風險描述緩解方案應(yīng)急計劃嚴重性 (1-5) 可能性 (%) 風險系數(shù) (嚴重性*可能性) 8 溝通計劃甲方代表乙方代表溝通方式溝通頻率/時間期望結(jié)果9 附件 l項目進度計劃 附件六 項目計劃變更說明項目名稱 申請日期 項目計劃變更申請 申請變更的 項目計劃 輸入名稱，版本，完成日期等信息 變更的內(nèi)容 及其理由 評估計劃變更將對 項目造成的影響 項目負責人簽字 變更申請的審批意見 處經(jīng)理審批 審批意見： 簽字： 日期 開發(fā)部負責人審批 審批意見： 簽字： 日期 業(yè)務(wù)部門意見 審批意見： 簽字： 日期 更改項目計劃 變更后的 項目計劃 輸入名稱，版本，完

46、成日期等信息 項目負責人簽字 附件七 設(shè)計說明書文件狀態(tài)： 草稿 正式發(fā)布 正在修改 文件標識： ProjectName- 當前版本： X.Y 作 者： 完成日期： Year-Month-Day 版 本 歷 史版本/狀態(tài)作者參與者起止日期備注1引言 1.1編寫目的 說明編寫這份詳細設(shè)計說明書的目的，指出預(yù)期的讀者。 1.2背景 說明： 待開發(fā)軟件系統(tǒng)的名稱； 本項目的任務(wù)提出者、開發(fā)者、用戶和運行該程序系統(tǒng)的計算中心。 1.3定義 列出本文件中用到專門術(shù)語的定義和外文首字母組詞的原詞組。 1.4參考資料 列出有關(guān)的參考資料，如： 本項目的經(jīng)核準的計劃任務(wù)書或合同、上級機關(guān)的批文； 屬于本項目的

47、其他已發(fā)表的文件； 本文件中各處引用到的文件資料，包括所要用到的軟件開發(fā)標準。列出這些文件的標題、文件編號、發(fā)表日期和出版單位，說明能夠取得這些文件的來源。 2程序系統(tǒng)的結(jié)構(gòu) 用一系列圖表列出本程序系統(tǒng)內(nèi)的每個程序（包括每個模塊和子程序）的名稱、標識符和它們之間 的層次結(jié)構(gòu)關(guān)系。 3程序1（標識符）設(shè)計說明 從本章開始，逐個地給出各個層次中的每個程序的設(shè)計考慮。以下給出的提綱是針對一般情況的。對于一個具體的模塊，尤其是層次比較低的模塊或子程序，其很多條目的內(nèi)容往往與它所隸屬的上一層 模塊的對應(yīng)條目的內(nèi)容相同，在這種情況下，只要簡單地說明這一點即可。 3.1程序描述 給出對該程序的簡要描述，主要

48、說明安排設(shè)計本程序的目的意義，并且，還要說明本程序的特點（如 是常駐內(nèi)存還是非常駐？是否子程序？是可重人的還是不可重人的？有無覆蓋要求？是順序處理還是并發(fā)處理等）。 3.2功能 說明該程序應(yīng)具有的功能，可采用IPO圖（即輸入一處理一輸出圖）的形式。 3.3性能 說明對該程序的全部性能要求，包括對精度、靈活性和時間特性的要求。3.4輸人項 給出對每一個輸入項的特性，包括名稱、標識、數(shù)據(jù)的類型和格式、數(shù)據(jù)值的有效范圍、輸入的方式。數(shù)量和頻度、輸入媒體、輸入數(shù)據(jù)的來源和安全保密條件等等。 3.5輸出項 給出對每一個輸出項的特性，包括名稱、標識、數(shù)據(jù)的類型和格式，數(shù)據(jù)值的有效范圍，輸出的形式、數(shù)量和頻

49、度，輸出媒體、對輸出圖形及符號的說明、安全保密條件等等。 3.6算法 詳細說明本程序所選用的算法，具體的計算公式和計算步驟。 3.7流程邏輯 用圖表（例如流程圖、判定表等）輔以必要的說明來表示本程序的邏輯流程。 3.8接口 用圖的形式說明本程序所隸屬的上一層模塊及隸屬于本程序的下一層模塊、子程序，說明參數(shù)賦值和調(diào)用方式，說明與本程序相直接關(guān)聯(lián)的數(shù)據(jù)結(jié)構(gòu)（數(shù)據(jù)庫、數(shù)據(jù)文卷）。 3.9存儲分配 根據(jù)需要，說明本程序的存儲分配。 3.10注釋設(shè)計 說明準備在本程序中安排的注釋，如： 加在模塊首部的注釋； 加在各分枝點處的注釋； 對各變量的功能、范圍、缺省條件等所加的注釋； 對使用的邏輯所加的注釋等等。 3.11限制條件 說明本程序運行中所受到的限制條件。 3.12測試計劃 說明對本程序進行單體測試的計劃，包括對測試的技術(shù)要求、輸入數(shù)據(jù)、預(yù)期結(jié)果、進度安排、人員職責、設(shè)備條件驅(qū)動程序及樁模