信息系統(tǒng)開發(fā)項目管理手冊

信息系統(tǒng)開發(fā)項目管理指導(dǎo)書

1、項目建設(shè)總體目的

系統(tǒng)應(yīng)當根據(jù)甲方顧客H勺既有業(yè)務(wù)需求及發(fā)展規(guī)劃的擴延規(guī)定，

提供功能完善、界面友好、流程清晰、智能高效，配置維護以便日勺系

統(tǒng)功能，滿足系統(tǒng)運行穩(wěn)定、安全、可靠、高效等技術(shù)規(guī)定。提供電

腦版和版2個版本，

2、項目開發(fā)建設(shè)過程及規(guī)定

為了保證項目能按照甲乙雙方到達的目的規(guī)定順利開展，甲乙雙

方應(yīng)當聯(lián)合成立項目組，由乙方編制《項目執(zhí)行計劃》（式樣見附件

1）并有甲方確認同意.

2.1系統(tǒng)需求分析

1、開發(fā)商必須對甲方企業(yè)日勺業(yè)務(wù)需求進行深入調(diào)研，搜集匯總

客戶的詳細需求，出具《業(yè)務(wù)需求闡明書》（式樣見附件2）,并保證

《業(yè)務(wù)需求闡明書》中包括了所有的業(yè)務(wù)需求°《業(yè)務(wù)需求闡明書》

經(jīng)甲方企業(yè)（顧客）負責人簽字確認，作為業(yè)務(wù)需求基線。

2、開發(fā)商在獲得甲方簽字確認U勺《業(yè)務(wù)需求闡明書》后，提出

技術(shù)需求和處理方案，并對系統(tǒng)進行定義，出具《系統(tǒng)需求規(guī)格闡明

書》（式樣見附件3）?！断到y(tǒng)需求規(guī)格闡明書》需詳細列出業(yè)務(wù)對系

統(tǒng)的規(guī)定（界面、輸入、輸出、管理功能、安全需求、運作模式、關(guān)

鍵指標等）?！断到y(tǒng)需求規(guī)格闡明書》需經(jīng)甲方企業(yè)（顧客）負責人簽

字確認。

3、當業(yè)務(wù)需求發(fā)生變更時，應(yīng)由甲方企業(yè)提交《需求變更申請》

（式樣見附件4）給乙方開發(fā)商實行。

2.2系統(tǒng)設(shè)計

為簡化流程，本項目提議將概要設(shè)計和詳細設(shè)計合二為一，統(tǒng)一

遵照完備性、一致性、擴展性、可靠性、安全性、可維護性等原則。

1、在該階段確定總體構(gòu)造和軟件開發(fā)架構(gòu)，文獻命名規(guī)范，編

碼規(guī)范。按軟件需求劃提成子系統(tǒng)，定義目的系統(tǒng)的功能模塊及各個

功能模塊的關(guān)系。

2、確定軟件模塊構(gòu)造，給出每個功能模塊日勺功能描述、數(shù)據(jù)接

口描述，各模塊之間的詳細接口信息、，并完畢《系統(tǒng)設(shè)計闡明書》（式

樣見附件5）。

3、《系統(tǒng)設(shè)計闡明書》應(yīng)當包括所有顧客界面的原型圖。

4、完畢數(shù)據(jù)庫的設(shè)計，并編寫《數(shù)據(jù)庫設(shè)計闡明書》。

5、在設(shè)計階段，顧客應(yīng)充足參與，保證設(shè)計能滿足系統(tǒng)需求。

6、甲方應(yīng)對組織對開發(fā)商提交日勺《系統(tǒng)設(shè)計闡明書》進行評審,

設(shè)計評審均以《業(yè)務(wù)需求闡明書》和《系統(tǒng)需求規(guī)格闡明書》為根據(jù),

保證系統(tǒng)設(shè)計滿足所有需求，并出具《系統(tǒng)設(shè)計評審匯報》（式樣見

附件6）。

2.3系統(tǒng)開發(fā)

1、系統(tǒng)開發(fā)包括程序編碼、單元測試和集成測試。開發(fā)商根據(jù)

《系統(tǒng)設(shè)計闡明書》制定系統(tǒng)開發(fā)計戈IJ,并提交給甲方對計劃進行監(jiān)

督。

2、開發(fā)商有條件的狀況下盡量開發(fā)、測試和生產(chǎn)環(huán)境獨立。選

擇軟件工具，明確項目組員的職責分工，按照編碼規(guī)范和詳細設(shè)計實

現(xiàn)軟件功能。

3、代碼應(yīng)滿足構(gòu)造良好，清晰易讀，且與設(shè)計一致，符合編碼

規(guī)范。

4、開發(fā)人員需要軟件實現(xiàn)過程中編寫軟件功能闡明，源代碼闡

明。軟件功能闡明文檔應(yīng)闡明項目名稱、編號、軟件名稱和版本號，

軟件功能、重要功能實現(xiàn)過程。源代碼闡明應(yīng)闡明項目編號、軟件名

稱、功能，全局變量、數(shù)據(jù)庫字典、函數(shù)功能、接口。該文檔包括在

源代碼文獻中，以注釋形式存在。

5、開發(fā)商進行單元測試和集成測試。開發(fā)人員處理測試人員反

饋的測試問題，并以書面形式反饋重要問題及處理措施，直至系統(tǒng)運

行穩(wěn)定。測試組出具《系統(tǒng)測試匯報》，測試人員簽字確認測試成果。

2.4顧客測試

1、開發(fā)商編制《顧客測試計劃》（式樣見附件7）,測試計劃必

須定義測試原則，并明確多種測試H勺測試環(huán)節(jié)和需要的系統(tǒng)設(shè)置規(guī)

定，并提交甲方準備。

2、甲方應(yīng)當按照開發(fā)商測試組規(guī)定配合原則測試數(shù)據(jù)，測試用

數(shù)據(jù)要足夠模擬使用環(huán)境中U勺實際數(shù)據(jù)。對已評估為敏感信息U勺數(shù)據(jù)

進行敏感性處理和保護。

3、按照測試計劃完畢顧客測試后，測試組應(yīng)當出具《顧客測試

匯報》（式樣見附件8）,甲乙雙方必須在顧客測試匯報中簽字確認。

4、完畢測試后，開發(fā)商完畢系統(tǒng)協(xié)助文檔（其中包括《顧客操

作手冊》和《安裝維護手冊》）日勺編寫。凡波及應(yīng)用系統(tǒng)的變更，應(yīng)

對系統(tǒng)協(xié)助文檔及時更新。

2.5系統(tǒng)試運行

1、項目組必須制定《試運行計劃》（式樣見附件9）,并制定試

運行驗收指標?！对囘\行計劃》中應(yīng)包括問題應(yīng)對機制，明確問題溝

通渠道和職責分工。

2、項目組聯(lián)合甲方企業(yè)進行有關(guān)系統(tǒng)布署工作，準備培訓資料,

對有關(guān)顧客和信息技術(shù)人員進行培訓。

3、項目組根據(jù)《試運行計戈D負責對顧客的破舊系統(tǒng)進行系統(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)容。

4、系統(tǒng)轉(zhuǎn)換和數(shù)據(jù)遷移完畢后，正式啟動試運行。在試運行過

程中，項目組應(yīng)把系統(tǒng)運行狀況（系統(tǒng)資源使用，反應(yīng)速度等）記錄

到試運行匯報中。必要時，項目組應(yīng)根據(jù)系統(tǒng)運行狀況對應(yīng)用系統(tǒng)進

行優(yōu)化。

5、試運行到達試運行計劃規(guī)定的終止條件時，開發(fā)商編寫《試

運行匯報》（式樣見附件10）。此匯報應(yīng)由開發(fā)商和甲方單位簽字確

認，試運行結(jié)束。

2.6系統(tǒng)驗收與正式上線

1、系統(tǒng)驗收重要顧客單位及開發(fā)商聯(lián)合構(gòu)成獨立系統(tǒng)驗收小組,

由驗收小組共同約定驗收日勺原則和措施。驗收小組從功能需求及技術(shù)

需求層面對系統(tǒng)進行綜合評估，系統(tǒng)驗收內(nèi)容包括但不限于移交給甲

方的系統(tǒng)測試匯報、系統(tǒng)安裝文檔、配置文檔、源代碼、操作手冊、

維護手冊、系統(tǒng)應(yīng)急預(yù)案、系統(tǒng)“回退”計劃等。

2、驗收小組應(yīng)根據(jù)驗收狀況整頓形成《系統(tǒng)驗收匯報》（式樣見

附件11）,驗收匯報必須甲乙雙方簽字，并提交甲方作為付款根據(jù)。

3、系統(tǒng)驗收合格且問題整改完畢并經(jīng)甲乙雙方重要領(lǐng)導(dǎo)同意后

系統(tǒng)轉(zhuǎn)入正式上線運行。

3售后服務(wù)及保密規(guī)定

開發(fā)商應(yīng)當保證系統(tǒng)技術(shù)支持人員隊伍（、J穩(wěn)定，明確售后服務(wù)內(nèi)

容與責任，按照協(xié)議規(guī)定安排維護人員對系統(tǒng)進行技術(shù)支持。

系統(tǒng)需求變更或調(diào)整，記錄變更原因和軟件及源代碼口勺版本控

制，按照軟件變更規(guī)定對系統(tǒng)進行維護。

為了保護甲乙雙方日勺商'也、技術(shù)秘密等權(quán)益，開發(fā)商與甲方、開

發(fā)商與其有關(guān)員工必須簽訂保密協(xié)議。

附件L項目執(zhí)行計劃

文獻狀態(tài)：文獻標識：

[V]草稿目前版本：

[]正式公布作者：

[]正在修改完畢日期：

版本歷史

版本/狀態(tài)作者參與者起止日期備注

1文檔簡介

1.1文檔目的

1.2文檔范圍

1.3參照文獻

提醒：

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

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

例如：

［AAA］作者，《立項提議書》，機構(gòu)名稱，日期

1.5術(shù)語與縮寫解釋

縮寫、術(shù)語解釋

2項目簡介

2.1項目范圍

提醒：

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

（2）闡明本項目“應(yīng)當包括的內(nèi)容”和''不包括的內(nèi)容”。

2.2項目目的

提醒：給出“清晰的”、“可實現(xiàn)”、“可驗證”的目的。

2.3客戶與最終顧客簡介

提醒：請闡明本項目H勺客戶、顧客及其有關(guān)負責人是誰，描述最終顧客的特性。

2.4約束

提醒:

（1）請闡明在項目開發(fā)過程中應(yīng)當遵照日勺原則或規(guī)范

（2）請闡明有關(guān)項目也許對本項目導(dǎo)致的影響。

（3）闡明某些假設(shè)和依賴。

3項目過程定義

3.1軟件生命周期模型

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

3.2項目規(guī)范

提醒：描述項目需遵照的規(guī)范，例如：編碼規(guī)范。此處可以體現(xiàn)為編碼規(guī)范的鏈接。

3.3措施與工具

提醒：闡明在過程中將采用的措施與工具。例如采用RationalRose進行面向?qū)ο?/p>

分析與設(shè)計，采用VisualSourceSafe進行配置管理,采用MicrosoftOffice制作文

檔。

措施與工具用途

VisualSourceSafe配置管理

???

4里程碑計劃

序號里程碑名稱開始日期結(jié)束日期工作成果備注

5資源計劃

5.1人力資源計劃

提醒：制定本項目日勺角色職責表，并為已知的項目組員分派角色（一種人可以兼多

種角色）。

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

高層領(lǐng)導(dǎo)

項目經(jīng)理

需求分析員

系統(tǒng)設(shè)計員

程序員

測試員

???

5.2軟硬件資源計劃

提醒：分析項目開發(fā)、測試、運行所需的軟硬件資源和關(guān)鍵計算機資源（會影響軟

件產(chǎn)品的性能的CPU、內(nèi)存、帶寬等內(nèi)容），重要內(nèi)容包括：

?資源級別（分為“關(guān)鍵”、“一般”兩種）

?詳細配置

?獲取方式（如“已經(jīng)存在”、“可以借用”或“需要購置”等）與獲取時間

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

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

稱

關(guān)鍵

關(guān)鍵

一般

???

6文檔交付列表

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

7風險管理計劃

提醒：如卜是各個列標題的解釋。

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

風險級別：確定風險時嚴重性、也許性、風險系數(shù)

風險描述：緩和方案或者應(yīng)急計劃。

風險級別

風險編號嚴重性也許性風險系數(shù)風隆描述緩和方案應(yīng)急計劃

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

8溝通計劃

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

9附件

?項目進度計劃

■進度表

提醒:制定項目開發(fā)的進度表(提議給出項目里程碑計劃)。例如:

編號里程碑名稱估計結(jié)束時間備注

需求調(diào)研完畢

項目計劃完畢

需求分析完畢

系統(tǒng)設(shè)計完畢

.........

開發(fā)完畢

集成測試完畢

系統(tǒng)測試完畢

顧客驗收測試完畢

試運行結(jié)束

項目驗收

附件2：業(yè)務(wù)需求闡明書

文獻狀態(tài)：文獻標識：

[V]草稿目前版本：

[]正式公布作者：

[]正在修改完畢日期：

版本歷史

版本/狀態(tài)作者參與者起止日期備注

1概述

1.1業(yè)務(wù)調(diào)研人員名單

【可選】

序號職能部門姓名主管聯(lián)絡(luò)備注

1.2業(yè)務(wù)范圍

此處描寫總體業(yè)務(wù)的概要分類。

1.3業(yè)務(wù)目的

從甲方高層或商務(wù)利益的角度提出本業(yè)務(wù)系統(tǒng)H勺期望目的，以及評價原則。

1.4有關(guān)文檔

闡明：列出本文檔的所有參照文獻（可以是非正式出版物），包括既有規(guī)范、原則、批

文、引用到的文獻、資料等，

1.5業(yè)務(wù)詞匯表

闡明：列出本文檔時所引用的專屬領(lǐng)域詞匯、術(shù)語等，以便于業(yè)務(wù)需求H勺提供者和接受

者是建立在一致的業(yè)務(wù)理解恭礎(chǔ)之上的。

2組織構(gòu)造及業(yè)務(wù)

2.1業(yè)務(wù)有關(guān)組織構(gòu)造、人員組織構(gòu)造

闡明：假如顧客崗位設(shè)置復(fù)雜可分別設(shè)置，業(yè)務(wù)組織構(gòu)造和人員組織構(gòu)造

2.2組織機構(gòu)描述

2.3角色職責

闡明：將業(yè)務(wù)波及時詳細人員進行一定程度的分類利抽象，描述該抽象角色的操作職貨。

2.4管理綜述

【可選】

闡明：重要描述該業(yè)務(wù)的管理特點和管理模式。例如：

2.5既有業(yè)務(wù)流程清單

【可選】

闡明：既有業(yè)務(wù)流程需要考慮，諸多新的業(yè)務(wù)是在已經(jīng)有業(yè)務(wù)流程基礎(chǔ)上進行重組時。

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

3業(yè)務(wù)流程及業(yè)務(wù)處理描述

闡明：針對每一項詳細的目的業(yè)務(wù)，描述詳細H勺業(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ù)流程C

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è)計約束

【可選】

闡明：開發(fā)過程中必須使用內(nèi)軟件語言、軟件進程需求、重要開發(fā)匚具、關(guān)鍵技術(shù)、第

三方產(chǎn)品等。

4.3產(chǎn)品應(yīng)當遵照的原則或規(guī)范

【可選】

闡明：論述本產(chǎn)品應(yīng)當遵照什么原則、規(guī)范或業(yè)務(wù)規(guī)則，違反原則、規(guī)范或業(yè)務(wù)規(guī)則H勺

產(chǎn)品一般不太也許被接受。

5其他

5.1目前關(guān)鍵問題和困難

5.2業(yè)務(wù)對項目實行的需求卻期望

【可選】

5.3其他未盡事宜

附件3:系統(tǒng)需求規(guī)格闡明書

文獻狀態(tài)：文獻標識：

[V]草稿目前版本：

[]正式公布作者：

[]正在修改完畢日期：

版本歷史

版本/狀態(tài)作者參與者起止日期備注

1引言

1.1目的

例如：規(guī)定系統(tǒng)H勺邊界和目的，描述系統(tǒng)H勺功能性需求和非功能性需求。

1.2讀者對象及閱讀提議

闡明：指明本文檔面向的讀考群，及對應(yīng)H勺閱讀意見。

1.3文檔范圍

【可選】

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

例模型，系統(tǒng)原型，系統(tǒng)測試用例等文檔。

1.4參照文檔

闡明：列出本文檔的所有參照文獻（可以是非正式出版物），包括計劃任務(wù)書、協(xié)議、

批文、引用到的文獻、資料及軟件開發(fā)原則等。

1.5術(shù)語與縮寫解釋

闡明：列出本文獻中用到的專門術(shù)語的定義和縮寫詞H勺原訶組，并予以解釋，以便于所

有讀者到達共識。

2綜合描述

2.1系統(tǒng)背景

【可選】

闡明：簡介系統(tǒng)的預(yù)期效果、歷史原因。

2.2問題闡明

【可選】

提供一段闡明，總結(jié)此項目需要處理的問題。可以采用如下格式:

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

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

問題日勺后果［該問題會導(dǎo)致什么后果］

成功的處理方案［應(yīng)列出成功處理方案的某些重要長處］

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）有助于控制需求的變更。

?完整而精確的定義本產(chǎn)品的干系人；

?明確本產(chǎn)品所影響到的部門和業(yè)務(wù)；

?用圖表或者文字描述產(chǎn)品的范圍，概要H勺定義產(chǎn)品的功能。

2.4干系人與顧客闡明

【可選】

2.4.1顧客環(huán)境

【可選】

詳細闡明目的顧客的工作環(huán)境。如下是幾項提議：

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

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

與否有特殊的環(huán)境約束：移動、戶外、乘機旅行等？

目前使用H勺是哪些系統(tǒng)平臺？后來會使用哪些平臺？

還在使用哪些應(yīng)用程序？您H勺應(yīng)用程序與否需要和這些應(yīng)用程序集成？

在此處可以從業(yè)務(wù)模型中摘錄某些內(nèi)容來概述所波及的任務(wù)和角色等等。

2.4.2干系人簡檔

【可選】

通過在下表中填寫各干系人的有關(guān)信息來闡明系統(tǒng)中的各個干系人，詳盡的簡檔應(yīng)包括

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

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

此處只需填寫姓名。］

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

類型［簡介干系人啊技能專長、技術(shù)背景和純熟程度（即權(quán)威顧客、業(yè)務(wù)顧

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

職責［列出干系人對所開發(fā)的系統(tǒng)負有的關(guān)鍵職責，即他們作為干系人的利

益。］

使用頻率［該干系人使用系統(tǒng)的頻率］

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

2.4.3關(guān)鍵的干系人/顧客需要

列出「系人認為既有處理方案存在的關(guān)鍵問題。對于列出的每個問題，需澄清如下要點:

-為何會出現(xiàn)這一問題？

?目前怎樣處理該問題？

?干系人需要什么樣日勺處理方案？

務(wù)必要理解干系人或顧客對處理各個問題H勺相對重視程度。分級和累積投票措施表明，

必須處理H勺問題與干系人或顧客但愿處理的問題大有不一樣。

2.5目的業(yè)務(wù)模型

【可選】

闡明：新系統(tǒng)業(yè)務(wù)模型描述，如有對應(yīng)業(yè)務(wù)模型材料了，可專為需求規(guī)格闡明書日勺輸入

參照資料。

2.6功能摘要

總結(jié)該產(chǎn)品將提供依J重要長處和特性，而不必波及每個功能的細節(jié)。對功能加以組織，

使客戶或初次閱讀該文檔H勺其他人可以理解此功能列表。

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

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

重要程度，以ABC三類來表達：A：關(guān)鍵功能；B：輔助功能；C：外圍功能；

級別，按照繼承關(guān)系分為：一級，二級，三級；

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

2.8功能與業(yè)務(wù)對照關(guān)系表

闡明：業(yè)務(wù)組為主編寫業(yè)務(wù)需求，業(yè)務(wù)需求提交至信息技術(shù)組后，由信息技術(shù)組建立目

的系統(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ā)期限等。

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

報表格式：數(shù)據(jù)命名：財務(wù)處理；審計追蹤，等等。

硬件限制闡明：本項包括在多種硬件約束卜運行的軟件規(guī)定，例如，應(yīng)當包括:

硬件配置的特點（接口數(shù)，指令系統(tǒng)等）；內(nèi)存儲器和輔助存儲器H勺容量。

2.9.1運行環(huán)境約束

闡明：硬件設(shè)備，支持軟件，接口，控制等方面的約束

名稱詳細規(guī)定

2.9.2設(shè)計約束

【可選】

闡明：開發(fā)過程中必須使用內(nèi)軟件語言、軟件進程需求、重要開發(fā)工具、關(guān)鍵技術(shù)、第

三方產(chǎn)品等。

2.9.3產(chǎn)品應(yīng)當遵照H勺原則或規(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非功能需求

3.2.1外部接口

3.2.1.1顧客接口

闡明：提供顧客使用軟件產(chǎn)品時的接口需求。例如，假如系統(tǒng)的顧客通過顯示終端進行

操作，就必須指定如下規(guī)定：

a對屏幕格式日勺規(guī)定

闡明：對界面上的各對象、類型、寬度、取值范圍、數(shù)據(jù)來源、能否為空等屬性進

行描述。

b報表或菜單H勺頁面打印格式和內(nèi)容

c輸入輸出時需求

闡明：解釋各輸入輸出數(shù)據(jù)類型，并逐項闡明其媒體、格式、數(shù)值范圍、精度等。

對軟件日勺數(shù)據(jù)輸出及必須標明的控制輸出量進行解釋并舉例，包括對硬拷貝匯報

（正常成果輸出、狀態(tài)輸出及異常輸出）以及圖形或顯示匯報的描述。

d程序功能鍵口勺可用性

闡明：快捷鍵定義等。

3.2.1.2硬件接口

【可選】

闡明：要指出軟件產(chǎn)品和系統(tǒng)硬部件之間每一種接口H勺邏輯特點。還也許包括如下事宜:

支撐什么樣用J設(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)容

和格式定義接口，但不必詳細描述任何已經(jīng)有完整文獻的接口，只要引用定義該接口的

文獻即可。

【接口定義】

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

接口名稱

接口描述填寫接口完畢的任務(wù)

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

源系統(tǒng)填寫接口輸入方系統(tǒng)或部件

目的系統(tǒng)填寫接口輸出方系統(tǒng)或部件

廠商提供/客戶化開發(fā)

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

表名

文獻數(shù)量

峰值數(shù)據(jù)量

頻度填寫數(shù)據(jù)處理的頻度

復(fù)雜度

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

(automatic),還是都支持

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

【其他系統(tǒng)詳細信息】

闡明：列出所有與接口交互的外圍系統(tǒng)的詳細信息。包括輸入、輸出系統(tǒng)等

系統(tǒng)填寫與接口交互的系統(tǒng)名稱

系統(tǒng)類型填寫是接口的數(shù)據(jù)源系統(tǒng)(source)還是目的系統(tǒng)(object)

數(shù)據(jù)庫填寫交互系統(tǒng)使用的數(shù)據(jù)庫及版本

軟件填寫交互系統(tǒng)日勺軟件名稱

架構(gòu)類型交互系統(tǒng)II勺架構(gòu)類型是B/S還是C/S。

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

技術(shù)支持填寫交互系統(tǒng)的開發(fā)商和支持商

功能支持填寫詳細的1支持商或技術(shù)團體

數(shù)據(jù)歸屬

【接口從屬系統(tǒng)的詳細信息［可選］］

系統(tǒng)填寫接口從屬系統(tǒng)的名稱

模塊從屬于詳細的模塊名稱

數(shù)據(jù)庫從屬系統(tǒng)日勺數(shù)據(jù)庫及版本

負責人

控制匯報

【接口配置】

(1)接口基礎(chǔ)信息配置

闡明：接口基礎(chǔ)信息日勺配置項n,描述配置的)方式。

(2)接口運行參數(shù)配置

闡明：接口運行參數(shù)口勺配置方式和環(huán)節(jié)。

【其他配置［可選］］

闡明：外圍系統(tǒng)或有關(guān)模塊日勺配置。

3.2.1.4通信接口

【可選】

闡明：指定多種通信接口。例如，局部網(wǎng)絡(luò)的協(xié)議等等。

3.2.2其他非功能性需求

闡明：下表中的多種需求，可根據(jù)實際狀況進行選擇其中的一種或者幾種進行描述，在

表的背面是多種需求的詳細解釋。

名稱詳細規(guī)定

靜態(tài)數(shù)值需求

動態(tài)數(shù)值需求

精度

時間特性規(guī)定

可用性

可靠性

可維護性

安全性

可移植性

可擴展性

兼容性

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精度

闡明:對該軟件的輸入、輸出數(shù)據(jù)精度的規(guī)定，也許包括傳播過程中的精度。

3.2.2.4時間特性規(guī)定

闡明：對于該軟件的時間特性規(guī)定，如對：

a.響應(yīng)時間；

b.更新處理時間：

c.數(shù)據(jù)n勺轉(zhuǎn)換和傳送時間；

d.解題時間等規(guī)定。

3.2.2.5數(shù)據(jù)管理規(guī)定

【可選】

闡明：需要管理日勺文卷和記錄日勺個數(shù)、表和文卷H勺大小規(guī)模，要按可預(yù)見的增長對數(shù)據(jù)

及其分量的存儲規(guī)定做出估算。

3.2.2.6可用性

指出一般顧客和高級顧客要高效地執(zhí)行特定操作所需的培訓時間，指出經(jīng)典任務(wù)的可評

測任務(wù)次數(shù)或根據(jù)顧客已知或喜歡的其他系統(tǒng)確定新系統(tǒng)的可用性需求

性能

3.2.2.7可靠性

指出可用時間比例（xx.xx%）、使用小時數(shù)、維護訪問權(quán)、降級模式操作等。平均故障

間隔時間（MTBF）。平均修復(fù)時間（MTTR）一系統(tǒng)在發(fā)生故障后可以暫停運行口勺時間。指

出系統(tǒng)輸出規(guī)定具有的精密度（辨別率）和精確度（按照某一已知H勺原則）。

3.2.3文檔需求

闡明：重要是在線顧客手冊與協(xié)助系統(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ù)

字典H勺有關(guān)部分并加輔助闡明，如：引用到的字段等。

4補充資料

【可選】

4.1待確定口勺問題列表

【可選】

需求標題1

調(diào)查方式

調(diào)查人

調(diào)查對象

時間、地點

需求信息記錄

附件4：需求變更申請

記錄號:

項目：類型：開發(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ù)負責同意不一-樣意

人意見：

簽字：日期；

變更成果

變更分析

對有關(guān)的資源影響分析需求變更對人員、開發(fā)設(shè)備和目的設(shè)備的影響,

僅信息技術(shù)組填寫

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

僅信息技術(shù)組填寫

對其他系統(tǒng)或接口分析需求變更引起的J系統(tǒng)變更、其他系統(tǒng)或接口的變更,

的影響僅信息技術(shù)組填寫

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

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

僅信息技術(shù)組填寫

開發(fā)商意見

開發(fā)商負貢人意同意不一樣意

見：

指定驗證人員：

簽字：日期：

變更成果

變更H勺系統(tǒng)及版本闡明變更后的工作產(chǎn)品

簽字：日期：

變更驗證

完整性是否

對的性是否

驗證變更成果

附加變更是否

版本和名稱是否

甲方驗證人意見：符合規(guī)定不符合規(guī)定

簽字：日期：

附件5：系統(tǒng)設(shè)計闡明書

文獻狀態(tài)：文獻標識：

[V]草稿目前版本：

[]正式公布作者：

[]正在修改完畢日期：

版本歷史

版本/狀態(tài)作者參與者起止日期備注

i引言

1.1編寫日H勺

闡明編寫這份詳細設(shè)計闡明書口勺FI的，指出預(yù)期的讀者。

1.2背景

闡明：

待開發(fā)軟件系統(tǒng)口勺名稱；

本項目的任務(wù)提出者、開發(fā)者、顧客和運行該程序系統(tǒng)的計算中心。

1.3定義

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

1.4參照資料

列出有關(guān)I為參照資料，如：

本項目的經(jīng)核準日勺計劃任務(wù)書或協(xié)議、上級機關(guān)的批文;

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

本文獻中各處引用到的文獻資料，包括所要用到的軟件開發(fā)原則。列出這些文獻n勺

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

2程序系統(tǒng)的構(gòu)造

用一系列圖表列出本程序系統(tǒng)內(nèi)的每個程序（包括每個模塊和子程序）的名稱、標

識符和它們之間的層次構(gòu)造關(guān)系。

3程序1（標識符）設(shè)計闡明

從本章開始，逐一地給出各個層次中叫每個程序的設(shè)計考慮。如下給出的提綱是針

對一般狀況的.對于一種詳細的模塊，尤其是層次比較低的模塊或子程序，其諸多條目

的?內(nèi)容往往與它所從屬的上一層模塊時對應(yīng)條目日勺內(nèi)容相似，在這種狀況下，只要簡

樸地闡明這一點即可。

3.1程序描述

給出對該程序的簡要描述，重要闡明安排設(shè)計本程序的H的意義，并且，還要闡明

本程序的特點（如是常駐內(nèi)存還是非常駐？與否子程序？是可重人的還是不可重人

日勺？有無覆蓋規(guī)定？是次序處理還是并發(fā)處理等）。

3.2功能

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

3.3性能

闡明對該程序的所有性能規(guī)定，包括對精度、靈活性和時間特性的規(guī)定。

3.4輸入項

給出對每一種輸入項的特性，包括名稱、標識、數(shù)據(jù)的類型和格式、數(shù)據(jù)值的有效

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

3.5輸出項

給出對每一種輸出項歐I特性，包括名稱、標識、數(shù)據(jù)歡I類型和格式，數(shù)據(jù)值的有效

范圍，榆出的形式、數(shù)量和頻度，輸出媒體、對輸出圖形及符號的J闡明、安仝保密條件

等等。

3.6算法

詳細闡明本程序所選用的算法，詳細的計算公式和計算環(huán)節(jié)。

3.7流程邏輯

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

3.8接口

用圖的形式闡明本程序所從屬的上一層模塊及從屬于本程序口勺下一層模塊、子程

序，闡明參數(shù)賦值和調(diào)用方式，闡明與本程序相直接關(guān)聯(lián)的數(shù)據(jù)構(gòu)造（數(shù)據(jù)庫、數(shù)據(jù)文

卷）。

3.9界面原型圖

按照系統(tǒng)各功能模塊的邏輯次序，提供界面原型圖的跳轉(zhuǎn)展示，各項人機互動組件

及數(shù)據(jù)顯示必須基本完善，界面直觀友好。

3.10存儲分派

根據(jù)需要，闡明本程序的存儲分派。

3.11注釋設(shè)計

闡明準備在本程序中安排的注釋，如:

加在模塊首部的注釋；

加在各分枝點處H勺注釋：

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

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

3.12限制條件

闡明本程序運行中所受到II勺限制條件。

3.13尚未處理的問題

闡明在本程序的設(shè)計中尚未處理而設(shè)口?者認為在軟件完畢之前應(yīng)處理的問題。

4程序2（標識符）設(shè)計闡明

用類似F.3的方式，闡明第2個程序乃至第N個程序II勺設(shè)計考慮。

附件6：系統(tǒng)設(shè)計評審匯報

文獻狀態(tài)：文獻標識：ProjectName-

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

[]正式公布作者：

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

版本歷史

版本/狀態(tài)作者參與者起止日期備注

1.基本信息

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

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

技術(shù)評審方式（正式評審）或者（走查）

評審時間

評審地點

參與技術(shù)評審的人員

類別名字工作單位職稱、職務(wù)：

主持人

計申

/I、如

狙貝

記錄員

2.缺陷識別和跟蹤

評審問題跟蹤表

編問題問題嚴重提交提交問題處理措施/問實問備

號描述類型性者日期處理原因闡明題際題注

負責處關(guān)關(guān)

人理閉閉

狀日驗

態(tài)*證

人

1

2

3

3.評審結(jié)論與意見

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

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

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

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

意見

負責人簽字：

簽字日期：

附件7：顧客測試計劃

文獻狀態(tài)：文獻標識：

[V]草稿目前版本：

[]正式公布作者：

[]正在修改完畢日期：

版本歷史

版本/狀態(tài)作者參與者起止日期備注

1.測試范圍與重要內(nèi)容

提醒：系統(tǒng)測試小組應(yīng)當根據(jù)項目日勺特性確定測試范圍與內(nèi)容。一般地，系統(tǒng)測試

的重要內(nèi)容包括功能測試、強健性測試、性能測試、顧客界面測試、安全性(security)

測試、安裝與反安裝測試等,

2.測試措施

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

3.測試環(huán)境與測試輔助工具

環(huán)境

設(shè)備配置名稱/類型備注

服務(wù)器軟件

硬件

客戶端軟件

硬件

網(wǎng)絡(luò)

工具

類型工具開發(fā)商版本

測試管理

缺陷跟蹤

用于功能性測試的二具

用于性能測試的工具

測試覆蓋監(jiān)測器或評測器

4.測試進度計劃

任務(wù)人員任務(wù)開始日期結(jié)束日期

制定測試計劃

設(shè)計測試

實行測試

執(zhí)行測試

對測試進行評估

5.測試完畢準則

提醒：

對于非嚴格系統(tǒng)可以采用“基于測試用例”的準則：

（1）功能性測試用例通過率到達100%;

（2）非功能性測試用例通過率到達95%時。

對于嚴格系統(tǒng)，應(yīng)當補充“基于BUG密度”的規(guī)則：

相鄰n個CPU小時內(nèi)“測試期BLG密度”所有低于某個值mo例如n不小于10,m

不不小于等于1。

最終一次回歸測試二類缺陷數(shù)量為零，用例外非常規(guī)缺陷數(shù)量不不小于等于2個/

萬行程序：

測試用例功能點覆蓋率100%；

6.BUG管理與改錯計劃

提醒：根據(jù)所采用口勺BIG管理工具確定：（1）BUG管理流程，（2）BUG修改流程。

定義BUG修改約定，例如：不一樣級別的BUG必須在幾日內(nèi)處理完畢。

7.附錄.本計劃審批意見

測試組審批意見:

簽字日期

附件8：顧客測試匯報

1.基本信息

測試根據(jù)例如：參照原則、客戶需求、需求規(guī)格闡明書、測試用例等

測試范圍

測試驗收原則

測試環(huán)境描述

測試驅(qū)動程序描述提醒：可以把測試驅(qū)動程序當作附件

測試人員

測試時間

須注明每次回歸測試

的時間

測試工具

2.實況記錄

模塊測試用例編號期望成果測試成果缺陷密度與否執(zhí)行了回歸測試

3.測試總評價

根據(jù)對測試成果提出一種有關(guān)軟件能力的全面分析，需標明遺留的重要缺