自考本科教材-NO2需求規(guī)約課件

軟件需求與軟件需求規(guī)約主講：段智敏考試大綱 本章要求了解軟件需求和需求規(guī)約概念的根底上，掌握需求和需求規(guī)約的根本特性、需求分類、需求發(fā)現(xiàn)根本技術(shù)，了解表達(dá)規(guī)約需求的根本手段、需求規(guī)約在軟件開發(fā)中的作用。識記需求定義及其根本特性需求規(guī)約定義及其根本特性領(lǐng)會功能需求和非功能需求及根本關(guān)系需求發(fā)現(xiàn)技術(shù)規(guī)約需求的三種語言需求在軟件開發(fā)中的作用

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

--定義問題的根本格式是什么?不管是自頂向下的軟件開發(fā)，還是自底向上的軟件開發(fā)，正確定義問題，是解決問題的前提。定義問題的根本要素定義問題的根本要素是“需求〞何謂需求? 一個需求是一個有關(guān)“要予構(gòu)造〞的陳述，用以描述待開發(fā)產(chǎn)品〔或項〕功能上的能力、性能參數(shù)或者其它性質(zhì)。Arequirementisastatementthathasbeenconstructedtodescribeanecessaryfunctionalcapability,performanceparameter,orotherpropertyoftheintendedproduct(oritem).需求分析 需求來源于用戶的一些“需要〞，這些“需要〞被分析、確認(rèn)后形成完整的文檔，該文檔詳細(xì)地說明了產(chǎn)品“必須或應(yīng)當(dāng)〞做什么〞。

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

必須在對話窗口的中間顯示錯誤警告，其中使用紅色的、14點加粗Arial字體。其中:功能-能顯示錯誤警告設(shè)計約束-在對話窗口的中間顯示,并使用紅色的、14點加粗Arial字體。需求分析 如果只有一些零碎的對話、資料或郵件，你就以為自己已經(jīng)掌握了需求，那是自欺欺人。例如：人們并不清楚究竟該做什么，但卻一直忙碌不停地開發(fā)。與客戶打交道的主要目的是：一是獲取需求，二是簽合同。不要把錢扔到水里。需求問題有時如同愛情問題，真是“當(dāng)局者迷，旁觀者清〞。開發(fā)人員在用戶處呆了兩三天就埋頭開發(fā)。用戶告訴開發(fā)人員我要開發(fā)一個XX系統(tǒng)，但是我很忙，你先開發(fā)一個讓我看看。

需求分析“樹上有十只鳥，開槍打死一只，還剩幾只？〞 某日，面試前來應(yīng)聘的高級程序員，他反問“是無聲手槍或別的無聲的槍嗎？〞 面試官答：“不是。〞“槍聲有多大？〞 面試官答：“80-100分貝。〞“在這個城市里打鳥犯不犯法？〞 面試官答：“不犯。〞“您確定那只鳥真的被打死啦？〞 面試官答：“確定。拜托，你告訴我還剩幾只就行了？〞“OK，樹上的鳥里有沒有聾子？〞 面試官答：“沒有。〞“有沒有關(guān)在籠子里的？〞 面試官答：“沒有。〞“有沒有殘疾的或餓的飛不動的鳥？〞 面試官答：“沒有。〞“算不算懷孕肚子里的小鳥？〞 面試官答：“不算。〞“打鳥的人眼有沒有花？保證是十只？〞 面試官答：“沒有花，就十只。〞 面試官滿腦門是汗，但他繼續(xù)問：“有沒有傻的不怕死的？〞 面試官答：“都怕死。〞“會不會一槍打死兩只？〞 面試官答：“不會。〞“所有的鳥都可以自由活動嗎？〞 面試官答：“完全可以。〞“如果您的答復(fù)沒有騙人，〞程序員滿懷信心的說，“打死的鳥要是掛在樹上沒掉下來，那么就剩一只，如果掉下來，就一只不剩。〞需求的根本性質(zhì)什么樣的陳述可以作為需求?IEEE標(biāo)準(zhǔn)830-1998要求單一需求必須具有5個根本性質(zhì):必要的(Necessary)。是要求的嗎？無歧義的(Unambiguous)。只能用一種方式解釋嗎？可測試的(testable)?？梢詫λM(jìn)行測試嗎？可跟蹤的(Traceable)。可以從一個開發(fā)階段到另一個階段對它進(jìn)行跟蹤嗎？可測量的(Measurable)?？梢詫λM(jìn)行測量嗎？注:確定一個需求是否滿足以上五個性質(zhì)是復(fù)雜耗時的過程。需求分類 需求主要分為功能需求和非功能需求兩大類。功能需求規(guī)約了系統(tǒng)或系統(tǒng)構(gòu)件必須執(zhí)行的功能，是需求的主體。非功能性需求是功能需求所派生的其他需求。功能需求性能需求外部接口需求設(shè)計約束需求質(zhì)量屬性需求功能需求功能需求規(guī)約了系統(tǒng)或系統(tǒng)構(gòu)件必須執(zhí)行的功能。例如：系統(tǒng)應(yīng)對所有已銷售的應(yīng)納稅商品計算銷售稅。系統(tǒng)應(yīng)提供一種方法，使系統(tǒng)用戶可根據(jù)本地利率調(diào)整銷售稅比例。系統(tǒng)應(yīng)能夠產(chǎn)生月銷售報表。除了對要執(zhí)行的功能給出一個陳述外，還應(yīng)規(guī)約如下內(nèi)容：關(guān)于該功能輸入的所有假定，或為了驗證該功能輸入，有關(guān)檢測的假定。功能內(nèi)的任一次序，這一次序是與外部有關(guān)的。對異常條件的響應(yīng)，包括所有內(nèi)外部所產(chǎn)生的錯誤。需求的時序或優(yōu)先程度。功能之間的互斥規(guī)那么。系統(tǒng)內(nèi)部狀態(tài)的假定。為了該功能的執(zhí)行，所需要的輸入和輸出次序。用于轉(zhuǎn)換或內(nèi)部計算所需要的公式。關(guān)于功能需求應(yīng)考慮以下問題：功能源功能共享的數(shù)據(jù)功能與外部界面的交互功能所使用的計算資源可見，功能需求是整個需求的主體，幾乎構(gòu)成了由交談和小組討論所得到的所有初始需求。這意味著:

沒有功能需求，就談不上其它需求，即性能需求、外部接口需求、設(shè)計約束和質(zhì)量屬性。

性能x

功能１

功能２

功能３．．．非功能需求性能需求 性能需求(Performancerequirement)規(guī)約了一個系統(tǒng)或系統(tǒng)構(gòu)件必須具有的性能特性。例如：

系統(tǒng)應(yīng)該在5分鐘內(nèi)計算出給定季度的總銷售稅。系統(tǒng)應(yīng)該在1分鐘內(nèi)從100000條記錄中檢索出一個銷售定單。該應(yīng)用必須支持100個Windows95/NT工作站的并行訪問。 性能需求隱含了一些滿足功能需求的設(shè)計方案，經(jīng)常對設(shè)計產(chǎn)生一些關(guān)鍵的影響。例如：排序，關(guān)于花費(fèi)時間的規(guī)約將確定哪種算法是可行的。 性能需求對功能需求而言，可以是一對多的。非功能需求外部接口需求 外部接口需求(Externalinterfacerequirement)規(guī)約了系統(tǒng)或系統(tǒng)構(gòu)件必須與之交互的硬件、軟件或數(shù)據(jù)庫元素。它也可能規(guī)約其格式、時間或其他因素。 例如：賬戶接收系統(tǒng)必須為月財務(wù)狀況系統(tǒng)提供更新信息，如在“財務(wù)系統(tǒng)描述〞第4修訂版中所描述的。引擎控制系統(tǒng)必須正確處理從飛行控制系統(tǒng)接收來的命令，符合接口控制文檔B2-10A4，修訂版C的1到8段的規(guī)定。

外部接口需求用戶接口(Userinterfaces)：規(guī)約了軟件產(chǎn)品和用戶之間接口的邏輯特性。即規(guī)約對給用戶所顯示的數(shù)據(jù)，對用戶所要求的數(shù)據(jù)以及用戶如何控制該用戶接口。硬件接口(Hardwareinterfaces)：如果軟件系統(tǒng)必須與硬件設(shè)備進(jìn)行交互，那么就應(yīng)說明所要求的支持和協(xié)議類型。軟件接口(Softwareinterfaces)：允許與其它軟件產(chǎn)品進(jìn)行交互，如，數(shù)據(jù)管理系統(tǒng)、操作系統(tǒng)或數(shù)學(xué)軟件包。通訊接口(Communicationsinterfaces)：規(guī)約待開發(fā)系統(tǒng)與通訊設(shè)施(如，局域網(wǎng))之間的交互。如果通訊需求包含了系統(tǒng)必須使用的網(wǎng)絡(luò)類型〔TCP/IP，WindowsNT,Novell〕，那么有關(guān)類型的信息就應(yīng)包含在SRS中。外部接口需求內(nèi)存約束(Memoryconstraints)：描述易失性存儲和永久性存儲的特性和限制，特別應(yīng)描述它們是否被用于與一個系統(tǒng)中其它處理的通訊。操作(Operation)：規(guī)約用戶如何使系統(tǒng)進(jìn)入正常和異常的運(yùn)行以及在系統(tǒng)正常和異常運(yùn)行下如何與系統(tǒng)進(jìn)行交互。應(yīng)該描述在用戶組織中的操作模式，包括交互模式和非交互模式；描述每一模式的數(shù)據(jù)處理支持功能；描述有關(guān)系統(tǒng)備份、恢復(fù)和升級功能方面的需求。地點需求(Siteadaptationrequirements)：描述系統(tǒng)安裝以及如何調(diào)整一個地點，以適應(yīng)新的系統(tǒng)。非功能需求設(shè)計約束 設(shè)計約束限制了系統(tǒng)或系統(tǒng)構(gòu)件的設(shè)計方案。就約束的本身而言，對其進(jìn)行權(quán)衡或調(diào)整是相當(dāng)困難的，甚至是不可能的。它們必須予以滿足。這一性質(zhì)，是與其它需求的最主要差異。為了滿足功能、性能和其它需求，許多設(shè)計約束將對軟件工程規(guī)劃、所需要的附加本錢和工作產(chǎn)生直接影響。例如：系統(tǒng)必須用C++或其他面向?qū)ο笳Z言編寫。系統(tǒng)用戶接口需要菜單。任取10秒，一個特定應(yīng)用所消耗的可用計算能力平均不超過50%。必須在對話窗口的中間顯示錯誤警告，其中使用紅色的、14點加粗Arial字體。設(shè)計約束針對產(chǎn)品開發(fā)，為確定其相關(guān)的設(shè)計約束，一般需要考慮以下10個方面：法規(guī)政策(Regulatorypolicies)硬件限制(Hardwarelimitations)，例如：處理速度、信號定序需求、存儲容量、通訊速度以及可用性等。與其它應(yīng)用接口(Interfacestootherapplications)，如，當(dāng)外部系統(tǒng)處于一個特定狀態(tài)時，禁止新系統(tǒng)某些操作。并發(fā)操作(Paralleloperations)，例如，可能要求從一些不同的源，并發(fā)地產(chǎn)生或接收數(shù)據(jù)。對此，必須清晰地給出有關(guān)時間的描述。審計功能(Auditfunctions)，規(guī)約軟件系統(tǒng)必須滿足的數(shù)據(jù)記錄準(zhǔn)那么或事務(wù)記錄準(zhǔn)那么。如，如果用戶觀察或修改數(shù)據(jù)，那么就可能要求該系統(tǒng)為了以后復(fù)審，記錄該系統(tǒng)的動作。設(shè)計約束控制功能(Controlfunctions)：可以對系統(tǒng)的管理能力進(jìn)行遠(yuǎn)程控制、可以對其他外部軟件以及內(nèi)部過程進(jìn)行控制。高級語言需求(Higherorderlanguagerequirements)握手協(xié)議(Signalhandshakeprotocols)：通常用于硬件和通訊控制軟件，特別當(dāng)給出特定的時間約束時，一般就要把“握手協(xié)議〞作為一項約束。應(yīng)用的關(guān)鍵程度(Criticalityoftheapplication)，許多生物醫(yī)學(xué)、航空、軍事或財務(wù)軟件屬于這一類。平安考慮(Safetyandsecurityconsiderations)。非功能需求質(zhì)量屬性 質(zhì)量屬性(Qualityattribute)規(guī)約了軟件產(chǎn)品必須具有的一個性質(zhì)是否到達(dá)質(zhì)量方面一個所期望的水平。例如：可靠性：軟件系統(tǒng)在指定環(huán)境中沒有失敗而正常運(yùn)行的概率。存活性：當(dāng)系統(tǒng)的某一局部系統(tǒng)不能運(yùn)行時，該軟件繼續(xù)運(yùn)行或支持關(guān)鍵功能的可能性?？删S護(hù)性：發(fā)現(xiàn)和改正一個軟件故障或?qū)μ囟ǖ姆秶M(jìn)行修改所要求的平均工作。用戶友好性：學(xué)習(xí)和使用一個軟件系統(tǒng)的容易程度。平安性：在一個預(yù)定的時間內(nèi)，使軟件系統(tǒng)平安的可能性?？梢浦残裕很浖到y(tǒng)運(yùn)行的平臺類型。需求發(fā)現(xiàn)技術(shù)假設(shè)現(xiàn)在獲得一個開發(fā)工程，如何獲取需求呢？自悟要求對業(yè)務(wù)熟悉，用于不方便對用戶調(diào)查交談對供需雙方都有要求，要防止需求越界觀察進(jìn)駐現(xiàn)場熟悉業(yè)務(wù)，客戶可能抵觸小組會復(fù)雜系統(tǒng)常用方法提煉有一定文檔或者現(xiàn)有一些資料，功能標(biāo)準(zhǔn)情景模擬，用例法……需求獲取方法是靈活的靈活組合屢次迭代需求規(guī)約概念 一個需求規(guī)約是一個軟件項/產(chǎn)品/系統(tǒng)所有需求陳述的正式文檔,是一個軟件產(chǎn)品／系統(tǒng)的概念模型。 Arequirementspecificationistheformaldocumentationallrequirementstatementsforanitem/product/system.根本性質(zhì) IEEE標(biāo)準(zhǔn)還規(guī)定SRS必須具有以下4個性質(zhì)：重要性和穩(wěn)定性程度(Rankedforimportanceandstability)。按需求的重要性和穩(wěn)定性，對需求進(jìn)行分級?？尚薷牡?Modifiable)。在不過多地影響其它需求的前提下，可以容易地修改一個單一需求.完整的(Complete)。沒有被遺漏的需求.一致的(Consistent)。不存在互斥的需求.注：大型復(fù)雜工程和一些有能力的組織，在開發(fā)需求文檔時，往往使用系統(tǒng)化的需求分析技術(shù)和工具。其中一些方法提供了系統(tǒng)化、自動化的功能，逐一驗證單一需求所具有的五個性質(zhì)，并進(jìn)一步驗證需求規(guī)約是否具有以上四個性質(zhì)。需求規(guī)約SRS評審標(biāo)準(zhǔn)無二義性 “無二義性〞是指每個需求只有唯一的含義。如果一個人說的話，不同的人可能有不同的理解，那么這句話就有二義性。如果需求存在二義性，將會導(dǎo)致誤解需求而開發(fā)出偏離需求的產(chǎn)品。 為了使需求無二義性，人們在寫?產(chǎn)品需求規(guī)格說明書?時措詞應(yīng)當(dāng)準(zhǔn)確，切勿模棱兩可。完備性 “完備〞〔Complete〕是指?產(chǎn)品需求規(guī)格說明書?中沒有遺漏一些必要的需求。 人們往往傾向于關(guān)注系統(tǒng)的特色功能，而無視了其它一些不起眼的但卻是必需的功能。 不完備的?產(chǎn)品需求規(guī)格說明書?將導(dǎo)致產(chǎn)生功能不完整的軟件，用戶在使用該軟件時可能無法完成預(yù)期的任務(wù)。SRS性質(zhì)一致性 “一致〞〔Consistent〕是指?產(chǎn)品需求規(guī)格說明書?中各個需求之間不會發(fā)生矛盾。矛盾常常潛伏在需求文檔的上下文中。必要性 ?產(chǎn)品需求規(guī)格說明書?中的各項需求對用戶而言應(yīng)當(dāng)都是必要的?？梢园选氨匾暠扔鳛椤把┲兴吞卡??！氨匾曂耙徊?，要么是“畫蛇添足〞要么是“錦上添花〞。 “畫蛇添足〞顯然是壞事，會導(dǎo)致開發(fā)人員多干一些吃力不討好的工作。所以要盡量剔除需求規(guī)格說明書中“畫蛇添足〞的那些需求。 “錦上添花〞是好事，可能會讓用戶獲得比期望更多的喜悅，但是眼前用戶不會為此多付錢。開發(fā)者應(yīng)當(dāng)集中精力先完成必要的需求，如果條件允許那么再做“錦上添花〞的需求。為了防止主次顛倒，應(yīng)當(dāng)在?產(chǎn)品需求規(guī)格說明書?中將那些“錦上添花〞的需求設(shè)置為較低的優(yōu)先級。SRS性質(zhì)可實現(xiàn) SRS中的各項需求對開發(fā)方而言應(yīng)當(dāng)都是可實現(xiàn)的〔Attainable〕。 “可實現(xiàn)〞意味著在技術(shù)上是可行的，并且滿足時間、費(fèi)用、質(zhì)量等約束。 營銷人員和用戶談生意時，為了能拿到“單子〞，他們往往對用戶提出的需求“來者不拒〞。吹牛皮雖然不犯法，但是SRS可是白紙黑字啊。經(jīng)過雙方確認(rèn)的SRS相當(dāng)于商業(yè)合同，如果開發(fā)方不能夠?qū)崿F(xiàn)SRS中的內(nèi)容，那就是違約，可能會被罰款的。 對于合同工程，如果開發(fā)方不能確信某些需求是否可實現(xiàn)，那么應(yīng)事先與用戶協(xié)商，達(dá)成一致的處理意見，防止將來發(fā)生商業(yè)糾紛。SRS性質(zhì)可驗證 SRS中的各項需求對用戶方而言應(yīng)當(dāng)都是可驗證的。如果需求不可驗證，那么用戶就無法驗收軟件，可能會發(fā)生商業(yè)糾紛。 例如，摩天大樓的一項需求是“抗十二級臺風(fēng)〞，需求看起來堂而皇之，但是如何驗證呢？當(dāng)摩天大樓完工后驗收時，用戶又不是巫師，他怎能造個十二級臺風(fēng)來試驗？如果雙方都認(rèn)可“采用計算機(jī)模擬十二級臺風(fēng)〞等效于實際測試，那么這項需求就是“可驗證〞的。確定優(yōu)先級 理論上講，軟件的所有需求都應(yīng)當(dāng)被實現(xiàn)。但是在現(xiàn)實之中，工程存在“進(jìn)度、費(fèi)用、人力資源〞等限制。在工程剛開始的時候，開發(fā)方和客戶比較樂觀，什么都要做，可是做著做著，常常會面臨“進(jìn)度延誤、費(fèi)用超支、人員缺乏〞等問題。 需要采取“取舍〞方法：先做優(yōu)先級高的需求，后做〔甚至放棄〕優(yōu)先級低的需求，這樣可以將風(fēng)險降到最低。 需求的優(yōu)先級其實就是需求“輕重緩急〞的分級表述，例如劃分為“高、中、低〞三級。一般地，由用戶和開發(fā)方共同確定需求的優(yōu)先級。需求規(guī)約格式實例××××××系統(tǒng)需求規(guī)格說明書1．引言1．1編寫目的說明編寫本需求分析規(guī)格說明書的目的。1．2背景說明(1)給出待開發(fā)的軟件產(chǎn)品的名稱；(2)說明本工程的提出者、開發(fā)者及用戶；(3)說明該軟件產(chǎn)品將做什么，如必要，說明不做什么。1．3術(shù)語定義列出本文檔中所用的專門術(shù)語的定義和外文首字母組詞的原詞組。1．4參考資料列出本文檔中所引用的全部資料，包括標(biāo)題、文檔編號、版本號、出版日期及出版單位等，必要時注明資料來源。需求規(guī)約格式實例2．概述2．1功能概述表達(dá)待開發(fā)軟件產(chǎn)品將完成的主要功能，并用方框圖來表示各功能及其相互關(guān)系。2．2約束表達(dá)對系統(tǒng)設(shè)計產(chǎn)生影響的限制條件，并對下一節(jié)中所述的某些特殊需求提供理由，如管理模式、硬件限制、與其他應(yīng)用的接口、平安保密的考慮等。需求規(guī)約格式實例3．?dāng)?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．2數(shù)據(jù)字典

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

3．2．2數(shù)據(jù)項說明以表格的形式說明每一數(shù)據(jù)項，格式如下表所示：需求規(guī)約格式實例4．接口

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

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

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

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

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

(3)版本號。需求規(guī)約格式實例5．性能需求5．1精度逐項說明對各項輸入數(shù)據(jù)和輸出數(shù)據(jù)到達(dá)的精度，包括傳輸中的精度要求。5．2時間特征定量地說明本軟件的時間特征，如響應(yīng)時間、更新處理時間、數(shù)據(jù)傳輸、轉(zhuǎn)換時間、計算時間等。5．3靈活性說明本軟件所具有的靈活性，即當(dāng)用戶需求(如對操作方式、運(yùn)行環(huán)境、結(jié)果精度、時間特性等的要求)有某些變化時，本軟件的適應(yīng)能力。需求規(guī)約格式實例6．屬性

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

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

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

6．4可移植性規(guī)定用戶程序、用戶接口的兼容方面的約束。需求規(guī)約格式實例7．其他需求7．1數(shù)據(jù)庫說明作為產(chǎn)品的一局部來開發(fā)的數(shù)據(jù)庫的需求。如：(1)使用的頻率； (2)訪問的能力；(3)數(shù)據(jù)元素和文件描述；(4)數(shù)據(jù)元素、記錄和文件關(guān)系；(5)靜態(tài)和動態(tài)組織；(6)數(shù)據(jù)保存要求。7．2操作列出用戶要求的正常及特殊的操作，如：(1)在用戶組織中各種方式的操作；(2)后援和恢復(fù)操作。7．3故障及處理列出可能發(fā)生的軟件和硬件故障，并指出這些故障對各項性能指標(biāo)所產(chǎn)生的影響及對故障的處理要求。書中給出的是一份需求規(guī)格說明書的樣例，在實際軟件工程中，每個開發(fā)組織可根據(jù)相關(guān)的標(biāo)準(zhǔn)和從事的開發(fā)領(lǐng)域，規(guī)定自己組織的軟件需求分析規(guī)格說明書的格式。1.引言1.1目的1.2文檔約定1.3預(yù)期的讀者和閱讀建議1.4產(chǎn)品的范圍1.5參考文獻(xiàn)2.綜合描述2.1產(chǎn)品的前景2.2產(chǎn)品的功能2.3用戶類和特征2.4運(yùn)行環(huán)境2.5設(shè)計和實現(xiàn)上的限制2.6假設(shè)和依賴3.外部接口需求3.1用戶界面3.2硬件接口3.3軟件接口3.4通信接口4.系統(tǒng)特性4.1說明和優(yōu)先級4.2鼓勵/響應(yīng)序列4.3功能需求5.其它非功能需求5.1性能需求5.2平安設(shè)施需求5.3平安性需求5.4軟件質(zhì)量屬性5.5業(yè)務(wù)規(guī)那么5.6用戶文檔6.其它需求附錄1：詞匯表附錄2：分析模型附錄3：待確定問題需求規(guī)約的三種語言非形式化的規(guī)約 即以一種自然語言來表達(dá)需求規(guī)約。 其中: 可以不局限于那種語言通常所約定的任何符號或特殊限制〔例如文法和詞法〕，但要為那些在一個特定語境中所使用的術(shù)語提供語義定義。 一般情況下，該語境與該術(shù)語通常使用的語境有區(qū)別。需求規(guī)約的三種語言半形式化的規(guī)約 即以半形式化符號體系(包括術(shù)語表、標(biāo)準(zhǔn)化的表達(dá)格式等)來表達(dá)需求規(guī)約。因此,半形式化規(guī)約的編制應(yīng)遵循一個標(biāo)準(zhǔn)的表示模板(一些約定)。 其中:術(shù)語說明確地標(biāo)識了一些詞，可以基于某一種自然語言。標(biāo)準(zhǔn)化的表達(dá)格式(例如例如數(shù)據(jù)流圖、狀態(tài)轉(zhuǎn)換圖、實體關(guān)系圖、數(shù)據(jù)結(jié)構(gòu)圖以及過程結(jié)構(gòu)圖等)標(biāo)識了一些元信息,支持以更清晰的方式系統(tǒng)化地來編制文檔。應(yīng)用中,不管是詞還是標(biāo)準(zhǔn)化的表達(dá)格式,在表達(dá)上均必須遵循一些約定,即應(yīng)以一種準(zhǔn)確和一致方式使用之。需求規(guī)約的三種語言形式化規(guī)約 即以一種基于良構(gòu)數(shù)學(xué)概念的符號體系來編制需求規(guī)約，一般往往伴有解釋性注釋的支持。 其中:以數(shù)學(xué)概念用于定義該符號體系的詞法和語義;定義了一組支持邏輯推理的證明規(guī)那么,并支持這一符號體系的定義和引用。需求規(guī)約的作用 需求在軟件開發(fā)中的作用概括為：作為軟件開發(fā)組織和用戶之間一份事實上的技術(shù)合同書；是產(chǎn)品功能及其環(huán)境的表達(dá)。對于工程的其余大多數(shù)工作，它是一個管理控制點。對于產(chǎn)品的設(shè)計，它是一個正式的、受控的起始點。創(chuàng)立產(chǎn)品驗收測試方案和用戶指南的根底，即基于需求分析規(guī)規(guī)約一般還會產(chǎn)生另外兩個文檔——初始測試方案和用戶系統(tǒng)操作描述。SRS不能實現(xiàn)的作用它不是一個設(shè)計文檔。它是一個“為了〞設(shè)計的文檔。它不是進(jìn)度或規(guī)劃文檔，不應(yīng)該包含更適宜包含在工作陳述〔SOW〕、軟件工程管理方案(SPMP)、軟件生存周期管理計劃(SLCMP)、軟件配置管理方案(SCMP)或軟件質(zhì)量保證方案(SQAP)等文檔中的信息。因此，在SRS中不應(yīng)給出:工程本錢；交付進(jìn)度；報告規(guī)程；軟件開發(fā)方法；質(zhì)量保證規(guī)程；配置管理規(guī)程；驗證和確認(rèn)規(guī)程；驗收規(guī)程；安裝規(guī)程。工程的需求及其需求規(guī)約關(guān)系 工程需求是客戶和開發(fā)者之間有關(guān)技術(shù)合同-產(chǎn)品/系統(tǒng)需求的理解，應(yīng)記錄在工作陳述SOW中或其他某一工程文檔(例如，工程管理方案)中。SRS應(yīng)只關(guān)注產(chǎn)品需求,即:產(chǎn)品/系統(tǒng)需求-“交付給客戶的產(chǎn)品是什么〞SOW應(yīng)關(guān)注工程工作與管理,即:工程需求-“開發(fā)組要做的是什么〞。習(xí)題——解釋術(shù)語軟件需求

軟件需求以一種技術(shù)形式，描述了一個產(chǎn)品/系統(tǒng)應(yīng)該具有的功能、性能和其它性質(zhì)。P23功能需求

功能需求規(guī)約了系統(tǒng)或系統(tǒng)構(gòu)件必須執(zhí)行的功能。P24非公能需求

非公能需求是性能、外部接口、設(shè)計約束和質(zhì)量屬性這4類需求的統(tǒng)稱。P23需求規(guī)約

需求規(guī)約是一個軟件項/產(chǎn)品/系統(tǒng)所有需求陳述的正式文檔，它表達(dá)了一個軟件產(chǎn)品/系統(tǒng)的概念模型。P28

習(xí)題——簡答題簡述需求與需求規(guī)約的根本性質(zhì)。 答：需求的根本性質(zhì)：必要的，該需求是用戶所要求的。無歧義的，該需求只能用一種方式解釋。可測的，該需求是可進(jìn)行測試的。可跟蹤的，該需求可從一個開發(fā)階段跟蹤到另一個階段?？蓽y量的，該需求是可測量的。P23 需求規(guī)約的根本性質(zhì)：重要性和穩(wěn)定性程度：按需求的重要性和穩(wěn)定性，對需求進(jìn)行分級?？尚薷牡?/p>