需求工程-05需求工程vs.系統(tǒng)分析幻燈片資料

1REvs.SystemsAnalysis

需求工程vs.系統(tǒng)分析2需求工程vs.系統(tǒng)分析

REvs.SystemsAnalysis需求工程由系統(tǒng)分析發(fā)展而來(lái)系統(tǒng)分析關(guān)注企業(yè)內(nèi)部的信息系統(tǒng)主要采用非形式化的需求描述，工具和方法,例如：DFD,E-R,OO,…80年代中期形成，90年代以來(lái)成為研究熱點(diǎn)。多見于管理學(xué)院，工程學(xué)科，和計(jì)算機(jī)科學(xué)的本科生和研究生教學(xué)3需求工程vs.系統(tǒng)分析

REvs.SystemsAnalysis需求工程超出系統(tǒng)分析的范圍涵蓋整個(gè)形式化問(wèn)題從“企業(yè)需求”到“精確描述”不僅限于信息系統(tǒng)實(shí)時(shí)系統(tǒng)嵌入系統(tǒng)交互系統(tǒng)基于組件的系統(tǒng)webservices相對(duì)較少關(guān)注企業(yè)管理問(wèn)題和企業(yè)業(yè)務(wù)流程5將問(wèn)題與解決方案分開理解問(wèn)題

需求獲取問(wèn)題的形式化表示

形式規(guī)約，形式建模就問(wèn)題性質(zhì)達(dá)成共識(shí)

驗(yàn)證,沖突及矛盾消解,磋商 需求管理–維護(hù)雙方的共識(shí)6設(shè)計(jì)活動(dòng)改變客觀世界狀態(tài)7什么是需求？（Jackson,1995）領(lǐng)域性質(zhì)(DomainProperty)：無(wú)論系統(tǒng)存在與否均存在的應(yīng)用領(lǐng)域的性質(zhì)。需求(Requirements)：由系統(tǒng)的存在而產(chǎn)生的應(yīng)用領(lǐng)域性質(zhì)。規(guī)約描述(Specification)：描述系統(tǒng)為滿足需求而應(yīng)具有的行為。需求證明的標(biāo)準(zhǔn)(VerificationCriteria)：1、運(yùn)行在某臺(tái)機(jī)器上的程序滿足規(guī)約描述；2、針對(duì)給定的領(lǐng)域性質(zhì)，規(guī)約描述滿足需求。需求驗(yàn)證的標(biāo)準(zhǔn)（ValidationCriteria）：1、是否已發(fā)現(xiàn)所有重要需求？2、是否已發(fā)現(xiàn)所有有關(guān)的領(lǐng)域性質(zhì)？8實(shí)例RequirementR需求:只有被授權(quán)者能夠訪問(wèn)數(shù)據(jù)庫(kù)。DomainPropertiesD領(lǐng)域性質(zhì):授權(quán)者持有密碼。密碼不會(huì)分享給未授權(quán)者。SpecificationS規(guī)約描述:用戶輸入密碼后，將被準(zhǔn)許訪問(wèn)數(shù)據(jù)庫(kù)。S+DimplyR當(dāng)領(lǐng)域模型出錯(cuò)時(shí)，會(huì)有什么后果9需求：關(guān)于為什么？做什么？

不包括怎么做？（why,what,how）…需求描述必須給出為什么需要這樣一個(gè)系統(tǒng)?！猂oss,1977通常，需求描述系統(tǒng)要做什么，而不是怎么做。但是，二者不太容易區(qū)分，上一個(gè)抽象層次的“怎么做”經(jīng)常在下一個(gè)抽象層次上轉(zhuǎn)化為“做什么”。Jackson給出的稍為清楚的解釋：“為什么”和“做什么”是指系統(tǒng)的設(shè)計(jì)目的，是置身系統(tǒng)外部，對(duì)應(yīng)用領(lǐng)域性質(zhì)的描述?！霸趺醋觥笔侵赶到y(tǒng)的內(nèi)部結(jié)構(gòu)和行為。——Jackson,199510“描述”是需求工程的核心

（Jackson,1995）用非形式化的語(yǔ)言指出感興趣的主題現(xiàn)象，并命名(designation)。例如：Parent(x,p)：p是x的父母。Female(x):x是女性。術(shù)語(yǔ)的形式化定義(definition)和使用。例如：Mother(x,m)≡Parent(x,m)andFemale(m)Sister(x,y)≡Female(y)andmother(x,m)andmother(y,m)andfather(x,f)andfather(y,f)11“描述”是需求工程的核心

（Jackson,1995,p58-59）關(guān)于領(lǐng)域性質(zhì)的無(wú)可駁的描述(refutabledescription)。無(wú)可駁性依賴于與主題現(xiàn)象的一致性。例如：對(duì)所有的m和x，Parent(x，m)蘊(yùn)含not(parent(m,x))開發(fā)過(guò)程中的帶有假設(shè)性質(zhì)的概略描述(roughsketch)。例如：“人與人之間總是通過(guò)某種方式相互聯(lián)系”“每個(gè)人實(shí)際上只能有一個(gè)家”12存在問(wèn)題的需求描述實(shí)例含糊的需求描述：“工資總額由上一條記錄獲得”“所有客戶都具有同一控制域“錯(cuò)誤的需求描述：“所有系統(tǒng)將九月作為財(cái)政年度的起始時(shí)間”不完整的需求描述：“出錯(cuò)信息顯示在屏幕的第24行“矛盾或不一致的需求描述：“C=A+B”；“C=A-B”無(wú)法測(cè)試的需求：“系統(tǒng)應(yīng)具有友好的界面“13需求的層次軟件需求包括三個(gè)不同的層次業(yè)務(wù)需求（businessrequirement）

反映了組織機(jī)構(gòu)或客戶對(duì)系統(tǒng)、產(chǎn)品高層次的目標(biāo)要求，它們?cè)陧?xiàng)目視圖與范圍文檔中予以說(shuō)明。用戶需求(userrequirement)

描述了用戶使用產(chǎn)品必須要完成的任務(wù)，這在使用實(shí)例（usecase）文檔或方案腳本（scenario）說(shuō)明中予以說(shuō)明。功能需求(functionalrequirement)（包括非功能需求）：定義了開發(fā)人員必須實(shí)現(xiàn)的軟件功能，使得用戶能完成他們的任務(wù)，從而滿足了業(yè)務(wù)需求。14軟件需求各組成部分之間的關(guān)系對(duì)一個(gè)復(fù)雜產(chǎn)品來(lái)說(shuō)，軟件功能需求也許只是系統(tǒng)需求的一個(gè)子集，另外一些可能屬于軟件部件。管理人員或市場(chǎng)分析人員確定軟件的業(yè)務(wù)需求，使公司運(yùn)作更加高效（對(duì)信息系統(tǒng)而言）或具有很強(qiáng)的市場(chǎng)競(jìng)爭(zhēng)力（對(duì)商業(yè)軟件產(chǎn)品而言）。所有的用戶需求必須與業(yè)務(wù)需求一致。用戶需求使需求分析者能從中總結(jié)出功能需求以滿足用戶對(duì)產(chǎn)品的要求從而完成其任務(wù)，而開發(fā)人員則根據(jù)功能需求來(lái)設(shè)計(jì)軟件以實(shí)現(xiàn)必須的功能。15非功能性需求：作為功能需求的補(bǔ)充，軟件需求規(guī)格說(shuō)明還應(yīng)包括非功能需求，它描述了系統(tǒng)展現(xiàn)給用戶的行為和執(zhí)行的操作等。它包括產(chǎn)品必須遵從的標(biāo)準(zhǔn)、規(guī)范和合約；外部界面的具體細(xì)節(jié)；性能要求；設(shè)計(jì)或?qū)崿F(xiàn)的約束條件及質(zhì)量屬性。所謂約束是指對(duì)開發(fā)人員在軟件產(chǎn)品設(shè)計(jì)和構(gòu)造上的限制。質(zhì)量屬性是通過(guò)多種角度對(duì)產(chǎn)品的特點(diǎn)進(jìn)行描述，從而反映產(chǎn)品功能。多角度描述產(chǎn)品對(duì)用戶和開發(fā)人員都極為重要。16需求工程17本章內(nèi)容工程與軟件工程軟件需求工程需求工程師需求工程vs.系統(tǒng)分析軟件生命周期中的需求活動(dòng)關(guān)于需求的基本觀點(diǎn)18RequirementactivitiesintheSElifecycle

軟件生命周期中的需求活動(dòng)19瀑布模型（Waterfall/Baseline）核心思想：系統(tǒng)開發(fā)是逐步求精的過(guò)程各步驟相對(duì)獨(dú)立，便于管理存在的問(wèn)題：忽略了需求的動(dòng)態(tài)性需求完成后，用戶對(duì)項(xiàng)目的參與即停止需求描述與設(shè)計(jì)分開不支持原型的使用和軟件重用（Loucopoulos&Karakostas,1995）20原型法（Prototype）適用范圍：用于獲取關(guān)于系統(tǒng)用戶界面的需求用于檢驗(yàn)設(shè)計(jì)方案的可行性，或探討系統(tǒng)性能問(wèn)題存在的問(wèn)題：用戶將原型誤認(rèn)為最終系統(tǒng)原型所反映的系統(tǒng)是不全面的（Loucopoulos&Karakostas,1995,p30）21增量式開發(fā)與演化式開發(fā)

Incrementalvs.Evolutionary(Thayer&Dorfman,1997,p10)22螺旋模型(SpiralModel)螺旋模型主要用于風(fēng)險(xiǎn)分析每一輪開發(fā)活動(dòng)具體包括:制定下一輪計(jì)劃決定設(shè)計(jì)目標(biāo)和限制條件評(píng)估候選方案,風(fēng)險(xiǎn)降解產(chǎn)品開發(fā)需求工程有關(guān)步驟為：需求風(fēng)險(xiǎn)分析規(guī)劃設(shè)計(jì)可以減少需求變更所帶來(lái)的風(fēng)險(xiǎn)存在的問(wèn)題：無(wú)法應(yīng)付不可預(yù)見的需求變化23V型模型

（V-Model）

(Macaulay,1996）24關(guān)于敏捷模型（AgileModels）基本原則：減少溝通障礙程序員與客戶直接交流減低繁重的文檔負(fù)擔(dān)文檔代價(jià)昂貴但用途有限對(duì)開發(fā)人員給予充分信任無(wú)需運(yùn)用花樣翻新的過(guò)程模型給與提示響應(yīng)客戶要求而非嚴(yán)格遵循合同條文缺點(diǎn)：依賴程序員的記憶力源代碼是難于維護(hù)的依賴口頭交流易發(fā)生誤解假定只有唯一的客戶代表不可能反映多視角制作短期計(jì)劃無(wú)長(zhǎng)期及前瞻性規(guī)劃25本章內(nèi)容工程與軟件工程軟件需求工程需求工程師需求工程vs.系統(tǒng)分析軟件生命周期中的需求活動(dòng)關(guān)于需求的基本觀點(diǎn)26Viewpoints

關(guān)于需求的基本觀點(diǎn)27關(guān)于需求的基本觀點(diǎn)需求工程活動(dòng)不總是順序進(jìn)行問(wèn)題描述不總是先于解決方案描述在系統(tǒng)開發(fā)的任何階段描述問(wèn)題均是有益的需求工程是在各開發(fā)階段持續(xù)進(jìn)行的一系列活動(dòng)問(wèn)題陳述無(wú)法追求完美需求模型是對(duì)世界的近似表示將包括不精確和不一致性會(huì)省略某些信息細(xì)致的分析將降低導(dǎo)致嚴(yán)重問(wèn)題的風(fēng)險(xiǎn)…但風(fēng)險(xiǎn)永不可能降解為零28關(guān)于需求的基本觀點(diǎn)追求規(guī)約的描述會(huì)降低性價(jià)比需求分析是有開銷的不同的項(xiàng)目，性價(jià)比的平衡點(diǎn)是不同的問(wèn)題描述永不可能是固定的變化是無(wú)法避免的，因此應(yīng)納入計(jì)劃之中對(duì)變化的處理應(yīng)定期進(jìn)行29可能的需求來(lái)源客戶專有需求對(duì)于有著明確問(wèn)題的特定客戶，最終客戶享有決定權(quán)。市場(chǎng)需求對(duì)于在市場(chǎng)上廣泛出售的產(chǎn)品，營(yíng)銷團(tuán)隊(duì)扮演著顧客和用戶代表的角色，產(chǎn)品必須擁有顧客。社會(huì)需求系統(tǒng)的目的是造福社會(huì)，而不需要客戶（支付報(bào)酬）一些開源/自由軟件，科學(xué)研究軟件綜合為特定客戶開發(fā)，但最終希望面向