第3章軟件需求與軟件需求規(guī)約模板課件

三、軟件需求及系統(tǒng)/產(chǎn)品(需求)規(guī)約

--定義問題的基本要素是什么?

--定義問題的基本格式是什么?

不論是自頂向上的軟件開發(fā),還是自底向上的軟件開發(fā),正確定義問題,是解決問題的前提.三、軟件需求及系統(tǒng)/產(chǎn)品(需求)規(guī)約不論是自頂向上的軟件11定義問題的基本要素定義問題的基本要素是”需求”

1)何謂需求?

一個需求是一個有關“要予構造”的陳述，用以描述待開發(fā)產(chǎn)品（或項）功能上的能力、性能參數(shù)或者其它性質(zhì)。

Arequirementisastatementthathasbeenconstructedtodescribeanecessaryfunctionalcapability,performanceparameter,orotherpropertyoftheintendedproduct(oritem).

1定義問題的基本要素2例如：

系統(tǒng)必須有能力支持100個以上的并發(fā)用戶，每個用戶可以處理附錄A中操作任務的任選組合，平均響應時間應該小于1秒，最大響應時間應小于5秒。

其中:功能-可以處理附錄A中操作任務的任選組合性能-有能力支持100個以上的并發(fā)用戶平均響應時間應小于1秒，最大響應時間應小于5秒。

必須在對話窗口的中間顯示錯誤警告，其中使用紅色的、

14點加粗Arial字體。

其中:功能-能顯示錯誤警告設計約束-在對話窗口的中間顯示,并使用紅色的、14點加粗Arial字體。

32)什么樣的陳述可以作為需求

--需求的基本性質(zhì)

IEEE標準830-1998要求單一需求必須具有5個基本性質(zhì):

必要的(Necessary)。是要求的嗎？

無歧義的(Unambiguous)。只能用一種方式解釋嗎？

可測試的(testable)。可以對它進行測試嗎？

可跟蹤的(Traceable)?？梢詮囊粋€開發(fā)階段到另一個階段對它進行跟蹤嗎？

可測量的(Measurable)?？梢詫λM行測量嗎？注:確定一個需求是否滿足以上五個性質(zhì)是復雜耗時的過程.2)什么樣的陳述可以作為需求4

3)需求分類

功能；

性能；

外部接口；

設計約束；

質(zhì)量屬性。

功能需求功能需求規(guī)約了系統(tǒng)或系統(tǒng)構件必須執(zhí)行的功能。例如：

系統(tǒng)應對所有已銷售的應納稅商品計算銷售稅。系統(tǒng)應提供一種方法，使系統(tǒng)用戶可根據(jù)本地利率調(diào)整銷售稅比例.

系統(tǒng)應能夠產(chǎn)生月銷售報表。

5

除了對要執(zhí)行的功能給出一個陳述外，還應規(guī)約如下內(nèi)容：

關于該功能輸入的所有假定，或為了驗證該功能輸入，有關檢測的假定。

功能內(nèi)的任一次序，這一次序是與外部有關的。

對異常條件的響應，包括所有內(nèi)外部所產(chǎn)生的錯誤。

需求的時序或優(yōu)先程度。

功能之間的互斥規(guī)則。系統(tǒng)內(nèi)部狀態(tài)的假定。為了該功能的執(zhí)行，所需要的輸入和輸出次序。用于轉(zhuǎn)換或內(nèi)部計算所需要的公式。除了對要執(zhí)行的功能給出一個陳述外，還應規(guī)約如下內(nèi)容：6關于功能需求應考慮以下問題：（1）功能源。（2）功能共享的數(shù)據(jù)。（3）功能與外部界面的交互。（4）功能所使用的計算資源。可見,功能需求是整個需求的主體，幾乎構成了由交談和小組討論所得到的所有初始需求。這意味著:

沒有功能需求,就談不上其它需求,即性能需求、外部接口需求、設計約束和質(zhì)量屬性。關于功能需求應考慮以下問題：7性能需求性能需求(Performancerequirement)規(guī)約了一個系統(tǒng)或系統(tǒng)構件必須具有的性能特性。例如：

系統(tǒng)應該在5分鐘內(nèi)計算出給定季度的總銷售稅。系統(tǒng)應該在1分鐘內(nèi)從100000條記錄中檢索出一個銷售定單。該應用必須支持100個Windows95/NT工作站的并行訪問。

注1：性能需求隱含了一些滿足功能需求的設計方案，經(jīng)常對設計產(chǎn)生一些關鍵的影響。例如：排序，關于花費時間的規(guī)約將確定哪種算法是可行的。注2:性能需求對功能需求而言,可以是一對多的,例如:

性能x

功能１

功能２

功能３．．．性能需求性能x8外部接口需求外部接口需求(Externalinterfacerequirement)規(guī)約了系統(tǒng)或系統(tǒng)構件必須與之交互的硬件、軟件或數(shù)據(jù)庫元素。它也可能規(guī)約其格式、時間或其他因素。例如：賬戶接收系統(tǒng)必須為月財務狀況系統(tǒng)提供更新信息，如在“財務系統(tǒng)描述”第4修訂版中所描述的。引擎控制系統(tǒng)必須正確處理從飛行控制系統(tǒng)接收來的命令，符合接口控制文檔B2-10A4，修訂版C的1到8段的規(guī)定。

外部接口需求9--用戶接口(Userinterfaces)：規(guī)約了軟件產(chǎn)品和用戶之間接口的邏輯特性。即規(guī)約對給用戶所顯示的數(shù)據(jù)，對用戶所要求的數(shù)據(jù)以及用戶如何控制該用戶接口。

--硬件接口(Hardwareinterfaces)：如果軟件系統(tǒng)必須與硬件設備進行交互，那么就應說明所要求的支持和協(xié)議類型。

--軟件接口(Softwareinterfaces)：允許與其它軟件產(chǎn)品進行交互，如，數(shù)據(jù)管理系統(tǒng)、操作系統(tǒng)或數(shù)學軟件包。

--通訊接口(Communicationsinterfaces)：規(guī)約待開發(fā)系統(tǒng)與通訊設施(如，局域網(wǎng))之間的交互。如果通訊需求包含了系統(tǒng)必須使用的網(wǎng)絡類型（TCP/IP，WindowsNT,Novell），那么有關類型的信息就應包含在SRS中。--用戶接口(Userinterfaces)：規(guī)約了軟10--內(nèi)存約束(Memoryconstraints)：描述易失性存儲和永久性存儲的特性和限制，特別應描述它們是否被用于與一個系統(tǒng)中其它處理的通訊。--操作(Operation)：規(guī)約用戶如何使系統(tǒng)進入正常和異常的運行以及在系統(tǒng)正常和異常運行下如何與系統(tǒng)進行交互。應該描述在用戶組織中的操作模式，包括交互模式和非交互模式；描述每一模式的數(shù)據(jù)處理支持功能；描述有關系統(tǒng)備份、恢復和升級功能方面的需求。

--地點需求(Siteadaptationrequirements)：描述系統(tǒng)安裝以及如何調(diào)整一個地點，以適應新的系統(tǒng)。--內(nèi)存約束(Memoryconstraints)：描述11設計約束設計約束限制了系統(tǒng)或系統(tǒng)構件的設計方案。就約束的本身而言，對其進行權衡或調(diào)整是相當困難的，甚至是不可能的。它們必須予以滿足。這一性質(zhì)，是與其它需求的最主要差別。為了滿足功能、性能和其它需求，許多設計約束將對軟件項目規(guī)劃、所需要的附加成本和工作產(chǎn)生直接影響。例如：

系統(tǒng)必須用C++或其他面向?qū)ο笳Z言編寫。系統(tǒng)用戶接口需要菜單。任取10秒，一個特定應用所消耗的可用計算能力平均不超過50%。必須在對話窗口的中間顯示錯誤警告，其中使用紅色的、14點加粗

Arial字體。

設計約束12針對產(chǎn)品開發(fā)，為確定其相關的設計約束，一般需要考慮以下10個方面：

--法規(guī)政策(Regulatorypolicies)；

--硬件限制(Hardwarelimitations)，例如：處理速度、信號定序需求、存儲容量、通訊速度以及可用性等；

--與其它應用接口(Interfacestootherapplications)，如，當外部系統(tǒng)處于一個特定狀態(tài)時，禁止新系統(tǒng)某些操作

--并發(fā)操作(Paralleloperations)，例如，可能要求從/自一些不同的源，并發(fā)地產(chǎn)生或接收數(shù)據(jù)。對此，必須清晰地給出有關時間的描述。針對產(chǎn)品開發(fā)，為確定其相關的設計約束，一般需要考慮以下10個13--審計功能(Auditfunctions)，規(guī)約軟件系統(tǒng)必須滿足的數(shù)據(jù)記錄準則或事務記錄準則。如，如果用戶察看或修改數(shù)據(jù)，那么就可能要求該系統(tǒng)為了以后復審，記錄該系統(tǒng)的動作。--控制功能(Controlfunctions)：可以對系統(tǒng)的管理能力進行遠程控制、可以對其他外部軟件以及內(nèi)部過程進行控制。

--高級語言需求(Higherorderlanguagerequirements)：

--握手協(xié)議(Signalhandshakeprotocols)：通常用于硬件和通訊控制軟件，特別當給出特定的時間約束時，一般就要把“握手協(xié)議”作為一項約束。

--應用的關鍵程度(Criticalityoftheapplication)，許多生物醫(yī)學、航空、軍事或財務軟件屬于這一類。

--安全考慮(Safetyandsecurityconsiderations)。--審計功能(Auditfunc14質(zhì)量屬性質(zhì)量屬性(Qualityattribute)規(guī)約了軟件產(chǎn)品必須具有的一個性質(zhì)是否達到質(zhì)量方面一個所期望的水平。例如：屬性描述可靠性軟件系統(tǒng)在指定環(huán)境中沒有失敗而正常運行的概率。存活性當系統(tǒng)的某一部分系統(tǒng)不能運行時，該軟件繼續(xù)運行或支持關鍵功能的可能性。可維護性發(fā)現(xiàn)和改正一個軟件故障或?qū)μ囟ǖ姆秶M行修改所要求的平均工作。用戶友好性學習和使用一個軟件系統(tǒng)的容易程度。安全性在一個預定的時間內(nèi)，使軟件系統(tǒng)安全的可能性?？梢浦残攒浖到y(tǒng)運行的平臺類型。質(zhì)量屬性152定義需求的基本格式

--需求規(guī)約（ＳＲＳ）

1)概念一個需求規(guī)約是一個軟件項/產(chǎn)品/系統(tǒng)所有需求陳述的正式文檔,是一個軟件產(chǎn)品／系統(tǒng)的概念模型。

Arequirementspecificationistheformaldocumentationallrequirementstatementsforanitem/product/system.2)基本性質(zhì)

IEEE標準還規(guī)定SRS必須具有以下4個性質(zhì)：

重要性和穩(wěn)定性程度(Rankedforimportanceandstability)。

2定義需求的基本格式16可修改的(Modifiable)。在不過多地影響其它需求的前提下，可以容易地修改一個單一需求.完整的(Complete)。沒有被遺漏的需求.

一致的(Consistent)。不存在互斥的需求.

注：大型復雜項目和一些有能力的組織，在開發(fā)需求文檔時，往往使用系統(tǒng)化的需求分析技術和工具。其中一些方法提供了系統(tǒng)化、自動化的功能，逐一驗證單一需求所具有的五個性質(zhì)，并進一步驗證需求規(guī)約是否具有以上四個性質(zhì)。可修改的(Modifiable)。在不過多地影響其它需17××××××系統(tǒng)需求規(guī)格說明書1．引言1．1編寫目的說明編寫本需求分析規(guī)格說明書的目的。

1．2背景說明

(1)給出待開發(fā)的軟件產(chǎn)品的名稱；

(2)說明本項目的提出者、開發(fā)者及用戶；

(3)說明該軟件產(chǎn)品將做什么，如必要，說明不做什么。

1．3術語定義列出本文檔中所用的專門術語的定義和外文首字母組詞的原詞組。

1．4參考資料列出本文檔中所引用的全部資料，包括標題、文檔編號、版本號、出版日期及出版單位等，必要時注明資料來源。3)需求規(guī)約格式實例××××××系統(tǒng)需求規(guī)格說明書3182．概述

2．1功能概述敘述待開發(fā)軟件產(chǎn)品將完成的主要功能，并用方框圖來表示各功能及其相互關系。

2．2約束敘述對系統(tǒng)設計產(chǎn)生影響的限制條件，并對下一節(jié)中所述的某些特殊需求提供理由，如管理模式、硬件限制、與其他應用的接口、安全保密的考慮等。2．概述193．數(shù)據(jù)流圖與數(shù)據(jù)字典3．1數(shù)據(jù)流圖

3．1．1數(shù)據(jù)流圖l(1)畫出該數(shù)據(jù)流圖(2)加工說明

(a)編號

(b)加工名(c)輸入流(d)輸出流(e)加工邏輯(3)數(shù)據(jù)流說明

3．1．2數(shù)據(jù)流圖2……3．數(shù)據(jù)流圖與數(shù)據(jù)字典203．2數(shù)據(jù)字典

3．2．1文件說明說明文件的成分及組織方式。

3．2．2數(shù)據(jù)項說明以表格的形式說明每一數(shù)據(jù)項，格式如下表所示：3．2數(shù)據(jù)字典214．接口

4．1用戶接口說明人機界面的需求，包括：(1)屏幕格式；

(2)報表或菜單的頁面打印格式及內(nèi)容；(3)可用的功能鍵及鼠標。

4．2硬件接口說明該軟件產(chǎn)品與硬件之間各接l51的邏輯特點及運行該軟件的硬件設備特征。

4．3軟件接口說明該軟件產(chǎn)品與其他軟件之間接口，對于每個需要的軟件產(chǎn)品，應提供：(1)名稱；

(2)規(guī)格說明；

(3)版本號。

225．性能需求

5．1精度逐項說明對各項輸入數(shù)據(jù)和輸出數(shù)據(jù)達到的精度，包括傳輸中的精度要求。

5．2時間特征定量地說明本軟件的時間特征，如響應時間、更新處理時間、數(shù)據(jù)傳輸、轉(zhuǎn)換時間、計算時間等。

5．3靈活性說明本軟件所具有的靈活性，即當用戶需求(如對操作方式、運行環(huán)境、結果精度、時間特性等的要求)有某些變化時，本軟件的適應能力。5．性能需求236．屬性

6．1可使用性規(guī)定某些需求，如檢查點、恢復方法和重啟動性，以確保軟件可使用。

6.2保密性規(guī)定保護軟件的要素。

6．3可維護性規(guī)定確保軟件是可維護的需求，如模塊耦合矩陣。

6．4可移植性規(guī)定用戶程序、用戶接口的兼容方面的約束。6．屬性247．其他需求

7．1數(shù)據(jù)庫說明作為產(chǎn)品的一部分來開發(fā)的數(shù)據(jù)庫的需求。如：

(1)使用的頻率；(2)訪問的能力；

(3)數(shù)據(jù)元素和文件描述；(4)數(shù)據(jù)元素、記錄和文件關系；

(5)靜態(tài)和動態(tài)組織；(6)數(shù)據(jù)保留要求。

7．2操作列出用戶要求的正常及特殊的操作，如：

(1)在用戶組織中各種方式的操作；(2)后援和恢復操作。

7．3故障及處理列出可能發(fā)生的軟件和硬件故障，并指出這些故障對各項性能指標所產(chǎn)生的影響及對故障的處理要求。注意:以上給出的是一份需求規(guī)格說明書的樣例，在實際軟件工程中，每個開發(fā)組織可根據(jù)相關的標準和從事的開發(fā)領域，規(guī)定自己組織的軟件需求分析規(guī)格說明書的格式。

254)表達需求規(guī)約(規(guī)格說明書)的三種風格非形式化的規(guī)約即以一種自然語言來表達需求規(guī)約,如同使用一種自然語言寫了一篇文章.

其中:可以不局限于那種語言通常所約定的任何符號或特殊限制(例如文法和詞法）,但要為那些在一個特定語境中所使用的術語提供語義定義，一般情況下，該語境與通常使用該術語的語境是有區(qū)別的。

4)表達需求規(guī)約(規(guī)格說明書)的三種風格26半形式化的規(guī)約即以半形式化符號體系(包括術語表、標準化的表達格式等)來表達需求規(guī)約。因此,半形式化規(guī)約的編制應遵循一個標準的表示模板(一些約定)。其中:--術語表明確地標識了一些詞，可以基于某一種自然語言

--標準化的表達格式(例如例如數(shù)據(jù)流圖、狀態(tài)轉(zhuǎn)換圖、實體關系圖、數(shù)據(jù)結構圖以及過程結構圖等)標識了一些元信息,支持以更清晰的方式系統(tǒng)化地來編制文檔.--應用中,不論是詞還是標準化的表達格式,在表達上均必須遵循一些約定,即應以一種準確和一致方式使用之。半形式化的規(guī)約27形式化規(guī)約即以一種基于良構數(shù)學概念的符號體系來編制需求規(guī)約，一般往往伴有解釋性注釋的支持。其中:--以數(shù)學概念用于定義該符號體系的詞法和語義;--定義了一組支持邏輯推理的證明規(guī)則,并支持這一符號體系的定義和引用。形式化規(guī)約285)需求規(guī)約的作用其作用可概括為：第一也是最重要的，作為軟件開發(fā)組織和用戶之間一份事實上的技術合同書；是產(chǎn)品功能及其環(huán)境的體現(xiàn)。第二，對于項目的其余大多數(shù)工作，它是一個管理控制點。第三，對于產(chǎn)品的設計，它是一個正式的、受控的起始點。第四，是創(chuàng)建產(chǎn)品驗收測試計劃和用戶指南的基礎,即基于需求分析規(guī)規(guī)約一般還會產(chǎn)生另外兩個文檔——初始測試計劃和用戶系統(tǒng)操作描述。5)需求規(guī)約的作用29初始測試計劃主要內(nèi)容:對未來系統(tǒng)中的哪些功能和性能指標進行測試，以及達到何種要求。

作用:指導系統(tǒng)開發(fā)早期發(fā)現(xiàn)并修改一個錯誤,減少測試代價.注:在以后階段的軟件開發(fā)中，對這個測試計劃要不斷地修正和完善，并成為相應階段文檔的一部分。注:大量的統(tǒng)計數(shù)字表明，在系統(tǒng)開發(fā)早期發(fā)現(xiàn)并修改一個錯誤的代價往往很低，越到系統(tǒng)開發(fā)的后期，改正同樣錯誤所花費的代價越高。例如，假設在需求分析階段檢測并改正一個錯誤的代價為1個單位，那么到了軟件測試階段檢測并改正同樣的錯誤所花費的代價，一般需要10

個單位，而到軟件發(fā)布后的代價就可能高達100個單位。

30用戶系統(tǒng)操作描述主要內(nèi)容:從用戶使用系統(tǒng)的角度,簡要描述系統(tǒng)功能和性能,使用系統(tǒng)的主要步驟和方法，以及系統(tǒng)用戶的責任等。系統(tǒng)，作用:在軟件開發(fā)的早期，準備一份初步的用戶手冊可以使未來的系統(tǒng)用戶能夠從使用的角度檢查、審核目標系統(tǒng)，從而比較容易判斷這個系統(tǒng)是否符合他們的需要。

為了書寫這樣的文檔，也會迫使系統(tǒng)分析員從用戶的角度來考慮軟件系統(tǒng)。這樣不論是審查還是復審時,就更容易發(fā)現(xiàn)不一致和誤解的地方，這對保證軟件質(zhì)量和項目成功是很重要的。注:相當于一份初步的用戶手冊。用戶系統(tǒng)操作描述注:相當于一份初步的用戶手冊。31

SRS所不能實現(xiàn)的作用第一，它不是一個設計文檔。它是一個“為了”設計的文檔。第二，它不是進度或規(guī)劃文檔，不應該包含更適宜包含在工作陳述（SOW）、軟件項目管理計劃(SPMP)、軟件生存周期管理計劃(SLCMP)、軟件配置管理計劃(SCMP)或軟件質(zhì)量保證計劃(SQAP)等文檔中的信息。因此，在SRS中不應給出:項目成本；

交付進度；報告規(guī)程；軟件開發(fā)方法；質(zhì)量保證規(guī)程；配置管理規(guī)程；驗證和確認規(guī)程；驗收規(guī)程；安裝規(guī)程。SRS所不能實現(xiàn)的作用32關于項目的需求及其需求規(guī)約項目需求是客戶和開發(fā)者之間有關技術合同-產(chǎn)品/系統(tǒng)需求的理解，應記錄在工作陳述SOW中或其他某一項目文檔(例如，項目管理計劃)中。即SRS應只關注產(chǎn)品需求,即:

產(chǎn)品/系統(tǒng)需求-“交付給客戶的產(chǎn)品是什么”

SOW應關注項目工作與管理,即:

項目需求-“開發(fā)組要做的是什么”。關于項目的需求及其需求規(guī)約33作業(yè)P66246作業(yè)P6634三、軟件需求及系統(tǒng)/產(chǎn)品(需求)規(guī)約

--定義問題的基本要素是什么?

--定義問題的基本格式是什么?

不論是自頂向上的軟件開發(fā),還是自底向上的軟件開發(fā),正確定義問題,是解決問題的前提.三、軟件需求及系統(tǒng)/產(chǎn)品(需求)規(guī)約不論是自頂向上的軟件351定義問題的基本要素定義問題的基本要素是”需求”

1)何謂需求?

一個需求是一個有關“要予構造”的陳述，用以描述待開發(fā)產(chǎn)品（或項）功能上的能力、性能參數(shù)或者其它性質(zhì)。

Arequirementisastatementthathasbeenconstructedtodescribeanecessaryfunctionalcapability,performanceparameter,orotherpropertyoftheintendedproduct(oritem).

1定義問題的基本要素36例如：

系統(tǒng)必須有能力支持100個以上的并發(fā)用戶，每個用戶可以處理附錄A中操作任務的任選組合，平均響應時間應該小于1秒，最大響應時間應小于5秒。

其中:功能-可以處理附錄A中操作任務的任選組合性能-有能力支持100個以上的并發(fā)用戶平均響應時間應小于1秒，最大響應時間應小于5秒。

必須在對話窗口的中間顯示錯誤警告，其中使用紅色的、

14點加粗Arial字體。

其中:功能-能顯示錯誤警告設計約束-在對話窗口的中間顯示,并使用紅色的、14點加粗Arial字體。

372)什么樣的陳述可以作為需求

--需求的基本性質(zhì)

IEEE標準830-1998要求單一需求必須具有5個基本性質(zhì):

必要的(Necessary)。是要求的嗎？

無歧義的(Unambiguous)。只能用一種方式解釋嗎？

可測試的(testable)?？梢詫λM行測試嗎？

可跟蹤的(Traceable)。可以從一個開發(fā)階段到另一個階段對它進行跟蹤嗎？

可測量的(Measurable)。可以對它進行測量嗎？注:確定一個需求是否滿足以上五個性質(zhì)是復雜耗時的過程.2)什么樣的陳述可以作為需求38

3)需求分類

功能；

性能；

外部接口；

設計約束；

質(zhì)量屬性。

功能需求功能需求規(guī)約了系統(tǒng)或系統(tǒng)構件必須執(zhí)行的功能。例如：

系統(tǒng)應對所有已銷售的應納稅商品計算銷售稅。系統(tǒng)應提供一種方法，使系統(tǒng)用戶可根據(jù)本地利率調(diào)整銷售稅比例.

系統(tǒng)應能夠產(chǎn)生月銷售報表。

39

除了對要執(zhí)行的功能給出一個陳述外，還應規(guī)約如下內(nèi)容：

關于該功能輸入的所有假定，或為了驗證該功能輸入，有關檢測的假定。

功能內(nèi)的任一次序，這一次序是與外部有關的。

對異常條件的響應，包括所有內(nèi)外部所產(chǎn)生的錯誤。

需求的時序或優(yōu)先程度。

功能之間的互斥規(guī)則。系統(tǒng)內(nèi)部狀態(tài)的假定。為了該功能的執(zhí)行，所需要的輸入和輸出次序。用于轉(zhuǎn)換或內(nèi)部計算所需要的公式。除了對要執(zhí)行的功能給出一個陳述外，還應規(guī)約如下內(nèi)容：40關于功能需求應考慮以下問題：（1）功能源。（2）功能共享的數(shù)據(jù)。（3）功能與外部界面的交互。（4）功能所使用的計算資源。可見,功能需求是整個需求的主體，幾乎構成了由交談和小組討論所得到的所有初始需求。這意味著:

沒有功能需求,就談不上其它需求,即性能需求、外部接口需求、設計約束和質(zhì)量屬性。關于功能需求應考慮以下問題：41性能需求性能需求(Performancerequirement)規(guī)約了一個系統(tǒng)或系統(tǒng)構件必須具有的性能特性。例如：

系統(tǒng)應該在5分鐘內(nèi)計算出給定季度的總銷售稅。系統(tǒng)應該在1分鐘內(nèi)從100000條記錄中檢索出一個銷售定單。該應用必須支持100個Windows95/NT工作站的并行訪問。

注1：性能需求隱含了一些滿足功能需求的設計方案，經(jīng)常對設計產(chǎn)生一些關鍵的影響。例如：排序，關于花費時間的規(guī)約將確定哪種算法是可行的。注2:性能需求對功能需求而言,可以是一對多的,例如:

性能x

功能１

功能２

功能３．．．性能需求性能x42外部接口需求外部接口需求(Externalinterfacerequirement)規(guī)約了系統(tǒng)或系統(tǒng)構件必須與之交互的硬件、軟件或數(shù)據(jù)庫元素。它也可能規(guī)約其格式、時間或其他因素。例如：賬戶接收系統(tǒng)必須為月財務狀況系統(tǒng)提供更新信息，如在“財務系統(tǒng)描述”第4修訂版中所描述的。引擎控制系統(tǒng)必須正確處理從飛行控制系統(tǒng)接收來的命令，符合接口控制文檔B2-10A4，修訂版C的1到8段的規(guī)定。

外部接口需求43--用戶接口(Userinterfaces)：規(guī)約了軟件產(chǎn)品和用戶之間接口的邏輯特性。即規(guī)約對給用戶所顯示的數(shù)據(jù)，對用戶所要求的數(shù)據(jù)以及用戶如何控制該用戶接口。

--硬件接口(Hardwareinterfaces)：如果軟件系統(tǒng)必須與硬件設備進行交互，那么就應說明所要求的支持和協(xié)議類型。

--軟件接口(Softwareinterfaces)：允許與其它軟件產(chǎn)品進行交互，如，數(shù)據(jù)管理系統(tǒng)、操作系統(tǒng)或數(shù)學軟件包。

--通訊接口(Communicationsinterfaces)：規(guī)約待開發(fā)系統(tǒng)與通訊設施(如，局域網(wǎng))之間的交互。如果通訊需求包含了系統(tǒng)必須使用的網(wǎng)絡類型（TCP/IP，WindowsNT,Novell），那么有關類型的信息就應包含在SRS中。--用戶接口(Userinterfaces)：規(guī)約了軟44--內(nèi)存約束(Memoryconstraints)：描述易失性存儲和永久性存儲的特性和限制，特別應描述它們是否被用于與一個系統(tǒng)中其它處理的通訊。--操作(Operation)：規(guī)約用戶如何使系統(tǒng)進入正常和異常的運行以及在系統(tǒng)正常和異常運行下如何與系統(tǒng)進行交互。應該描述在用戶組織中的操作模式，包括交互模式和非交互模式；描述每一模式的數(shù)據(jù)處理支持功能；描述有關系統(tǒng)備份、恢復和升級功能方面的需求。

--地點需求(Siteadaptationrequirements)：描述系統(tǒng)安裝以及如何調(diào)整一個地點，以適應新的系統(tǒng)。--內(nèi)存約束(Memoryconstraints)：描述45設計約束設計約束限制了系統(tǒng)或系統(tǒng)構件的設計方案。就約束的本身而言，對其進行權衡或調(diào)整是相當困難的，甚至是不可能的。它們必須予以滿足。這一性質(zhì)，是與其它需求的最主要差別。為了滿足功能、性能和其它需求，許多設計約束將對軟件項目規(guī)劃、所需要的附加成本和工作產(chǎn)生直接影響。例如：

系統(tǒng)必須用C++或其他面向?qū)ο笳Z言編寫。系統(tǒng)用戶接口需要菜單。任取10秒，一個特定應用所消耗的可用計算能力平均不超過50%。必須在對話窗口的中間顯示錯誤警告，其中使用紅色的、14點加粗

Arial字體。

設計約束46針對產(chǎn)品開發(fā)，為確定其相關的設計約束，一般需要考慮以下10個方面：

--法規(guī)政策(Regulatorypolicies)；

--硬件限制(Hardwarelimitations)，例如：處理速度、信號定序需求、存儲容量、通訊速度以及可用性等；

--與其它應用接口(Interfacestootherapplications)，如，當外部系統(tǒng)處于一個特定狀態(tài)時，禁止新系統(tǒng)某些操作

--并發(fā)操作(Paralleloperations)，例如，可能要求從/自一些不同的源，并發(fā)地產(chǎn)生或接收數(shù)據(jù)。對此，必須清晰地給出有關時間的描述。針對產(chǎn)品開發(fā)，為確定其相關的設計約束，一般需要考慮以下10個47--審計功能(Auditfunctions)，規(guī)約軟件系統(tǒng)必須滿足的數(shù)據(jù)記錄準則或事務記錄準則。如，如果用戶察看或修改數(shù)據(jù)，那么就可能要求該系統(tǒng)為了以后復審，記錄該系統(tǒng)的動作。--控制功能(Controlfunctions)：可以對系統(tǒng)的管理能力進行遠程控制、可以對其他外部軟件以及內(nèi)部過程進行控制。

--高級語言需求(Higherorderlanguagerequirements)：

--握手協(xié)議(Signalhandshakeprotocols)：通常用于硬件和通訊控制軟件，特別當給出特定的時間約束時，一般就要把“握手協(xié)議”作為一項約束。

--應用的關鍵程度(Criticalityoftheapplication)，許多生物醫(yī)學、航空、軍事或財務軟件屬于這一類。

--安全考慮(Safetyandsecurityconsiderations)。--審計功能(Auditfunc48質(zhì)量屬性質(zhì)量屬性(Qualityattribute)規(guī)約了軟件產(chǎn)品必須具有的一個性質(zhì)是否達到質(zhì)量方面一個所期望的水平。例如：屬性描述可靠性軟件系統(tǒng)在指定環(huán)境中沒有失敗而正常運行的概率。存活性當系統(tǒng)的某一部分系統(tǒng)不能運行時，該軟件繼續(xù)運行或支持關鍵功能的可能性。可維護性發(fā)現(xiàn)和改正一個軟件故障或?qū)μ囟ǖ姆秶M行修改所要求的平均工作。用戶友好性學習和使用一個軟件系統(tǒng)的容易程度。安全性在一個預定的時間內(nèi)，使軟件系統(tǒng)安全的可能性?？梢浦残攒浖到y(tǒng)運行的平臺類型。質(zhì)量屬性492定義需求的基本格式

--需求規(guī)約（ＳＲＳ）

1)概念一個需求規(guī)約是一個軟件項/產(chǎn)品/系統(tǒng)所有需求陳述的正式文檔,是一個軟件產(chǎn)品／系統(tǒng)的概念模型。

Arequirementspecificationistheformaldocumentationallrequirementstatementsforanitem/product/system.2)基本性質(zhì)

IEEE標準還規(guī)定SRS必須具有以下4個性質(zhì)：

重要性和穩(wěn)定性程度(Rankedforimportanceandstability)。

2定義需求的基本格式50可修改的(Modifiable)。在不過多地影響其它需求的前提下，可以容易地修改一個單一需求.完整的(Complete)。沒有被遺漏的需求.

一致的(Consistent)。不存在互斥的需求.

注：大型復雜項目和一些有能力的組織，在開發(fā)需求文檔時，往往使用系統(tǒng)化的需求分析技術和工具。其中一些方法提供了系統(tǒng)化、自動化的功能，逐一驗證單一需求所具有的五個性質(zhì)，并進一步驗證需求規(guī)約是否具有以上四個性質(zhì)?？尚薷牡?Modifiable)。在不過多地影響其它需51××××××系統(tǒng)需求規(guī)格說明書1．引言1．1編寫目的說明編寫本需求分析規(guī)格說明書的目的。

1．2背景說明

(1)給出待開發(fā)的軟件產(chǎn)品的名稱；

(2)說明本項目的提出者、開發(fā)者及用戶；

(3)說明該軟件產(chǎn)品將做什么，如必要，說明不做什么。

1．3術語定義列出本文檔中所用的專門術語的定義和外文首字母組詞的原詞組。

1．4參考資料列出本文檔中所引用的全部資料，包括標題、文檔編號、版本號、出版日期及出版單位等，必要時注明資料來源。3)需求規(guī)約格式實例××××××系統(tǒng)需求規(guī)格說明書3522．概述

2．1功能概述敘述待開發(fā)軟件產(chǎn)品將完成的主要功能，并用方框圖來表示各功能及其相互關系。

2．2約束敘述對系統(tǒng)設計產(chǎn)生影響的限制條件，并對下一節(jié)中所述的某些特殊需求提供理由，如管理模式、硬件限制、與其他應用的接口、安全保密的考慮等。2．概述533．數(shù)據(jù)流圖與數(shù)據(jù)字典3．1數(shù)據(jù)流圖

3．1．1數(shù)據(jù)流圖l(1)畫出該數(shù)據(jù)流圖(2)加工說明

(a)編號

(b)加工名(c)輸入流(d)輸出流(e)加工邏輯(3)數(shù)據(jù)流說明

3．1．2數(shù)據(jù)流圖2……3．數(shù)據(jù)流圖與數(shù)據(jù)字典543．2數(shù)據(jù)字典

3．2．1文件說明說明文件的成分及組織方式。

3．2．2數(shù)據(jù)項說明以表格的形式說明每一數(shù)據(jù)項，格式如下表所示：3．2數(shù)據(jù)字典554．接口

4．1用戶接口說明人機界面的需求，包括：(1)屏幕格式；

(2)報表或菜單的頁面打印格式及內(nèi)容；(3)可用的功能鍵及鼠標。

4．2硬件接口說明該軟件產(chǎn)品與硬件之間各接l51的邏輯特點及運行該軟件的硬件設備特征。

4．3軟件接口說明該軟件產(chǎn)品與其他軟件之間接口，對于每個需要的軟件產(chǎn)品，應提供：(1)名稱；

(2)規(guī)格說明；

(3)版本號。

565．性能需求

5．1精度逐項說明對各項輸入數(shù)據(jù)和輸出數(shù)據(jù)達到的精度，包括傳輸中的精度要求。

5．2時間特征定量地說明本軟件的時間特征，如響應時間、更新處理時間、數(shù)據(jù)傳輸、轉(zhuǎn)換時間、計算時間等。

5．3靈活性說明本軟件所具有的靈活性，即當用戶需求(如對操作方式、運行環(huán)境、結果精度、時間特性等的要求)有某些變化時，本軟件的適應能力。5．性能需求576．屬性

6．1可使用性規(guī)定某些需求，如檢查點、恢復方法和重啟動性，以確保軟件可使用。

6.2保密性規(guī)定保護軟件的要素。

6．3可維護性規(guī)定確保軟件是可維護的需求，如模塊耦合矩陣。

6．4可移植性規(guī)定用戶程序、用戶接口的兼容方面的約束。6．屬性587．其他需求

7．1數(shù)據(jù)庫說明作為產(chǎn)品的一部分來開發(fā)的數(shù)據(jù)庫的需求。如：

(1)使用的頻率；(2)訪問的能力；

(3)數(shù)據(jù)元素和文件描述；(4)數(shù)據(jù)元素、記錄和文件關系；

(5)靜態(tài)和動態(tài)組織；(6)數(shù)據(jù)保留要求。

7．2操作列出用戶要求的正常及特殊的操作，如：

(1)在用戶組織中各種方式的操作；(2)后援和恢復操作。

7．3故障及處理列出可能發(fā)生的軟件和硬件故障，并指出這些故障對各項性能指標所產(chǎn)生的影響及對故障的處理要求。注意:以上給出的是一份需求規(guī)格說明書的樣例，在實際軟件工程中，每個開發(fā)組織可根據(jù)相關的標準和從事的開發(fā)領域，規(guī)定自己組織的軟件需求分析規(guī)格說明書的格式。

594)表達需求規(guī)約(規(guī)格說明書)的三種風格非形式化的規(guī)約即以一種自然語言來表達需求規(guī)約,如同使用一種自然語言寫了一篇文章.

其中:可以不局限于那種語言通常所約定的任何符號或特殊限制(例如文法和詞法）,但要為那些在一個特定語境中所使用的術語提供語義定義，一般情況下，該語境與通常使用該術語的語境是有區(qū)別的。

4)表達需求規(guī)約(規(guī)格說明書)的三種風格60