SE04需求分析基礎(chǔ)

1、軟件工程Software Engineering1第4章 需求分析基礎(chǔ)分析的任務(wù)、過程、原則初步需求獲取技術(shù)需求建模問題抽象、問題分解與多視點(diǎn)分析支持需求分析的快速原型技術(shù)需求規(guī)格說明與評(píng)審軟件需求：用戶對(duì)目標(biāo)軟件系統(tǒng)在功能、行為、 性能、設(shè)計(jì)約束等方面的期望2第4章 需求分析基礎(chǔ)IEEE軟件工程標(biāo)準(zhǔn)詞匯表(1997年)中定義需求為： (1)用戶解決問題或達(dá)到目標(biāo)所需的條件或權(quán)能(Capability)。 (2)系統(tǒng)或系統(tǒng)部件要滿足合同、標(biāo)準(zhǔn)、規(guī)范或其它正式規(guī)定文檔所需具有的條件或權(quán)能。 (3)一種反映上面(1)或(2)所描述的條件或權(quán)能的文檔說明。準(zhǔn)確、完整和規(guī)范化的軟件需求是軟件開發(fā)成功的

2、關(guān)鍵。軟件項(xiàng)目中40%-60%的問題都是在需求階段埋下的禍根主要障礙：用戶對(duì)應(yīng)用問題的理解、描述以及他們對(duì)目標(biāo)軟件的需求往往具有片面性、模糊性，甚至不一致性3第4章 需求分析基礎(chǔ)不適當(dāng)?shù)男枨筮^程所引起的一些風(fēng)險(xiǎn)：調(diào)研的用戶不多，導(dǎo)致產(chǎn)品無法被接受用戶需求的增加帶來過度的耗費(fèi)和降低產(chǎn)品的質(zhì)量模棱兩可的需求說明可能導(dǎo)致時(shí)間的浪費(fèi)和返工用戶增加一些不必要的特性和開發(fā)人員畫蛇添足(gold-plating)過分簡(jiǎn)略的需求說明以致遺漏某些關(guān)鍵需求忽略某類用戶的需求將導(dǎo)致眾多客戶的不滿不完善的需求說明使得項(xiàng)目計(jì)劃和跟蹤無法準(zhǔn)確進(jìn)行44.1 需求分析的任務(wù)與原則軟件需求分析：對(duì)應(yīng)用問題及環(huán)境的理解和分析，為

3、問題涉及的信息、功能及系統(tǒng)行為建立模型。將用戶需求精確化、完全化，最終形成需求規(guī)格說明書分析目標(biāo)：準(zhǔn)確理解用戶的要求，進(jìn)行細(xì)致的調(diào)查分析，將用戶的非形式的要求轉(zhuǎn)化為完整的需求定義，再將需求定義轉(zhuǎn)換為相應(yīng)的形式化的規(guī)格說明 深入描述軟件的功能和性能，確定軟件的設(shè)計(jì)約束、軟件同其他系統(tǒng)元素的接口細(xì)節(jié)，定義軟件的其他有效性需求 一方面必須全部理解用戶的各項(xiàng)要求但又不能全盤接受；另一方面要準(zhǔn)確表達(dá)被接受的要求。只有經(jīng)過確切描述的軟件需求才能成為軟件設(shè)計(jì)的基礎(chǔ)5需求分析的任務(wù)需求分析的任務(wù)：就是借助于當(dāng)前系統(tǒng)的邏輯模型導(dǎo)出目標(biāo)系統(tǒng)的邏輯模型，解決目標(biāo)系統(tǒng)的 “做什么” 的問題。目標(biāo)系統(tǒng)當(dāng)前系統(tǒng)物理模型邏

4、輯模型模型化抽象化物理模型邏輯模型具體化實(shí)例化理解需求表達(dá)需求導(dǎo)出怎么做做什么6需求分析的任務(wù) 需求分析階段要解決的問題，是讓用戶和開發(fā)者共同明確將要開發(fā)的是一個(gè)什么樣的系統(tǒng)。主要兩個(gè)任務(wù)（1）通過對(duì)問題及其環(huán)境的理解、分析和綜合，建立分析模型(Analysis Model)。（2）在完全地弄清用戶對(duì)軟件系統(tǒng)的確切要求的基礎(chǔ)上，用“軟件需求規(guī)格說明書”（Software Requirement Specification，SRS）把用戶的需求表達(dá)出來。7需求分析的任務(wù)建立分析模型 由于用戶群體的各個(gè)用戶往往會(huì)從不同的角度闡述他們對(duì)原始問題的理解和對(duì)目標(biāo)軟件的需求，分析模型是描述軟件需求的一組模

5、型。一方面用于精確地記錄用戶對(duì)原始問題和目標(biāo)軟件的描述另一方面，它也將幫助分析人員發(fā)現(xiàn)用戶需求中的不一致性，排除不合理的部分，挖掘潛在的用戶需求這種模型往往包含問題及其環(huán)境所涉及的信息流、處理功能、用戶界面、行為模型及設(shè)計(jì)約束等。是形成需求說明、進(jìn)行軟件設(shè)計(jì)與實(shí)現(xiàn)的基礎(chǔ)8需求分析的任務(wù)編寫需求說明應(yīng)該具有準(zhǔn)確性和一致性。它是連接計(jì)劃時(shí)期和開發(fā)時(shí)期的橋梁，也是軟件設(shè)計(jì)的依據(jù)。應(yīng)該具有清晰性和無二義性。它是溝通用戶和系統(tǒng)分析員思想的媒介，雙方要用它來表達(dá)對(duì)于需要計(jì)算機(jī)解決的問題的共同理解。應(yīng)該直觀、易讀和易于修改。應(yīng)盡量采用標(biāo)準(zhǔn)的圖形、表格和簡(jiǎn)單的符號(hào)來表示，使不熟悉計(jì)算機(jī)的用戶也能一目了然。9需

6、求分析過程問題識(shí)別分析與綜合編寫文檔分析評(píng)審可行性研究需求導(dǎo)出和分析需求描述需求有效性驗(yàn)證可行性報(bào)告系統(tǒng)模型用戶需求和系統(tǒng)需求需求文擋10問題識(shí)別從分析當(dāng)前系統(tǒng)包含的數(shù)據(jù)開始例如當(dāng)前系統(tǒng)使用的賬冊(cè)、卡片和報(bào)表，手工處理當(dāng)前信息的方法與不足，用戶需要改進(jìn)的主要問題及其迫切性等對(duì)軟件功能的需求和界面的需求為了收集到全面完整的信息，需將客戶按使用頻率、使用特性、優(yōu)先及等方面進(jìn)行分類，每類選擇若干用戶代表，從代表那里收集他們希望的軟件系統(tǒng)功能、用戶與系統(tǒng)間的交互和對(duì)話方式等需求對(duì)質(zhì)量的要求，包括性能、有效性、可靠性、可用性和設(shè)計(jì)約束等，提高用戶對(duì)軟件的滿足程度如果客戶的要求和已有產(chǎn)品很相似，則需要考慮

7、可否復(fù)用一些已有的軟件組件11分析與綜合（需求提煉：分析建模） 分析人員應(yīng)了解問題及環(huán)境，應(yīng)與用戶合作清除用戶需求的模糊性、岐義性和不一致性，并對(duì)相互沖突的需求進(jìn)行折衷分析人員與用戶合作對(duì)問題進(jìn)行分析、綜合，結(jié)合軟件的特點(diǎn)及開發(fā)經(jīng)驗(yàn)，尋求軟件需求為用戶的問題及準(zhǔn)備開發(fā)的軟件建立模型，從不同的角度、不同的抽象級(jí)別精確地說明對(duì)問題的理解、對(duì)目標(biāo)軟件的需求 圖形化的分析模型是說明軟件需求極好的手段，常用的模型包括數(shù)據(jù)流圖、實(shí)體關(guān)系圖、控制流圖、狀態(tài)轉(zhuǎn)換圖、用例圖、類對(duì)象關(guān)系及其行為圖文圖等。有些軟件還需要繪制系統(tǒng)關(guān)聯(lián)圖、創(chuàng)建用戶接口原型、確定需求優(yōu)先級(jí)別12編寫SRS（需求描述） 以需求模型為基礎(chǔ)，

8、考慮到軟件問題的可解性，生成需求規(guī)格說明和初步的用戶手冊(cè)。需求規(guī)格說明包含對(duì)目標(biāo)軟件系統(tǒng)的外部行為的完整描述、需求驗(yàn)證標(biāo)準(zhǔn)以及用戶在性能、質(zhì)量、可維護(hù)性等方面的要求。初步用戶手冊(cè)包括用戶界面描述以及有關(guān)目標(biāo)軟件使用方法的初步構(gòu)想。文檔 遵循規(guī)范，內(nèi)容全面、結(jié)構(gòu)清晰、措辭準(zhǔn)確、格式嚴(yán)謹(jǐn)將初步用戶手冊(cè)作為分析文檔,有助于分析人員從用戶角度考慮軟件需求，并鼓勵(lì)用戶盡早參予軟件開發(fā)活動(dòng) 必須使用統(tǒng)一格式的文檔進(jìn)行描述。為了使需求描述具有統(tǒng)一的風(fēng)格，可以采用已有的且可滿足項(xiàng)目需要的模板，如IEEE標(biāo)準(zhǔn)830-1998和GB9385中描述的SRS模板13需求評(píng)審分析人員在用戶和軟件設(shè)計(jì)人員的配合下，對(duì)自己

9、生成的需求規(guī)格說明和初步的用戶手冊(cè)進(jìn)行評(píng)審，確保軟件需求的完全性、精確性和一致性，并使用戶和軟件設(shè)計(jì)人員對(duì)需求規(guī)格說明及用戶手冊(cè)的理解達(dá)成一致。需求規(guī)格說明得到用戶和軟件開發(fā)方的確認(rèn)后，應(yīng)成為用戶方與軟件開發(fā)方合同的一部分。14需求分析流程15需求分析的原則原則能夠表達(dá)和理解問題的信息域和功能域能夠?qū)栴}進(jìn)行分解和不斷細(xì)化，建立問題的層次結(jié)構(gòu)需要給出系統(tǒng)的邏輯視圖和物理視圖方法面向數(shù)據(jù)流的分析面向數(shù)據(jù)的分析面向?qū)ο蟮姆治鲂枨蟮乃捻?xiàng)基本標(biāo)準(zhǔn)：明確(clear)、完整(complete)、一致(consistent)、可測(cè)試(testable)164.2 初步需求獲取技術(shù)訪談與會(huì)議深入調(diào)查研究聯(lián)合

10、小組開發(fā)原型17訪談與會(huì)議個(gè)別訪談或小組會(huì)議分析人員應(yīng)精心準(zhǔn)備問題，通過用戶對(duì)問題的回答，逐步理解用戶對(duì)目標(biāo)軟件的要求 (1)循序漸進(jìn) 首先關(guān)心一般性、整體性問題，然后再討論細(xì)節(jié)問題。 (2)客觀、公正 不應(yīng)限制用戶在回答問題過程中自由發(fā)揮。 (3)總結(jié) 問題匯總后應(yīng)能反映軟件或其子系統(tǒng)的全貌，能覆蓋用戶對(duì)目標(biāo)軟件或其子系統(tǒng)在功能、行為、性能諸方面的要求。細(xì)節(jié)問題留待以后解決。18深入調(diào)查研究調(diào)查研究 考察用戶軟件或其子系統(tǒng)業(yè)務(wù)流程 學(xué)習(xí)用戶的有關(guān)業(yè)務(wù)知識(shí)，在用戶幫助下了解用戶的軟件或子系統(tǒng)業(yè)務(wù)流程，結(jié)合軟件開發(fā)和應(yīng)用的經(jīng)驗(yàn)提出新的用戶需求注意：開發(fā)軟件系統(tǒng)不僅是為了模擬手工操作過程，還必須將

11、最好的經(jīng)濟(jì)效益、最快的處理速度、最合理的操作流程、最友好的用戶界面作為軟件的目標(biāo)19聯(lián)合小組建立軟件開發(fā)方和用戶方共同組成的聯(lián)合小組，小組成員對(duì)分析負(fù)有相同的責(zé)任聯(lián)合小組要制定自己的工作制度和計(jì)劃，確定專門的記錄員，另設(shè)專人負(fù)責(zé)會(huì)議的議程和資料的綜合、整理選擇易于理解、比較簡(jiǎn)潔、精確的表示機(jī)制作為描述語言，如輔以文字說明的流程圖20需求獲取一般過程1、識(shí)別系統(tǒng)用戶 分析客戶方的所有用戶類型以及潛在的類型，然后根據(jù)他們的要求來確定系統(tǒng)的整體目標(biāo)和系統(tǒng)的工作范圍。如有領(lǐng)導(dǎo)使用，則應(yīng)該有領(lǐng)導(dǎo)查詢系統(tǒng)；如果是單機(jī)系統(tǒng)，則對(duì)安全性可以少考慮。2、用戶調(diào)研與訪談 會(huì)議、電話、Email、小組討論、模擬演示

12、等，每次都要有記錄，確定功能需求、非功能需求(響應(yīng)時(shí)間、自動(dòng)恢復(fù)時(shí)間)、環(huán)境限制、設(shè)計(jì)約束等。3、訪談結(jié)果整理 對(duì)于用戶提出的每個(gè)需求都要知道“為什么”，并判斷這種需求是否有充足的理由。 將那種以“如何實(shí)現(xiàn)”的表達(dá)方式轉(zhuǎn)換為“實(shí)現(xiàn)什么”。 分析由用戶需求衍生出的隱含需求，并識(shí)別用戶沒有明確提出來的隱含需求。如工時(shí)統(tǒng)計(jì)計(jì)算工資，生產(chǎn)系統(tǒng)工資系統(tǒng)。4、訪談結(jié)果呈現(xiàn) 明確標(biāo)識(shí)出那些未確定的需求項(xiàng)。 使需求符合系統(tǒng)的整體目標(biāo)。 保證需求項(xiàng)之間的一致性，解決需求項(xiàng)之間可能存在的沖突。21出版社管理信息系統(tǒng)調(diào)查表編號(hào)提出問題1您在哪個(gè)部門工作？2出版業(yè)務(wù)流程是什么？3您每日都處理那些文件、數(shù)據(jù)、報(bào)表？4工

13、作中手工處理特別麻煩的事情是什么？5工作中手工處理什么問題解決不了？影響效率的問題有哪些？6您認(rèn)為提高工作效率，節(jié)省工作時(shí)間，減輕工作強(qiáng)度可采取哪些辦法？7您的部門需要成本核算和統(tǒng)計(jì)的內(nèi)容有哪些？8您的部門采用計(jì)算機(jī)管理工作情況如何？9如何改進(jìn)業(yè)務(wù)流程使之更合理？10哪些問題是目前傳統(tǒng)手工方法根本無法解決的？11出版社管理信息系統(tǒng)需要解決什么問題？22實(shí)例分析家庭保安系統(tǒng) 家庭保安市場(chǎng)正以每年40%的速度增長(zhǎng)。我們希望建立一種基于微處理器的家庭保安系統(tǒng)，它能夠識(shí)別異常事件并采取相應(yīng)的防護(hù)措施。這些異常事件包括：非法入侵、火災(zāi)、水淹，等等。一旦異常情況被相應(yīng)的傳感器探測(cè)出來，系統(tǒng)應(yīng)自動(dòng)用電話向監(jiān)

14、控中心報(bào)警。此外，系統(tǒng)應(yīng)允許戶主對(duì)其行為實(shí)施程序式控制。聯(lián)合小組首先制定工作制度，經(jīng)過數(shù)次會(huì)議討論，明確問題的范圍、問題與環(huán)境的關(guān)系，并就開發(fā)軟件產(chǎn)品的必要性達(dá)成共識(shí)后，小組負(fù)責(zé)人要求每位參加人列出應(yīng)用問題及環(huán)境中有關(guān)的對(duì)象、這些對(duì)象所實(shí)施的操作以及對(duì)象間的互相作用23實(shí)例分析控制面板、電話機(jī)、監(jiān)控中心、煙霧報(bào)警器、門窗報(bào)警器、警報(bào)器等對(duì)象；用戶編程控制、電話撥號(hào)、報(bào)警等操作要求對(duì)對(duì)象及操作進(jìn)行詳細(xì)描述用戶可能提出約束條件，如成本、響應(yīng)時(shí)間優(yōu)先處理順序等最后初步分析活動(dòng)，綜合、整理，形成文檔，該文檔作為后續(xù)分析活動(dòng)的基礎(chǔ)。部分需求文檔（不包括約束條件和測(cè)試標(biāo)準(zhǔn)）如下 “家庭保安系統(tǒng)”的軟件允許

15、用戶在安裝時(shí)進(jìn)行系統(tǒng)配置，實(shí)施對(duì)傳感器的監(jiān)控并通過控制面板與用戶進(jìn)行信息交互。24實(shí)例分析配置操作包括：（1）指定每一傳感器的種類和編號(hào)；（2）設(shè)置開、關(guān)機(jī)密碼；（3）指定報(bào)警電話號(hào)碼；（4）指定報(bào)警延遲和電話重?fù)苎舆t時(shí)間（以秒為單位）。當(dāng)軟件系統(tǒng)接收到傳感器發(fā)出的數(shù)據(jù)后，判別是否出現(xiàn)異常事件。如果是，則在指定的延遲時(shí)間內(nèi)撥報(bào)警電話號(hào)碼，撥號(hào)操作將按照重?fù)苎舆t反復(fù)進(jìn)行，直到電話接通。然后軟件系統(tǒng)負(fù)責(zé)報(bào)告時(shí)間、地點(diǎn)和異常事件的性質(zhì)。開機(jī)后，軟件系統(tǒng)負(fù)責(zé)顯示當(dāng)前工作狀態(tài)，接收并處理用戶指令。254.3 需求建模建立軟件模型是分析活動(dòng)的關(guān)鍵目標(biāo)軟件系統(tǒng)的模型用來刻劃系統(tǒng)所涉及的信息、處理功能及系統(tǒng)運(yùn)

16、行時(shí)的外部行為模型不應(yīng)涉及軟件實(shí)現(xiàn)細(xì)節(jié)，這樣會(huì)分散分析人員的注意力，限制軟件設(shè)計(jì)人員的聰明才智分析人員應(yīng)以簡(jiǎn)潔、準(zhǔn)確、清晰的方式，系統(tǒng)地描述軟件需求模型，如選擇圖形符號(hào)表示信息流、處理功能及系統(tǒng)行為，利用受限的自然語言給出用戶需求描述為了處理大型問題，模型表示機(jī)制應(yīng)具備良好的結(jié)構(gòu)化能力264.3 需求建模通常由一組模型組成信息(或數(shù)據(jù))模型功能模型行為模型最常用的兩種分析模型結(jié)構(gòu)化分析模型面向?qū)ο蠓治瞿Ｐ蚉ressman用簡(jiǎn)明的圖形介紹了這兩種分析模型的組成結(jié)構(gòu)274.3 需求建模結(jié)構(gòu)化分析模型模型的核心是DD(Data Dictionary，數(shù)據(jù)字典)，它是系統(tǒng)所涉及的各種數(shù)據(jù)對(duì)象的總和。從

17、DD出發(fā)可以構(gòu)建3種圖：1）E-R圖(Entity-Relation Diagram，實(shí)體關(guān)系圖)：用于描述數(shù)據(jù)對(duì)象間的關(guān)系，它代表軟件的數(shù)據(jù)模型，。2）DFD(Data Flow Diagram，數(shù)據(jù)流圖)：主要作用是指明系統(tǒng)中數(shù)據(jù)是如何流動(dòng)和變換的，以及描述數(shù)據(jù)流進(jìn)行變換的功能，在DFD中出現(xiàn)的每個(gè)功能的描述則寫在加工說明(PSPEC)中，一起構(gòu)成軟件的功能模型。3）STD(Status Transfer Diagram，狀態(tài)-變遷圖)：用于指明系統(tǒng)在外部事件的作用下將會(huì)如何動(dòng)作，表明了系統(tǒng)的各種狀態(tài)以及各種狀態(tài)之間的變遷，從而構(gòu)成行為模型的基礎(chǔ)，關(guān)于軟件控制方面的附加信息則包含在控制說明

18、(CSPEC)中。 早期模型僅包括DD、DFD和PSPEC等3個(gè)組成部分，主要用于描述軟件的數(shù)據(jù)模型(用DD)與功能模型(用DFD和PSPEC)284.3 需求建模面向?qū)ο蠓治瞿Ｐ湍Ｐ偷暮诵氖恰笆褂脤?shí)例”(Use Case)，簡(jiǎn)稱“用例”。當(dāng)通過FAST小組獲得軟件的需求后，軟件分析員即可據(jù)此創(chuàng)建一組“場(chǎng)景”(Scenario)，每個(gè)場(chǎng)景包含了一個(gè)使用實(shí)例。從這些用例出發(fā)，進(jìn)一步抽取和定義OOA模型的3種模型，即： 1）類-對(duì)象模型：描述系統(tǒng)所涉及的全部類-對(duì)象，每一個(gè)類-對(duì)象都通過屬性、操作和協(xié)作者來進(jìn)行進(jìn)一步描述。 2）對(duì)象關(guān)系模型：描述對(duì)象之間的靜態(tài)關(guān)系，同時(shí)定義了系統(tǒng)中所有重要的消息路

19、徑，它也可以具體化到對(duì)象的屬性、操作和協(xié)作者。 3）對(duì)象行為模型：描述了系統(tǒng)的動(dòng)態(tài)行為，即對(duì)象在特定的狀態(tài)下如何反映外界的事件。 與結(jié)構(gòu)化分析模型相類似，上述3種模型大體上相當(dāng)于E-R圖、DFD圖和STD圖，分別起到描述數(shù)據(jù)模型、功能模型與行為模型的作用。294.4 問題的抽象、分解與多視點(diǎn)分析抽象：關(guān)注一般問題的解決途徑，以此指導(dǎo)特殊問題的求解。分析人員應(yīng)該注意用戶描述的抽象級(jí)別，統(tǒng)一規(guī)劃系統(tǒng)行為。避免不一致性，減少分析的工作量。30分解根據(jù)問題的規(guī)模和復(fù)雜性進(jìn)行分解，并對(duì)子問題展開進(jìn)一步的分析逐級(jí)分解，直至子問題的規(guī)模降至合適程度在問題分解過程中，要建立子問題之間的相互聯(lián)系必須遵循子問題內(nèi)

20、部緊藕合，子問題之間松藕合的原則31視點(diǎn)分解法視點(diǎn)分解法 在分析的初期，整體地把握一個(gè)大型問題的軟件需求是困難的。需要從各個(gè)角度分別對(duì)問題進(jìn)行理解和分析，然后再綜合，達(dá)到全面理解的目的需求分析視點(diǎn) 系統(tǒng)觀點(diǎn) 用戶觀點(diǎn) 信息觀點(diǎn) 功能觀點(diǎn) 行為觀點(diǎn)等整理、綜合用戶描述，應(yīng)注意用戶視點(diǎn)的變化，避免遺漏324 .5 支持需求分析的快速原型技術(shù)按照傳統(tǒng)的軟件開發(fā)方法，目標(biāo)軟件要等到木已成舟才能交用戶認(rèn)可。分析、設(shè)計(jì)及編碼積累的各種問題，導(dǎo)致用戶對(duì)目標(biāo)軟件提出諸多修改，甚至全盤否決，造成人力、物力的巨大浪費(fèi)。軟件開發(fā)早期，快速建立目標(biāo)軟件系統(tǒng)原型，讓用戶對(duì)原型進(jìn)行評(píng)估并提出意見。原型幾經(jīng)改進(jìn)最終確定，它

21、將進(jìn)化成軟件產(chǎn)品。設(shè)計(jì)和編碼人員遵循原型確立的外部特征實(shí)現(xiàn)軟件產(chǎn)品。如果軟件產(chǎn)品含有大量人機(jī)交互、可視輸出、或者涉及復(fù)雜的算法，應(yīng)采用快速原型技術(shù)。33支持需求分析的快速原型技術(shù)分析階段使用快速原型技術(shù)與問題本身的復(fù)雜度以及可用的開發(fā)工具、環(huán)境有關(guān)。如果問題非常復(fù)雜，在當(dāng)前工具、環(huán)境的支持下開發(fā)可運(yùn)行的原型需要投入太多人力或占用太多時(shí)間，那么可對(duì)某些子問題，尤其是用戶界面，使用快速原型技術(shù)進(jìn)行部分分析。 某些軟件項(xiàng)目，雖不能構(gòu)造實(shí)際可運(yùn)行的快速原型，但可以采用幻燈片演示等方法，向用戶直觀描述目標(biāo)軟件系統(tǒng)的外部行為。34快速建造原型過程(1)利用需求分析技術(shù)、方法，生成簡(jiǎn)化的需求規(guī)格說明(2)對(duì)

22、簡(jiǎn)化的需求規(guī)格說明進(jìn)行檢查、修訂，生成設(shè)計(jì)規(guī)格說明。為了快速生成原型,只關(guān)心軟件的總體結(jié)構(gòu)、用戶界面和數(shù)據(jù)設(shè)計(jì)，而不注重過程內(nèi)部的控制流。(3)在快速原型工具或環(huán)境的幫助下，快速生成可運(yùn)行的軟件原型并進(jìn)行測(cè)試、改進(jìn)。主要工具有：可重用軟部件庫(kù)、用戶界面自動(dòng)生成器等。35快速建造原型過程(4)將原型提交用戶評(píng)估并征求改進(jìn)意見。(5)迭代上述過程，直到用戶滿意。 通過評(píng)審的原型應(yīng)全面、準(zhǔn)確地反映用戶對(duì)目標(biāo)軟件在外部行為方面的需求，可以作為需求規(guī)格說明的一部分并成為軟件設(shè)計(jì)和編碼的基礎(chǔ)。36軟件原型的分類探索型：目的是要弄清對(duì)目標(biāo)系統(tǒng)的要求，確定所希望的特性，并探討多種方案的可行性。實(shí)驗(yàn)型：這種原型

23、用于大規(guī)模開發(fā)和實(shí)現(xiàn)之前，考核方案是否合適，規(guī)格說明是否可靠。進(jìn)化型：這種原型的目的不在于改進(jìn)規(guī)格說明，而是將系統(tǒng)建造得易于變化，在改進(jìn)原型的過程中，逐步將原型進(jìn)化成最終系統(tǒng)。37原型開發(fā)模型3839原型開發(fā)技術(shù)可執(zhí)行規(guī)格說明基于腳本(scenario)的設(shè)計(jì)自動(dòng)程序設(shè)計(jì)專用語言可復(fù)用(reusable)的軟件簡(jiǎn)化假設(shè)404.6 需求規(guī)格說明與評(píng)審產(chǎn)生需求規(guī)格說明并進(jìn)行評(píng)審需求規(guī)格說明應(yīng)成為開發(fā)過程必須遵循的指導(dǎo)原則41需求規(guī)格說明目標(biāo)(1) 用戶通過需求規(guī)格說明可初步判定目標(biāo)軟件能否滿足需求，設(shè)計(jì)人員將需求規(guī)格說明作為軟件設(shè)計(jì)的基礎(chǔ)(2)支持目標(biāo)軟件系統(tǒng)的確認(rèn)，需求規(guī)格說明的各項(xiàng)需求應(yīng)該是可

24、測(cè)試的(3)控制系統(tǒng)進(jìn)化過程，需求分析完成后，如果用戶追加需求，開發(fā)人員再次進(jìn)行需求分析，擴(kuò)充需求規(guī)格說明，進(jìn)行軟件設(shè)計(jì)等42需求規(guī)格說明內(nèi)容功能、行為需求描述系統(tǒng)的輸入、輸出及相互關(guān)系非行為需求描述軟件系統(tǒng)工作時(shí)應(yīng)具備的各種屬性，如效率、可靠性、安全性、可維護(hù)性、可移植性等為使需求規(guī)格說明更加簡(jiǎn)潔，其它內(nèi)容不應(yīng)寫入，如人員、成本、進(jìn)度、設(shè)計(jì)方案、質(zhì)量控制等。這些內(nèi)容單獨(dú)形成文檔43需求規(guī)格說明1 引言 1.1 需求規(guī)格說明的目的 1.2 軟件產(chǎn)品的作用范圍 1.3 定義、同義詞與縮寫 1.4 參考文獻(xiàn) 1.5 需求規(guī)格說明概覽2 一般性描述 2.1 產(chǎn)品與其環(huán)境之間的關(guān) 2.2 產(chǎn)品功能 2

25、.3 用戶特征 2.4 限制與約束 2.5 假設(shè)與前提條件3 特殊需求附錄索引44特殊需求描述3 特殊需求 3.1 功能或行為需求 3.1.1 功能或行為需求1 3.1.1.1 引言 3.1.1.2 輸入 3.1.1.3 處理過程描述 3.1.1.4 輸出 3.1.2 功能或行為需求2 3.1.n 功能或行為需求n 3.2 外部界面需求 3.2.1 用戶界面 3.2.2 硬件界面 3.2.3 軟件界面 3.3 性能需求 3.4 設(shè)計(jì)約束 3.4.1 標(biāo)準(zhǔn)化約束 3.4.2 硬件約束 3.5 屬性 3.5.1 可用性 3.5.2安全性 3.5.3 可維護(hù)性 3.5.4 可移植性 3.6 其它需求 3.6.1 數(shù)據(jù)庫(kù)需求 3.6.2 用戶操作需求 3.6.3 工作場(chǎng)地需求45需求評(píng)審需求規(guī)格說明進(jìn)入設(shè)計(jì)階段之前，必須進(jìn)行評(píng)審。如果發(fā)現(xiàn)錯(cuò)誤或缺陷，應(yīng)及時(shí)糾正或更改需求分析、模型，需求規(guī)格說明，并重新評(píng)審。衡量需求規(guī)格說明的標(biāo)準(zhǔn) 正確性 無歧義性 完全性 可驗(yàn)證性 一致性 可理解性 可修改性 可追蹤性46需求評(píng)審(1)正確性。需求規(guī)格說明書的功能、行為、性能描述必須與用戶對(duì)目標(biāo)軟件產(chǎn)品的期望相吻合。(2)無歧義性。需求規(guī)格說明的任何語法單位只能有唯一的語義解釋。確保無歧義性的一種有效措施是在需求規(guī)格說明中使用標(biāo)準(zhǔn)化術(shù)語，并對(duì)術(shù)語的語義進(jìn)行顯