軟件工程課件-CH4

第二部分建模

11/28/20221第二部分建模

11/27/20221模型模型:對問題的書面上的無歧義文字或圖形的描述.簡言之,模型是對現(xiàn)實(shí)的簡化.通過模型,人們可以了解所研究事物的本質(zhì).最杰出的模型:地圖11/28/20222模型模型:對問題的書面上的無歧義文字或圖形的描述.簡言之,建模建模:對現(xiàn)實(shí)系統(tǒng)進(jìn)行適當(dāng)?shù)倪^濾,用適當(dāng)?shù)谋憩F(xiàn)規(guī)則描述出簡潔的模型.建模是一種深入解決問題的方法.建模的原則(1).選擇建立什么樣的模型對如何發(fā)現(xiàn)和解決問題具有重要的影響。正確的模型有助于提高開發(fā)者的洞察力。(2).每個模型可以有多種表達(dá)方式.使用者的身份和使用的原因是評判模型好壞的關(guān)鍵。11/28/20223建模11/27/20223(3).最好的模型總是能夠切合實(shí)際.模型是現(xiàn)實(shí)的簡化，必須保證簡化過程不會掩蓋任何重要的細(xì)節(jié)。(4).孤立的模型是不完整的。11/28/20224(3).最好的模型總是能夠切合實(shí)際.模型是現(xiàn)實(shí)的簡化，必軟件建模的實(shí)現(xiàn)過程軟件建模的作用是把來源于現(xiàn)實(shí)世界的問題轉(zhuǎn)化為計算機(jī)可以理解和實(shí)現(xiàn)的問題.軟件建模的實(shí)現(xiàn)過程是從需求入手,用模型表達(dá)分析設(shè)計過程,最終將模型映射成軟件實(shí)現(xiàn).現(xiàn)實(shí)世界計算機(jī)世界映射需求模型編碼11/28/20225軟件建模的實(shí)現(xiàn)過程軟件建模的作用是把來源于現(xiàn)實(shí)世界的問題轉(zhuǎn)化第四章理解需求11/28/20226第四章理解需求11/27/20226最恐怖的噩夢：一個客戶走進(jìn)你的辦公室，坐下，正視著你，然后說：“我知道你認(rèn)為我說的是什么，但你并不理解的是：我所說的并不是我想要的?！?1/28/20227最恐怖的噩夢：11/27/202274.1需求工程構(gòu)建一個軟件系統(tǒng)最困難的部分是確定構(gòu)建什么。其他部分工作不會像這部分工作一樣，在出錯之后會如此嚴(yán)重地影響隨后實(shí)現(xiàn)的系統(tǒng)，并且以后修補(bǔ)竟會如此的困難?！狥redBrooks一些常見的現(xiàn)象需求工程（RequirementEngineering,RE）是指致力于不斷理解需求的大量任務(wù)和技術(shù)。從軟件過程的角度來看，需求工程是一個軟件工程動作，開始于溝通活動并持續(xù)到建模活動。他必須適應(yīng)于過程、項(xiàng)目、產(chǎn)品和人員工作的需要。11/28/202284.1需求工程構(gòu)建一個軟件系統(tǒng)最困難的部分是確定構(gòu)建什么。需求工程為設(shè)計和構(gòu)造奠定了堅(jiān)實(shí)的基礎(chǔ)。如果沒有需求工程，那么實(shí)現(xiàn)的軟件很有可能無法滿足客戶的需求。需求工程過程通過執(zhí)行七個不同的活動來實(shí)現(xiàn)：起始、導(dǎo)出、精化、協(xié)商、規(guī)格說明、確認(rèn)和管理。11/28/20229需求工程為設(shè)計和構(gòu)造奠定了堅(jiān)實(shí)的基礎(chǔ)。如果沒有需求工程，那么起始建立基本的理解，包括對問題、誰需要解決方案、所期望解決方案的性質(zhì)、與項(xiàng)目利益相關(guān)者和開發(fā)人員之間達(dá)成初步交流合作的效果。11/28/202210起始11/27/202210導(dǎo)出詢問客戶、用戶和其他人，系統(tǒng)或產(chǎn)品的目標(biāo)是什么，想要實(shí)現(xiàn)什么，系統(tǒng)和產(chǎn)品如何滿足業(yè)務(wù)的要求，最終系統(tǒng)或產(chǎn)品如何用于日常工作，這些問題是非常簡單的。但是，實(shí)際上并非如此簡單“——這非常困難。為什么導(dǎo)出需求這么困難？范圍問題理解問題易變問題11/28/202211導(dǎo)出11/27/202211精化精化是由一系列的用戶場景建模和求精任務(wù)驅(qū)動的。這些用戶場景描述了如何讓最終用戶和其他參與者與系統(tǒng)進(jìn)行交互。解析每個用戶場景以便提取分析類——最終用戶可見的業(yè)務(wù)域?qū)嶓w。應(yīng)該定義每個分析類的屬性，確定每個類所需要的服務(wù)，確定類之間的關(guān)聯(lián)和協(xié)作關(guān)系，并完成各種補(bǔ)充圖。精化是件好事，但你必須知道何時可以停止精化。關(guān)鍵是能采用為設(shè)計監(jiān)理一個堅(jiān)實(shí)基礎(chǔ)的方式說明問題。如果超出這個點(diǎn)就是在做設(shè)計。11/28/202212精化11/27/202212協(xié)商需求工程師必須通過協(xié)商過程來調(diào)解沖突。應(yīng)該讓客戶、用戶和其他利益相關(guān)者對各自的需求排序，然后按優(yōu)先級討論沖突。使用迭代的方法給需求排序，評估每項(xiàng)需求對項(xiàng)目產(chǎn)生的成本和風(fēng)險，表述內(nèi)部沖突，刪除、組合和（或）修改需求，以便參與各方均能達(dá)到一定的滿意度。在有效的協(xié)商中沒有贏家也沒有輸家，而是雙贏。這是因?yàn)殡p方合作才是“交易”的堅(jiān)實(shí)基礎(chǔ)。11/28/202213協(xié)商11/27/202213規(guī)格說明規(guī)格說明的形式和格式隨著待開發(fā)軟件的規(guī)模和復(fù)雜度的不同而變化。一個規(guī)格說明可以是一份寫好的文檔、一套圖形化的模型。一個形式化的數(shù)學(xué)模型、一組使用場景、一個原型或上述各項(xiàng)的任意組合。例：湖南省輕工鹽業(yè)集團(tuán)人力資源系統(tǒng)需求分析說明書11/28/202214規(guī)格說明11/27/202214確認(rèn)在確認(rèn)這一步將對需求工程的工作產(chǎn)品進(jìn)行質(zhì)量評估。需求確認(rèn)要檢查規(guī)格說明以保證：已無歧義的說明了所有的系統(tǒng)需求；已檢測出不一致性、疏忽和錯誤并得到糾正；工作產(chǎn)品符合為過程、項(xiàng)目和產(chǎn)品建立的標(biāo)準(zhǔn)。正式的技術(shù)評審時最主要的需求確認(rèn)機(jī)制。確認(rèn)需求的評審小組包括軟件工程師、客戶、用戶和其他利益相關(guān)者，他們檢查系統(tǒng)規(guī)格說明，查找內(nèi)容或解釋上的錯誤，以及可能需要進(jìn)一步解釋澄清的地方、丟失的信息、不一致性、沖突的需求或是不可實(shí)現(xiàn)的需求。需求確認(rèn)檢查表11/28/202215確認(rèn)11/27/202215需求管理tortoiseSVN11/28/202216需求管理tortoiseSVN11/27/2022164.2建立根基理想情況是：利益相關(guān)者和軟件工程師在同一個小組工作?，F(xiàn)實(shí)情況：往往很難做到。啟動需求工程所必需的步驟1.確認(rèn)利益相關(guān)者2.識別多重觀點(diǎn)3.協(xié)同合作4.首次提問11/28/2022174.2建立根基理想情況是：利益相關(guān)者和軟件工程師在同一個小4.2.1確認(rèn)利益相關(guān)者利益相關(guān)者：直接或間接地從正在開發(fā)的系統(tǒng)中獲益的人。在開始階段，需求工程師應(yīng)該創(chuàng)建一個人員列表，列出哪些有助于誘導(dǎo)出需求的人員。最初的人員列表將隨著接觸的利益相關(guān)者人數(shù)的增多而增加，因?yàn)槊總€利益相關(guān)者都將被詢問“你認(rèn)為我還應(yīng)該和誰交流”。11/28/2022184.2.1確認(rèn)利益相關(guān)者11/27/2022184.2.2識別多重觀點(diǎn)把三個利益相關(guān)者請進(jìn)一個房間，然后問他們想要什么樣的系統(tǒng)，你很有可能會得到四個或更多的不同觀點(diǎn)——作者不詳需求工程師的工作就是把所有的利益相關(guān)者和提供的信息（包括不一致或是矛盾的需求）分類，分類的方法應(yīng)該便于決策制定者為系統(tǒng)選擇一個內(nèi)部一致的需求集合。11/28/2022194.2.2識別多重觀點(diǎn)11/27/2022194.2.3協(xié)同合作需求工程師的工作是標(biāo)識公共區(qū)域（即所有利益相關(guān)者都同意的需求）和矛盾區(qū)域或不一致區(qū)域（即某個利益相關(guān)者提出的需求和其他利益相關(guān)者的需求相矛盾）。很明顯，后者更具有挑戰(zhàn)性。協(xié)作并不意味著必須由委員會定義需求。在很多情況下，利益相關(guān)者的協(xié)作是提供他們各自關(guān)于需求的觀點(diǎn)，而一個強(qiáng)有力的“項(xiàng)目領(lǐng)導(dǎo)者”（例如業(yè)務(wù)經(jīng)理或高級技術(shù)員）可能要對刪減哪些需求做出最終決策。11/28/2022204.2.3協(xié)同合作11/27/2022204.2.4首次提問問問題的人是五分鐘的傻瓜，而不問問題的人將永遠(yuǎn)是傻瓜。——中國諺語什么問題有助于你獲得對問題的初步認(rèn)識？在需求導(dǎo)出時的提問應(yīng)該是“與環(huán)境無關(guān)的”。第一組與環(huán)境無關(guān)的問題集中于客戶和其他利益相關(guān)者、整體目標(biāo)、收益。下一組問題有助于軟件開發(fā)組更好的理解問題，并允許客戶表達(dá)其對解決方案的看法最后一組問題關(guān)注與溝通活動本身的效率。11/28/2022214.2.4首次提問11/27/2022214.3導(dǎo)出需求導(dǎo)出需求（又稱為需求收集）是與問題求解、精化、談判和規(guī)格說明等方面的元素結(jié)合在一起的。為了鼓勵合作，一個包括利益相關(guān)者和開發(fā)人員的團(tuán)隊(duì)共同完成如下任務(wù)：確認(rèn)問題，為解決方案的要素提供建議，商討不同的方法并描述初步的需求解決方案。1.協(xié)作收集需求2.質(zhì)量功能部署3.用戶場景4.導(dǎo)出工作產(chǎn)品11/28/2022224.3導(dǎo)出需求導(dǎo)出需求（又稱為需求收集）是與問題求解、精化4.3.1協(xié)作收集需求主持一個協(xié)作需求收集會議的基本原則是什么？會議由軟件工程師和其他的利益相關(guān)者共同舉辦和參與。制定籌備和參與會議的規(guī)則。建議擬定一個會議議程，這個議程既要足夠正式，使其涵蓋所有的重點(diǎn)；但也不能太正式，以鼓勵思想的自由交流。由一個“調(diào)解人”（可以是客戶、開發(fā)人員或其他人）控制會議。采用“方案論證手段”（可以是工作表、活動掛圖、不干膠貼紙或電子公告牌、聊天室或虛擬論壇）。目的：識別問題，提出解決方案的要素，協(xié)商不同的方法以及在有利于完成目標(biāo)的氛圍中確定一套解決需求問題的初步方案。11/28/2022234.3.1協(xié)作收集需求11/27/2022234.3.2質(zhì)量功能部署（QualityFunctionDeployment，QFD）一種將客戶要求轉(zhuǎn)為成軟件技術(shù)需求的質(zhì)量管理技術(shù)，目的是最大限度的讓客戶從軟件工程過程中感到滿意。為了達(dá)到這個目標(biāo)，QFD強(qiáng)調(diào)理解“什么是對客戶有價值的”，然后在整個工程活動中部署這些價值。QFD確認(rèn)了三類需求：正常需求：特定的系統(tǒng)功能期望需求：人機(jī)交互的容易性，軟件安裝的簡易性令人興奮的需求：多重觸控技術(shù)的觸摸屏11/28/2022244.3.2質(zhì)量功能部署（QualityFunction4.3.3用戶場景當(dāng)收集需求時，系統(tǒng)功能和特性的整體愿景開始具體化。但是在軟件團(tuán)隊(duì)弄清楚不同類型的最終用戶如何使用這些功能和特性之前，很難轉(zhuǎn)移到更技術(shù)化的軟件工程活動。為實(shí)現(xiàn)著一點(diǎn)，開發(fā)人員和用戶可以創(chuàng)建一系列的場景（場景可以識別對將要構(gòu)建系統(tǒng)的使用線索）。場景通常稱為用例，它提供了將如何使用系統(tǒng)的描述。11/28/2022254.3.3用戶場景11/27/2022254.3.4導(dǎo)出工作產(chǎn)品什么樣的信息是需求收集產(chǎn)生的？要求和可行性陳述系統(tǒng)或產(chǎn)品范圍的界限說明參與需求導(dǎo)出的客戶、用戶和其他利益相關(guān)者的名單系統(tǒng)技術(shù)環(huán)境的說明需求列表（最好按照功能加以組織）以及每個需求適用的領(lǐng)域限制。一系列使用場景，有助于深入了解系統(tǒng)或產(chǎn)品在不同運(yùn)行環(huán)境下的使用。任何能夠更好的定義需求的原型所有參與需求導(dǎo)出的人員需要評審以上的每一個工作產(chǎn)品。11/28/2022264.3.4導(dǎo)出工作產(chǎn)品11/27/2022264.4開發(fā)用例從參與者的角度定義用例。參與者是人員（用戶）胡設(shè)備在和軟件交互時所扮演的較色。參與者和最終用戶并非一回事。典型的用戶可能在使用系統(tǒng)時扮演了許多不同的較色，而參與者表示了一類外部實(shí)體，在用例中他們僅扮演一種較色。主要參與者和次要參與者開發(fā)用例11/28/2022274.4開發(fā)用例從參與者的角度定義用例。參與者是人員（用戶）4.5構(gòu)建需求模型4.5.1需求模型的元素基于場景的元素功能說明——處理軟件功能的描述用例——描述“參與者”和系統(tǒng)之間的交互作用基于類的元素由場景暗示行為元素狀態(tài)圖面向數(shù)據(jù)流元素數(shù)據(jù)流圖11/28/2022284.5構(gòu)建需求模型4.5.1需求模型的元素11/27/2一組用戶場景，描述系統(tǒng)的線程使用從“參與者”的點(diǎn)-視角來描述每一個場景——人或設(shè)備以某種方式與軟件交互每一個場景回答以下問題：誰是主要參與者、次要參與者？參與者的目標(biāo)是什么？故事開始前有什么前提條件？參與者完成的主要工作或功能是什么？按照故事所描述的還可能需要考慮什么異常？參與者的交互中有什么可能的變化？參與者將獲得、產(chǎn)生或改變哪些系統(tǒng)信息？參與者必須通知系統(tǒng)有關(guān)外部環(huán)境的改變嗎？參與者希望從系統(tǒng)獲取什么信息？11/28/202229一組用戶場景，描述系統(tǒng)的線程使用11/27/20222930用例圖房主安裝/接觸系統(tǒng)通過因特網(wǎng)訪問系統(tǒng)報警事件的響應(yīng)遇到錯誤條件重新配置傳感器以及相關(guān)的系統(tǒng)特性傳感器系統(tǒng)管理員11/28/20223030用例圖房主安裝/接觸系統(tǒng)通過因特網(wǎng)訪問系統(tǒng)報警事件的響應(yīng)31類圖從SafeHome系統(tǒng)…傳感器11/28/20223131類圖從SafeHome系統(tǒng)…傳感器11/27/202232狀態(tài)圖ReadingCommandsSystemstatus=“ready”Displaymsg=“entercmd”Displaystatus=steadyEntry/subsystemsreadyDo:polluserinputpanelDo:readuserinputDo:interpretuserinputStatenameStatevariablesStateactivities狀態(tài)名狀態(tài)變量狀態(tài)活動讀指令11/28/20223232狀態(tài)圖ReadingSystemstatus=“33分析模式模式名稱：

捕獲模式本質(zhì)的描述符。目的：描述該模式實(shí)現(xiàn)了或代表什么。動機(jī)：說明怎樣用模式解決問題的一個場景。影響環(huán)境：對外部問題（影響）的描述，即能夠影響如何使用模式，并當(dāng)應(yīng)用該模式時，影響即將被解決的外部問題。解決方案：對如何應(yīng)用模式來解決強(qiáng)調(diào)結(jié)構(gòu)和行為問題的描述。效果：解決了發(fā)生在應(yīng)用模式時和應(yīng)用過程中存在權(quán)衡的問題。設(shè)計：通過使用已知的設(shè)計模式討論如何實(shí)現(xiàn)該分析模式。已知應(yīng)用:在實(shí)際系統(tǒng)中使用的例子。相關(guān)模式：與命名模式有關(guān)的一個或更多分析模式，因?yàn)?1)與命名模式共同使用；(2)在結(jié)構(gòu)上，與命名模式相似；(3)是命名模式的一個變化。11/28/20223333分析模式模式名稱：捕獲模式本質(zhì)的描述符。11/27/344.6協(xié)商需求確定關(guān)鍵的利益相關(guān)者是即將參與協(xié)商的人確定每個利益相關(guān)者“贏”的條件贏的條件并不總是顯而易見的協(xié)商致力于導(dǎo)致“雙贏”的一組需求11/28/202234344.6協(xié)商需求確定關(guān)鍵的利益相關(guān)者11/27/2022354.7確認(rèn)需求-I每項(xiàng)需求都和系統(tǒng)或產(chǎn)品的整體目標(biāo)一致嗎？所有的需求都已經(jīng)在相應(yīng)的抽象層上說明了嗎？換句話說，是否有一些需求是在技術(shù)細(xì)節(jié)過多的層次上提出的，并不適合當(dāng)前的階段。需求是真正必須的，還是另外加上去的，有可能不是系統(tǒng)目標(biāo)所必須的特性嗎？每項(xiàng)需求都有界定且無歧義嗎？每項(xiàng)需求都有歸屬權(quán)嗎？換句話說，是否每個需求都標(biāo)記了來源（通常是一個明確的人）？有需求和其他需求相沖突嗎？11/28/202235354.7確認(rèn)需求-I每項(xiàng)需求都和系統(tǒng)或產(chǎn)品的整體目標(biāo)一36確認(rèn)需求-II在系統(tǒng)或產(chǎn)品所處的技術(shù)環(huán)境下每個需求都能夠?qū)崿F(xiàn)嗎？一旦實(shí)現(xiàn)后，每項(xiàng)需求是可測試的嗎？需求模型恰當(dāng)反應(yīng)了將要構(gòu)建系統(tǒng)的信息、功能和行為嗎？需求模型是否已經(jīng)使用合適的方式“分割”，能夠逐步地揭示詳細(xì)的系統(tǒng)信息嗎？已經(jīng)使用了需求模型簡化需求模型嗎？所有的模型都已經(jīng)被恰當(dāng)?shù)卮_認(rèn)了嗎？所有的模式都和客戶的需求一致嗎？

11/28/20223636確認(rèn)需求-II在系統(tǒng)或產(chǎn)品所處的技術(shù)環(huán)境下每個需求都能小結(jié)需求工程的任務(wù)是為設(shè)計和構(gòu)建活動建立一個可靠堅(jiān)固的基礎(chǔ)。需求工程發(fā)生在與客戶溝通活動和為一般的軟件過程定義的建?；顒舆^程中。軟件團(tuán)隊(duì)成員要實(shí)施7個不同的需求工程只能：起始、導(dǎo)出、精化、協(xié)商、規(guī)格說明、確認(rèn)和管理。在項(xiàng)目起始階段，項(xiàng)目利益相關(guān)者建立基本的問題需求，定義最重要的項(xiàng)目約束以及陳述主要的特征和功能，必須讓系統(tǒng)表現(xiàn)出這些特征和功能以滿足目標(biāo)。在此階段中利用有主持人的會議、QFD和使用場景的開發(fā)進(jìn)行需求的收集活動。11/28/202237小結(jié)需求工程的任務(wù)是為設(shè)計和構(gòu)建活動建立一個可靠堅(jiān)固的基礎(chǔ)。第二部分建模

11/28/202238第二部分建模

11/27/20221模型模型:對問題的書面上的無歧義文字或圖形的描述.簡言之,模型是對現(xiàn)實(shí)的簡化.通過模型,人們可以了解所研究事物的本質(zhì).最杰出的模型:地圖11/28/202239模型模型:對問題的書面上的無歧義文字或圖形的描述.簡言之,建模建模:對現(xiàn)實(shí)系統(tǒng)進(jìn)行適當(dāng)?shù)倪^濾,用適當(dāng)?shù)谋憩F(xiàn)規(guī)則描述出簡潔的模型.建模是一種深入解決問題的方法.建模的原則(1).選擇建立什么樣的模型對如何發(fā)現(xiàn)和解決問題具有重要的影響。正確的模型有助于提高開發(fā)者的洞察力。(2).每個模型可以有多種表達(dá)方式.使用者的身份和使用的原因是評判模型好壞的關(guān)鍵。11/28/202240建模11/27/20223(3).最好的模型總是能夠切合實(shí)際.模型是現(xiàn)實(shí)的簡化，必須保證簡化過程不會掩蓋任何重要的細(xì)節(jié)。(4).孤立的模型是不完整的。11/28/202241(3).最好的模型總是能夠切合實(shí)際.模型是現(xiàn)實(shí)的簡化，必軟件建模的實(shí)現(xiàn)過程軟件建模的作用是把來源于現(xiàn)實(shí)世界的問題轉(zhuǎn)化為計算機(jī)可以理解和實(shí)現(xiàn)的問題.軟件建模的實(shí)現(xiàn)過程是從需求入手,用模型表達(dá)分析設(shè)計過程,最終將模型映射成軟件實(shí)現(xiàn).現(xiàn)實(shí)世界計算機(jī)世界映射需求模型編碼11/28/202242軟件建模的實(shí)現(xiàn)過程軟件建模的作用是把來源于現(xiàn)實(shí)世界的問題轉(zhuǎn)化第四章理解需求11/28/202243第四章理解需求11/27/20226最恐怖的噩夢：一個客戶走進(jìn)你的辦公室，坐下，正視著你，然后說：“我知道你認(rèn)為我說的是什么，但你并不理解的是：我所說的并不是我想要的?！?1/28/202244最恐怖的噩夢：11/27/202274.1需求工程構(gòu)建一個軟件系統(tǒng)最困難的部分是確定構(gòu)建什么。其他部分工作不會像這部分工作一樣，在出錯之后會如此嚴(yán)重地影響隨后實(shí)現(xiàn)的系統(tǒng)，并且以后修補(bǔ)竟會如此的困難。——FredBrooks一些常見的現(xiàn)象需求工程（RequirementEngineering,RE）是指致力于不斷理解需求的大量任務(wù)和技術(shù)。從軟件過程的角度來看，需求工程是一個軟件工程動作，開始于溝通活動并持續(xù)到建模活動。他必須適應(yīng)于過程、項(xiàng)目、產(chǎn)品和人員工作的需要。11/28/2022454.1需求工程構(gòu)建一個軟件系統(tǒng)最困難的部分是確定構(gòu)建什么。需求工程為設(shè)計和構(gòu)造奠定了堅(jiān)實(shí)的基礎(chǔ)。如果沒有需求工程，那么實(shí)現(xiàn)的軟件很有可能無法滿足客戶的需求。需求工程過程通過執(zhí)行七個不同的活動來實(shí)現(xiàn)：起始、導(dǎo)出、精化、協(xié)商、規(guī)格說明、確認(rèn)和管理。11/28/202246需求工程為設(shè)計和構(gòu)造奠定了堅(jiān)實(shí)的基礎(chǔ)。如果沒有需求工程，那么起始建立基本的理解，包括對問題、誰需要解決方案、所期望解決方案的性質(zhì)、與項(xiàng)目利益相關(guān)者和開發(fā)人員之間達(dá)成初步交流合作的效果。11/28/202247起始11/27/202210導(dǎo)出詢問客戶、用戶和其他人，系統(tǒng)或產(chǎn)品的目標(biāo)是什么，想要實(shí)現(xiàn)什么，系統(tǒng)和產(chǎn)品如何滿足業(yè)務(wù)的要求，最終系統(tǒng)或產(chǎn)品如何用于日常工作，這些問題是非常簡單的。但是，實(shí)際上并非如此簡單“——這非常困難。為什么導(dǎo)出需求這么困難？范圍問題理解問題易變問題11/28/202248導(dǎo)出11/27/202211精化精化是由一系列的用戶場景建模和求精任務(wù)驅(qū)動的。這些用戶場景描述了如何讓最終用戶和其他參與者與系統(tǒng)進(jìn)行交互。解析每個用戶場景以便提取分析類——最終用戶可見的業(yè)務(wù)域?qū)嶓w。應(yīng)該定義每個分析類的屬性，確定每個類所需要的服務(wù)，確定類之間的關(guān)聯(lián)和協(xié)作關(guān)系，并完成各種補(bǔ)充圖。精化是件好事，但你必須知道何時可以停止精化。關(guān)鍵是能采用為設(shè)計監(jiān)理一個堅(jiān)實(shí)基礎(chǔ)的方式說明問題。如果超出這個點(diǎn)就是在做設(shè)計。11/28/202249精化11/27/202212協(xié)商需求工程師必須通過協(xié)商過程來調(diào)解沖突。應(yīng)該讓客戶、用戶和其他利益相關(guān)者對各自的需求排序，然后按優(yōu)先級討論沖突。使用迭代的方法給需求排序，評估每項(xiàng)需求對項(xiàng)目產(chǎn)生的成本和風(fēng)險，表述內(nèi)部沖突，刪除、組合和（或）修改需求，以便參與各方均能達(dá)到一定的滿意度。在有效的協(xié)商中沒有贏家也沒有輸家，而是雙贏。這是因?yàn)殡p方合作才是“交易”的堅(jiān)實(shí)基礎(chǔ)。11/28/202250協(xié)商11/27/202213規(guī)格說明規(guī)格說明的形式和格式隨著待開發(fā)軟件的規(guī)模和復(fù)雜度的不同而變化。一個規(guī)格說明可以是一份寫好的文檔、一套圖形化的模型。一個形式化的數(shù)學(xué)模型、一組使用場景、一個原型或上述各項(xiàng)的任意組合。例：湖南省輕工鹽業(yè)集團(tuán)人力資源系統(tǒng)需求分析說明書11/28/202251規(guī)格說明11/27/202214確認(rèn)在確認(rèn)這一步將對需求工程的工作產(chǎn)品進(jìn)行質(zhì)量評估。需求確認(rèn)要檢查規(guī)格說明以保證：已無歧義的說明了所有的系統(tǒng)需求；已檢測出不一致性、疏忽和錯誤并得到糾正；工作產(chǎn)品符合為過程、項(xiàng)目和產(chǎn)品建立的標(biāo)準(zhǔn)。正式的技術(shù)評審時最主要的需求確認(rèn)機(jī)制。確認(rèn)需求的評審小組包括軟件工程師、客戶、用戶和其他利益相關(guān)者，他們檢查系統(tǒng)規(guī)格說明，查找內(nèi)容或解釋上的錯誤，以及可能需要進(jìn)一步解釋澄清的地方、丟失的信息、不一致性、沖突的需求或是不可實(shí)現(xiàn)的需求。需求確認(rèn)檢查表11/28/202252確認(rèn)11/27/202215需求管理tortoiseSVN11/28/202253需求管理tortoiseSVN11/27/2022164.2建立根基理想情況是：利益相關(guān)者和軟件工程師在同一個小組工作?，F(xiàn)實(shí)情況：往往很難做到。啟動需求工程所必需的步驟1.確認(rèn)利益相關(guān)者2.識別多重觀點(diǎn)3.協(xié)同合作4.首次提問11/28/2022544.2建立根基理想情況是：利益相關(guān)者和軟件工程師在同一個小4.2.1確認(rèn)利益相關(guān)者利益相關(guān)者：直接或間接地從正在開發(fā)的系統(tǒng)中獲益的人。在開始階段，需求工程師應(yīng)該創(chuàng)建一個人員列表，列出哪些有助于誘導(dǎo)出需求的人員。最初的人員列表將隨著接觸的利益相關(guān)者人數(shù)的增多而增加，因?yàn)槊總€利益相關(guān)者都將被詢問“你認(rèn)為我還應(yīng)該和誰交流”。11/28/2022554.2.1確認(rèn)利益相關(guān)者11/27/2022184.2.2識別多重觀點(diǎn)把三個利益相關(guān)者請進(jìn)一個房間，然后問他們想要什么樣的系統(tǒng)，你很有可能會得到四個或更多的不同觀點(diǎn)——作者不詳需求工程師的工作就是把所有的利益相關(guān)者和提供的信息（包括不一致或是矛盾的需求）分類，分類的方法應(yīng)該便于決策制定者為系統(tǒng)選擇一個內(nèi)部一致的需求集合。11/28/2022564.2.2識別多重觀點(diǎn)11/27/2022194.2.3協(xié)同合作需求工程師的工作是標(biāo)識公共區(qū)域（即所有利益相關(guān)者都同意的需求）和矛盾區(qū)域或不一致區(qū)域（即某個利益相關(guān)者提出的需求和其他利益相關(guān)者的需求相矛盾）。很明顯，后者更具有挑戰(zhàn)性。協(xié)作并不意味著必須由委員會定義需求。在很多情況下，利益相關(guān)者的協(xié)作是提供他們各自關(guān)于需求的觀點(diǎn)，而一個強(qiáng)有力的“項(xiàng)目領(lǐng)導(dǎo)者”（例如業(yè)務(wù)經(jīng)理或高級技術(shù)員）可能要對刪減哪些需求做出最終決策。11/28/2022574.2.3協(xié)同合作11/27/2022204.2.4首次提問問問題的人是五分鐘的傻瓜，而不問問題的人將永遠(yuǎn)是傻瓜?！袊V語什么問題有助于你獲得對問題的初步認(rèn)識？在需求導(dǎo)出時的提問應(yīng)該是“與環(huán)境無關(guān)的”。第一組與環(huán)境無關(guān)的問題集中于客戶和其他利益相關(guān)者、整體目標(biāo)、收益。下一組問題有助于軟件開發(fā)組更好的理解問題，并允許客戶表達(dá)其對解決方案的看法最后一組問題關(guān)注與溝通活動本身的效率。11/28/2022584.2.4首次提問11/27/2022214.3導(dǎo)出需求導(dǎo)出需求（又稱為需求收集）是與問題求解、精化、談判和規(guī)格說明等方面的元素結(jié)合在一起的。為了鼓勵合作，一個包括利益相關(guān)者和開發(fā)人員的團(tuán)隊(duì)共同完成如下任務(wù)：確認(rèn)問題，為解決方案的要素提供建議，商討不同的方法并描述初步的需求解決方案。1.協(xié)作收集需求2.質(zhì)量功能部署3.用戶場景4.導(dǎo)出工作產(chǎn)品11/28/2022594.3導(dǎo)出需求導(dǎo)出需求（又稱為需求收集）是與問題求解、精化4.3.1協(xié)作收集需求主持一個協(xié)作需求收集會議的基本原則是什么？會議由軟件工程師和其他的利益相關(guān)者共同舉辦和參與。制定籌備和參與會議的規(guī)則。建議擬定一個會議議程，這個議程既要足夠正式，使其涵蓋所有的重點(diǎn)；但也不能太正式，以鼓勵思想的自由交流。由一個“調(diào)解人”（可以是客戶、開發(fā)人員或其他人）控制會議。采用“方案論證手段”（可以是工作表、活動掛圖、不干膠貼紙或電子公告牌、聊天室或虛擬論壇）。目的：識別問題，提出解決方案的要素，協(xié)商不同的方法以及在有利于完成目標(biāo)的氛圍中確定一套解決需求問題的初步方案。11/28/2022604.3.1協(xié)作收集需求11/27/2022234.3.2質(zhì)量功能部署（QualityFunctionDeployment，QFD）一種將客戶要求轉(zhuǎn)為成軟件技術(shù)需求的質(zhì)量管理技術(shù)，目的是最大限度的讓客戶從軟件工程過程中感到滿意。為了達(dá)到這個目標(biāo)，QFD強(qiáng)調(diào)理解“什么是對客戶有價值的”，然后在整個工程活動中部署這些價值。QFD確認(rèn)了三類需求：正常需求：特定的系統(tǒng)功能期望需求：人機(jī)交互的容易性，軟件安裝的簡易性令人興奮的需求：多重觸控技術(shù)的觸摸屏11/28/2022614.3.2質(zhì)量功能部署（QualityFunction4.3.3用戶場景當(dāng)收集需求時，系統(tǒng)功能和特性的整體愿景開始具體化。但是在軟件團(tuán)隊(duì)弄清楚不同類型的最終用戶如何使用這些功能和特性之前，很難轉(zhuǎn)移到更技術(shù)化的軟件工程活動。為實(shí)現(xiàn)著一點(diǎn)，開發(fā)人員和用戶可以創(chuàng)建一系列的場景（場景可以識別對將要構(gòu)建系統(tǒng)的使用線索）。場景通常稱為用例，它提供了將如何使用系統(tǒng)的描述。11/28/2022624.3.3用戶場景11/27/2022254.3.4導(dǎo)出工作產(chǎn)品什么樣的信息是需求收集產(chǎn)生的？要求和可行性陳述系統(tǒng)或產(chǎn)品范圍的界限說明參與需求導(dǎo)出的客戶、用戶和其他利益相關(guān)者的名單系統(tǒng)技術(shù)環(huán)境的說明需求列表（最好按照功能加以組織）以及每個需求適用的領(lǐng)域限制。一系列使用場景，有助于深入了解系統(tǒng)或產(chǎn)品在不同運(yùn)行環(huán)境下的使用。任何能夠更好的定義需求的原型所有參與需求導(dǎo)出的人員需要評審以上的每一個工作產(chǎn)品。11/28/2022634.3.4導(dǎo)出工作產(chǎn)品11/27/2022264.4開發(fā)用例從參與者的角度定義用例。參與者是人員（用戶）胡設(shè)備在和軟件交互時所扮演的較色。參與者和最終用戶并非一回事。典型的用戶可能在使用系統(tǒng)時扮演了許多不同的較色，而參與者表示了一類外部實(shí)體，在用例中他們僅扮演一種較色。主要參與者和次要參與者開發(fā)用例11/28/2022644.4開發(fā)用例從參與者的角度定義用例。參與者是人員（用戶）4.5構(gòu)建需求模型4.5.1需求模型的元素基于場景的元素功能說明——處理軟件功能的描述用例——描述“參與者”和系統(tǒng)之間的交互作用基于類的元素由場景暗示行為元素狀態(tài)圖面向數(shù)據(jù)流元素數(shù)據(jù)流圖11/28/2022654.5構(gòu)建需求模型4.5.1需求模型的元素11/27/2一組用戶場景，描述系統(tǒng)的線程使用從“參與者”的點(diǎn)-視角來描述每一個場景——人或設(shè)備以某種方式與軟件交互每一個場景回答以下問題：誰是主要參與者、次要參與者？參與者的目標(biāo)是什么？故事開始前有什么前提條件？參與者完成的主要工作或功能是什么？按照故事所描述的還可能需要考慮什么異常？參與者的交互中有什么可能的變化？參與者將獲得、產(chǎn)生或改變哪些系統(tǒng)信息？參與者必須通知系統(tǒng)有關(guān)外部環(huán)境的改變嗎？參與者希望從系統(tǒng)獲取什么信息？11/28/202266一組用戶場景，描述系統(tǒng)的線程使用11/27/20222967用例圖房主安裝/接觸系統(tǒng)通過因特網(wǎng)訪問系統(tǒng)報警事件的響應(yīng)遇到錯誤條件重新配置傳感器以及相關(guān)的系統(tǒng)特性傳感器系統(tǒng)管理員11/28/20226730用例圖房主安裝/接觸系統(tǒng)通過因特網(wǎng)訪問系統(tǒng)報警事件的響應(yīng)68類圖從SafeHome系統(tǒng)…傳感器11/28/20226831類圖從SafeHome系統(tǒng)…傳感器11/27/202269狀態(tài)圖ReadingCommandsSystemstatus=“ready”Displaymsg=“entercmd”Displaystatus=steadyEntry/subsystemsreadyDo:polluserinputpanelDo