軟件工程課件-07需求工程過程

6、紀律是自由的第一條件。——黑格爾7、紀律是集體的面貌，集體的聲音，集體的動作，集體的表情，集體的信念。——馬卡連柯8、我們現(xiàn)在必須完全保持黨的紀律，否則一切都會陷入污泥中?！R克思9、學(xué)校沒有紀律便如磨坊沒有水?！涿兰~斯10、一個人應(yīng)該：活潑而守紀律，天真而不幼稚，勇敢而魯莽，倔強而有原則，熱情而不沖動，樂觀而不盲目。——馬克思軟件工程課件07需求工程過程軟件工程課件07需求工程過程6、紀律是自由的第一條件。——黑格爾7、紀律是集體的面貌，集體的聲音，集體的動作，集體的表情，集體的信念。——馬卡連柯8、我們現(xiàn)在必須完全保持黨的紀律，否則一切都會陷入污泥中?！R克思9、學(xué)校沒有紀律便如磨坊沒有水?！涿兰~斯10、一個人應(yīng)該：活潑而守紀律，天真而不幼稚，勇敢而魯莽，倔強而有原則，熱情而不沖動，樂觀而不盲目。——馬克思軟件工程課件07需求工程過程需求工程過程RequirementsEngineeringProcess需求工程過程是發(fā)現(xiàn)，分析和確認系統(tǒng)需求的過程（Processesusedtodiscover,analyseandvalidatesystemrequirements）6、紀律是自由的第一條件?！诟駹栜浖こ陶n件07需求工1軟件工程課件-07需求工程過程2軟件工程課件-07需求工程過程3軟件工程課件-07需求工程過程4軟件工程課件-07需求工程過程5需求工程過程需求工程所采用的過程多種多樣，它由應(yīng)用領(lǐng)域、參與人員和開發(fā)需求的機構(gòu)決定然而，在所有過程中也存在著一些相同的一般活動需求提取；需求分析；需求確認；需求管理。需求工程過程需求工程所采用的過程多種多樣，它由應(yīng)用領(lǐng)域、參與6需求工程過程需求工程過程7需求工程需求工程8可行性研究

（Feasibilitystudies）一個可行性研究決定提出的系統(tǒng)是否值得去做。研究焦點在于檢查該系統(tǒng)是否對機構(gòu)目標有貢獻；在既定預(yù)算和現(xiàn)有技術(shù)的情況下，是否能完成該系統(tǒng)的工程；該系統(tǒng)是否能與其它正在使用的系統(tǒng)進行集成。可行性研究

（Feasibilitystudies）一個可9可行性研究的實現(xiàn)實現(xiàn)手段依賴于信息評估（需要什么），信息收集和報告編寫對機構(gòu)里的人來說，問題是如果系統(tǒng)實現(xiàn)不了怎么辦?現(xiàn)有流程的問題是什么?提出的系統(tǒng)會有多大的幫助?集成將會遇到什么問題?需要新的技術(shù)嗎?要具備什么技能?對提出的系統(tǒng)提供支持的必要工具有那些?可行性研究的實現(xiàn)實現(xiàn)手段依賴于信息評估（需要什么），信息收集10提取（Elicitation）與分析有時稱其為需求提取或需求發(fā)現(xiàn)需要技術(shù)人員與顧客一起找出應(yīng)用領(lǐng)域，所提供的系統(tǒng)服務(wù)以及系統(tǒng)操作限制它可能涉及到最終用戶，管理人員，維護工程師，領(lǐng)域?qū)＜?，同業(yè)商會等等。這些被稱為利益相關(guān)人（stakeholders）提?。‥licitation）與分析有時稱其為需求提取或需11需求分析問題利益相關(guān)人不知道他們真正需要什么。利益相關(guān)人用自己的語言來表達需求。不同的利益相關(guān)人的需求可能會有沖突。機構(gòu)和政治的因素可能會影響系統(tǒng)需求。在分析過程中需求變化了。有新的利益相關(guān)人加入進來，業(yè)務(wù)環(huán)境也發(fā)生改變。需求分析問題利益相關(guān)人不知道他們真正需要什么。12需求螺旋需求螺旋13過程活動需求發(fā)現(xiàn)通過與利益相關(guān)人進行互動來發(fā)現(xiàn)需求，領(lǐng)域需求也要在這個階段找出來。需求的組織和分類把相關(guān)的需求進行分組并把它們放到一個聚類中。協(xié)商和優(yōu)先級排序?qū)⑿枨筮M行優(yōu)先級排序并解決需求沖突。編寫需求文檔編寫需求文檔并進入下一個螺旋階段過程活動需求發(fā)現(xiàn)14需求發(fā)現(xiàn)是對現(xiàn)有系統(tǒng)和提出的系統(tǒng)進行信息收集以及從這些信息中提取出用戶需求和系統(tǒng)需求的過程。信息來源包括文檔、系統(tǒng)的利益相關(guān)者和類似系統(tǒng)的規(guī)格說明。需求發(fā)現(xiàn)是對現(xiàn)有系統(tǒng)和提出的系統(tǒng)進行信息收集以及從這些信息中15銀行自動取款機系統(tǒng)（ATM）這里所用的例子是一個自動出納（auto-teller）系統(tǒng)，它能夠提供某些自動銀行服務(wù)。有些系統(tǒng)只為具有本系統(tǒng)的銀行的顧客提供一些服務(wù)，而對其他顧客提供的服務(wù)卻很少。服務(wù)包括提取現(xiàn)金（cashwithdrawal），傳遞信息（messagepassing，對一個服務(wù)請求發(fā)送一個消息），定出結(jié)算單（orderingastatement）和轉(zhuǎn)賬（transferringfunds）。銀行自動取款機系統(tǒng)（ATM）這里所用的例子是一個自動出納（16ATM利益相關(guān)人銀行顧客其他銀行的代表銀行管理人員柜臺職員數(shù)據(jù)庫管理員安全管理人員市場部門硬件和軟件維護工程師銀行校對員ATM利益相關(guān)人銀行顧客17觀點（Viewpoints）觀點是用一種構(gòu)造需求的方法來表達不同利益相關(guān)人的觀念。這種多角度的分析方法是很重要的，因為沒有唯一正確的分析系統(tǒng)需求的方法。觀點（Viewpoints）觀點是用一種構(gòu)造需求的方法來表達18觀點的類型互動者觀點人或其它系統(tǒng)是與系統(tǒng)直接互動的。在一個ATM上，客戶數(shù)據(jù)庫和賬目數(shù)據(jù)庫都代表互動者觀點。間接觀點那些不用系統(tǒng)的利益相關(guān)人也會影響到需求。在一個ATM上，管理員和保安人員就代表間接觀點。領(lǐng)域觀點領(lǐng)域特征和限制也會影響需求，在一個ATM上的例子就是銀行間的通信標準。觀點的類型互動者觀點19觀點識別識別觀點要采用：系統(tǒng)服務(wù)的提供者和接受者；與被識別的系統(tǒng)直接互動的系統(tǒng)；規(guī)則和標準；業(yè)務(wù)和非功能需求的源頭；開發(fā)和維護系統(tǒng)的工程師；市場和其它業(yè)務(wù)觀點。觀點識別識別觀點要采用：20LIBSYS觀點的層次結(jié)構(gòu)LIBSYS觀點的層次結(jié)構(gòu)21面談（Interviewing）通過正式的或非正式的面談，需求小組向利益相關(guān)人詢問關(guān)于他們?nèi)绾问褂孟到y(tǒng)和怎樣開發(fā)系統(tǒng)的問題。有兩種面談方式：限定式面談——回答一組預(yù)先擬定好的問題。開放式面談——沒有預(yù)定的議程和議題和利益相關(guān)人交談。面談（Interviewing）通過正式的或非正式的面談，需22面談實踐通常是限定式與開放式面談相結(jié)合。面談有利于收集到利益相關(guān)人的觀點以及有關(guān)他們?nèi)绾闻c系統(tǒng)互動的信息。面談不利于對領(lǐng)域需求的理解需求工程師不理解特定領(lǐng)域的術(shù)語；人們認為一些領(lǐng)域知識太普通了，以至于不值得去考慮或講出來。面談實踐通常是限定式與開放式面談相結(jié)合。23有效的面談?wù)呙嬲務(wù)邞?yīng)該以樂意和虛心的態(tài)度傾聽利益相關(guān)人的意見，不要對需求抱有成見。他們應(yīng)該用一個提問和建議來鼓勵被訪者，而不是期望被訪者簡單地回答像“你想做什么？”這樣的問題。有效的面談?wù)呙嬲務(wù)邞?yīng)該以樂意和虛心的態(tài)度傾聽利益相關(guān)人的意見24情節(jié)（Scenarios）情節(jié)是在現(xiàn)實生活中如何使用一個系統(tǒng)的例子。它們應(yīng)該包括：對初始情況的一個描述；對常規(guī)事件流的一個描述；關(guān)于如何導(dǎo)致錯誤的一個描述；關(guān)于其它并發(fā)活動的信息；對情節(jié)的結(jié)束狀態(tài)的一個描述。情節(jié)（Scenarios）情節(jié)是在現(xiàn)實生活中如何使用一個系統(tǒng)25LIBSYS情節(jié)(1)LIBSYS情節(jié)(1)26LIBSYS情節(jié)(2)LIBSYS情節(jié)(2)27用況（Usecases）用況是基于UML技術(shù)的一種情節(jié)，它識別出一個交互中的參與者并描述這個交互本身。可以用一組用況描述與系統(tǒng)發(fā)生的所有可能的互動情況可以用順序圖補充用況的細節(jié)，它展示了在系統(tǒng)中處理事件的順序。用況（Usecases）用況是基于UML技術(shù)的一種情節(jié)，它28文章打印的用況文章打印的用況29LIBSYS的用況LIBSYS的用況30文章打印的順序圖文章打印的順序圖31社會和機構(gòu)因素軟件系統(tǒng)是在一個社會和機構(gòu)的環(huán)境中使用的。這個環(huán)境可以影響甚至主導(dǎo)系統(tǒng)需求社會和機構(gòu)的因素不是一個單一的觀點，它對所有的觀點都會有影響好的分析員必須對這些因素很敏感，目前還沒有系統(tǒng)的方法來解決他們分析中的問題。社會和機構(gòu)因素軟件系統(tǒng)是在一個社會和機構(gòu)的環(huán)境中使用的。這個32人種學(xué)（Ethnography）一些社會科學(xué)家花費了相當(dāng)可觀的時間來觀察和分析人們實際是如何工作的。人們往往知道自己的工作而不知道他們的工作與機構(gòu)中其他工作的聯(lián)系。社會和機構(gòu)因素的重要性是可以觀察的。人種學(xué)的研究表明，工作通常遠比簡單的系統(tǒng)模型所包含的要豐富和復(fù)雜的多。人種學(xué)（Ethnography）一些社會科學(xué)家花費了相當(dāng)可觀33聚焦人種學(xué)是在一個研究空中交通管制過程的項目中開發(fā)出來的方法。它把人種學(xué)和原型法結(jié)合起來。原型法開發(fā)引出了一些尚未回答的問題，這些問題正是人種學(xué)研究所關(guān)注的。人種學(xué)的問題是它研究的是現(xiàn)在的實踐，它們所依賴的某些歷史背景已是不再相關(guān)的。聚焦人種學(xué)是在一個研究空中交通管制過程的項目中開發(fā)出來的方法34人種學(xué)和原型法人種學(xué)和原型法35人種學(xué)的范圍需求來自于人們實際工作方式，而不是過程定義中所建議的工作方式。需求來自于合作以及對他人活動的認識。人種學(xué)的范圍需求來自于人們實際工作方式，而不是過程定義中所建36需求確認(validation)證明需求所描述的系統(tǒng)是客戶所真正需要的。因為需求差錯的成本很高，所以確認非常重要在交付之后修正一個需求差錯（requirementserror）的成本比修正一個實現(xiàn)錯誤（implementationerror）的成本高達100倍。需求確認(validation)證明需求所描述的系統(tǒng)是客戶所37需求檢查（checking）有效性（Validity）。系統(tǒng)所提供的功能是否很好地支持了客戶的要求?一致性（Consistency）。需求有沒有沖突?完整性（Completeness）。是否包含了客戶所需要的全部功能?現(xiàn)實性（Realism）。在所獲得的預(yù)算和技術(shù)條件下，需求能不能實現(xiàn)？可檢驗性（Verifiability）。需求是否可以檢驗?需求檢查（checking）有效性（Validity）。系統(tǒng)38需求確認技術(shù)需求審核（reviews）對需求進行系統(tǒng)地人工分析。原型法（prototyping）用一個可執(zhí)行的系統(tǒng)模型去驗證需求。測試案例生成法（Test-casegeneration）為需求開發(fā)測試以檢驗其可測程度。一致性跟蹤（consistencytracking）對需求進行一致性跟蹤和檢查。需求確認技術(shù)需求審核（reviews）39需求復(fù)核（reviews）當(dāng)需求定義形成后，應(yīng)該定期復(fù)核。客戶和承包人都應(yīng)該參與復(fù)核。復(fù)核可以是正式的(有完整的文檔)，也可以是非正式的。開發(fā)人員、顧客和用戶之間的良好溝通有助于早期解決問題。需求復(fù)核（reviews）當(dāng)需求定義形成后，應(yīng)該定期復(fù)核。40復(fù)核檢查（Reviewchecks）可檢驗性（Verifiability）。

需求是否確實可測?可理解性（Comprehensibility）。

需求是否完全被理解?可跟蹤性（Traceability）。需求的來源是否清楚?可裁剪性（Adaptability)。需求變化是否不會對其他需求有很大的影響?復(fù)核檢查（Reviewchecks）可檢驗性（Verifi41需求管理需求管理是在系統(tǒng)開發(fā)和需求工程過程中，對變化的需求進行管理的過程。需求難免是不完整的和不一致的隨著業(yè)務(wù)需求的變化和對所開發(fā)的系統(tǒng)的更深了解，在過程中會出現(xiàn)新的需求；不同觀點具有不同的需求，而且它們常常是相互矛盾的需求管理需求管理是在系統(tǒng)開發(fā)和需求工程過程中，對變化的需求進42需求變更在開發(fā)過程中，各個不同觀點的需求的優(yōu)先序改變了。系統(tǒng)客戶從業(yè)務(wù)的角度出發(fā)指定的需求可能會與最終用戶的需求相沖突。在開發(fā)中，系統(tǒng)的業(yè)務(wù)和技術(shù)環(huán)境改變了。需求變更在開發(fā)過程中，各個不同觀點的需求的優(yōu)先序改變了。43需求進化需求進化44不變的和易變的需求不變需求（Enduringrequirements）。它是穩(wěn)定的，它來自顧客機構(gòu)的核心活動需求。例如一個醫(yī)院總是有醫(yī)生，護士等等。它也可以來自領(lǐng)域模型易變需求（Volatilerequirements）。在系統(tǒng)開發(fā)或使用中變化的那部分需求。例如在醫(yī)院，來自保?。╤ealth-care）政策的需求。不變的和易變的需求不變需求（Enduringrequire45需求分類（Classification）易變需求（Mutablerequirements）隨系統(tǒng)環(huán)境而變的需求。漸現(xiàn)需求（Emergentrequirements）隨著對系統(tǒng)的不斷理解而出現(xiàn)的需求。后果需求（Consequentialrequirements）由于引入計算機系統(tǒng)而產(chǎn)生的需求。兼容需求（Compatibilityrequirements）受制于機構(gòu)過程或者其它系統(tǒng)的需求。需求分類（Classification）易變需求（Mutab46需求管理計劃編制在需求工程過程中，需要規(guī)劃：需求識別（Requirementsidentification）

如何逐個地鑒定需求。對一個變更的管理過程（Achangemanagementprocess）在對一個需求變化進行分析的時候所要遵循的過程。跟蹤策略（Traceabilitypolicies）所需要維護的需求關(guān)系的信息數(shù)量有多大。計算機輔助軟件工程的工具支持（CASEtoolsupport）管理需求變更所需要的工具支持。需求管理計劃編制在需求工程過程中，需要規(guī)劃：47可跟蹤性（Traceability）可跟蹤性涉及到需求，需求來源和系統(tǒng)設(shè)計之間的關(guān)系。來源可跟蹤性（Sourcetraceability）從需求到提出這些需求的利益相關(guān)人的聯(lián)系。需求可跟蹤性（Requirementstraceability）在相關(guān)的需求之間的聯(lián)系。設(shè)計可跟蹤性（Designtraceability）由需求到設(shè)計的聯(lián)系。可跟蹤性（Traceability）可跟蹤性涉及到需求，需求48AtraceabilitymatrixU—rowAusescolumnB;R—rowAisrelatedwithcolumnB.AtraceabilitymatrixU—rowAu49CASE工具支持需求存儲（Requirementsstorage）需求應(yīng)該在一個安全和可管理的數(shù)據(jù)存儲器中來管理。變更管理（Changemanagement）變更管理過程是一個工作流過程，它的每個階段都是可以定義的，而且在這些階段之間有一部分信息流是自動化的。跟蹤管理（Traceabilitymanagement）自動查找（Automatedretrieval）需求之間的聯(lián)系。CASE工具支持需求存儲（Requirementsstor50需求變更管理應(yīng)該應(yīng)用到所有提出變化的需求上。主要階段（Principalstages）問題分析（Problemanalysis）。對需求問題和變更提議進行討論；變更分析和成本計算（Changeanalysisandcosting）。評估變更對其他需求的影響。變更實現(xiàn)（Changeimplementation）。修改需求文檔和其它與變更有關(guān)的文檔。需求變更管理應(yīng)該應(yīng)用到所有提出變