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

1REvs.SystemsAnalysis

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

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

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

需求獲取問題的形式化表示

形式規(guī)約，形式建模就問題性質達成共識

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

不包括怎么做？（why,what,how）…需求描述必須給出為什么需要這樣一個系統(tǒng)?！猂oss,1977通常，需求描述系統(tǒng)要做什么，而不是怎么做。但是，二者不太容易區(qū)分，上一個抽象層次的“怎么做”經(jīng)常在下一個抽象層次上轉化為“做什么”。Jackson給出的稍為清楚的解釋：“為什么”和“做什么”是指系統(tǒng)的設計目的，是置身系統(tǒng)外部，對應用領域性質的描述。“怎么做”是指系統(tǒng)的內部結構和行為?！狫ackson,199510“描述”是需求工程的核心

（Jackson,1995）用非形式化的語言指出感興趣的主題現(xiàn)象，并命名(designation)。例如：Parent(x,p)：p是x的父母。Female(x):x是女性。術語的形式化定義(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）關于領域性質的無可駁的描述(refutabledescription)。無可駁性依賴于與主題現(xiàn)象的一致性。例如：對所有的m和x，Parent(x，m)蘊含not(parent(m,x))開發(fā)過程中的帶有假設性質的概略描述(roughsketch)。例如：“人與人之間總是通過某種方式相互聯(lián)系”“每個人實際上只能有一個家”12存在問題的需求描述實例含糊的需求描述：“工資總額由上一條記錄獲得”“所有客戶都具有同一控制域“錯誤的需求描述：“所有系統(tǒng)將九月作為財政年度的起始時間”不完整的需求描述：“出錯信息顯示在屏幕的第24行“矛盾或不一致的需求描述：“C=A+B”；“C=A-B”無法測試的需求：“系統(tǒng)應具有友好的界面“13需求的層次軟件需求包括三個不同的層次業(yè)務需求（businessrequirement）

反映了組織機構或客戶對系統(tǒng)、產(chǎn)品高層次的目標要求，它們在項目視圖與范圍文檔中予以說明。用戶需求(userrequirement)

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

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

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

（V-Model）

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

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