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

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

--定義問(wèn)題的根本要素是什么?

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

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

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

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

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

性能x

功能１

功能２

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

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

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

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

(a)編號(hào)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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