版本頁

標題：**集團信息技術管理制度

主題：軟件開發管理制度

文檔編號：

版本闡明：

版本號版本日期作者備注

V1.0創立

V1.0審批

**集團

軟件開發管理制度

第一節總則

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

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

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

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

計、軟件開發、集成和有關技術支持工作，普通僅向外購買關于硬件設備和

支撐軟件平臺；合伙開發是公司與專業II公司（合伙商）共同協作完畢IT

應用項目實行和技術支持工作，普通形式是公司負責提供業務框架，合伙商

提供技術框架，雙方構成開發團隊進行項目實行，IT系統尋常支持由IT技

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

外部（二級）支持；外包開發是指將IT應用項目設計、開發、集成、培訓

等任務承包給某家專業公司（可以是專業IT公司或征詢公司等），由該公司

（承包商）負責應用項目實行。

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

籌劃和監控、配備管理、合伙開發管理和結項管理。軟件工程涉及需求管

理、系統設計、系統實現、系統測試、顧客接受測試、試運營、系統驗收、

系統上線和數據遷移。

第五條除特別指定，本制度中項目組涉及業務組（或需求提出組）、IT組（也許涉

及網絡管理員和合伙開發商）。

第二節立項管理

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

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

明確項目范疇和邊界。

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

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

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

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

稱“項目組”），項目組應涉及業務組（由公司有關業務部門構成）和IT組

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

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

理工作，保證開發能及時完畢并能滿足業務需要。項目組人員選取應滿足項

目對業務及技術規定，項目組人員應有足修業務和IT技術方面專業知識來

勝任項目各方面工作。

第三節需求分析

第九條立項后業務組對顧客需求進行匯總整頓，出具《業務需求闡明書》：附件

并保證《業務需求闡明書》中包括了所有業務需求。經系統使用部門

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

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

行定義，出具《系統需求規格闡明書》（附件三）。《系統需求規格闡明書》

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

作模式、核心指標（KPI）等）。《系統需求規格闡明書》需要由業務組提交給

有關業務流程負責人確認。

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

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

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

第四節項目籌劃和監控

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

和控制。

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

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

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

籌劃。業務組組長和IT組組長需配合項目經理對項目籌劃執行狀況進行監

控，保證項目按籌劃完畢。

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

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

第五節系統設計

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

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

第十八條在系統設計階段中，顧客應充分參加，保證系統設計能滿足系統需求。

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

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

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

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

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

系統設計滿足所有需求。

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

審批后方可進行。

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

第六節系統實現

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

性進行審批。

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

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

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

方面應當做到隔離；如果環境分隔是通過要輯形式實現，應定期檢查網絡設

立。項目組對已授權訪問生產環境人員進行詳細記錄，并對該記錄進行定期

檢查，保證只有經授權人員才干訪問到生產環境。

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

第七節系統測試和顧客測試

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

性進行審批。

第二十八條《系統/顧客測試籌劃》必要定義測試原則，并明確各種測試測試環節和需

要系統設立規定。

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

格訪問控制，保證只有有關項目人員才干訪問及使用。

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

已評估為敏感信息數據進行敏感性解決和保護。

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

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

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

第三十二條系統測試通過后，IT組配合業務組建立顧客測試環境，業務組依照顧客測試

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

組組長應在顧客測試報告中簽字確認。

第三十三條項目組完畢系統協助文檔（其中涉及《顧客操作手冊》和《安裝維護手

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

第八節試運營

第三十四條系統重要使用部門依照項目規模及影響決定試運營方略。

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

主管領導審批。《試運營籌劃》中應包括問題應對機制，明確問題溝通渠道

和職責分工。

第三十六條項目組聯合試運營單位進行有關系統布置工作，準備培訓資料，對有關顧客

和信息技術人員進行培訓。顧客培訓完畢度應為實行后評估指標之一。

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

統環境，保證運營環境能滿足新應用系統需要。系統轉換時必要詳細記錄原

系統中重要參數、設立等系統信息，并填寫試運營報告有關內容。系統參

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

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

中應包括遷移方案、測試方案、數據定義，新舊數據對照表、遷移時間、回

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

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

報告》（附件十四），其中涉及數據來源、轉換前狀態、轉換后狀態，數據遷

移負責人、對完整性檢查狀況、對精確性檢查狀況等內容。各有關部門驗收

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

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

驗收。

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

營單位辦公室把系統運營狀況（系統資源使用，反映速度等）記錄到試運營

報告中。必要時，項目組應依照系統運營狀況相應用系統進行優化。

第四十二條試運營達到試運營籌劃規定終結條件時，項目組編寫《試運營報告》（附件

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

視。公司主管領導審視試運營成果，決定試運營結束或延期。

第九節系統驗收

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

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

評估。

第四十四條驗收小組應依照驗收狀況整頓形成《系統驗收報告》（附件十六）提交系統

重要使用部門和信息技術部門審視。

第四十五條系統重要使用部門和信息技術部門負責人依照系統測試、試運營狀況訂立驗

收意見。

第十節系統上線

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

第四十七條普通狀況下，系統上線包括數據遷移工作。

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

籌劃得到批準后才干開始布置上線工作。

第四十九條《系統上線籌劃》內容應涉及但不限于：

1、布置方式和資源分派（涉及人力資源及服務器資源）；

2、上線工作時間表；

3、上線操作環節以及問題解決環節；

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

5、數據遷移需求和實行籌劃；

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

7、顧客培訓籌劃（涉及：培訓籌劃、培訓手冊、培訓考核等）；

8、總公司下發系統原則參數配備。

第五十條上線單位在上線初期需加強尋常運營狀態監控，浮現問題時應及時解決，對

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

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

匯總整頓。《系統驗收評估報告》內容涉及：數據精確性、系統性能及穩定

性、接口問題、權限問題、業務操作影響度、問題解決狀況、備份、批解決

等。

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

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

理。

第十一節合伙開發管理

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

度。

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

第五十六條項目經理同合伙開發商明確規定項目變更范疇和解決方式，重點關注需求和

設計變更。

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

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

時，合伙開發商需及時向項目經理報告。

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

第五十九條項目組同合伙開發商商定驗收原則和辦法。

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

第十二節外包開發管理

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

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

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

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

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

第六十四條項目組同外包開發商商定驗收原則和辦法。

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

第十三節附則

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

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

附件一立項分析報告

文獻狀態：文獻標記：ProjectName-

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

[]正式發布作者：

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

版本歷史

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

1.項目簡介

1.1.項目目

提示:用簡潔語言闡明本項目〃是什么”，“實現什么目”。描述簡潔且清晰。

1.2.項目背景

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

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

⑵業務需求及發展趨勢;

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

(4)特殊業務需求等。

1.3.項目范疇

提示:依照對既有需求理解來擬定項目基本范疇,闡明本系統“應當包括內容”和

“不包括內容”。

2.項目籌劃

2.1.項目團隊

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

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

項目經理

需求開發人員

系統設計人員

編程人員

測試人員

質量保證人員

配備管理人員

服務與維護人員

2.2.成本預計

內容成本（人民幣）備注

人力資源

軟硬件資源

差旅費

會議費

接待費

*■?

2.3.進度表

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

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

需求調研完畢

項目籌劃完畢

需求分析完畢

概要設計完畢

詳細設計完畢

實現完畢

集成測試完畢

系統測試完畢

顧客瞼收測試完畢

試運營結束

項目驗收

3.總結

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

附件二業務需求闡明書

文獻狀態：文獻標記：ProjectName-

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

[]正式發布作者：

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

版本歷史

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

1概述

1.1業務調研人員名單

【可選】

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

1.2業務范疇

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

1.3業務目的

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

1.4有關文檔

闡明：列出本文檔所有參照文獻（可以是非正式出版物），涉及既有規范、原則、批文、引

用到文獻、資料等。

1.5業務詞匯表

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

在一致業務理解基本之上。

2組織構造及業務

2.1業務有關組織構造、人員組織構造

闡明：如果客戶崗位設立復雜可分別設立，業務組織構造和人員組織構造

2.2組織機構描述

2.3角色職責

闡明：將業務涉及詳細人員進行一定限度分類和抽象，描述該抽象角色操作職責。

2.4管理綜述

【可選】

闡明：重要描述該業務管理特點和管理模式。例如：

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

天數、庫存、歷史銷售記錄。采購籌劃制定以生產籌劃為根據。

25既有業務流程清單

【可選】

闡明：既有業務流程需要考慮，諸多新業務是在已有業務流程基本上進行重組。

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

3業務流程及業務解決描述

闡明：針對每一項詳細目的業務，描述詳細業務流程，以及有關業務詳細描述。

3.1詳細業務流程（系統名稱+編號）

對于詳細業務流程命名有規范，對詳細流程進行編號，便于形成需求矩陣，同步形成需求

管理和跟蹤。

3.1.1業務流程

3.1.2業務描述

闡明：描述詳細業務流程。

3.1.3有關業務對象

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

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

3.1.4業務規則及核心算法

闡明：描述業務環節核心算法體系。

4假定和約束

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

4.1運營環境約束

4.2設計約束

【可選】

闡明：開發過程中必要使用軟件語言、軟件進程需求、重要開發工具、核心技術、第三方

o

4.3產品應當遵循原則或規范

【可選】

闡明：闡述本產品應當遵循什么原則、規范或業務規則，違背原則、規范或業務規則產品

普通不太也許被接受。

5其她

5.1當前核心問題和困難

5.2業務對項目實行需求和盼望

【可選】

5.3其她未盡事宜

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

文獻狀態：文獻標記：ProjectName-

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

[]正式發布作者：

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

版本歷史

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

1引言

1.1目

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

1.2讀者對象及閱讀建議

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

1.3文檔范疇

【可選】

闡明：對本文范疇做闡述，本文檔改動時，受到影響范疇，例如，本文引用到用例模型，

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

1.4參照文檔

闡明：列出木文檔所有參照文獻（可以是非正式出版物），涉及籌劃任務書、合同、批文、

引用到文獻、資料及軟件開發原則等。

1.5術語與縮寫解釋

闡明：列出本文獻中用到專門術語定義和縮寫詞原詞組，并予以解釋，以便于所有讀者達

到共識。

2綜合描述

2.1系統背景

【可選】

闡明：簡介系統預期效果、歷史因素。

2.2問題闡明

【可選】

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

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

影響［問題影響干系人］

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

成功解決方案［應列出成功解決方案某些重要長處］

2.3系統范疇

闡明：闡述本項目“合用業務領域”和“不合用業務領域”，本產品”應當包括內容”和

“不包括內容”。說清晰系統范疇好處是：（1）有助于判斷什么是需求，什么不是需求;

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

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

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

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

2.4干系人與顧客闡明

【可選】

2.4.1顧客環境

【可選】

詳細闡明目的顧客工作環境。如下是幾項建議：

該任務由多少人來完畢？與否總在變化？

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

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

當前使用是哪些系統平臺？后來會使用哪些平臺？

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

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

2.4.2干系人簡檔

【可選】

通過在下表中填寫各干系人有關信息來闡明系統中各個干系人，詳盡簡檔應涉及各種干系

人在如下方面信息：

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

處只需填寫姓名。］

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

類型［簡介干系人技能特長、技術背景和純熟限度（即權威顧客、業務顧

客、專家顧客、初級顧客等）］

職責［列出干系人對所開發系統負有核心職責，即她們作為干系人利益。］

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

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

2.4.3核心干系人/顧客需要

列出干系人以為既有解決方案存在核心問題。對于列出每個問題，需澄清如下要點：

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

?當前如何解決該問題？

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

務必要理解干系人或顧客對解決各個問題相對注重限度。分級和累積投票辦法表白，必要

解決問題與干系人或顧客但愿解決問題大有不同。

2.5目的業務模型

【可選】

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

資料。

2.6功能摘要

總結該產品將提供重要長處和特性，而不必涉及每個功能細節。對功能加以組織，使客戶

或初次閱讀該文檔其她人可以理解此功能列表。

2.7功能清單及重要限度闡明

闡明：功能名稱、功能描述、重要限度。

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

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

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

2.8功能與業務對照關系表

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

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

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

書明書》。

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

2.9假定和約束

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

格式限制闡明：本項將指定由既有原則或規則派生規定。例如：

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

硬件限制闡明：本項涉及在各種硬件約束下運營軟件規定，例如，應當涉及:

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

2.9.1運營環境約束

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

名稱詳細規定

2.9.2設計約束

【可選】

闡明：開發過程中必要使用軟件語言、軟件進程需求、重要開發工具、核心技術、第三方

產品等。

2.9.3產品應當遵循原則或規范

闡明：闡述本產品應當遵循什么原則、規范或業務規則，違背原則、規范或業務規則產品

普通不太也許被接受。

3詳細需求

3.1功能需求

3.1.1詳細功能

3.1.1.1內容

闡明：對于每一類功能或者有時對于每一種功能，需要詳細描述其輸入、加工和輸出需

求。

3.2非功能需求

3.2.1外部接口

3.2.1.1顧客接口

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

就必要指定如下規定：

a對屏幕格式規定

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

述。

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

c輸入輸出需求

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

軟件數據輸出及必要標明控制輸出量進行解釋并舉例，涉及對硬拷貝報告（正常成果

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

d程序功能鍵可用性

闡明：快捷鍵定義等。

3.2.1.2硬件接口

【可選】

闡明：要指出軟件產品和系統硬部件之間每一種接口邏輯特點。還也許涉及如下事宜：支

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

3.2.1.3軟件接口

【可選】

闡明：在此要指定需使用其地軟件產品(例如，數據管理系統、操作系統或數學軟件包)，

以及同其她應用系統之間接口。對每一種所需軟件產品，要提供如下內容：名字、助記

符、規格闡明號、版本號、來源。

對于每一種接口，這某些應闡明與軟件產品有關接口軟件目，并依照信息內容和格式定義

接口，但不必詳細描述任何已有完整文獻接口，只要引用定義該接口文獻即可。

【接口定義】

下表是對某些接口詳細描述：

接口名稱

接口描述填寫接口完畢任務

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

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

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

廠商提供/客戶化開發

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

表名

文獻數■:

峰值數據?

頻度填寫數據解決頻度

復雜度

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

(automatic),還是都支持

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

【其她系統詳細信息】

闡明：列出所有與接口交互外圍系統詳細信息。涉及輸入、輸出系統等

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

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

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

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

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

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

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

功能支持填寫詳細支持商或技術團隊

數據歸屬

【接口從屬系統詳細信息［可選］］

系統填寫接口從屬系統名稱

模塊從屬于詳細模塊名稱

數據庫從屬系統數據庫及版本

負責人

控制報告

【接口配備】

(1)接口基本信息配備

闡明：接口基本信息配備項目，描述配備方式。

(2)接口運營參數配備

闡明：接口運營參數配備方式和環節。

【其她配備［可選］］

闡明：外圍系統或有關模塊配備。

3.2.1.4通信接口

【可選】

闡明：指定各種通信接口。例如，局部網絡合同等等。

3.2.2其她非功能性需求

闡明：下表中各種需求，可依照實際狀況進行選取其中一種或者幾種進行描述，在表背面

是各種需求詳細解釋。

名稱詳細規定

靜態數值需求

動態數值需求

精度

時間特性規定

可用性

可靠性

可維護性

安全性

可移植性

可擴展性

兼容性

???

3.2.2.1靜態數值需求

闡明：支持終端數；支持并行操作顧客數。

3.2,2.2動態數值需求

闡明：欲解決事務和任務數量，以及在正常狀況下和峰值工作條件下一定期間周期中解決

數據總量。

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補充資料

【可選】

4.1待擬定問題列表

【可選】

需求標題1

調查方式

調查人

調核對象

時間、地點

需求信息記錄

附件四需求變更申請

記錄號：

項目：類型：開發項目

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

申請部門：申請日期：

變更內容

變更內容闡明變更內容及變更理由,

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

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

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

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

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

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

口影響業務組填寫

業務負責人意批準不批準

見：

簽字：日期：

變更成果

變更分析

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

僅信息技術組填寫

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

僅信息技術組填寫

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

影響僅信息技術組填寫

對開發工作量、進預計需求變更對開發工作量和進度影響,需闡明本次變更工作量/成

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

僅信息技術組填寫

信息技術部畝批意見

信息技術組負責人批準不批準

意見：

指定驗證人員：

簽字：日期：

處經理意見：批準不批準報告上級

簽字：日期：

上級經理意見：批準不批準

簽字：日期：

變更成果

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

簽字：日期：

變更驗證

完整性是否

驗證變更成果

對的性是否

是

附加變更否

版本和名稱是否

驗證人意見：符合規定不符合規定

簽字：日期：

附件五項目籌劃書

文獻狀態：文獻標記：ProjectName-

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

［］正式發布作者：

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

版本歷史

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

1文檔簡介

1.1文檔目

1.2文檔范疇

1.3參照文獻

提示：

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

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

例如：

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

1.5術語與縮寫解釋

縮寫、術語解釋

2項目簡介

2.1項目范疇

提示:

（1）用簡潔語言闡明K項目“是什么”，“闡明用途”。

（2）闡明本項目“應當包括內容”和“不包括內容”。

2.2項目目的

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

2.3客戶與最后顧客簡介

提示：請闡明本項目客戶、顧客及其有關負責人是誰，描述最后顧客特性。

2.4約束

提示：

（1）請闡明在項目開發過程中應當遵循原則或規范

（2）請闡明有關項目也許對本項目導致影響。

（?）闡明某些假設和依賴。

3項目過程定義

3.1軟件生命周期模型

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

3.2項目規范

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

3.3辦法與工具

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

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

辦法與工具用途

VisuaISourceSafe配備管理

■■?

4里程碑籌劃

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

5資源籌劃

5.1人力資源籌劃

提示：制定本項目角色職責表，并為已知項目成員分派角色（一種人可以兼各種角

色）。

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

高層領導

項目經理

需求分析員

系統設計員

程序員

測試員

---

5.2軟硬件資源籌劃

提示：分析項目開發、測試、運營所需軟硬件資源和核心計算機資源（會影響軟件產

品性能CPU、內存、帶寬等內容），重要內容涉及：

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

?詳細配備

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

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

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

稱

核心

核心

普通

■■?

6文檔交付列表

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

7風險管理籌劃

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

商定在項目中風險管理方案，例如：風險辨認頻度、風險跟蹤頻度等。

風險級別：擬定風險嚴重性、也許性、風險系數

風險描述：緩和方案或者應急籌劃。

風險級別

風險編號嚴重性也許性風險系數風險描述緩和方案應急籌劃

(1-5)(%)(嚴重性*也許性)

8溝通籌劃

甲方代表乙方代表溝通方式溝通頻率/時間盼望成果

9附件

?項目進度籌劃

附件六項目籌劃變更闡明

項目名稱申請日期

項目籌劃變更申請

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

《項目籌劃》

變更內容

及其理由

評估籌劃變更將對

項目導致影響

項目負責人簽字

變更申請審批意見

審批意見：

處經理審批

簽字，日期

審批意見：

信息技術部負責人

審批

簽字，日期

審批意見：

業務部門意見

簽字，日期

更改項目籌劃

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

《項目籌劃》

項目負責人簽字

附件七設計闡明書

文獻狀態：文獻標記：ProjectName-Modu1e-Design

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

[]正式發布作者：

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

版本歷史

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

1引言

1.1編寫目

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

1.2背景

闡明：

待開發軟件系統名稱；

本項目任務提出者、開發者、顧客和運營該程序系記錄算中心。

1.3定義

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

1.4參照資料

列出關于參照資料，如：

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

屬于本項目其她已刊登文獻；

本文獻中各處引用到文獻資料，涉及所要用到軟件開發原則。列出這些文獻標題、文

獻編號、刊登日期和出版單位，闡明可以獲得這些文獻來源。

2程序系統構造

用一系列圖表列出本程序系統內每個程序（涉及每個模塊和子程序）名稱、標記符和

它們之間層次構造關系。

3程序1（標記符）設計闡明

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

況。對于一種詳細模塊，特別是層次比較低模塊或子程序，其諸多條目內容往往與它所從

屬上一層模塊相應條目內容相似，在這種狀況下，只要簡樸地闡明這一點即可。

3.1程序描述

給出對該程序簡要描述，重要闡明安排設計本程序目意義，并且，還要闡明本程序特

點（如是常駐內存還是非常駐？與否子程序？是可重人還是不可重人？有無覆蓋規定？

是順序解決還是并發解決等）。

3.2功能

闡明該程序應具備功能，可采用IPO圖（即輸入一解決一輸出圖）形式。

3.3性能

闡明對該程序所有性能規定，涉及對精度、靈活性和時間特性規定。

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個程序設計考慮。

附件八單元測試用例

1測試范疇

闡明：本用例測試功能點,

2測試環境

環境1：

硬件環境;

服務器端:

客戶端:

軟件環境:

服務器端:

客戶端:

網絡環境：

環境2：

3數據準備

闡明：可以引用恰當附件，如EXCEL文獻、文本文獻等扁平文獻等，這些文獻內存儲著測

試準備數據。

測試用例

功能1

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

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

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

依賴描述無

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

始數據

依賴樣例測試本用例依賴有關用例名稱

序號前置條件測試子項執行環節預期成果實際成果備注

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

例運營前基本流還各個用例步預測成種執行環試有關聯

置條件。是備選角色操作果；節實際成核對點、

如登陸、流；規定動作。果；檢查點。

權限、設測試遍歷

備就緒所有備選

等；流；

附件九設計評審報告

文獻狀態：文獻標記：ProjectName-

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

[]正式發布作者：

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

版本歷史

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

1.基本信息

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

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

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

評審時間

評審地點

參加技術評審人員

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

主持人

評審

小組

成員

記錄員

2.缺陷辨認和跟蹤

評審問題跟蹤表

編問題問題嚴重提交提交問題解決辦法/問實問備

號描述類型性者日期解決因素闡明題際題注

負責解關關

人決閉閉

狀日驗

態期證

人

1

2

3

3.評審結論與意見

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

[]工作成果合格，“無需修改”或者“需要輕微修改但不必再審核”。

評審結論[V]工作成果基本合格，需要作少量修改，之后通過審核即可。

[]工作成果不合格，需要作比較大修改，之后必要重新對其評審。

意見

負責人簽字：

簽字日期：

附件十系統/顧客測試籌劃

文獻狀態：文獻標記：

[V]草稿當前版本：

[]正式發布作者：

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

版本歷史

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

1.測試范疇與重要內容

提示：系統測試小組應當依照項目特性擬定測試范疇與內容。普通地，系統測試重要

內容涉及功能測試、健壯性測試、性能測試、顧客界面測試、安全性(security)測試、

安裝與反安裝測試等。

2.測試辦法

提示：例如黑盒測試和白盒測試。

3.測試環境與測試輔助工具

環境

設備配備名稱/類型備注

服務器軟件

硬件

客戶端軟件

硬件

網絡

工具

類型工具開發商版本

測試管理

缺陷跟蹤

用于功能性測試工具

用于性能測試工具

測試覆蓋監測器或評測器

4.測試進度籌劃

任務人員任務開始日期結束日期

制定測試籌劃

設計測試

實行測試