小語種翻譯軟件服務投標方案（技術方案）

小語種翻譯軟件服務投標方案

目錄

第一章需求理解...................................4

1.1.對用戶需求理解透徹，明確系統(tǒng)的建設要求和目

標...........................................4

1.2.系統(tǒng)建設目標.............................5

1.3.建設要求響應.............................6

第二章技術方案.................................31

2.1.產品技術先進，性能穩(wěn)定、升級擴展性強，技術

方案科學、合理、詳盡，可行性強...............31

2.2.總則...................................35

2.3.立項管理...............................36

2.4.需求分析...............................37

2.5.項目計劃和監(jiān)控.........................38

2.6.小語種翻譯軟件系統(tǒng)設計.................39

2.7.小語種翻譯軟件系統(tǒng)實現(xiàn).................40

2.8.系統(tǒng)測試和用戶測試.....................41

2.9.試運行.................................42

2.10.系統(tǒng)驗收...............................44

2.11.系統(tǒng)上線...............................45

第三章合作開發(fā)管理.............................47

3.1.立項分析報告...........................48

3.2.單元測試用例...........................81

3.3.試運行計劃.............................93

3.4.數(shù)據(jù)遷移計劃...........................96

3.5.試運行報告...........................100

3.6.系統(tǒng)驗收報告.........................102

3.7.系統(tǒng)上線計劃.........................103

3.8.系統(tǒng)驗收評估報告.......................107

第四章技術指標...............................109

4.1.第四章“技術服務需求”第三部分“技術指標”

中，有▲標記11項逐條響應..................109

4.2.系統(tǒng)需求響應..........................111

4.3.翻譯性能優(yōu)化——▲語種數(shù)量.............116

4.4.翻譯性能優(yōu)化——▲翻譯質量.............116

4.5.翻譯性能優(yōu)化——▲翻譯速度.............116

4.6.翻譯性能優(yōu)化——▲并發(fā)要求.............117

4.7.翻譯系統(tǒng)擴展——▲語種數(shù)量.............117

4.8.翻譯系統(tǒng)擴展——▲翻譯質量.............117

4.9.翻譯系統(tǒng)擴展——▲翻譯速度.............117

4.10.翻譯系統(tǒng)擴展——▲并發(fā)要求...........118

第五章文本內容分析——▲言論抽取...............119

5.1.文本內容分析——▲引語歸因.............119

5.2.框架擴展性——▲以API封裝知識資源建設系統(tǒng)

各功能模塊，提供所有算法可配置接口及并行任務監(jiān)

控、調度接口...............................119

5.3.運維服務...............................119

5.4.性能擴展性——#節(jié)點數(shù)線性增加，加速比隨之增

加.........................................120

5.5.算法擴展性——#知識資源建設算法預留擴展接

口，可進行二次開發(fā).........................120

第六章服務、實施方案詳盡，完全滿足系統(tǒng)需求中的運維

服務方案.......................................121

6.1.項目組織機構...........................122

6.2.服務原則...............................123

6.3.熱線支持服務...........................124

6.4.現(xiàn)場支持服務...........................125

6.5.售后服務流程...........................127

6.6.項目實施過程管理.......................133

6.7.項目質量控制...........................136

第七章擬派實施人員匯總表格式...................145

7.1.擬派實施人員表.........................145

7.2.擬派實施人員表格式.....................148

7.3.計算機學科碩士以上學歷人員名冊.........150

7.4.項目人員資質...........................157

第一章需求理解

1.1.對用戶需求理解透徹，明確系統(tǒng)的建設要求和目標

1.1需求理解

機器翻譯是使用計算機自動進行語言翻譯的技術，它可

以在高效的實現(xiàn)不同語言之間自動轉換的同時，基本達到人

類翻譯的質量。機器翻譯高效、高質量的翻譯能夠打破語言

屏障，使得對海量實時數(shù)據(jù)的跨語言處理成為可能。目前系

統(tǒng)已支持中文->英文、法文->英文、阿拉伯文->英文、德文

->英文、西班牙文->英文、葡萄牙文->英文、日文->英文、

俄文->英文、英文->中文共9個語言對的翻譯，尚無文本內

容分析能力。

1.2.系統(tǒng)建設目標

本項目的目標是提升已有的翻譯系統(tǒng)的翻譯質量、擴展

翻譯系統(tǒng)所支持的語言對、以及新增對英文新聞文本的內容

分析功能。

服務商需在規(guī)定的時限內完成相關工作，按照本項目系

統(tǒng)升級完善、調整優(yōu)化的需求，完成系統(tǒng)性能升級以及新增

服務開發(fā)工作。確保優(yōu)化后系統(tǒng)以及新增系統(tǒng)滿足業(yè)務處理

功能和性能需求。保證系統(tǒng)安全、穩(wěn)定運行。

1.3.建設要求響應

專門術語：

SQLSERVER:系統(tǒng)服務器所使用的數(shù)據(jù)庫關系系統(tǒng)

(DBMS)。

SQL:一種用于訪問查詢數(shù)據(jù)庫的語言

事務流：數(shù)據(jù)進入模塊后可能有多種路徑進行處理。

主鍵：數(shù)據(jù)庫表中的關鍵域。值互不相同。

外部主鍵：數(shù)據(jù)庫表中與其他表主鍵關聯(lián)的域。

ROLLBACK:數(shù)據(jù)庫的錯誤恢復機制。

縮寫：

系統(tǒng)：若未特別指出，統(tǒng)指本小語種翻譯軟件。

SQL:StructuredQueryLanguage(結構化查詢語言)。

ATM:AsynchronousTransferMode(異步傳輸模式)。

UML:統(tǒng)一建模語言、是一套用來設計軟件藍圖的標準

建模語言，是一種從軟件分析、設計到編寫程序規(guī)范的標準

化建模語言。

UDP:UserDatagramProtocol是無連接的傳輸層協(xié)

議

分布式代理：可隱藏服務器ip,減少服務器的危險；

服務器代理：可驗證用戶數(shù)據(jù)的正確性，以及安全性，

進行處理

三級代理：減輕服務器壓力，可實現(xiàn)智能作弊系統(tǒng)!

標準、條件和約定

本項目遵從以下標準：

GB/T13702-1992計算機軟件分類與代碼

GB/T20918-2007信息技術

GB/T19003-2008軟件工程

GB/T5538-1995軟件工程標準分類法

GB/T9386-2008計算機富安居測試文檔編制

GB/T9385-2008計算機軟件需求規(guī)格說明

系統(tǒng)開發(fā)嚴格按照軟件工程的方法進行組織，系統(tǒng)的開

發(fā)過程按照需求分析、系統(tǒng)分析與設計要求、系統(tǒng)編碼、系

統(tǒng)測試幾個過程有序推進。下表所示系統(tǒng)開發(fā)流程圖，采用

原型及迭代方式開發(fā)，根據(jù)用戶需求持續(xù)改進，直到最終用

戶確認滿意。

開發(fā)流程總述

如下圖示流程定義了我公司內部的軟件開發(fā)過程，以指

導和規(guī)范軟件項目中開發(fā)過程的定義和相應的實施。

該過程可劃分為一系列子過程，包括：軟件需求分析、

設計、編碼、測試、驗收、維護，每個子過程又由一系列任

務和活動組成，如設計過程又可分為結構設計和詳細設計。

但是在實際開發(fā)項目中，情況仍然會是千變萬化的，因此我

們也并不是一成不變的死板執(zhí)行一個僵化的工作流程，我們

的原則是在一個規(guī)范流程的指導和約束下，根據(jù)具體工程項

目的實際要求，為每一個項目評估并制定真正能夠最好的滿

足該項目要求的開發(fā)流程。

開始

《軟件雷求規(guī)格說明書》(初碼)

《系統(tǒng)測試計劃(》《系統(tǒng)測試率例)

軟件需求分析(初稿)

《用戶手肝)(楓要》

m測表一

N:改進

《獻件需求規(guī)格說明書》

同行評審(系統(tǒng)測試計劃》《系統(tǒng)測試案例)

通過《個人評審記錄》

《評審報告》

《結構設計說明書》(初稿》

《集成測試計劃)《集成測試案例)

《初稿)

結構設計《用戶于冊)(初稿)

《迫測表一)

N:改進

《結構設計說明書5》

《集成測試計劃)《集成測達案例》

評審通過《個人評審記錄)

評審報告)

《詳細設計說明書》(初稿)

《單元測試計劃)《單元測試案例》

《初稿)

詳細設計《用戶手冊)(飾改稿)

《迫測表一)

N,改進(詳細設計說明書》

《單元測試計劃》《單元測試案例》

《用戶手冊》(修改稿)

評審通過《個人評審記錄》

評審報告》

算代碼、潭代碼文件清單

《單元測試報告)(經過審批)

輔碼《軟件問圓狀態(tài)登記表》

《軟件問題報告單

《集成工作單》

《集成測試工作單)

《集成測試報告)(經過審批》

集成測試《軟件閂題狀態(tài)登記表》

《軟件問題報告單)

成的軟件系信

《系統(tǒng)測試報告》(經過審批)

(軟件問題狀態(tài)登記表》

《軟件問題報告單》

《系統(tǒng)管理員使用說明書》(經過審批)

系統(tǒng)測試(安裝于冊》(經過申批)

《用戶手冊》(經過審壯

軟件系統(tǒng)(系統(tǒng)測試通

驗收測試報告

《軟件問翻報告單》

《軟件間豳狀杏登記表》

驗收驗收報告

可交付產品

(軟件需求規(guī)格說明書》(升級版)

《客戶需求登記表》

(客戶需求統(tǒng)計表》

(設計說明書》(升級版)

維護《軟件問題報告單》

(軟件間麗狀杏登記表》

(軟件維護實施計劃》

作護后的軟件系線

結束

在應用系統(tǒng)軟件開發(fā)項目中，我們仍將遵循這一思想，

這一點將在隨后的項目開發(fā)實施計劃部分有具體的體現(xiàn)，在

這里和下面的相關章節(jié)中，我們仍將圍繞著這個完整的開發(fā)

流程來分析說明，以此來闡明我們對項目開發(fā)的完整過程管

理思想和相關實踐。下面我們對這個軟件開發(fā)工作流程進行

簡要地分解說明。

軟件需求分析

(1)概述

由于應用系統(tǒng)與眾多相關應用軟件需要進行交互，因此

需要先對這些應用系統(tǒng)進行分別梳理，充分做好需求調研工

作，編寫經項目單位認可并評審通過的《系統(tǒng)需求規(guī)格說明

書》。

軟件需求分析是按照項目定義的軟件開發(fā)過程，根據(jù)系

統(tǒng)分配給軟件的需求(見《系統(tǒng)需求規(guī)格說明書》),進行

軟件質量特性規(guī)格說明的過程。該過程包括進一步明確軟件

運行環(huán)境，明確對軟件的功能、性能和數(shù)據(jù)要求，以及軟件

與硬件、軟件與軟件之間的接口要求等，并對軟件需求進行

驗證和文檔化，即完成對軟件需求的分析與規(guī)格定義。

本元素在整個過程中的位置如下圖所示：

系統(tǒng)軟件需結構設

圖示：軟件需求分析在軟件開發(fā)過程中的位置

(2)入口準則和出口準則

1)入口準則

要素判斷準則

客戶需求

已由CCB批準為基線

(《系統(tǒng)需求規(guī)

已進入配置庫

格說明書》)

2)出口準則

要素判斷準則

已經過審查

軟件需求規(guī)

已批準為基線

格說明書

已進入配置庫

系統(tǒng)測試計劃已經過審查

系統(tǒng)測試案已獲得批準

例已進入配置庫

用戶手冊(概

已編寫

要)

追溯表一已填寫

(3)評審

評審《軟件需求規(guī)格說明書》,具體評審過程見《評審

程序文件》,對軟件需求的評審準則包括：

●系統(tǒng)需求和系統(tǒng)設計的可追溯性；

●與系統(tǒng)需求的一致性；

●內部一致性；

●可測試性；

●軟件設計的可行性；

●運作和維護的可行性。

對軟件需求中的問題，與系統(tǒng)工程組或客戶一起確定和

審查，根據(jù)審查結果對軟件需求進行適當?shù)男薷?，必要時按

基線變更控制的要求對客戶需求進行相應的修改。對軟件需

求規(guī)格說明書進行同行評審。審查、批準軟件需求規(guī)格說明

書。

將軟件需求規(guī)格說明書置于配置管理之下。

(4)工作產品

●《軟件需求規(guī)格說明書》

●《系統(tǒng)測試計劃》

●《系統(tǒng)測試案例》

●《用戶手冊》

●《追溯表》

(5)職責

●項目經理：負責組建軟件需求分析組；確定是否需要

對有關人員進行培訓；負責軟件需求規(guī)格說明書的審

查和批準。

●軟件需求分析組：軟件需求分析的主要承擔者，負責

完成本過程元素要求產生的所有工作產品。

●系統(tǒng)測試負責人：負責組織軟件系統(tǒng)測試組對軟件需

求進行分析，審查軟件需求的可測試性；參與軟件需

求規(guī)格說明書的審查和批準。

●質量保證人員：參與工作產品的審查，統(tǒng)計缺陷，并

對軟件需求分析過程進行審計。

●系統(tǒng)開發(fā)組：配合處理涉及客戶需求的軟件需求問題。

●客戶：必要時參與軟件需求規(guī)格說明書的審查和批準。

結構設計

(1)概述

結構設計是指按照《軟件需求規(guī)格說明書》,設計軟件

系統(tǒng)的體系結構，即模塊結構，定義每個模塊的主要功能和

模塊之間的聯(lián)系(即接口),并確定軟件系統(tǒng)的數(shù)據(jù)體系結

構。

本元素在整個過程中的位置如下圖所示：

軟件結詳

圖示：軟件需求分析在軟件開發(fā)過程中的位置圖

(2)入口準則和出口準則

1)入口準則

要素判斷準則

軟件需求規(guī)格說經過審查

明書審查獲得批準

進入配置庫

2)出口準則

要素判斷準則

結構設計說明書經過審查

集成測試計劃審查獲得批準

集成測試案例進入配置庫

用戶手冊(初稿)

已完善

追溯表一

(3)評審

●對《結構設計說明書》和《集成測試計劃》進行同行

評審。

●對結構設計中的問題，與軟件需求分析人員一起確定

和審查，并對結構設計進行適當?shù)母摹?/p>

●審查、批準《結構設計說明書》,必要時，對其進行

設計評審。

●將《結構設計說明書》、《集成測試計劃》和《集成

測試案例》置于配置管理之下。

(4)工作產品

●《結構設計說明書》

●《集成測試計劃》

●《集成測試案例》

●《用戶手冊》

●《追溯表》

(5)職責

1)項目經理

負責選擇合適的設計人員，組建結構設計工作組；負責

《結構設計說明書》和《集成測試計劃》的審查和批準。

2)結構設計人員

結構設計階段工作的主要承擔者，負責完成本過程元素

產生的所有工作產品。

3)系統(tǒng)分析員

配合處理涉及軟件需求的問題。

4)系統(tǒng)開發(fā)負責人

負責組織系統(tǒng)工程組對結構設計進行分析，審查結構設

計的可測試性；負責協(xié)調處理涉及軟件需求的問題；參與《結

構設計說明書》和《集成測試計劃》的審查和批準。

5)軟件測試負責人

負責組織軟件測試組對結構設計進行分析，審查結構設

計的可測試性；參與《結構設計說明書》和《集成測試計劃》

的審查和批準。

詳細設計

(1)概述

詳細設計是根據(jù)《結構設計說明書》進行模塊設計，將

結構設計所獲得的模塊按照單元、程序、規(guī)程的順序逐步細

化。詳細定義各個單元的數(shù)據(jù)結構、程序的實現(xiàn)算法以及程

序、單元、模塊之間的接口等，作為以后編碼工作的依據(jù)。

本元素在整個過程中的位置如下圖所示：

結構設詳細設8編碼

圖示：詳細設計在軟件開發(fā)過程中的位置

(2)入口準則和出口準則

1)入口準則

要素判斷準則

結構設計說明書經過審查

審查獲得批準

進入配置庫

2)出口準則

要素判斷準則

詳細設計說明書經過審查

審查獲得批準

進入配置庫

(3)評審

對《詳細設計說明書》和《單元測試計劃》可進行走查

或(和)同行評審；

對詳細設計中的問題，與結構設計人員一起確定和審

查，并對詳細設計做出適當?shù)母模?/p>

審查、批準《詳細設計說明書》,必要時，對其進行設

計評審；

將《詳細設計說明書》和《單元測試計劃》置于配置管

理之下。

(4)工作產品

●《詳細設計說明書》

●《單元測試計劃》

●《單元測試案例》

●《用戶手冊》

●《追溯表》

(5)職責

1)項目經理

負責選擇合適的設計人員，組建詳細設計組；負責《詳

細設計說明書》和《單元測試計劃》的審查和批準。

2)詳細設計人員

詳細設計階段工作的主要承擔者。負責完成本過程元素

產生的所有工作產品。

3)系統(tǒng)分析員

配合處理涉及軟件需求的問題。

4)系統(tǒng)開發(fā)負責人

負責組織系統(tǒng)工程組對詳細設計進行分析，審查詳細設

計的可測試性；負責協(xié)調處理涉及軟件需求的問題；參與《詳

細設計說明書》和《單元測試計劃》的審查和批準。

5)軟件測試負責人

負責組織軟件測試組對詳細設計進行分析，審查詳細設

計的可測試性；參與《詳細設計說明書》和《單元測試計劃》

的審查和批準。

編碼

(1)概述

編碼階段主要完成的工作是根據(jù)詳細設計說明書編寫

程序源代碼，包括必要的數(shù)據(jù)文件，并進行單元測試，單元

測試的內容包括模塊內程序的邏輯、功能、參數(shù)傳遞、變量

引用、出錯處理等方面。

本元素在整個過程中的位置如下圖所示：

詳細設編集成

圖示：編碼階段在軟件開發(fā)過程中的位置

(2)入口準則和出口準則

1)入口準則

要素判斷準則

詳細設計說明書經過審查

單元測試計劃獲得批準

進入配置庫

2)出口準則

要素判斷準則

源代碼文件源代碼文件獲得批準

源代碼文件清單源代碼文件進入配置庫

的源代碼區(qū)

單元測試報告提交測試負責人

軟件問題報告單提交問題管理渠道

(3)評審

對源代碼文件進行同行評審，主要的方法為對照詳細設

計說明書對代碼進行查閱，也可根據(jù)編程者的經驗或程序的

難度、重要程度，選擇走查評審方式，但目的都是發(fā)現(xiàn)程序

存在的問題。

(4)工作產品

●源代碼文件

●《單元測試報告》

●《軟件問題報告單》

●《軟件問題狀態(tài)登記表》

(5)職責

1)項目經理

建立編碼組、測試組或相應崗位，并進行必要的培訓；

跟蹤進度和問題解決狀態(tài)；對提交的源代碼進行批準(或指

定負責人進行批準工作)。

2)程序員

編寫程序代碼；測試程序代碼；修改程序代碼；提交工

作產品，批準后將其導入配置區(qū)的源碼庫。

3)單元測試人員

測試源代碼；提交測試報告和軟件問題報告單。

4)評審人員

對指定源代碼文件進行閱讀，發(fā)現(xiàn)缺陷和問題，填寫評

審報告。

模塊集成測試

(1)概述

集成測試階段主要完成的工作是集成和集成測試。集成

是參考結構設計說明書并根據(jù)詳細說明書中規(guī)定的系統(tǒng)集

成方案將不同的經測試的程序單元進行構造，并逐步構造成

一個完整的軟件產品的過程；集成測試則是在集成完成之

后，對各單元、模塊之間接口的正確性和集成后功能的正確

性進行驗證。

對于大型軟件，集成測試可以采取分步進行的方法，可

以先對各子系統(tǒng)進行集成測試，然后在子系統(tǒng)之間進行集成

測試。

本元素在整個過程中的位置如下圖所示：

編碼集系

圖示：集成測試在軟件開發(fā)過程中的位置

(2)入口準則和出口準則

1)入口準則

要素判斷準則

結構設計說明書經過審查

詳細設計說明書獲得批準

集成測試計劃進入配置庫

源代碼文件

2)出口準則

要素判斷準則

集成的軟件系統(tǒng)獲得批準

(完整的源代碼和目進入配置庫

標代碼)

集成測試報告提交集成測試負責

人

軟件問題報告單已進入軟件問題管

理流程

(3)審查階段

核查集成狀態(tài)和結果，并進行批準；

批準后，將目標程序和程序清單進入目標代碼庫。

(4)工作產品

●集成后的系統(tǒng)目標代碼(包括文件清單),及相應的

源代碼(包括文件清單)

●集成測試報告

●《軟件問題報告單》

●《軟件問題狀態(tài)登記表》

●《集成工作單》

●《集成測試工作單》

(5)職責

●項目經理：建立集成組、集成測試組或相應崗位，并

進行必要的培訓；跟蹤進度和問題解決狀態(tài)；對集成

后的系統(tǒng)目標碼進行批準(或指定負責人進行批準工

作)。

●集成負責人員：負責集成過程的實施。

●集成人員：負責環(huán)境構建，集成的過程操作，并將集

成后的目標代碼提交批準。

●程序員、設計人員：修改源碼或設計，解決集成過程

中出現(xiàn)的與源碼有關的問題。

●測試人員：測試系統(tǒng)目標碼，將測試報告和軟件問題

報告單提交測試負責人。

系統(tǒng)測試

(1)概述

系統(tǒng)測試的主要任務是從系統(tǒng)需求的角度對系統(tǒng)運行

的正確性和性能進行驗證。系統(tǒng)測試的依據(jù)為系統(tǒng)測試計

劃。

本元素在整個過程中的位置如下圖所示：

集成系驗收

圖示：系統(tǒng)測試在軟件開發(fā)過程中的位置

(2)入口準則和出口準則

1)入口準則

要素判斷準則

系統(tǒng)需求經過審查

系統(tǒng)的目標代碼獲得批準

系統(tǒng)測試計劃進入配置庫

用戶手冊編寫完成

2)出口準則

要素判斷準則

系統(tǒng)測試報告獲得批準

軟件問題報告單

(3)工作產品

●《系統(tǒng)測試報告》

●《軟件問題報告單》

●《軟件問題狀態(tài)登記表》

(4)職責

●項目經理：負責建立系統(tǒng)測試組或相關的崗位，并進

行必要的培訓；跟蹤進度和問題解決狀態(tài)；對最終的

目標代碼進行批準(或指定負責人進行批準工作)。

●程序員、設計人員：修改源碼或設計，解決集成過程

中出現(xiàn)的與源碼有關的問題。

●測試人員：測試系統(tǒng)目標碼，將測試報告提交測試負

責人，將軟件問題報告單提交問題管理渠道。

驗收

(1)概述

驗收階段主要由驗收測試、驗收測試問題改正和驗收三

部分組成：

驗收測試的主要目的是驗證所開發(fā)的系統(tǒng)在用戶的使

用環(huán)境下(或模擬的使用環(huán)境下)是否滿足系統(tǒng)需求，從用

戶的角度驗證整個系統(tǒng)運行的正確性。

驗收測試問題改正是對驗收測試中發(fā)現(xiàn)的差異性問題

進行修改。

驗收則是在驗收測試的基礎上，依據(jù)項目合同或項目任

務書對項目的完成情況進行綜合評價。

本元素在整個過程中的位置如下圖所示：

系統(tǒng)驗維護

圖示：驗收在軟件開發(fā)過程中的位置

驗收的三個組成部分視項目立項類型和客戶的要求選

擇執(zhí)行。

(2)入口準則和出口準則

1)入口準則

要素判斷準則

驗收測試計劃(有驗驗收測試前完成評

收測試要求的項目)審。

測試(系統(tǒng)測試、集已完成

成測試、單元測試)

2)出口準則

要素判斷準則

驗收測試報告已提交

驗收測試問題報告單已關閉

驗收報告已提交

(3)工作產品

●驗收測試報告

●《軟件問題報告單》

●《軟件問題狀態(tài)登記表》

●驗收報告

●可交付產品

(4)職責

●驗收測試組：負責驗收測試的各項活動。

●開發(fā)組人員：負責驗收測試中發(fā)現(xiàn)問題的改正和測試

輔助。

●項目管理人員：負責指派驗收測試責任和完成測試規(guī)

程；確保測試質量和進程；確保組間協(xié)調。

●驗收組：具體進行驗收。

●CCB:批準運行基線。

維護

(1)概述

維護期是指：軟件產品/系統(tǒng)驗收后，進入軟件運行/系

統(tǒng)維護階段，直至軟件產品下一個版本的發(fā)布或系統(tǒng)維護期

終止；

本元素在整個軟件開發(fā)過程中的位置如下圖所示：

驗收維護

圖示：維護在軟件開發(fā)過程中的位置

(2)入口準則和出口準則

1)入口準則

要素判斷準則

軟件產品/系統(tǒng)已驗收

2)出口準則

要素判斷準則

軟件產品已退役

合同約定的維護期限已到期

合同約定的維護范圍已超出，須另簽協(xié)議

(3)工作產品

●《軟件需求規(guī)格說明書》

●《客戶需求登記表》

●《客戶需求統(tǒng)計表》

●《設計說明書》

●《軟件問題報告單》

●《軟件問題狀態(tài)登記表》

●《軟件維護實施計劃》

●維護后的軟件系統(tǒng)

(4)職責

維護負責人：制定軟件維護實施計劃，確認維護類型、

需求范圍，分配維護任務，追蹤任務的完成情況及其他項目

管理工作。軟件維護人員：負責進行軟件維護任務的執(zhí)行。

QA人員：負責協(xié)助維護負責人根據(jù)實際情況剪裁標準流

程。

第二章技術方案

2.1.產品技術先進，性能穩(wěn)定、升級擴展性強，技術方案

科學、合理、詳盡，可行性強

一、為用戶帶來準確的翻譯及發(fā)音

用戶小語種翻譯過程中會經常遇到不認識的單詞短語，

將其復制到小語種翻譯軟件當中可以進行小語種翻譯互譯

功能，還可以點擊發(fā)音，通過讀法和理解進行學習小語種，

更加適合用戶的學習狀態(tài)。準確的小語種讀法和詳細的解析

是用戶學習路上所需要的，這也是對于用戶需求的滿足。

二、幫用戶拓展相關聯(lián)單詞和短語

小語種翻譯軟件的開發(fā)為用戶帶了單詞的詞匯量提升，

用戶可以在小語種翻譯軟件客戶端進行相對應的單詞短語

學習，在學習的過程成長。每當用戶通過小語種翻譯單詞短

語之后，系統(tǒng)可以為用戶搜索到相關聯(lián)的單詞短語，幫助用

戶加深在學習英語時候的應用，讓用戶可以更好地進行單詞

短語在生活中的使用。

三、手機在線翻譯，快速且便捷

智能手機現(xiàn)在我們生活中大部分都是出門都會攜帶的

一款便捷性設備，用戶隨時隨地可以使用小語種翻譯軟件，

手機上操作可以充分得利用翻譯軟件的優(yōu)勢功能鞏固單詞

短語。打好英語基礎義不容辭，小語種翻譯軟件具備的快捷

性讓用戶更青睞于使用。

在學習英語的道路上是需要不斷積累的，小語種翻譯軟

件的開發(fā)是學習路上的一個“好老師”,幫助用戶解決在學

習上面所面臨的難題，幫助用戶鞏固英語的知識基礎。我們

的移動互聯(lián)網時代中，運用手機客戶端能夠為用戶帶來諸多

的便利事項，新穎有創(chuàng)意的小語種翻譯軟件開發(fā)可以吸引更

多用戶的眼光

S101開始

選擇待翻譯的詞語

S102

檢測翻譯數(shù)據(jù)庫內N

是否存在翻譯條目

S103

Y

將包含有翻譯條目信息的代碼塊替換

原與待翻譯的詞語相對應的代碼塊

結束

背景技術：

軟件開發(fā)時，要使它能同時應對世界不同地區(qū)和國家的

訪問，并針對不同地區(qū)和國家的訪問，提供相應的、符合來

訪者閱讀習慣的頁面或數(shù)據(jù)，就需要為軟件實現(xiàn)國際化。目

前在現(xiàn)有的為軟件實現(xiàn)國際化的技術中，要求程序員將需要

國際化的詞語的翻譯部分寫入配置文件中，因此，則必須要

求程序員具備較高的語言翻譯能力。

技術實現(xiàn)要素：

為了使語言翻譯能力較弱的程序員也能順利地對軟件

實現(xiàn)國際化，本申請?zhí)峁┝擞糜谲浖_發(fā)的自動翻譯方法及

用于軟件開發(fā)的自動翻譯系統(tǒng)。

本申請由以下技術方案實現(xiàn)的：

用于軟件開發(fā)的自動翻譯方法，包括以下步驟：

選擇待翻譯的詞語；

檢測翻譯數(shù)據(jù)庫內是否存在與待翻譯的詞語相對應的

翻譯條目，如果是，則將包含有翻譯條目信息的代碼塊替換

原與待翻譯的詞語相對應的代碼塊。

如上所述的用于軟件開發(fā)的自動翻譯方法，如果檢測到

翻譯數(shù)據(jù)庫內不存在與待翻譯的詞語相對應的翻譯條目，則

調用翻譯云服務器將待翻譯的詞語翻譯成指定語言生成翻

譯結果；

接收翻譯云服務器反饋的翻譯結果；

彈出翻譯結果并請求確認信息；

如果接收到翻譯結果確認信息，則將翻譯結果存儲于翻

譯數(shù)據(jù)庫內形成新的翻譯條目。

本申請還公開了用于軟件開發(fā)的自動翻譯系統(tǒng)，包括：

選擇模塊，其用于選擇待翻譯的詞語；

翻譯檢測模塊，其用于檢測翻譯數(shù)據(jù)庫內是否存在與待

翻譯的詞語相對應的翻譯條目；

代碼替換模塊，其用于將包含有翻譯條目信息的代碼塊

替換原與待翻譯的詞語相對應的代碼塊。

如上所述的用于軟件開發(fā)的自動翻譯系統(tǒng)，包括：

調用模塊，其用于在所述翻譯檢測模塊檢測到翻譯數(shù)據(jù)

庫內不存在與待翻譯的詞語相對應的翻譯條目時調用翻譯

云服務器將待翻譯的詞語翻譯成指定語言生成翻譯結果；

接收模塊，其用于接收翻譯云服務器反饋的翻譯結果；

請求確認模塊，其用于彈出翻譯結果并請求確認信息；

存儲模塊，其用于在接收到翻譯結果確認信息時將翻譯

結果存儲于翻譯數(shù)據(jù)庫內形成新的翻譯條目。

2.2.總則

為規(guī)范本小語種翻譯軟件服務項目軟件開發(fā)的管理工

作，特制定本制度。本制度適用于公司軟件研發(fā)與管理。

軟件開發(fā)遵循項目管理和軟件工程的基本原則。項目管

理涉及立項管理、項目計劃和監(jiān)控、配置管理、合作開發(fā)管

理和結項管理。軟件工程涉及需求管理、系統(tǒng)設計、系統(tǒng)實

現(xiàn)、系統(tǒng)測試、用戶接受測試、試運行、系統(tǒng)驗收、系統(tǒng)上

線和數(shù)據(jù)遷移。

除特別指定，本制度中項目組包括業(yè)務組(或需求提出

組)、IT組(可能包括網絡管理員和合作開發(fā)商)。

2.3.立項管理

提出開發(fā)需求的信息技術部門參與公司層面立項，進行

立項的技術可行性分析，編寫《立項分析報告》(附件一),

開展前期籌備工作?！读㈨椃治鰣蟾妗窇鞔_項目的范圍和

邊界。

應用系統(tǒng)主要使用部門將《立項分析報告》上交公司總

裁室進行立項審批，以保證系統(tǒng)項目與公司整體策略相一

致。

2.4.需求分析

立項后業(yè)務組對用戶需求進行匯總整理，出具《業(yè)務需

求說明書》(附件二),并確保《業(yè)務需求說明書》中包含

了所有的業(yè)務需求。經系統(tǒng)使用部門審批確認，作為業(yè)務需

求基線。

IT組在獲得《業(yè)務需求說明書》后，提出技術需求和解

決方案，并對系統(tǒng)進行定義，出具《系統(tǒng)需求規(guī)格說明書》

(附件三)?！断到y(tǒng)需求規(guī)格說明書》需詳細列出業(yè)務對系

統(tǒng)的要求(界面、輸入、輸出、管理功能、安全需求、運作

模式、關鍵指標(KPI)等)?！断到y(tǒng)需求規(guī)格說明書》需要

由業(yè)務組提交給相關業(yè)務流程負責人確認。

對于合作開發(fā)的項目，當業(yè)務需求發(fā)生變更時，業(yè)務組

應提交《需求變更申請》(附件四),IT組組長審批后交給

合作開發(fā)商實施。

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

2.5.項目計劃和監(jiān)控

軟件開發(fā)采用項目形式進行管理。項目經理負責整個項

目的計劃、組織、領導和控制。

需求分析過程中，項目經理組織制定詳細的《項目計劃

書》(附件五),包括具體任務描述和項目進度表等。

在項目的各個階段，業(yè)務組組長和IT組組長需配合項

目經理制定階段性項目計劃。業(yè)務組組長和IT組組長需配

合項目經理對項目計劃執(zhí)行情況進行監(jiān)控，確保項目按計劃

完成。

項目計劃需要變更時，項目經理填寫《項目計劃變更說

明》(附件六),并提交公司主管領導審批，通過審批后，

交給業(yè)務組組長和IT組組長執(zhí)行。

2.6.小語種翻譯軟件系統(tǒng)設計

系統(tǒng)設計應分為概要設計和詳細設計，系統(tǒng)設計要遵循

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

則。

在系統(tǒng)設計階段中，用戶應充分參與，確保系統(tǒng)設計能

滿足系統(tǒng)需求。

項目組進行詳細設計，出具《設計說明書》(附件七)

和《單元測試用例》(附件八)?！对O計說明書》中需要定

義系統(tǒng)輸入輸出說明和接口設計說明。公司主管領導組織相

關人員對概要設計進行評審，出具《設計評審報告》(附件

九)。業(yè)務組組長和IT組組長應參加此評審并對評審意見

簽字確認。

設計評審均以《業(yè)務需求說明書》和《系統(tǒng)需求規(guī)格說

明書》為依據(jù)，確保系統(tǒng)設計滿足全部需求。

對已確認通過的系統(tǒng)設計進行修改需獲得管理部門、業(yè)

務組組長和IT組組長的審批后方可進行。

對系統(tǒng)設計的修改的文檔須由文檔管理人員進行歸檔

管理。

2.7.小語種翻譯軟件系統(tǒng)實現(xiàn)

項目組根據(jù)《設計說明書》制定系統(tǒng)實現(xiàn)計劃，并提交

項目經理對計劃可行性進行審批。

系統(tǒng)實現(xiàn)包括程序編碼、單元測試和集成測試。

項目組保證開發(fā)、測試和生產環(huán)境獨立，為各環(huán)境建立

訪問權限控制機制，并明確項目成員的職責分工。對開發(fā)環(huán)

境、測試環(huán)境與生產環(huán)境在物理或邏輯方面應該做到隔離；

如果環(huán)境的分隔是通過邏輯形式實現(xiàn)的，應定期檢查網絡設

置。項目組對已授權訪問生產環(huán)境的人員進行詳細記錄，并

對該記錄進行定期檢查，確保只有經授權的人員才能訪問到

生產環(huán)境。

項目組進行單元測試和集成測試，測試人員簽字確認測

試結果。

2.8.系統(tǒng)測試和用戶測試

項目組制定《系統(tǒng)/用戶測試計劃》(附件十),并提

交項目經理對計劃可行性進行審批。

《系統(tǒng)/用戶測試計劃》必須定義測試標準，并明確各

種測試的測試步驟和需要的系統(tǒng)設置要求。

項目組向數(shù)據(jù)擁有部門申請獲取測試用業(yè)務數(shù)據(jù)的使

用權，對獲取的數(shù)據(jù)進行嚴格的訪問控制，確保只有相關項

目人員才能訪問及使用。

項目組負責測試數(shù)據(jù)準備，測試用數(shù)據(jù)要足夠模擬生產

環(huán)境中的實際數(shù)據(jù)。對已評定為敏感信息的數(shù)據(jù)進行敏感性

處理和保護。

IT組或合作開發(fā)商建立測試環(huán)境進行系統(tǒng)測試。在系統(tǒng)

測試中對新系統(tǒng)內部各模塊之間的接口和與其他系統(tǒng)的接

口進行充分測試。出具《系統(tǒng)測試報告》(附件十一),測

試人員簽字確認測試結果。

系統(tǒng)測試通過后，IT組配合業(yè)務組建立用戶測試環(huán)境，

業(yè)務組根據(jù)用戶測試用例進行用戶測試，出具《用戶測試報

告》(附件十一),業(yè)務組組長和IT組組長應在用戶測試

報告中簽字確認。

項目組完成系統(tǒng)幫助文檔(其中包括《用戶操作手冊》

和《安裝維護手冊》)。凡涉及應用系統(tǒng)的變更，應對系統(tǒng)

幫助文檔及時更新。

2.9.試運行

系統(tǒng)主要使用部門根據(jù)項目規(guī)模及影響決定試運行策

略。

項目組制定《試運行計劃》(附件十二),并制定試運

行驗收指標，上報公司主管領導審批?！对囘\行計劃》中應

包含問題應對機制，明確問題溝通渠道和職責分工。

項目組聯(lián)合試運行單位進行相關系統(tǒng)部署工作，準備培

訓資料，對相關用戶和信息技術人員進行培訓。用戶培訓的

完成度應為實施后評估的指標之一。

項目組根據(jù)《試運行計劃》進行系統(tǒng)轉換和數(shù)據(jù)遷移。

系統(tǒng)轉換前，檢查系統(tǒng)環(huán)境，確保運行環(huán)境能滿足新應用系

統(tǒng)的需要。系統(tǒng)轉換時必須詳細記錄原系統(tǒng)中的重要參數(shù)、

設置等系統(tǒng)信息，并填寫試運行報告相關內容。系統(tǒng)參數(shù)、

設置的轉換工作作為系統(tǒng)上線的驗收的評估指標之一。

數(shù)據(jù)遷移前，應制定詳細的《數(shù)據(jù)遷移計劃》(附件十

三),《數(shù)據(jù)遷移計劃》中應包含遷移方案、測試方案、數(shù)

據(jù)定義，新舊數(shù)據(jù)對照表、遷移時間、回退計劃等信息。數(shù)

據(jù)遷移計劃需經項目經理和主管領導簽字審批。

數(shù)據(jù)遷移后，項目組對數(shù)據(jù)遷移的完整性和準確性作出

檢查，出具《數(shù)據(jù)遷移報告》(附件十四),其中包括數(shù)據(jù)

來源、轉換前狀態(tài)、轉換后狀態(tài)，數(shù)據(jù)遷移負責人、對完整

性檢查情況、對準確性檢查情況等內容。各相關部門驗收轉

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

系統(tǒng)轉換和數(shù)據(jù)遷移由試運行單位業(yè)務部門和公司主

管領導共同監(jiān)督并進行驗收。

系統(tǒng)轉換和數(shù)據(jù)遷移驗收通過后，正式啟動試運行。在

試運行過程中，試運行單位辦公室把系統(tǒng)運行情況(系統(tǒng)資

源使用，反應速度等)記錄到試運行報告中。必要時，項目

組應根據(jù)系統(tǒng)運行情況對應用系統(tǒng)進行優(yōu)化。

試運行達到試運行計劃規(guī)定的終止條件時，項目組編寫

《試運行報告》(附件十五)。此報告應由項目組和試運行

單位簽字確認，并提交公司主管領導審閱。公司主管領導審

閱試運行結果，決定試運行結束或延期。

2.10.系統(tǒng)驗收

系統(tǒng)主要使用部門及信息技術部門聯(lián)合組成獨立系統(tǒng)

驗收小組，也可授權原項目組作為驗收小組。驗收小組從功

能需求及技術需求層面對系統(tǒng)進行綜合評估。

驗收小組應根據(jù)驗收情況整理形成《系統(tǒng)驗收報告》(附

件十六)提交系統(tǒng)主要使用部門和信息技術部門審閱。

系統(tǒng)主要使用部門和信息技術部門負責人根據(jù)系統(tǒng)測

試、試運行情況簽署驗收意見。

2.11.系統(tǒng)上線

系統(tǒng)上線應遵循穩(wěn)妥、可控、安全的原則。

通常情況下，系統(tǒng)上線包含數(shù)據(jù)遷移工作。

項目組制定《系統(tǒng)上線計劃》(附件十七),上報公司

主管領導審批。在上線計劃得到批準后才能開始部署上線工

作。

《系統(tǒng)上線計劃》內容應包括但不限于：

部署方式和資源分配(包括人力資源及服務器資源);

上線工作時間表；

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

項目階段性里程碑和成果匯報(項目執(zhí)行狀態(tài)的審閱、

進度安排等);

數(shù)據(jù)遷移的需求和實施計劃；

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

用戶培訓計劃(包括：培訓計劃、培訓手冊、培訓考核

等);

公司下發(fā)的系統(tǒng)標準參數(shù)配置。

上線單位在上線初期需加強日常運行狀態(tài)監(jiān)控，出現(xiàn)問

題時應及時處理，對重大問題應啟動緊急預案。

在完成上線后要填寫《系統(tǒng)驗收評估報告》(附件十八),

上報公司項目組匯總整理?！断到y(tǒng)驗收評估報告》內容包括：

數(shù)據(jù)準確性、系統(tǒng)性能及穩(wěn)定性、接口問題、權限問題、業(yè)

務操作影響度、問題處理情況、備份、批處理等。

上線單位管理層要對《系統(tǒng)驗收評估報告》進行審批簽

字。

公司主管領導批準結項后，業(yè)務組和IT組將整理的文

檔提交各自部門統(tǒng)一管理。

第三章合作開發(fā)管理

合作開發(fā)商的選擇應遵循公司相關規(guī)定，合作商資質認

定參見第三方管理制度。

合作開發(fā)商必須遵循公司《軟件開發(fā)管理制度》。

項目經理同合作開發(fā)商明確規(guī)定項目變更的范圍和處

理方式，重點關注需求和設計變更。

項目經理負責監(jiān)控合作開發(fā)商的項目管理及軟件開發(fā)

活動。合作開發(fā)商應按計劃定期向項目經理報告進展狀態(tài)，

并提交階段性成果文檔。發(fā)生重大問題時，合作開發(fā)商需及

時向項目經理匯報。

IT組組長派專人監(jiān)控合作開發(fā)商的質量保證過程。

項目組同合作開發(fā)商商定驗收的標準和方法。

以上各要求需要在開發(fā)合同中明確。

3.1.立項分析報告

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

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

[]正式發(fā)作者：

布

完成日期：Year-Month-Day

[]正在修

改

版本歷史

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

小語種翻譯軟件服務項目

項目介紹

1.1.項目目的

1.2.提示：用簡練的語言說明本項目“是什么”,

“實現(xiàn)什么目的”。描述簡練且清晰。

1.3.項目背景

1.4.提示：闡述項目背景，重點說明“為什么”

會產生本項目。

1.5.(1)公司的短期、長期發(fā)展戰(zhàn)略；

1.6.(2)業(yè)務需求及發(fā)展趨勢；

1.7.(3)技術狀況及發(fā)展趨勢；

1.8.(4)特殊的業(yè)務需求等。

1.9.項目范圍

1.10.提示：根據(jù)對現(xiàn)有需求的了解來確定項目基

本范圍，說明本系統(tǒng)“應當包含的內容”和“不包含的

內容”。

1.11.項目計劃

1.12.項目團隊

1.13.提示：說明項目團隊的角色、知識技能要求、

建議人選、人數(shù)、工作時間，如下表所示。

知識技能要建議人選、人

角色工作時間

求數(shù)

項目經理

需求開發(fā)人

員

系統(tǒng)設計人

員

編程人員

測試人員

質量保證人

員

配置管理人

員

服務與維護

人員

成本估計

內容成本(人民幣)備注

人力資源

軟硬件資源

差旅費

會議費

接待費

進度表

提示：制定項目開發(fā)的進度表(建議給出項目里程碑計劃)。

例如：

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

需求調研完成

項目計劃完成

需求分析完成

概要設計完成

詳細設計完成

實現(xiàn)完成

集成測試完成

系統(tǒng)測試完成

用戶驗收測試

完成

試運行結束

項目驗收

總結

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

業(yè)務需求說明書

文件狀態(tài)：文件標|ProjectName-

[√]草稿識：

[]正式發(fā)當前版X.Y

布本：

[]正在修作

改者：

完成日Year-Month-Day

期：

版本歷史

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

1概述

1.1業(yè)務調研人員名單

【可選】

職能部門姓名主管聯(lián)系電話備注

序

號

1.2業(yè)務范圍

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

1.3業(yè)務目標

從高層或商務利益的角度提出本業(yè)務系統(tǒng)的期望目標，

以及評價標準。

1.4相關文檔

說明：列出本文檔的所有參考文獻(可以是非正式出版

物),包括現(xiàn)有規(guī)范、標準、批文、引用到的文件、資料等。

1.5業(yè)務詞匯表

說明：列出本文檔的所引用的專屬領域詞匯、術語等，

以便于業(yè)務需求的提供者和接收者是建立在一致的業(yè)務理

解基礎之上的。

2組織結構及業(yè)務

2.1業(yè)務相關組織結構、人員組織結構

說明：如果客戶崗位設置復雜可分別設置，業(yè)務組織結

構和人員組織結構

2.2組織機構描述

2.3角色職責

說明：將業(yè)務涉及的具體人員進行一定程度的分類和抽

象，描述該抽象角色的操作職責。

2.4管理綜述

【可選】

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

典型按庫存生產模式。生產計劃以年度銷售計劃為指

導，并綜合考慮設備能力、生產天數(shù)、庫存、歷史銷售記錄。

采購計劃的制訂以生產計劃為依據(jù)。

2.5現(xiàn)有業(yè)務流程清單

【可選】

說明：現(xiàn)有業(yè)務流程需要考慮，很多新的業(yè)務是在已有

業(yè)務流程基礎上進行重組的。

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

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

說明：針對每一項具體的目標業(yè)務，描述具體的業(yè)務流

程，以及相關業(yè)務的具體描述。

3.1具體業(yè)務流程(系統(tǒng)名稱+編號)

對于具體業(yè)務流程的命名有規(guī)范，對具體流程進行編

號，便于形成需求矩陣，同時形成需求的管理和跟蹤。

3.1.1業(yè)務流程

3.1.2業(yè)務描述

說明：描述具體的業(yè)務流程。

3.1.3相關業(yè)務對象

說明：業(yè)務對象：業(yè)務流程中涉及的單據(jù)、報表等。

業(yè)務對象使用部門對應電子檔案編號

3.1.4業(yè)務規(guī)則及關鍵算法

說明：描述業(yè)務環(huán)節(jié)關鍵算法體系。

4假定和約束

說明：列出進行本軟件開發(fā)工作的假定和約束，例如開

發(fā)期限等。

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

4.2設計約束

【可選】

說明：開發(fā)過程中必須使用的軟件語言、軟件進程需求、

主要開發(fā)工具、核心技術、第三方產品等。

4.3產品應當遵循的標準或規(guī)范

【可選】

說明：闡述本產品應當遵循什么標準、規(guī)范或業(yè)務規(guī)則，

違反標準、規(guī)范或業(yè)務規(guī)則的產品通常不太可能被接受。

5其他

5.1目前核心問題和困難

5.2業(yè)務對項目實施的需求和期望

【可選】

5.3其他未盡事宜

系統(tǒng)需求規(guī)格說明書

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

[√]草稿識：

[]正式發(fā)當前版X.Y

布本：

[]正在修作

改

者：

完成日Year-Month-Day

期：

版本歷史

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

1引言

1.1目的

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

功能性需求。

1.2讀者對象及閱讀建議

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

1.3文檔范圍

【可選】

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

圍，例如，本文引用到的用例模型，系統(tǒng)原型，系統(tǒng)測試用

例等文檔。

1.4參考文檔

說明：列出本文檔的所有參考文獻(可以是非正式出版物),

包括計劃任務書、合同、批文、引用到的文件、資料及軟件

開發(fā)標準等。

1.5術語與縮寫解釋

說明：列出本文件中用到的專門術語的定義和縮寫詞的原詞

組，并給予解釋，以便于所有讀者達成共識。

2綜合描述

2.1系統(tǒng)背景

【可選】

說明：介紹系統(tǒng)的預期效果、歷史原因。

2.2問題說明

【可選】

提供一段說明，總結此項目需要解決的問題?？梢圆捎靡韵?/p>

格式：

問題是[對問題進行說明]

影響[問題影響的干系人]

問題的后果[該問題會導致什么后果]

成功的解決方案[應列出成功解決方案的一些主要優(yōu)

點]

2.3系統(tǒng)范圍

說明：闡述本項目“適用的業(yè)務領域”和“不適用的業(yè)務領

域”,本產品“應當包含的內容”和“不包含的內容”。說

清楚系統(tǒng)范圍的好處是：(1)有助于判斷什么是需求，什

么不是需求；(2)可以將開發(fā)精力集中在產品范圍之內；

(3)有助于控制需求的變更。

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

明確本產品所影響到的部門和業(yè)務；

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

2.4干系人與用戶說明

【可選】

2.4.1用戶環(huán)境

【接口配置】

(1)接口基礎信息配置

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

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

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

【其他配置[可選]】

說明：外圍系統(tǒng)或相關模塊的配置。

3.2.1.4通信接口

【可選】

說明：指定各種通信接口。例如，局部網絡的協(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ù)值需求

說明：欲處理的事務和任務的數(shù)量，以及在正常情況下

和峰值工作條件下一定時間周期中處理的數(shù)據(jù)總量。

3.2.2.3精度

說明：對該軟件的輸入、輸出數(shù)據(jù)精度的要求，可能包

括傳輸過程中的精度。

3.2.2.4時間特性要求

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

a.響應時間；

b.更新處理時間；

c.數(shù)據(jù)的轉換和傳送時間；

d.解題時間等要求。

3.2.2.5數(shù)據(jù)管理要求

【可選】

說明：需要管理的文卷和記錄的個數(shù)、表和文卷的大小

規(guī)模，要按可預見的增長對數(shù)據(jù)及其分量的存儲要求做出估

算。

3.2.2.6可用性

指出普通用戶和高級用戶要高效地執(zhí)行特定操作所需的培

訓時間，指出典型任務的可評測任務次數(shù)或根據(jù)用戶已知或

喜歡的其他系統(tǒng)確定新系統(tǒng)的可用性需求

性能

3.2.2.7可靠性

指出可用時間百分比(xx.xx%)、使用小時數(shù)、維護訪

問權、降級模式操作等。平均故障間隔時間(MTBF)。平均

修復時間(MTTR)一系統(tǒng)在發(fā)生故障后可以暫停運行的時

間。指出系統(tǒng)輸出要求具備的精密度(分辨率)和精確度(按

照某一已知的標準)。

3.2.3文檔需求

說明：主要是在線用戶手冊與幫助系統(tǒng)，也包括其他的

文檔

3.2.4第三方產品

【可選】

說明：使用到的第三方產品相關的使用許可、使用限

制、接口標準。

3.3數(shù)據(jù)字典

說明：把相關的數(shù)據(jù)抽取出來統(tǒng)一維護，在其他章節(jié)如

有類似信息描述，則關聯(lián)到數(shù)據(jù)字典的相關部分并加輔助說

明，如：引用到的字段等。

4補充資料

【可選】

4.1待確定的問題列表

【可選】

需求標題

1

調查方式

調查人

調查對象

時間、地

點

需求信息

記錄

需求變更申請

記錄號：

項類型：開發(fā)項目

目：

項目負責變更申請人：

人：

申請部門：申請日期：

變更內容

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

容如果變更為業(yè)務組提出，則業(yè)務組填寫；

及其理由如果變更為為信息技術組提出，則信息技術組填寫；

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

統(tǒng)及版本如果變更為業(yè)務組提出，則業(yè)務組填寫；

如果變更為為信息技術組提出，則信息技術組填寫；

對業(yè)務及分析需求變更引起的業(yè)務變更、業(yè)務接口的變更，

其接口的業(yè)務組填寫

影響

業(yè)務負責同意不同意

人意見：

簽字日期：

變更