一.引言

［軟件需求規格闡明書記錄對系統或系統的一部分日勺完整軟件需求。如下

是一種經典日勺軟件需求規格闡明書概述，用于波及用例建模日勺項目。此工件由一

種包構成，該包包括用例模型日勺用例、非功能性需求、接口需求以及其他支持信

息。本文檔模板適合采用用例建模技術的項目需求描述。］一一在正式編寫文

檔時，請刪除內容規定部分。

1.1編寫目日勺

本文檔作為***與XXXXXXXXXX企業之間就**x建立XXXX司（局或單位）論壇

系統需求理解到達一致共識口勺基礎文獻，作為雙方界定項目范圍、簽定協議口勺重

要基礎，也作為本項目驗收的重要根據。同步，本文檔也作為***后繼工作開展

的基礎，供雙方項目主管負責人、項目經理、技術開發人員、測試人員等理解需

求之用。

L2合用范圍

本文檔合用于所有與本項目有關日勺軟件開發階段及其有關人員，其中：***

方面的項目負責人、企業方項目經理、技術開發人員（包括分析人員、設計人員、

程序人員）、測試人員應重點閱讀本文檔各部分，其他人員可選擇性閱讀本文檔。

1.3文檔概述

本文檔重要描述了論壇系統項目的軟件需求。

本文檔首先從業務背景、系統功能、運行環境等方面概要描述系統，另首先

從顧客界面、軟件接口等方面描述系統日勺外部接口需求，然后深入詳細描述功能

性需求和非功能性需求以及待確定的問題。

1.4參照資料

［列出本文的參照文獻清單，包括出版單位、作者、版本、日期等信息。］

示范：------僅供參照，不具有任何實質性H勺內容。

《XXX總體需求書》(XXX單位XXX提供)

?xxx需求調研匯報》XXX

《設計模式》XXXXX出版社

1.5術語、定義和縮寫

［列出本文檔所波及的專業術語、縮寫詞及有關定義。

定義所有必要的術語，以便讀者可以對日勺地解釋軟件需求規格闡明，包括詞

頭和縮寫。你也許但愿為整個企業創立一張跨越多項項目的詞匯表，并且只包括

特定于單一項目H勺軟件需求規格闡明中的術語。］

示范：-----僅供參照，不具有任何實質性日勺內容。

1)OLTP：On-lineTransactionProcessing,聯機事務處理。

2)OLAP：On-LineAnalyticalProcessing,聯機分析處理；是使分析人

員、管理人員或執行人員可以從多角度電信息進行迅速、一致、交互地

存取,從而獲得對數據的更深入理解日勺一類軟件技術。

1.6Use-Case圖形規范

［對文檔中使用的Use-Case圖的圖符作簡介，同步闡明所應用UML規范的版

本，以便理解和統一。假如使用日勺是UMLVI.3原則規范，則可以直接將下列內

容作為文檔內容。］

一種Use-Case圖顯示H勺是Actor與Use-Case之間歐I某種關系。表1-1列出

了本文檔的Use-Case圖中用到的圖符、名稱及其功能簡介。

表1-1UMLVI.3UseCase圖符

圖符名稱描述

用于體現Usc-casc圖中的JUse-Case,每個UseCase

Use

UseCase用于體現所建模系統的一項外部功能需求，即從顧

Case

客日勺角度分析所得的需求。

用于描述與系統功能有關的外部實體，它可以是顧

ActorActor

客，也可以是外部系統。

用于連接Actor和UseCase,體現該Actor所代表

關聯的系統外部與該UseCase所描述的系統需求有關。

這也是Actor和UseCase之間唯一合法淤J連接。

由UseCaseA指向UseCaseB（被擴展），體現

UseCaseB描述了一項基本需求，而UseCaseA則

?extends?擴展

描述了該基本需求的特殊狀況，即用例A擴展了用

例B的需求。

由UseCaseA（子用例）指向UseCaseB（父用例），

泛化體現UseCaseA繼承了UseCaseB的特性，并增

長了新日勺特性。

由UseCaseA指向UseCaseB（被包括），體現

?include?包括

UseCaseA中包括了UseCaseB中的行為或功能。

二.系統概述

2.1業務背景

［概要描述本系統日勺業務背景和來源。若用圖表更能清晰描述業務背景，則

提議在用自然文字描述業務的同步，輔以圖形、表格來更精確地描述業務。］

示范：-----僅供參照，不具有任何實質性的內容。

為切實推進國家助學貸款管理工作，貫徹《有關切實推進國家助學貸款工作

有關問題時告知》（銀發［2023］38號）、《有關下達2023年度國家助學貸款指

導性貸款計劃的告知》（銀發［2023］253號）和《有關加強國家助學貸款'三考

核'工作的告知》（銀辦發［2023］239號）文獻精神及肖鋼副行長有關在我司建

立銀行系統的助學貸款專題記錄制度的指示，滿足“要按月考核經辦銀行國家助

學貸款的申請人數和申請金額、考核已審批貸款人數和貸款協議金額、考核算際

發放貸款人數和發放金額。”“按月編報分省‘四定'口勺國家助學貸款進度明細

表”和“增報《國家助學貸款'三考核'指標分地區、分銀行登記表》”的工作

規定，處理目前記錄中存在的指標口徑難于統一（銀行與學校、教育管理部門），

數據采集不準、不細，校名不規范，手工記錄勞動量大、效率不高等問題。滿足

對貸款學生基本信息、信用記錄的查詢；對學校進度明細的記錄；對分地區、分

行別的匯總記錄以及有關分析等新的管理需求，必須有對應的計算機軟件系統支

持，以處理數據的采集錄入、記錄匯總、上報傳播的需要。

2.2系統功能

［以圖形、表格等形式簡要闡明本軟件系統的重要功能，易于讀者理解。詳

細內容將在第4部分闡明。對于采用老式措施分析系統需求，提議用Visio畫出

整個系統的功能構造。］

示范：------僅供參照，不具有任何實質性口勺內容。

銀行業務通用網上記錄暨助學貸款記錄系統通過定制不同樣日勺業務類別，定

制記錄業務的項目、指標及其匯總關系等，迅速滿足不同樣銀行業務的記錄規定，

形成從各級金融機構到***各分支機構，從下級機構到上級機構的業務定制、數

據采集、分析、記錄和信息公布日勺記錄體系。重要任務和目日勺是：遵照***統一

數據采集、統一信息公布建設原則，增進信息整合和應用整合。作為“***信息

系統平臺“R勺一部分，為“***信息系統平臺”提供部分公用化模塊組件，防止

業務模塊的反復開發。最終實現一種銀行業務通用網上記錄系統平臺；并能以便

地定制新的記錄業務，并能靈活適應業務發展需要。運用銀行業務通用網上記錄

系統平臺布署助學貸款專題網上記錄系統，滿足對國家助學貸款的“三考核”規

定，滿足***全面掌握助學貸款業務信息的需要，并配合建立銀行系統的助學貸

款專題記錄制度。助學貸款記錄分析系統可為***全轄各機構和有關部門提供統

一的數據采集、分析、報表、信息公布等多方面的功能，并可為商業銀行、教育

部門以及社會公眾提供有關信息查詢和記錄分析成果。并作為個人征信系統初期

應用模型，為增進個人征信系統打下基礎。

系統功能關系圖如卜：

2.3顧客類別及特性

［確定你覺得也許使用該產品日勺不同樣顧客類并描述它們有關的特性。有某

些需求也許只與特定的顧客類有關。提供參與系統的主角的名稱列表及簡要闡

明，即簡要描述系統所波及日勺各角色及其職責。］

示范：-----僅供參照，不具有任何實質性口勺內容。

注：應在上圖位置給出使用本系統日勺客戶組織日勺角色或崗位職責分派圖以替

代上圖。

下表是對上圖關鍵顧客角色（Actor）日勺簡要闡明：

Actor名稱簡要闡明權限

所有權限

至緒環種者一般由總部IT人員來擔任，顧客數量比較少。負責系統（讀、寫、

示次目理百的配置、備份與恢復，以及任務管理等工作。刪除、創

立）

XXX崗位

系統時鐘

工作流引擎

2.4顧客文檔

［列出所需的顧客文檔，例如：顧客手冊，聯機顧客文檔、聯機協助系統、

有關申明的協助等的需求。］

示范：-----僅供參照，不具有任何實質性H勺內容。

本軟件應提供實時在線協助（即聯機協助系統）、顧客操作手冊、系統管理

員手冊、系統安裝手冊以及培訓文檔。

2.5設計和實現上日勺限制

［確定影響開發人員自由選擇H勺問題，并闡明這些問題為何成為一種限制。

描述在進行設計和實現時需要注意的問題，例如，必須使用或者防止的特定技術、

工具、編程語言和數據庫；所規定的開發規范或原則；企業方略、政府法規或工

業原則；數據轉換格式原則等等。］

示范：-----僅供參照，不具有任何實質性的內容。

本系統應具有良好的可擴展性、復雜操作環境的可適應性、靈活可配置日勺權

限控制、大容量數據操作的迅速響應及高可靠性以及與既有系統的兼容性，同步,

具有在線提醒和短信息提醒，可以實現多種數據格式的轉換，以多種圖形格式展

示分析成果。

本系統應支持多級無限擴展應用，符合國際、國內原則規范，可以與其他系

統無縫銜接。

2.6假設和依賴

［列舉出在對軟件需求規格闡明中影響需求陳說的假設原因（與已知原因相

對立）。這也許包括需求分析人員打算要用日勺商業組件或有關開發或運行環境的

問題。需求分析人員也許認為產品將符合一種特殊的顧客界面設計約定，不過另

一種SRS讀者卻也許不這樣認為。假如這些假設不對時、不一致或被更改，

就會使項目受到影響。

此外，確定項目對外部原因存在的I依賴。例如，假如你打算把其他項目開發

的組件集成到系統中，那么你就要依賴那個項目準時提供對日勺的操作組件。假如

這些依賴已經記錄到其他文檔（例如項目計劃）中了，那么在此就可以參照其他文

檔。］

示范：-----僅供參照，不具有任何實質性日勺內容。

本系統需要集成其他軟件開發商提供的組件或應用系統，假定需要集成日勺組

件可以準時提供并滿足需求。假定這些組件的運行環境與本系統運行環境不發生

沖突，能與本系統兼容。

此外，假定本文檔所描述的軟件需求均獲得了項目雙方所有客戶的承認且穩

定不變。

假如項目后期，客戶提出加、J需求變更超過了本需求規格范圍，則將嚴重影響

本系統的設計、開發和程序的穩定。

在本軟件需求規格闡明書定版之后，客戶需求發生了較大變更，變更后日勺需

求規格闡明將不在本文檔中補充，而以新的版本文檔給出。

2.7假設和依賴

［列舉出在對軟件需求規格闡明中影響需求陳說的假設原因（與已知原因相

對立）。這也許包括你打算要用日勺商業組件或有關開發或運行環境的問題。你也

許認為產品將符合一種特殊日勺顧客界面設計約定，不過另一種SRS讀者卻也

許不這樣認為。假如這些假設不對的、不一致或被更改，就會使項目受到影響。

此外，確定項目對外部原因存在的依賴。例如，假如你打算把其他項目開發

的組件集成到系統中，那么你就要依賴那個項目準時提供對日勺歐I操作組件。假如

這些依賴已經記錄到其他文檔（例如項目計劃）中了，那么在此就可以參照其他文

檔。］

示范：-----僅供參照，不具有任何實質性口勺內容。

本系統需要集成其他軟件開發商提供的組件或應用系統，假定需要集成日勺組

件可以準時提供并滿足需求。假定這些組件的運行環境與本系統運行環境不發生

沖突，能與本系統兼容。

此外，假定本文檔所描述的軟件需求均獲得了項目雙方所有客戶的承認且穩

定不變。

假如項目后期，客戶提出加、J需求變更超過了本需求規格范圍，則將嚴重影響

本系統的設計、開發和程序的穩定。

在本軟件需求規格闡明書定版之后，客戶需求發生了較大變更，變更后日勺需

求規格闡明將不在本文檔中補充，而以新的版本文檔給出。

三.功能需求

［本章節重要提供詳細H勺功能性需求描述。走于采用構造化措施分析需求的

項目，應采用如下內容組織方式闡明。］

3.1系統功能關系圖

［以框圖的形式體現新系統的各功能組之間的功能關系圖，易于讀者理解。

詳細內容描述將在第4.3部分闡明。

應分層次展示整個系統的功能，先從系統一一＞子系統一一＞模塊逐層展示，

并闡明各子系統和模塊之間口勺功能關系。同步，應注意與外部系統的接口。］

示范：-----僅供參照，不具有任何實質性口勺內容。

顧客通過“系統登錄/注銷“子系統進入系統，從“顧客和權限管理“子系

統獲得對應日勺權限進行操作，顧客從事業務定制、數據采集、記錄分析、信息公

布/瀏覽、業務查詢、顧客和權限管理等其被授權時操作，“日志管理”子系統

進行登記。顧客從“協助”子系統獲得協助。

3.2系統功能清單

［以表格的形式列出本軟件系統所有的功能項清單，詳細格式如下：

功

能

優先

需求章節項功能項編號功能項名稱功能簡要描述

級

數

描述顧客怎樣登錄課程注冊..t-

LDAP-FI-101登錄

系統

容許學生在學期結束前查當

LDAP-FT-102查當作績單高

作績單

容許學生向課程目錄中注冊

4.3課程注

8LDAPFI103注冊課程課程，也包括更新、刪除課程高

冊管理

等

容許專家在下學期到來之前，

選擇講講課

LDAP-FT-104從課程目錄中選擇符合自己高

程

的課程

3.3<功能組1>

功能簡述

［簡要描述本子系統的重要功能，并以功能關系圖展示子系統。］

示范：-----僅供參照，不具有任何實質性H勺內容。

業務定制功能組將提供數據庫構造定義、數據采集接口規范自定義以及基礎

數據管理功能，具有靈活易用、功能強大的特點，是顧客創立數據庫資源并對采

集業務進行定制集成管理工具。

《功能組1》各個功能項之間的關系如下圖所示。

數據構造定制

基礎數據管理

業務查詢定義

數據庫模型導入

數據采集接口規范定制

0

注：提議對上圖各功能項進行簡要闡明。

《功能組1》與其他功能組之間歐I關系框圖如下圖所示:

業務定制

數據采集

記錄分析

信息公布/瀏覽

業務查詢

系統參數、數據接口規范、數據構造

系統參數、數據構造

系統參數、數據構造

系統參數

功能清單

［以表格日勺形式列出〈功能組1》中所有功能項，便于讀者檢索。］

示范：-----僅供參照，不具有任何實質性的內容。

功能項編號功能項名稱功能簡要描述優先級

LDAP-FI-101登錄描述顧客怎樣登錄課程注冊系統高

LDAP-FI-102查當作績單容許學生在學期結束前查當作績單高

容許學生向課程目錄中注冊課程，也包括

LDAP-FI-103注冊課程高

更新、刪除課程等

選擇講講課容許專家在下學期到來之前，從課程目錄

LDAP-FI-104高

程中選擇符合自己的課程

????????????中

＜登錄系統）

［詳細列出功能模塊或功能單元的詳細需求。這些是必須提交給顧客的軟件

功能，使顧客可以使用所提供日勺特性執行服務或者使用所指定的I使用實例執行任

務。描述產品怎樣響應可預知的出錯條件或者非法輸入或動作。必須唯一地標識

每個需求。］

在每個功能需求的描述中必須包括如下內容，如表中所列:

功能編號LDAP-FI-101功能名稱登錄系統

參與者有權限的顧客優先級高

簡要描述描述顧客怎樣成功登錄課程注冊系統

執行條件無

功能詳細描述：一一詳細描述該功能項所執行的操作及其響應

1.系統祈求該actor輸入他或她/、J顧客名和口令；

2.該actor輸入他或她日勺顧客名和口令；

3.系統驗證該actor輸入歐I顧客名和口令，并將該actor登錄信息記入系統

日志中。

異常響應描述：一一詳細描述該功能項所執行的操作出現的異常響應

1.無效顧客名和或口令

假如該actor輸入一種無效的顧客名和或口令，系統應顯示一種錯誤消息。

處理成果成功登錄進入課程注冊系統；或者登錄不成功，系統狀態不變。

特定規定顧客名不能重名，口令不能為空，5次登錄不成功鎖定該帳戶。

外部接口無

補充闡明顧客名提供列表選擇，顧客名不能超過15字符，口令不能少于6

字符

<功能需求2>

［構造同］

《功能需求N>

［構造同］

3.4<功能組2>

［構造同3.3］

3.5〈功能組N>

［構造同3.3］

四.非功能需求

4.1系統質量需求

［本條應描述協議中標混的或從更高層次規格闡明派生出來日勺對系統或子系統質

量方面日勺需求，例如包括有關系統日勺功能性（實現所有所需功能的能力）、性能（支

持歐J顧客數、操作響應速度、資源占用約束等）、可靠性（產生對歐I、一致成果

日勺能力）、可維護性（易于改正的能力）、可用性（需要時進行訪問和操作日勺能力）、

靈活性（易于適應需求變化日勺能力）、可移植性（易于修改以適應新環境日勺能力）、

可重用性（可被多種應用使用歐I能力）、可測試性（易于充足測試的能力）、易用性

（易于學習和使用歐I能力）以及其他屬性的I定量需求。需求應盡量詳細、量化和

可以驗證。］

性能

［論述不同樣H勺應用領域對產品性能的需求，并解釋它們的原理以協助開發

人員作出合理的設計選擇。確定互相合作的顧客數或者所支持的操作、響應時間

以及與實時系統H勺時間關系。你還可以在這里定義容量需求，例如存儲器和磁盤

空間的需求或者存儲在數據庫中表的最大行數。盡量詳細地確定性能需求。也許

需要針對每個功能需求或特性分別陳說其性能需求，而不是把它們都集中在一起

陳說。］

示范：------僅供參照，不具有任何實質性日勺內容。

系統容量：支持3萬顧客，支持GB級數據。數據庫表行數不超過100萬行,

數據庫最大容量不超過1000GB,磁盤空間至少需要40G以上.

響應指標：運行速度取決于硬件配置和應用數據規模，在推薦配置環境下：

登錄響應時間在5秒內，刷新欄目響應時間在5秒內，刷新條目分頁列表響應時

間5秒內，打開信息條目響應時間3秒內，刷新部門、人員列表響應時間5秒內。

可靠性

［論述客戶對系統的可靠性方面日勺規定。可靠性是軟件無端障運行一

段時間日勺概率。］

示范：------僅供參照，不具有任何實質性日勺內容。

本系統H勺最終顧客波及面廣，因此，整體系統運行規定穩定，有很強H勺防錯、

抗錯能力，保證數據報送工作正常進行。

可靠性指標：在持續運行狀況下，系統可靠性99.9999%。提供應用服務器

集群技術和組件技術支持高可靠性和伸縮性。

可維護性

［論述客戶對系統的可維護性方面的規定。可維護性表明了自軟件中

糾正一種缺陷或做一次更改H勺簡易程度。］

示范：------僅供參照，不具有任何實質性日勺內容。

系統從設計上盡量考慮使得***大多數記錄系統的建設都能使用本軟件搭建

而成，量少做二次開發或者不做二次開發，直接通過系統配置搭建系統，從功能

上具有通用性，易修改和擴展。軟件開發使用組件技術，保證了可維護性高。系

統具有開放性，是指記錄、分析內容日勺可修改、可擴展性。例如，通過一定日勺授

權，系統管理人員即可根據未來記錄制度變動歐I需要對記錄指標進行增、刪等修

改，無需通過軟件開發技術人員。

兼容性：系統應支持多種操作系統、數據庫系統和、WEB服務器系統。采用

JAVA、JNDI技術來保證很好的可移植性和可擴展性。

可用性

［論述客戶對系統H勺可用性方面的規定。可用性表明了軟件具有隨時隨地可

以訪問和操作的能力。］

示范：-----僅供參照，不具有任何實質性H勺內容。

本系統采用B/S和C/S混合模式，支持脫機方式，因此可以保證顧客隨時隨

地訪問系統。同步，系統采用容錯技術，具有數據恢復功能，可以保證顧客隨時

隨地操作系統。

靈活性

［論述客戶對系統口勺靈活性方面的規定。靈活性表明了軟件系統可以易于適

應需求H勺變化的能力。］

示范：-----僅供參照，不具有任何實質性日勺內容。

適應多種數據傳播方式，可以提供靈活配置以適應業務需求日勺變化，如可自

行定義業務規則、采集機構、采集指標、處理邏輯、反饋信息等等，通過多方面

的定制以適應某個詳細H勺業務系統。

可移植性

［論述客戶對系統日勺可移植性方面的規定。可移植性表明了軟件易于修改以

適應多種環境的能力。］

示范：------僅供參照，不具有任何實質性的內容。

本系統支持多種網絡環境，尤其是互聯網，可以實現跨平臺操作。

可重用性

［論述客戶對系統H勺可重用性方面日勺規定。可重用性表明了軟件可以被多種

應用使用的能力。］

示范：------僅供參照，不具有任何實質性H勺內容。

本系統提供組件式服務，部分公用組件可以被其他系統所使用。同步，在未

來后繼升級系統時，可以使得部分組件被重用。

可測試性

［論述客戶對系統口勺可測試性方面日勺規定。可測試性表明了軟件可以在有限

時間、人力資源程度內被充足測試的能力。］

示范：------僅供參照，不具有任何實質性日勺內容。

軟件系統具有良好H勺可測試性，可以在4個工作周、3個人力H勺狀況下順利

完畢所有測試項目。詳細測試項目如下：

代碼檢查：程序開發人員除了調試外，還應進行重點檢查程序代碼語法錯誤。

單元測試：對構成系統H勺每個組件進行數據構造測試和功能性測試，重點是

組件的功能和程序邏輯。

集成測試：將組件組裝成子系統后，應再次對組裝后的）子系統進行功能性測

試，重點是組件與組件之間的接口測試。

系統測試：通過測試后的各子系統組裝成系統后，還應組織對整個系統進行

全面的測試，包括功能、性能以及接口測試。

性能測試：測試系統的操作對應速度以及資源占用效率。

壓力測試：測試系統的可靠性和伸縮性，以驗證系統能承受多大FI勺負載。

鑒于本軟件系統的特殊性，測試重點應放在功能和性能上，其他方面可略作

測試。

易用性

［論述客戶對系統歐I易用性方面日勺規定，易用性包括人機界面的友好

性，新顧客或不常使用產品日勺顧客在學習使用產品時日勺簡易程度等。］

示范：-----僅供參照，不具有任何實質性日勺內容。

系統應操作簡樸、易學易用、符合原則瀏覽將操作風格，豐富的聯機協助，

人性化日勺操作界面，界面布局合理，節省操作時間提高生產效率。

4.2安全性需求

［詳盡陳說與系統安全性、完整性或與私人問題有關的需求，包不顧

客身份確認或授權需求，數據庫安全性需求，工作流程安全性需求等。這些問題

將會影響到產品H勺使用和產品所創立或使用日勺數據的保護。定義顧客身份確認或

授權需求。明確產品必須滿足的安全性或保密性方略。］

示范：-----僅供參照，不具有任何實質性H勺內容。

網絡安全：能經受來自互聯網的i般性惡意襲擊。如病毒（包括木馬）襲擊、

口令猜測襲擊、黑客入侵等。因此，必須配置較強的J網絡安全防備、響應能力，

為應用系統提供安全可靠的網絡記錄平臺。

數據庫安全：數據庫級備份和恢復。數據庫級顧客進行角色和權限授權。使

得在異常狀況發生時，系統可以得以迅速恢復，防止數據的丟失或將其影響降到

最低程度。同樣，要保證存儲過程中數據不被非法訪問和篡改。

應用系統的安全：通過對顧客的身份鑒別，并實行對應的訪問控制方略后，

使顧客只能完畢得到系統授權的數據訪問功能操作。顧客只有經授權后才可以更

新程序，防止因錯誤程序更新而影響系統的正常運行。

4.3環境需求

［以列表形式或分類方式描述有關系統或子系統必須運行的環境需求，例如

包括硬件平臺、操作系統和版本，尚有其他的軟件組件或與其共存日勺應用程序。］

示范：------僅供參照，不具有任何實質性口勺內容。

砧勝操作系統及應用服務鱉件及其版應用軟件及其部件

硬件其版本

IBMServer、DB2（7.2EE以上版

Apache>MSITS5.0等；本）

服務器IBMRS6000A1XWAS（4.0以上版本）、OracleEE（9iEE以

WebLogic（7.0以上版上版本）

本）等;

瀏覽客PTTIE5.0以上或Netscape

800/64M/2G旭演及以上

戶端同等版本以上

提議配置IE5.0以上或NetscapeMicroStrategy7i客

特殊客

2G/64M/2G的。20個及以同等版本以上戶端

戶端

上

4.4保密性和私密性需求

［本條應指明保密性和私密性日勺系統需求，包括：系統運行的保密性/私密性

環境、提供日勺保密性或私密性的類型和程度、系統必須經受的保密性/私密性的

風險、減少此類危險所需的安全措施、系統必須遵照H勺保密性/私密性政策、必

須提供的保密性/私密性審核、保密性/私密性必須遵照確實證/承認準則。］

示范：------僅供參照，不具有任何實質性H勺內容。

數據保密：網絡傳遞數據通過加密。需要保證數據在采集、傳播和處理過程

中不被偷窺、竊取、篡改。

4.5業務規則

［列舉出有關產品日勺所有操作規則，例如什么人在特定環境下可以進行何種

操作。這些自身不是功能需求，但它們可以暗示某些功能需求執行這些規則。假

如波及非常多的業務規則，需要單獨作為一章來描述。］

示范：------僅供參照，不具有任何實質性日勺內容。

在數據上載前，報數人員要核查數據；在數據上載后，系統應反饋數據上載

成功信息。

4.6其他需求

［論述未在需求規格闡明書模板中定義H勺需求，如人員培訓、包裝和交時、

數據遷移等方面H勺需求。假如不需要增長其他需求，可省略這一部分。

定義在軟件需求規格闡明的其他部分未出現白勺需求，例如國際化需求或法律

上日勺需求。你還可以增長有關操作、管理和維護部分來完善產品安裝、配置、啟

動和關閉、修復和容錯，以及登錄和監控操作等方面H勺需求。］

示范：-----僅供參照，不具有任何實質性口勺內容。

本系統應提供數據遷移日勺接口，需要將原有系統日勺數據順利遷移到本系統

中。

本系統規定在安裝過程的任何環節都應提供退出安裝的操作，并能自動刪除

已復制日勺文獻。

在系統運行過程中，計算機忽然斷電，系統應具有數據備份和數據恢復功能,

并提供數據修復和容錯功能。

五.接口需求

［運用本節來確定可以保證新產品與外部組件對時連接的需求。關聯圖體現

了高層抽象的外部聯接。需要把對接口數據和控制組件的詳細描述寫入數據字典

中。假如產品的不同樣部分有不同樣的外部接口，那么應把這些外部接口的詳細

需求并入到這一部分的實例中。］

5.1顧客界面

［描述系統的界面類型以及界面的特定規定，包括界面布局、界面風格、界

面規范等。指出界面采用的原則或格式，所提供的原則功能（如協助），快捷鍵

設置，錯誤顯示格式，初步的GUI產品構件，并描述所需要的顧客界面的軟件組

件。描述每個顧客界面的邏輯特性。而對于顧客界面口勺細節，例如特定對話框的

布局，應當寫入一種獨立的顧客界面規格闡明中，而不能寫入軟件需求規格'闡明

中。］

示范（以B/S為例）：------如下示范僅供參照，應根據項目實際特點靈活

掌握。

本軟件系統的顧客界面總體規定：界面友好，布局合理，操作以便，美觀大

方。

本軟件系統H勺界面應遵照總體規定，分別從如下幾種方面進行詳細規定（以

B/S為例）：

1.界面布局

系統頁面重要劃分為三個顯示區（如圖）頂端為標題欄區，顯示標題欄目信

息；左側為欄目區，顯示樹型欄目導航信息；右側為信息條目列表區（主顯示區），

內容包括信息條目分單元列表。

樹形導航區

信心條目顯示區

系統欄目導航區

Banner區

2.界面風格

系統界面整體風格為：上部為Banner和系統欄目導航，左側是各個功能有

關口勺目錄樹，右側是各個功能的詳細E句數據以及功能實現。

系統界面色調以白色為背景色，一般字體為常規五號宋體字，目前操作（焦

點）應以不同樣顏色或虛框形式與非目前操作以示區別。所有界面風格應遵照統

一的界面規范。

1）系統的查詢頁面風格，如下圖：

2）在列表中增長一項向風格，如下圖:

3）對某個詳細細節的修改，如下圖

3.界面規范

1）將系統中的查詢、系統管理等不同樣權限的頁面分開，使得系統的

構造盡量清晰。

2）信息列表保持行高的一致，使分頁規范；相似操作按鈕位置的放置

相對固定等。

3）對操作者的操作應予以對應