軟件開發管理制度

版本：VI.0

2013年1月

第一節總則

第一條為規范自有軟件研發以及外包軟件的管理工作，特制定本制度。本制度適用

于公司總公司軟件研發與管理，分公司參照執行。

第二條本制度中軟件開發指新系統開發和現有系統重大改造。

第三條本制度中自行開發是指主要依賴公司自身的管理、業務和技術力量進行系統

設計、軟件開發、集成和相關的技術支持工作，一般僅向外購置有關的硬件

設備和支撐軟件平臺；合作開發是公司與專業IT公司（合作商）共同協作

完成IT應用的項目實施和技術支持工作，一般形式是公司負責提供業務框

架，合作商提供技術框架，雙方組成開發團隊進行項目實施，IT系統的日常

支持由IT技術中心和合作商共同承擔，IT技術中心負責內部（一級）支

持，合作商負責外部（二級）支持；外包開發是指將IT應用項目的設計、

開發、集成、培訓等任務承包給某家專業公司（可以是專業的IT公司或咨

詢公司等），由該公司（承包商）負責應用項目的實施。

第四條軟件開發遵循項目管理和軟件工程的基本原則。項目管理涉及立項管理、

項目計劃和監控、配置管理、合作開發管理和結項管理。軟件工程涉及需求

管理、系統設計、系統實現、系統測試、用戶接受測試、試運行、系統驗

收、系統上線和數據遷移。

第五條除特別指定，本制度中項目組包括業務組（或需求提出組）、IT組（可能包

括網絡管理員和合作開發商）。

第二節立項管理

第六條提出開發需求的信息技術部門參與公司層面立項，進行立項的技術可行性分

析，編寫《立項分析報告》（附件一），開展前期籌備工作。《立項分析報

告》應明確項目的范圍和邊界C

第七條應用系統主要使用部門將《立項分析報告》上交公司總裁室進行立項審批，

以保證系統項目與公司整體策略相一致。

第八條《立項分析報告》得到批準后，成立項目組（如果是外包開發，則成立外包

商項目組；如果是合作開發，則與外包商共同成立合作開發項目組，以下統

稱“項目組”），項目組應包括業務組（由公司相關業務部門組成）和IT組

（自行開發為辦公室網絡管理員；外包開發為外包商成員；合作開發為網絡

第1頁，共53頁

管理員和外包商成員）。公司委派一名員工負責監督項目的進度，進行項目

管理工作，確保開發能及時完成并能滿足業務需要。項目組人員的選擇應滿

足項目對業務及技術要求，項目組人員應有足夠的業務和IT技術方面的專

業知識來勝任項目各方面的工作。

第三節需求分析

第九條立項后業務組對用戶需求進行匯總整理，出具《業務需求說明書》：附件

-）,并確?！稑I務需求說明書》中包含了所有的業務需求。經系統使用部

門審批確認，作為業務需求基線。

第十條IT組在獲得《業務需求說明書》后，提出技術需求和解決方案，并對系統進

行定義，出具《系統需求規格說明書》（附件三）?！断到y需求規格說明書》

需詳細列出業務對系統的要求（界面、輸入、輸出、管理功能、安全需求、

運作模式、關鍵指標（KPI）等）。《系統需求規格說明書》需要由業務組提交

給相關業務流程負責人確認。

第十一條對于合作開發的項目，當業務需求發生變更時，業務組應提交《需求變更申

請》（附件四），IT組組長審批后交給合作開發商實施。

第十二條項目組應對需求變更影響到的文檔及時更新。

第四節項目計劃和監控

第十三條軟件開發采用項目形式進行管理。項目經理負責整個項目的計劃、組織、領

導和控制。

第十四條需求分析過程中，項目經理組織制定詳細的《項目計劃書》（附件五），包括

具體任務描述和項目進度表等。

第十五條在項目的各個階段，業務組組長和IT組組長需配合項目經理制定階段性項

目計劃.業務組組長和IT組組長需配合項目經理對項目計劃執行情況進行

監控，確保項目按計劃完成。

第十六條項目計劃需要變更時，項目經理填寫《項目計劃變更說明》（附件六），并提

交公司主管領導審批，通過審批后，交給業務組組長和IT組組長執行。

第五節系統設計

第十七條系統設計應分為概要設計和詳細設計，系統設計要遵循完備性、一致性、擴

第2頁，共53頁

展性、可靠性、安全性、可維護性等原則。

第十八條在系統設計階段中，用戶應充分參與，確保系統設計能滿足系統需求。

第十九條項目組進行詳細設計，出具《設計說明書》（附件七）和《單元測試用例》

（附件八）。《設計說明書》中需要定義系統輸入輸出說明和接口設計說明。

公司主管領導組織相關人員對概要設計進行評審，出具《設計評審報告》

（附件九）。業務組組長和IT組組長應參加此評審并對評審意見簽字確認。

第二十條設計評審均以《業務需求說明書》和《系統需求規格說明書》為依據，確保

系統設計滿足全部需求。

第二十一條對已確認通過的系統設計進行修改需獲得管理部門、業務組組長和IT組組

長的審批后方可進行。

第二十二條對系統設計的修改的文檔須由文檔管理人員進行歸檔管理。

第六節系統實現

第二十三條項目組根據《設計說明書》制定系統實現計劃，并提交項目經理對計劃可行

性進行審批。

第二十四條系統實現包括程序編碼、單元測試和集成測試。

第二十五條項目組保證開發、測試和生產環境獨立，為各環境建立訪問權限控制機制，

并明確項目成員的職責分工。對開發環境,測試環境與生產環境在物理或邏

輯方面應該做到隔離；如果環境的分隔是通過邏輯形式實現的，應定期檢查

網絡設置。項目組對已授權訪問生產環境的人員進行詳細記錄，并對該記錄

進行定期檢查，確保只有經授權的人員才能訪問到生產環境。

第二十六條項目組進行單元測試和集成測試，測試人員簽字確認測試結果。

第七節系統測試和用戶測試

第二十七條項目組制定《系統/用戶測試計劃》（附件十），并提交項目經理對計劃可行

性進行審批。

第二十八條《系統/用戶測試計劃》必須定義測試標準，并明確各種測試的測試步驟和

需要的系統設置要求。

第二十九條項目組向數據擁有部門申請獲取測試用業務數據的使用權，對獲取的數據進

行嚴格的訪問控制，確保只有相關項目人員才能訪問及使用。

第三十條項目組負責測試數據準備，測試用數據要足夠模擬生產環境中的實際數據。

第3頁，共53頁

對已評定為敏感信息的數據進行敏感性處理和保護。

第三十一條IT組或合作開發商建立測試環境進行系統測試。在系統測試中對新系統內部

各模塊之間的接口和與其他系統的接口進行充分測試。出具《系統測試報

告》（附件十一），測試人員簽字確認測試結果。

第三十二條系統測試通過后，IT組配合業務組建立用戶測試環境，業務組根據用尸測試

用例進行用戶測試，出具《用戶測試報告》（附件十一），業務組組長和IT

組組長應在用戶測試報告中簽字確認。

第三十三條項目組完成系統幫助文檔（其中包括《用戶操作手冊》和《安裝維護手

冊》）。凡涉及應用系統的變更，應對系統幫助文檔及時更新。

第八節試運行

第三十四條系統主要使用部門根據項目規模及影響決定試運行策略。

第三十五條項目組制定《試運行計劃》（附件十二），并制定試運行驗收指標，上報公司

主管領導審批?！对囘\行計劃》中應包含問題應對機制，明確問題溝通渠道

和職責分工。

第三十六條項目組聯合試運行單位進行相關系統部署工作，準備培訓資料，對相關用戶

和信息技術人員進行培訓。用戶培訓的完成度應為實施后評估的指標之一。

第三十七條項目組根據《試運行計劃》進行系統轉換和數據遷移。系統轉換前，檢查系

統環境，確保運行環境能滿足新應用系統的需要。系統轉換時必須詳細記錄

原系統中的重要參數、設置等系統信息，并填寫試運行報告相關內容。系統

參數、設置的轉換工作作為系統上線的驗收的評估指標之一。

第三十八條數據遷移前，應制定詳細的《數據遷移計劃》（附件十三），《數據遷移計

劃》中應包含遷移方案、測試方案、數據定義，新舊數據對照表、遷移時

間、回退計劃等信息。數據遷移計劃需經項目經理和主管領導簽字審批。

第三十九條數據遷移后，項目組對數據遷移的完整性和準確性作出檢查，出具《數據遷

移報告》（附件十四），其中包括數據來源、轉換前狀態、轉換后狀態，數據

遷移負責人、對完整性檢查情況、對準確性檢查情況等內容。各相關部門驗

收轉換結果后在該報告上簽字確認。

第四十條系統轉換和數據遷移由試運行單位業務部門和公司主管領導共同監督并進行

驗收。

第四十一條系統轉換和數據遷移驗收通過后，正式啟動試運行。在試運行過程中，試運

行單位辦公室把系統運行情況（系統資源，史用，反應速度等）記錄到試運行

第4頁，共53頁

報告中。必要時，項目組應根據系統運行情況對應用系統進行優化。

第四十二條試運行達到試運行計劃規定的終止條件時，項目組編寫《試運行報告》（附

件十五）。此報告應由項目組和試運行單位簽字確認，并提交公司主管領導

審閱。公司主管領導審閱試運行結果，決定試運行結束或延期。

第九節系統驗收

第四十三條系統主要使用部門及信息技術部門聯合組成獨立系統驗收小組，也可授權原

項目組作為驗收小組。驗收小組從功能需求及技術需求層面對系統進行綜合

評估。

第四十四條驗收小組應根據驗收情況整理形成《系統驗收報告》（附件十六）提交系統

主要使用部門和信息技術部門審閱。

第四十五條系統主要使用部門和信息技術部門負責人根據系統測試、試運行情況簽署驗

收意見。

第十節系統上線

第四十六條系統上線應遵循穩妥、可控、安全的原則。

第四十七條通常情況下，系統上線包含數據遷移工作。

第四十八條項目組制定《系統上線計劃》（附件十七），上報公司主管領導審批。在上線

計劃得到批準后才能開始部署上線工作。

第四十九條《系統上線計劃》內容應包括但不限于：

1、部署方式和資源分配（包括人力資源及服務器資源）；

2、上線工作時間表；

3、上線操作步驟以及問題處理步驟；

4、項目階段性里程碑和成果匯報（項目執行狀態的審閱、進度安排等）；

5、數據遷移的需求和實施計劃；

6、完整可行的應急預案和“回退”計劃；

7、用戶培訓計劃（刨舌：培訓計劃、培訓手冊、培訓考核等）；

8、總公司下發的系統標準參數配置。

第五十條上線單位在上線初期需加強日常運行狀態監控，出現問題時應及時處理，對

重大問題應啟動緊急預案。

第五十一條在完成上線后要填寫《系統驗收評估報告》（附件十八），上報總公司項目組

第5頁，共53頁

匯總整理?！断到y驗收評估報告》內容包括：數據準確性、系統性能及穩定

性、接口問題、權限問題、業務操作影響度、問題處理情況、備份、批處理

等。

第五十二條上線單位管理層要對《系統驗收評估報告》進行審批簽字。

第五十三條公司主管領導批準結項后，業務組和IT組將整理的文檔提交各自部門統一

管理。

第十一節合作開發管理

第五十四條合作開發商的選擇應遵循公司相關規定，合作商資質認定參見第三方管理制

度。

第五十五條合作開發商必須遵循公司《軟件開發管理制度》。

第五十六條項目經理同合作開發商明確規定項目變更的范圍和處理方式，重點關注需求

和設計變更。

第五十七條項目經理負責監控合作開發商的項目管理及軟件開發活動。合作開發商應按

計劃定期向項目經理報告進展狀態，并提交階段性成果文檔。發生重大問題

時，合作開發商需及時向項目經理匯報。

第五十八條IT組組長派專人監控合作開發商的質量保證過程。

第五十九條項目組同合作開發商商定驗收的標準和方法。

第六十條以上各要求需要在開發合同中明確。

第6頁，共53頁

第十二節外包開發管理

第六十一條立項申請得到公司主管領導的審批后，選定開發商，簽訂外包開發合同。

第六十二條項目經理負責監控外包開發商的項目管理及軟件開發活動。外包開發商應按

計劃定期向項目經理報告進展狀態，并提交階段性成果文檔。發生重大問題

時，外包開發商需及時向項目經理匯報。

第六十三條項目經理監控外包開發商的質量保證過程.

第六十四條項目組同外包開發商商定驗收的標準和方法。

第六十五條以上各要求需要在開發合同中明確。

第十三節附則

第六十六條本制度由公司總部信息技術部負責解釋和修訂。

第六十七條本制度自發布之日起開始執行。

第7頁，共53頁

附件一立項分析報告

文件狀態：文件標識：ProjectName-

[V]草稿當前版本：X.Y

[]正式發布作者：

[]正在修改完成日期：Year-Month-Day

版本歷史

版本/狀態作者參與者起止日期備注

1.項目介紹

1.1.項目目的

提示:用簡練的語言說明本項目“是什么”,“實現什么目的”。描述簡練且清晰。

1.2.項目背景

提示:闡述項目背景,重點說明“為什么”會產生本項目。

(1)公司的短期、長期發展戰略;

(2)業務需求及發展趨勢;

(3)技術狀況及發展趨勢;

(4)特殊的業務需求等。

1.3.項目范圍

提示:根據對現有需求的了解來確定項目基本范圍,說明本系統〃應當包含的內容”

和〃不包含的內容”。

2.項目計劃

2.1.項目團隊

提示:說明項目團隊的角色、知識技能要求、建議人選、人數、工作時間,如下表所

角色知識技能要求建議人選、人數工作時間

項目經理

需求開發人員

系統設計人員

第8頁，共53頁

編程人員

測試人員

質量保證人員

配置管理人員

服務與維護人員

2.2.成本估計

內容成本（人民幣）備注

人力資源

軟硬件資源

差旅費

會議費

接待費

*■?

2.3.進度表

提示:制定項目開發的進度表（建議給出項目里程碑計劃）。例如:

編號里程碑名稱預計結束時間備注

需求調研完成

項目計劃完成

需求分析完成

概要設計完成

詳細設計完成

實現完成

集成測試完成

系統測試完成

用戶驗收測試完成

試運行結束

項目驗收

3.總結

提示:給出清晰的建議結論,便于上級領導決策。

第9頁，共53頁

附件二業務需求說明書

文件狀態：文件標識：ProjectName-

[V]草稿當前版本：X.Y

[]正式發布作者：

[]正在修改完成日期：Year-Month-Day

版本歷史

版本/狀態作者參與者起止日期備注

1概述

1.1業務調研人員名單

【可選】

序號職能部門姓名主管聯系電話備注

1.2業務范圍

此處描寫總體業務的概要分類并。

1.3業務目標

從高層或商務利益的角度提出本業務系統的期望目標，以及評價標準。

1.4相關文檔

說明：列出本文檔的所有參考文獻（可以是非正式出版物），包括現有規范、標準'批文、

引用到的文件、資料等。

1.5業務詞匯表

說明：列出本文檔的所引用的專屬領域詞匯、術語等，以便于業務需求的提供者和接收者

是建立在一致的業務理解基礎之上的。

2組織結構及業務

2.1業務相關組織結構、人員組織結構

說明：如果客戶崗位設置復雜可分別設置，業務組織結構和人員組織結構

第10頁，共53頁

2.2組織機構描述

2.3角色職責

說明：將業務涉及的具體人員進行一定程度的分類和抽象，描述該抽象角色的操作職責。

2.4管理綜述

【可選】

說明：主要描述該業務的管理特點和管理模式。例如：

典型按庫存生產模式。生產計劃以年度銷售計劃為指導，并綜合考慮設備能力、生產

天數、庫存、歷史銷售記錄。采購計劃的制訂以生產計劃為依據。

2.5現有業務流程清單

【可選】

說明：現有業務流程需要考慮，很多新的業務是在已有業務流程基礎上進行重組的。

流程編號流程名稱責任部門輔助部門

3業務流程及業務處理描述

說明：針對每一項具體的目標業務，描述具體的業務流程，以及相關業務的具體描述。

3.1具體業務流程（系統名稱+編號）

對于具體業務流程的命名有規范，對具體流程進行編號，便于形成需求矩陣，同時形成需

求的管理和跟蹤c

3.1.1業務流程

3.1.2業務描述

說明：描述具體的業務流程。

3.1.3相關業務對象

說明：業務對象：業務流程中涉及的單據、報表等。

業務對象使用部門對應電子檔案編號

3.1.4業務規則及關鍵算法

說明：描述業務環節關鍵算法體系。

4假定和約束

說明：列出進行本軟件開發工作的假定和約束，例如開發期限等。

4.1運行環境約束

第11頁，共53頁

4.2設計約束

【可選】

說明：開發過程中必須使用的軟件語言、軟件進程需求、主要開發工具、核心技術、第三

方產品等。

4.3產品應當遵循的標準或規范

【可選】

說明：闡述本產品應當遵循什么標準、規范或業務規則，違反標準、規范或業務規則的產

品通常不太可能被接受。

5其他

5.1目前核心問題和困難

5.2業務對項目實施的需求和期望

【可選】

5.3其他未盡事宜

第12頁，共53頁

附件三系統需求規格說明書

文件狀態：文件標識：ProjectName-

[V]草稿當前版本：X.Y

[]正式發布作者：

[]正在修改完成日期：Year-Month-Day

版本歷史

版本/狀態作者參與者起止日期備注

1引言

1.1目的

例如：規定系統的邊界和目標，描述系統的功能性需求和非功能性需求。

1.2讀者對象及閱讀建議

說明：指明本文檔面向的讀者群，及相應的閱讀意見。

1.3文檔范圍

【可選】

說明：對本文的范圍做闡述，本文檔改動時，受到影響的范圍，例如，本文引用到的用例

模型，系統原型，系統測試用例等文檔。

1.4參考文檔

說明：列出本文檔的所有參考文獻（可以是非正式出版物），包括計劃任務書、合同、批

文、引用到的文件、資料及軟件開發標準等。

1-5術語與縮寫解釋

說明：列出本文件中用到的專門術語的定義和縮寫詞的原詞組，并給予解釋，以便于所有

讀者達成共識。

2綜合描述

2.1系統背景

【可選】

說明：介紹系統的預期效果、歷史原因。

第13頁，共53頁

2.2問題說明

【可選】

提供一段說明，總結此項目需要解決的問題。可以采用以下格式:

問題是［對問題進行說明］

影響［問題影響的干系人］

問題的后果［該問題會導致什么后吳］

成功的解決方案［應列出成功解決方案的一些主要優點］

2.3系統范圍

說明：闡述本項目“適用的業務領域”和“不適用的業務領域”，本產品“應當包含的內

容”和“不包含的內容說清楚系統范圍的好處是：（1）有助于判斷什么是需求，什么不

是需求；（2）可以將開發精力集中在產品范圍之內；（3）有助于控制需求的變更。

?完整而準確的定義本產品的干系人；

?明確本產品所影響到的部門和業務；

?用圖表或者文字描述產品的范圍，概要的定義產品的功能。

2.4干系人與用戶說明

【可選】

2.4.1用戶環境

【可選】

詳細說明目標用戶的工作環境。以下是幾項建議：

該任務由多少人來完成？是否總在變化？

一個任務周期需要多長時間？執行每項活動要用多長時間？是否總在變化？

是否有特殊的環境約束：移動、戶外、乘機旅行等？

目前使用的是哪些系統平臺？以后會使用哪些平臺？

還在使用哪些應用程序？您的應用程序是否需要和這些應用程序集成？

在此處可以從業務模型中摘錄一些內容來概述所涉及的任務和角色等等。

2.4.2干系人簡檔

【可選】

通過在下表中填寫各干系人的相關信息來說明系統中的各個干系人，詳盡的簡檔應包括各

種干系人在以下方面的信息：

代表［誰是此產品的干系人代表？（如在他處已作記錄，則此處為可選。）

此處只需填寫姓名。］

第14頁，共53頁

說明［對干系人類型的簡要說明。］

類型［介紹干系人的技能特長、技術背景和熟練程度（即權威用戶、業務用

戶、專家用戶、初級用戶等）］

職責［列出干系人對所開發的系統負有的關鍵職責，即他們作為干系人的利

益。］

使用頻率［該干系人使用系統的頻率］

意見/問題［在此處列出會阻礙成功的問題以及任何其他相關信息。］

2.4.3關鍵的干系人/用戶需要

列出干系人認為現有解決方案存在的關鍵問題。對于列出的每個問題，需澄清以下要點：

?為什么會出現這一問題？

?目前如何解決該問題？

?干系人需要什么樣的解決方案？

務必要了解干系人或用戶對解決各個問題的相對重視程度。分級和累積投票方法表明，必

須解決的問題與干系人或用戶希望解決的問題大有不同。

2.5目標業務模型

【可選】

說明：新系統業務模型描述，如有相應業務模型材料了，可作為需求規格說明書的輸入參

考資料。

2.6功能摘要

總結該產品將提供的主要優點和特性，而不必涉及每個功能的細節。對功能加以組織，使

客戶或初次閱讀該文檔的其他人能夠理解此功能列表。

2.7功能清單及重要程度說明

說明：功能名稱、功能描述,重要程度。

重要程度，以ABC三類來表示：A：核心功能；B：輔助功能；C：外圍功能；

級別，按照繼承關系分為：一級，二級，三級；

編號級別重要程度功能名稱功能描述備注

2.8功能與業務對照關系表

說明：業務組為主編寫業務需求，業務需求提交至信息技術組后，由信息技術組建立目標

第15頁，共53頁

系統業務模型并與業務組進行確認（本操作可選，也可由信息技術組與開發商合作建立），

目標業務模型作為系統需求的輸入，由信息技術組與開發商合作撰寫和評審《系統需求規

格書明書》。

業務需求目標系統業務活動（可選）功能名稱

2.9假定和約束

說明：列出進行本軟件開發工作的假定和約束，例如：開發語言、開發期限等。

格式限制說明：本項將指定由現有的標準或規則派生的要求。例如：

報表格式；數據命名；財務處理；審計追蹤，等等。

硬件限制說明：本項包括在各種硬件約束下運行的軟件要求，例如，應該包括:

硬件配置的特點（接口數，指令系統等）；內存儲器和輔助存儲器的容量。

2.9.1運行環境約束

說明：硬件設備、支持軟件、接口、控制等方面的約束

名稱詳細要求

2.9.2設計約束

【可選】

說明：開發過程中必須使用的軟件語言、軟件進程需求、主要開發工具、核心技術、第三

方產品等。

2.9.3產品應當遵循的標準或規范

說明：闡述本產品應當遵循什么標準、規范或業務規則，違反標準、規范或業務規則的產

品通常不太可能被接受。

3具體需求

3.1功能需求

3.1.1具體功能

3.1.1.1內容

說明：對于每一類功能或者有時對于每一個功能，需要具體描述其輸入、加工和輸出的需

求。

第16頁，共53頁

3.2非功能需求

3.2.1外部接口

3.2.1.1用戶接口

說明：提供用戶使用軟件產品時的接口需求。例如，如果系統的用戶通過顯示終端進行操

作，就必須指定如下要求：

a對屏幕格式的要求

說明：對界面上的各對象、類型、寬度、取值范圍、數據來源、能否為空等屬性進行

描述。

b報表或菜單的頁面打印格式和內容

c輸入輸出的需求

說明：解釋各輸入輸出數據類型，并逐項說明其媒體、格式、數值范圍、精度等。對

軟件的數據輸出及必須標明的控制輸出量進行解釋并舉例，包括對硬拷貝報告（正常

結果輸出、狀態輸出及異常輸出）以及圖形或顯示報告的描述。

d程序功能鍵的可用性

說明：快捷鍵定義等。

3.2.1.2硬件接口

【可選】

說明：要指出軟件產品和系統硬部件之間每一個接口的邏輯特點。還可能包括如下事宜：

支撐什么樣的設備，如何支撐這些設備，有何約定。

3.2.1.3軟件接口

【可選】

說明：在此要指定需使用的其他軟件產品（例如，數據管理系統、操作系統或數學軟件

包），以及同其他應用系統之間的接口。對每一個所需的軟件產品，要提供如下內容：名

字、助記符、規格說明號、版本號、來源。

對于每一個接口，這部分應說明與軟件產品相關的接口軟件的目的，并根據信息的內容和

格式定義接口，但不必詳細描述任何已有完整文件的接口，只要引用定義該接口的文件即

可。

【接口定義】

下表是對一些接口的具體描述：

接口名稱

接口描述填寫接口完成的任務

第17頁，共53頁

接口類型填寫是輸入接口(inbound)還是輸出接口(outbound)

源系統填寫接口輸入方系統或部件

目標系統填寫接口輸出方系統或部件

廠商提供/客戶化開發

文件類型填寫文件類型；若通過數據庫表來交互，請指明數據庫及

表名

文件數?

峰值數據?

頻度填寫數據處理的頻度

復雜度

批處理/人工填寫接口數據的驅動模式是人工(manual)還是自動

(automatic),還是都支持

接口類型填寫是實時接口還是批量接口等

【其他系統詳細信息】

說明：列出所有與接口交互的外圍系統的詳細信息。包括輸入、輸出系統等

系統填寫與接口交互的系統名稱

系統類型填寫是接口的數據源系統(source)還是目標系統(object)

數據庫填寫交互系統使用的數據庫及版本

軟件填寫交互系統的軟件名稱

架構類型交互系統的架構類型是B/S還是C/S。

位置填寫該軟件在交互軟件體系中所出的位置

技術支持填寫交互系統的開發商和支持商

功能支持填寫具體的支持商或技術團隊

數據歸雇

【接口隸屬系統的詳細信息［可選］】

系統填寫接口隸屬系統的名稱

模塊隸屬于具體的模塊名稱

數據庫隸屬系統的數據庫及版本

負責人

第18頁，共53頁

控制報告

【接口配置】

(1)接口基礎信息配置

說明：接口基礎信息的配置項目，描述配置的方式。

(2)接口運行參數配置

說明：接口運行參數的配置方式和步驟。

【其他配置［可選］］

說明：外圍系統或相關模塊的配置。

3.2.1.4通信接口

【可選】

說明：指定各種通信接口。例如，局部網絡的協議等等。

3.2.2其他非功能性需求

說明：下表中的各種需求，可根據實際情況進行選擇其中的一種或者幾種進行描述，在表

的后面是各種需求的詳細解釋。

名稱詳細要求

靜態數值需求

動態數值需求

精度

時間特性要求

可用性

可靠性

可維護性

安全性

可移植性

可擴展性

兼容性

■??

3.2.2.1靜態數值需求

說明：支持的終端數；支持并行操作的用戶數。

3.2.2.2動態數值需求

第19頁，共53頁

說明：欲處理的事務和任務的數量，以及在正常情況下卻峰值工作條件下一定時間周期中

處理的數據總量。

3.2.2.3精度

說明:對該軟件的輸入、輸出數據精度的要求，可能包括傳輸過程中的精度。

3.2.2.4時間特性要求

說明：對于該軟件的時間特性要求，如對：

a.響應時間；

b.更新處理時間；

c.數據的轉換和傳送時間；

d.解題時間等要求。

3.2.2.5數據管理要求

【可選】

說明：需要管理的文卷和記錄的個數、表和文卷的大小規模，要按可預見的增長對數據及

其分量的存儲要求做出估算。

3.2.2.6可用性

指出普通用戶和高級用戶要高效地執行特定操作所需的培訓時間，指出典型任務的可評測

任務次數或根據用戶已知或喜歡的其他系統確定新系統的可用性需求

性能

3.2.2.7可靠性

指出可用時間百分比（XX.xx%）,使用小時數、維護訪問權、降級模式操作等。平均故障

間隔時間（MTBF）。平均修復時間（MTTR）一系統在發生故障后可以暫停運行的時間。指出

系統輸出要求具備的精密度（分辨率）和精確度（按照某一已知的標準）。

3.2.3文檔需求

說明：主要是在線用戶手冊與幫助系統，也包括其他的文檔

3.2.4第三方產品

【可選】

說明：使用到的第三方產品相關的使用許可、使用限制、接口標準。

3.3數據字典

說明：把相關的數據抽取出來統一維護，在其他章節如有類似信息描述，則關聯到數據字

典的相關部分并加輔助說明，如：引用到的字段等。

4補充資料

【可選】

第20頁，共53頁

4.1待確定的問題列表

【可選】

需求標題1

調查方式

調查人

調查對象

時間、地點

需求信息記錄

第21頁，共53頁

附件四需求變更申請

記錄號：

項目：類型：開發項目

項目負責人：變更申請人：

申請部門：申請日期：

變更內容

變更的內容說明變更的內容及變更的理由,

及其理由如果變更為業務組提出,則業務組填寫;

如果變更為為信息技術組提出,則信息技術組填寫;

變更的系統及說明變更所涉及的工作產品及其當前版本,

版本如果變更為業務組提出,則業務組填寫;

如果變更為為信息技術組提出,則信息技術組填寫;

對業務及其接分析需求變更引起的業務變更,業務接口的變更,

口的影響業務組填寫

業務負責人意同意不同意

見：

簽字：日期：

第22頁，共53頁

變更結果

變更分析

對相關的資源影響分析需求變更對人員、開發設備和目標設備的影響,

僅信息技術組填寫

風險分析分析需求變更的風險,

僅信息技術組填寫

對其他系統或接口分析需求變更引起的系統變更、其他系統或接口的變更,

的影響僅信息技術組填寫

對開發工作量、進估計需求變更對開發工作量和進度的影響,需說明本次變更工作量/

度和成本影響成本是否超過本項目總開發工作量/總成本的1%?

僅信息技術組填寫

信息技術部審批意見

信息技術組負責人同意不同意

意見：

指定驗證人員：

簽字：日期：

處經理意見：同意不同意匯報上級

簽字：日期：

上級經理意見：同意不同意

簽字：日期：

變更結果

變更的系統及版本說明變更后的工作產品

簽字：日期：

變更驗證

完整性是否

驗證變更結果

正確性是否

第23頁，共53頁

附加變更是否

是

版本和名稱否

驗證人意見：符合要求不符合要求

簽字：日期：

第24頁，共53頁

附件五項目計劃書

文件狀態：文件標識：ProjectName-

［V］草稿當前版本：X.Y

［］正式發布作者：

［］正在修改完成日期：Year-Month-Day

版本歷史

版本/狀態作者參與者起止日期備注

1文檔介紹

1.1文檔目的

1.2文檔范圍

1.3參考文獻

提示：

列出本文檔的所有參考文獻（可以是非正式出版物），格式如下:

［標識符］作者，文獻名稱，出版單位（或歸屬單位），日期

例如：

［AAA］作者，《立項建議書》，機構名稱，日期

1.5術語與縮寫解釋

縮寫、術語解釋

2項目介紹

2.1項目范圍

提示：

（1）用簡練的語言說明本項目“是什么”，“說明用途”。

（2）說明本項目“應當包含的內容”和“不包含的內容”。

第25頁，共53頁

2.2項目目標

提示：給出“清晰的”、“可實現”、“可驗證”的目標。

2.3客戶與最終用戶介紹

提示：請說明本項目的客戶、用戶及其相關責任人是誰，描述最終用戶的特征。

2.4約束

提示：

(1)請說明在項目開發過程中應當遵循的標準或規范

(2)請說明相關項目可能對本項目造成的影響。

(3)說明一些假設和依賴。

3項目過程定義

3.1軟件生命周期模型

提示：簡要描述、繪制本項目的軟件生命周期模型。

3.2項目規范

提示：描述項目需遵循的規范，例如：編碼規范。此處可以表現為編碼規范的鏈接。

3.3方法與工具

提示：說明在過程中將采用的方法與工具。例如采用RationalRose進行面向對象分

析與設計，采用VisualSourceSafe進行配置管理，采用MicrosoftOffice制作文檔。

方法與工具用途

VisuaISourceSafe配置管理

???

4里程碑計劃

序號里程碑名稱升始日期結束日期工作成果備注

5資源計劃

5.1人力資源計劃

提示：制定本項目的角色職責表，并為已知的項目成員分配角色(一個人可以兼多個

角色)。

角色職責人員姓名工作說明

第26頁，共53頁

高層領導

項目經理

需求分析員

系統設計員

程序員

測試員

???

5.2軟硬件資源計劃

提示：分析項目開發、測試、運行所需的軟硬件資源和關鍵計算機資源（會影響軟件

產品的性能的CPU、內存、帶寬等內容），主要內容包括：

?資源級別（分為“關鍵”、“普通”兩種）

?詳細配置

?獲取方式（如“已經存在”、“可以借用”或“需要購買”等）與獲取時間

?使用說明（如“誰”在“什么”時候使用）

軟硬件資源名級別詳細配置獲取方式與時間使用說明

稱

關鍵

關鍵

普通

■■■

6文檔交付列表

序號交付文檔名稱交付日期備注

7風險管理計劃

提示：以下是各個列標題的解釋。

約定在項目中的風險管理方案，例如：風險識別頻度、風險跟蹤頻度等。

風險級別：確定風險的嚴重性、可能性、風險系數

風險描述：緩解方案或者應急計劃。

風險編號風險級別風險描述緩解方案應急計劃

第27頁，共53頁

嚴重性可能性風險系數

(1-5)(%)(嚴重性*可能性)

8溝通計劃

甲方代表乙方代表溝通方式溝通頻率/‘時間期望結果

9附件

?項目進度計劃

第28頁，共53頁

附件六項目計劃變更說明

項目名稱申請日期

項目計劃變更申請

申請變更的輸入名稱，版本，完成日期等信息

《項目計劃》

變更的內容

及其理由

評估計劃變更將對

項目造成的影響

項目負責人簽字

變更申請的審批意見

審批意見：

處經理審批

簽字，日期

審批意見：

信息技術部負責人

審批

簽字，日期

審批意見：

業務部門意見

簽字，日期

更改項目計劃

變更后的輸入名稱，版本，完成日期等信息

《項目計劃》

項目負責人簽字

第29頁，共53頁

附件七設計說明書

文件狀態：文件標識：ProjectName-Modu1e-Design

[V]草稿當前版本：X.Y

[]正式發布作者：

[]正在修改完成日期：Year-Month-Day

版本歷史

版本/狀態作者參與者起止日期備注

第30頁，共53頁

1引言

1.1編寫目的

說明編寫這份詳細設計說明書的目的，指出預期的讀者。

1.2背景

說明：

待開發軟件系統的名稱；

本項目的任務提出者、開發者、用戶和運行該程序系統的計算中心。

1.3定義

列出本文件中用到專門術語的定義和外文首字母組詞的原詞組。

1.4參考資料

列出有關的參考資料，如：

本項目的經核準的計劃任務書或合同、上級機關的批文；

屬于本項目的其他已發表的文件；

本文件中各處引用到的文件資料，包括所要用到的軟件開發標準。列出這些文件的標

題、文件編號、發表日期和出版單位，說明能夠取得這些文件的來源。

2程序系統的結構

用一系列圖表列出本程序系統內的每個程序（包括每個模塊和子程序）的名稱、標識

符和它們之間的層次結構關系。

3程序1（標識符）設計說明

從本章開始，逐個地給出各個層次中的每個程序的設計考慮。以下給出的提綱是針對

一般情況的。對于一個具體的模塊，尤其是層次比較低的模塊或子程序，其很多條目的內

容往往與它所隸屬的上一層模塊的對應條目的內容相同，在這種情況下，只要簡單地說

明這一點即可。

3.1程序描述

給出對該程序的簡要描述，主要說明安排設計本程序的目的意義，并且，還要說明本

程序的特點（如是常駐內存還是非常駐？是否子程序？是可重人的還是不可重人的？有

無覆蓋要求？是順序處理還是并發處理等1

3.2功能

說明該程序應具有的功能，可采用IPO圖（即輸入一處理一輸出圖）的形式。

3.3性能

說明對該程序的全部性能要求，包括對精度、靈活性和時間特性的要求。

第31頁，共53頁

3.4輸人項

給出對每一個輸入項的特性，包括名稱、標識、數據的類型和格式、數據值的有效范

圍、輸入的方式。數量和頻度、輸入媒體、輸入數據的來源和安全保密條件等等。

3.5輸出項

給出對每一個輸出項的特性，包括名稱、標識、數據的類型和格式，數據值的有效范

圍，輸出的形式、數量和頻度，輸出媒體、對輸出圖形及符號的說明、安全保密條件等

等。

3.6算法

詳細說明本程序所選用的算法，具體的計算公式和計算步驟。

3.7流程邏輯

用圖表（例如流程圖、判定表等）輔以必要的說明來表示本程序的邏輯流程。

3.8接口

用圖的形式說明本程序所隸屬的上一層模塊及隸屬于本程序的下一層模塊、子程序，

說明參數賦值和調用方式，說明與本程序相直接關聯的數據結構（數據庫、數據義卷）。

3.9存儲分配

根據需要，說明本程序的存儲分配。

3.10注釋設計

說明準備在本程序中安排的注釋，如：

加在模塊首部的注釋；

加在各分枝點處的注釋；

對各變量的功能、范圍、缺省條件等所加的注釋；

對使用的邏輯所加的注釋等等。

3.11限制條件

說明本程序運行中所受到的限制條件。

3.12測試計劃

說明對本程序進行單體測試的計劃，包括對測試的技術要求、輸入數據、預期結果、

進度安排、人員職責、設備條件驅動程序及樁模塊等的規定.

3.13尚未解決的問題

說明在本程序的設計中尚未解決而設計者認為在軟件完成之前應解決的問題。

4程序2（標識符）設計說明

用類似F.3的方式，說明第2個程序乃至第N個程序的設計考慮。

第32頁，共53頁

附件八單元測試用例

1測試范圍

說明：本用例測試的功能點。

2測試環境

環境1：

硬件環境:

服務器端:

客戶端:

軟件環境:

服務器端:

客戶端:

憫絡環境廠

環境2：

3數據準備

說明：可以引用適當的附件，如EXCEL文件、文本文件等扁平文件等，這些文件內存放著

測試準備的數據。

測試用例

功能1

測試編號功能模塊一子模塊一編號

測試項目模塊功能一子模塊功能

用例描述描述測試上述功能的測試點

依賴描述無

環境及初環境1,填寫用到的各種測試數據的名稱

始數據

依賴樣例測試本用例依賴的相關用例名稱

序號前置條件測試子項執行步驟預期結果實際結果備注

第33頁，共53頁

測試序號填寫本用說明測試詳細列出對應每一對應每一填寫與測

例運行的的基本流各個用例步的預測個執行步試相關聯

前置條還是備選角色的操結果；驟的實際的核對

件。如登流；要求作的動結果；點、檢查

陸、權測試遍歷作。點O

限、設備所有的備

就緒等；選流；

第34頁，共53頁

附件九設計評審報告

文件狀態：文件標識：ProjectName-

[7]草稿當前版本：X.Y

[]正式發布作者：

[]正在修改完成日期：Year-Month-Day

版本J力史

版本/狀態作者參與者起止日期備注

1.基本信息

提示:由評審主持人或評審員填寫此表格。

待評審的工作成果工作成果名稱，標識符，版本，作者，時間…

技術評審方式（正式評審）或者（走查）

評審時間

評審地點

參加技術評審的人員

類別名字工作單位職稱、職務：

主持人

評審

小組

成員

記錄員

第35頁，共53頁

2.缺陷識別和跟蹤

評審問題跟蹤表

編問題問題嚴重提交提交問題解決措施/問實問備

號