軟件工程實踐者的研究方法義PPT課件

1、第4章 理解需求第1頁/共71頁主要內(nèi)容v需求工程v建立根基v導(dǎo)出需求v開發(fā)用例v構(gòu)建需求模型v協(xié)商需求v確認(rèn)需求v小結(jié)第2頁/共71頁需求工程v需求工程幫助軟件工程師更好地理解他們將要解決的問題。其中所包含的一系列任務(wù)有助于理解軟件將如何影響業(yè)務(wù)、客戶想要什么以及最終用戶將如何和軟件交互。v軟件工程師和項目共利益者都將參與需求工程。第3頁/共71頁需求工程v在設(shè)計和開發(fā)某個一流的計算機軟件時，如果軟件解決的問題不對，那么即使軟件再精巧也滿足不了任何人的要求。這就是在設(shè)計和開發(fā)一個基于計算機的系統(tǒng)之前，理解客戶需求的重要性。第4頁/共71頁需求工程v理解問題的需求是軟件工程師所面對的最困難的任

2、務(wù)之一。v客戶難道不知道需要什么？v最終用戶難道對給他們帶來實際收益的特征和功能沒有清楚的認(rèn)識？v很多情況下的確是這樣的。甚至即使用戶和最終用戶清楚地知道他們的要求，這些要求也會在項目的實施過程中改變。第5頁/共71頁需求工程v需求工程是指致力于不斷理解需求的大量任務(wù)和技術(shù)。從軟件過程的角度來看，需求工程是一個軟件工程動作，開始于溝通并持續(xù)至建模。v需求工程在設(shè)計和構(gòu)造之間建立起聯(lián)系的橋梁。有人認(rèn)為開始于項目共利益者，即在那里定義業(yè)務(wù)需求，刻畫用戶場景，描述功能和特性，識別項目約束條件。另外一些人可能會建議從寬泛的系統(tǒng)定義開始，此時軟件只是更大的系統(tǒng)范圍中的一個構(gòu)件。但是不管起始點在哪里，橫跨

3、這個橋梁將把我們帶到項目之上更高的層次：由軟件團隊檢查將要進行的軟件工作的內(nèi)容，必須提交設(shè)計和構(gòu)建需要的特定要求，完成指導(dǎo)工作順序的優(yōu)先級定義以及將深切影響隨后設(shè)計的信息、功能和行為。第6頁/共71頁需求工程任務(wù)v需求工程為以下工作提供了良好的機制：理解客戶需要什么，分析要求，評估可行性，協(xié)商合理的方案，無歧義地詳細說明方案，確認(rèn)規(guī)格說明，管理需求以至將這些需求轉(zhuǎn)化為可運行系統(tǒng)。需求工程過程通過執(zhí)行七個不同的活動來完成：起始、導(dǎo)出、精化、協(xié)商、規(guī)格說明、確認(rèn)和管理。第7頁/共71頁起始v通常都是當(dāng)確定了商業(yè)要求或發(fā)現(xiàn)了潛在的新市場、新服務(wù)時項目才開始。業(yè)務(wù)領(lǐng)域的共利益者定義業(yè)務(wù)用例，確定市場的

4、寬度和深度，進行粗略的可行性分析，并確定項目范圍的工作說明。v在項目起始階段，軟件工程師會詢問一些似乎與項目無直接關(guān)系的問題。目的是對問題、方案需求方、期望方案的本質(zhì)、客戶和開發(fā)人員之間初步的交流和合作的效果建立基本的諒解。第8頁/共71頁導(dǎo)出v系統(tǒng)或產(chǎn)品的目標(biāo)是什么？v想要實現(xiàn)什么？v系統(tǒng)和產(chǎn)品如何滿足業(yè)務(wù)的要求，最終系統(tǒng)或產(chǎn)品如何用于日常工作？v而實際上導(dǎo)出需求卻是異常的困難。第9頁/共71頁導(dǎo)出v范圍問題：系統(tǒng)的邊界不清楚，或客戶/用戶的說明帶有多余的技術(shù)細節(jié)，這些細節(jié)可能會混淆而不是澄清系統(tǒng)的整體目標(biāo)。v理解問題：客戶/用戶并不完全確定需要什么，對其計算環(huán)境的能力和限制所知甚少，對問題

5、域沒有完整的認(rèn)識，與系統(tǒng)工程師在溝通上有問題，省略那些他們認(rèn)為是“明顯的”信息，確定的需求和其他客戶/用戶的需求相沖突，需求說明有歧義或不可測試。v易變問題：需求隨時間變化。第10頁/共71頁精化v精化是一個分析建模動作，由一系列的建模和求精任務(wù)構(gòu)成。當(dāng)描述最終用戶如何與系統(tǒng)交互的用戶場景創(chuàng)建和求精時，就會發(fā)生精化動作，每個用戶場景被分解為精煉分析類最終用戶可見的業(yè)務(wù)域?qū)嶓w。應(yīng)該定義每個分析類的屬性，確定每個類所需要的服務(wù)，確定類之間的關(guān)聯(lián)和協(xié)作關(guān)系，并完成各種UML圖作為補充。v精化的最終結(jié)果是形成一個精確的需求模型，用以說明軟件的功能、特征和信息的各個方面。 第11頁/共71頁協(xié)商v需求工

6、程師必須通過協(xié)商過程來調(diào)解客戶提出的過高的目標(biāo)要求和相互沖突的需求。應(yīng)該讓客戶、用戶和其他共利益者對各自的需求排序，然后按優(yōu)先級討論沖突。識別和分析與每項需求相關(guān)聯(lián)的風(fēng)險；粗略“估算”開發(fā)工作量，并用于評估需求對項目成本和交付時間的影響；使用迭代的方法、刪除、組合或修改需求，以便相關(guān)各方均能達到一定的滿意度。第12頁/共71頁規(guī)格說明v一個規(guī)格說明可以是一份寫好的文檔、一套圖形化的模型、一個形式化的數(shù)學(xué)模型，一組使用場景、一個原型或上述各項的任意組合。v在開發(fā)規(guī)格說明時保持靈活性有時是必要的，對大型系統(tǒng)而言，文檔最好采用自然語言描述和圖形化模型來編寫。而對于技術(shù)環(huán)節(jié)明確的較小產(chǎn)品或系統(tǒng)，使用場

7、景可能就足夠了。第13頁/共71頁確認(rèn)v確認(rèn)將對需求工程的工作產(chǎn)品進行質(zhì)量評估。需求確認(rèn)要檢查規(guī)格說明以保證：所有的系統(tǒng)需求已被無歧義地說明；不一致性、疏漏和錯誤已被檢測出并被糾正；工作產(chǎn)品符合為過程、項目和產(chǎn)品建立的標(biāo)準(zhǔn)。v正式技術(shù)評審是最主要的需求確認(rèn)機制。確認(rèn)需求的評審小組包括軟件工程師、客戶、用戶和其他共利益者，他們檢查系統(tǒng)規(guī)格說明，查找內(nèi)容或解釋上的錯誤，以及可能需要進一步解釋澄清的地方、丟失的信息、不一致性、沖突的需求或不現(xiàn)實的需求。第14頁/共71頁需求確認(rèn)檢查表v需求說明清晰嗎？有沒有可能造成誤解？v需求的來源（如人員、規(guī)則、文檔）弄清了嗎？需求的最終說明是否已經(jīng)根據(jù)或?qū)φ兆畛?/p>

8、來源檢查過？v需求是否用定量的術(shù)語界定？v其他哪些需求與此需求相關(guān)？是否已經(jīng)使用交叉索引或其他機制清楚地加以說明了？v需求是否違背某個系統(tǒng)領(lǐng)域的約束？v需求是否可以測試？如果可以，能否說明測試檢驗了需求？v對已經(jīng)創(chuàng)建的任何系統(tǒng)模型，需求是否可跟蹤？v對整體系統(tǒng)/產(chǎn)品目標(biāo)，需求是否可跟蹤？v規(guī)格說明的構(gòu)造方式是否有助于理解、引用和翻譯成更技術(shù)性的工作產(chǎn)品？v對已創(chuàng)建的規(guī)格說明是否建立了索引？v和系統(tǒng)性能、行為及運行特征相關(guān)的需求的說明是否清楚？哪些需求是隱含出現(xiàn)的？第15頁/共71頁需求管理v基于計算機的系統(tǒng)其需求會變更，而且變更的要求貫穿于系統(tǒng)的整個生存期。v需求管理是用于幫助項目組在項目進展

9、中標(biāo)識、控制和跟蹤需求以及變更需求的一組活動。v需求管理從標(biāo)識開始。每個需求被賦予唯一的標(biāo)識符。一旦需求被標(biāo)識，便開始建立跟蹤表，每個跟蹤表將標(biāo)識的需求與系統(tǒng)或其環(huán)境的一個或多個方面相關(guān)聯(lián)。第16頁/共71頁建立根基v在理想情況下，利益相關(guān)者和軟件工程師在同一個小組中工作。在這種情況下，需求工程就只是和組里熟悉的同事進行有意義的交談。但實際情況往往不是這樣。v客戶可能正在不同的城市或國家，對于想要什么可能僅有模糊的想法，對于將要構(gòu)建的系統(tǒng)可能存在不同的意見，技術(shù)知識可能很有限，可能僅有有限的時間與需求工程師溝通。軟件開發(fā)團隊經(jīng)常被迫在這種環(huán)境的限制下工作。第17頁/共71頁確認(rèn)利益相關(guān)者v利益

10、相關(guān)者可定義為“直接或間接從正在開發(fā)的系統(tǒng)中獲益的人”?？梢源_定如下幾個容易理解的利益相關(guān)者：業(yè)務(wù)操作管理人員、產(chǎn)品管理人員、市場營銷人員、內(nèi)部和外部客戶、最終用戶、顧問、產(chǎn)品工程師、軟件工程師、支持和維護工程師以及其他人員。每個共利益者對系統(tǒng)都有不同的考慮，當(dāng)系統(tǒng)成功開發(fā)后所能獲得的利益也不相同，同樣地，當(dāng)系統(tǒng)開發(fā)失敗時所面臨的風(fēng)險也不同。第18頁/共71頁確認(rèn)利益相關(guān)者v在開始階段，需求工程師應(yīng)該創(chuàng)建一個人員列表，列出那些有助于誘導(dǎo)出需求的人員。最初的人員列表將隨著接觸的共利益者人數(shù)增多而增加，因為每個共利益者都將被詢問“你認(rèn)為我還應(yīng)該和誰交談”。第19頁/共71頁識別多種觀點v因為存在很

11、多不同的利益相關(guān)者，所以系統(tǒng)需求調(diào)研也將從很多不同的視角展開。v這些參與者中的每一個人都將為需求工程貢獻信息。當(dāng)從多個角度收集信息時，所形成的需求可能存在不一致性或相互矛盾。需求工程師的工作就是把所有共利益者提供的信息分類，分類的方法應(yīng)該便于決策制定者為系統(tǒng)選擇一個內(nèi)部一致的需求集合。第20頁/共71頁協(xié)同合作v需求工程師的工作是標(biāo)識公共區(qū)域（即所有共利益者都同意的需求）和矛盾區(qū)域或不一致區(qū)域（即某個共利益者提出的需求和其他共利益者的需求相矛盾）。v很多情況下，共利益者的協(xié)作是提供他們各自關(guān)于需求的觀點，而一個有力的“項目領(lǐng)導(dǎo)者”可能要對刪減哪些需求做出最終判斷。第21頁/共71頁基于“優(yōu)先點

12、”的投票方案v所有的共利益者都會分配到一定數(shù)量的優(yōu)先點，這些優(yōu)先點可以適用于很多需求。每個共利益者在一個需求列表上，通過向每個需求分配一個或多個優(yōu)先點來表明該需求的相對重要性（從他或她的個人觀點）。優(yōu)先點用過之后就不能再次使用，一旦某個共利益者的優(yōu)先點用完，他就不能再對需求實施進一步的操作。所有共利益者在每項需求上的優(yōu)先點總數(shù)顯示了該需求的綜合重要性。第22頁/共71頁首次提問v第一組與環(huán)境無關(guān)的問題集中于客戶和其他共利益者、整體目標(biāo)、收益。v誰是這項工作的最初提出者？v誰將使用該解決方案？v成功的解決方案將帶來什么樣的經(jīng)濟收益？v對于這個解決方案你還需要其他資源嗎？第23頁/共71頁首次提問

13、v下一組問題有助于軟件開發(fā)組更好地理解問題，并允許客戶表達其對解決方案的看法。v如何描述由某成功的解決方案產(chǎn)生的“良好的”輸出？v該解決方案強調(diào)了什么問題？v能向我們展示（或描述）解決方案的使用環(huán)境嗎？v存在影響解決方案的特殊性能問題或約束嗎？第24頁/共71頁首次提問v最后一組問題關(guān)注于溝通活動本身的效率。v你是回答這些問題的合適人選嗎？你的回答是“正式的”嗎？v我的提問和你想解決的問題相關(guān)嗎？v我的問題是否太多了？v還有其他人員可以提供更多的信息嗎？v還有我應(yīng)該問的其他問題嗎？第25頁/共71頁首次提問v這些問題將有助于“打破堅冰”，并有助于交流的開始，而且這樣的交流對需求導(dǎo)出的成功至關(guān)重

14、要。但是，會議形式的問與答并非一定是會取得成功的好方法。事實上，Q&A會議應(yīng)該僅僅用于首次接觸，然后就應(yīng)該用需求誘導(dǎo)形式（包括問題求解、協(xié)商和規(guī)格說明）取代。第26頁/共71頁導(dǎo)出需求v導(dǎo)出需求是與問題求解、精化、談判和規(guī)格說明等方面的元素結(jié)合在一起的。為了鼓勵合作，一個包括利益相關(guān)者和開發(fā)人員的團隊共同完成如下任務(wù)：確認(rèn)問題，為解決方案的要素提供建議，商討不同的方法并描述初步的需求解決方案。第27頁/共71頁協(xié)同需求收集v提出面向團隊的需求收集方法是為了鼓勵合作，即一個包括共利益者和開發(fā)人員的團隊共同完成如下任務(wù)：確認(rèn)問題，為解決方案的要素提供建議，協(xié)商不同的方法，以及說明初步的解決

15、方案需求集合。第28頁/共71頁協(xié)同需求收集會議的基本原則v會議由軟件工程師和其他的利益相關(guān)者共同舉辦和參與。v制定籌備和參與會議的規(guī)則。v建議擬定一個會議議程，這個議程既要足夠正式，使其涵蓋所有的重要點；但也不能太正式，以鼓勵思想的自由交流。v由一個“調(diào)解人”(可以是客戶、開發(fā)人員或其他人)控制會議。v采用“方案論證手段”。v目的是識別問題，提出要解決方案的要素，協(xié)商不同的方法以及在有利于完成目標(biāo)的氛圍中確定一套解決需求問題的初步方案。 第29頁/共71頁協(xié)同需求收集v在需求的起始階段，基本問題和問題的答案確定了問題的范圍和對解決方案的整體理解。除了這些最初的會議之外，共利益者要寫一個12頁

16、的“產(chǎn)品要求”。此外還要選擇會議地點、時間和日期，并選舉“調(diào)解人”。來自開發(fā)組和其他共利益者組織的代表被邀請出席會議，在會議召開之前應(yīng)將產(chǎn)品要求分發(fā)給所有的與會者。第30頁/共71頁SafeHome實例1第31頁/共71頁協(xié)同需求收集v在召開會議評審產(chǎn)品要求的前幾天，要求每個與會者列出構(gòu)成系統(tǒng)周圍環(huán)境的對象、由系統(tǒng)產(chǎn)生的其他對象以及系統(tǒng)用來完成功能的對象。此外，要求每個與會者列出服務(wù)操作或與對象交互的服務(wù)（過程或功能）列表。最后，還要開發(fā)約束列表（如成本、規(guī)模大小、業(yè)務(wù)規(guī)則）和性能標(biāo)準(zhǔn)（如速度、精確度）。這些列表不要求完美無缺，但要反映每個人對系統(tǒng)的理解。第32頁/共71頁SafeHome實例

17、2第33頁/共71頁協(xié)同需求收集v這些對象列表可以用大的紙張釘在房間的墻上或用便簽紙貼在墻上或?qū)懺趬Π迳??；蛘?，列表也可以貼在內(nèi)部網(wǎng)站的電子公告牌上或聊天室中，便于會議前的評審。理想情況下，應(yīng)該能夠分別操作每個列表項，以便于合并列表、刪除項以及加入新項。在本階段，嚴(yán)禁批評和爭論。第34頁/共71頁協(xié)同需求收集v當(dāng)某個話題域的各個列表被提出后，小組將生成一個組合列表。該組合列表將刪除冗余項，并加入在討論過程中出現(xiàn)的一些新的想法，但是不刪除任何東西。在所有話題域的組合列表都生成后，主持人開始討論協(xié)調(diào)。組合列表可能會縮短、加長或重新措詞，以求更恰當(dāng)?shù)胤从臣磳㈤_發(fā)的產(chǎn)品/系統(tǒng)，目標(biāo)是為每個話題域（對象

18、、服務(wù)、約束或性能）提交一個意見一致的列表，在后面的工作中將用到這個列表。第35頁/共71頁協(xié)同需求收集v一旦完成意見一致的列表，團隊被分為更小的子團隊，每個子團隊試圖為每個列表中的一個或多個項目編寫小規(guī)格說明。每個小規(guī)格說明是對包含在列表中的單詞或短語的精煉。第36頁/共71頁SafeHome實例3vSafeHome對象控制面板的小規(guī)格說明：對象控制面板的小規(guī)格說明：控制面板是一個安裝在墻上的裝置，尺寸控制面板是一個安裝在墻上的裝置，尺寸大概是大概是95英寸；控制面板和傳感器、計英寸；控制面板和傳感器、計算機之間是無線連接；通過一個算機之間是無線連接；通過一個12鍵的鍵鍵的鍵盤與用戶交互，通

19、過一個盤與用戶交互，通過一個33的的LCD彩色彩色顯示器為用戶提供反饋信息；軟件將提供顯示器為用戶提供反饋信息；軟件將提供交互提示、回顯以及類似的功能。交互提示、回顯以及類似的功能。第37頁/共71頁協(xié)同需求收集v然后，每個子團隊將他們完成的每個小規(guī)格說明提交給所有的與會者討論，進行添加、刪除和進一步細化等工作。在某些情況下，編寫小規(guī)格說明可能會發(fā)現(xiàn)新的對象、服務(wù)、約束或性能需求，可以將這些新發(fā)現(xiàn)加入到原始列表中。在所有的討論過程中，團隊可能會提出某些在會議上不能解決的問題，將這些問題列表保留起來以便這些意見在以后的工作中發(fā)揮作用。第38頁/共71頁質(zhì)量功能部署v質(zhì)量功能部署QFD是一種將客戶

20、要求轉(zhuǎn)化成軟件技術(shù)需求的質(zhì)量管理技術(shù)。QFD強調(diào)理解“什么是對客戶有價值的”，然后在整個工程活動中部署這些價值。第39頁/共71頁QFD確認(rèn)的需求v正常需求：這些需求反映了在和客戶開會時確定的針對某產(chǎn)品或系統(tǒng)的目標(biāo)。如果實現(xiàn)了這些需求，將滿足客戶。v期望需求：這些需求隱含在產(chǎn)品或系統(tǒng)中，并且可能是非常基礎(chǔ)的以至于客戶沒有顯式地說明，但是缺少這些將導(dǎo)致客戶明顯不滿。v令人興奮的需求：這些需求反映了客戶期望之外的特點，但是如果實現(xiàn)這些特點的話將會使客戶非常滿意。第40頁/共71頁質(zhì)量功能部署vQFD通過客戶訪談和觀察、調(diào)查以及檢查歷史數(shù)據(jù)（如問題報告）為需求收集活動獲取原始數(shù)據(jù)。然后把這些數(shù)據(jù)翻譯

21、成需求表稱為客戶意見表，并由客戶評審。接下來使用各種圖表、矩陣和評估方法抽取期望的需求并努力導(dǎo)出令人興奮的需求。第41頁/共71頁用戶場景v當(dāng)收集需求時，系統(tǒng)功能和特點的整體愿景開始具體化。但是在軟件團隊弄清楚不同類型的最終用戶如何使用這些功能和特征之前，很難轉(zhuǎn)移到更技術(shù)化的軟件工程活動。為實現(xiàn)這一點，開發(fā)人員和用戶可以創(chuàng)建一系列的場景場景可以識別對將要構(gòu)建的系統(tǒng)的使用線索。場景通常稱為用例，它提供了系統(tǒng)將如何被使用的描述。第42頁/共71頁導(dǎo)出工作產(chǎn)品v要求和可行性陳述。v系統(tǒng)或產(chǎn)品范圍的界限說明。v參與需求導(dǎo)出的客戶、用戶和其他共利益者的列表。v系統(tǒng)技術(shù)環(huán)境的說明。v需求列表以及每個需求適

22、用的領(lǐng)域限制。v一系列使用場景，有助于深入了解系統(tǒng)或產(chǎn)品在不同運行環(huán)境下的使用。v任何能夠更好地定義需求的原型。第43頁/共71頁開發(fā)用例v一個用例捕獲一個合同，即說明當(dāng)對某個共利益者的請求響應(yīng)時，在各種條件下系統(tǒng)的行為。本質(zhì)上，用例講述了能表達主體場景的故事：最終用戶如何在一特定環(huán)境下和系統(tǒng)交互。這個故事可以是敘述性的文本、任務(wù)或交互的概要、基于模板的說明或圖表顯示。不管形式如何，用例從最終用戶的角度描述了軟件或系統(tǒng)。第44頁/共71頁開發(fā)用例v撰寫用例的第一步是定義各類故事中所包含的“參與者”。參與者是在將要說明的功能和行為環(huán)境內(nèi)使用系統(tǒng)或產(chǎn)品的各類人員（或設(shè)備）。參與者是任何與系統(tǒng)或產(chǎn)品

23、通信的事物，且對系統(tǒng)本身而言參與者是外部的。當(dāng)使用系統(tǒng)時，每個參與者都有一個或多個目標(biāo)。第45頁/共71頁開發(fā)用例v參與者與最終用戶并非一回事。典型的用戶可能在使用系統(tǒng)時扮演了許多不同的角色，而參與者表示了一類外部實體（經(jīng)常是人員，但不限于人員），在用例中他們僅扮演一種角色。例如，考慮一個機床操作員（一個用戶），他和生產(chǎn)車間（其中布置了許多機器人和數(shù)控機床）內(nèi)的某個控制計算機交互。在仔細考察需求后，控制計算機的軟件需要四種不同的交互模式（角色）：編程模式、測試模式、監(jiān)測模式和糾錯模式。4個參與者可定義為：程序員、測試員、監(jiān)控員和故障檢修員。有些情況下，機床操作員可以扮演所有這些角色，而有些情況

24、下，每個參與者的角色可能由不同的人員扮演。第46頁/共71頁開發(fā)用例v需求導(dǎo)出是一個逐步演化的活動，第一次迭代中并不能確認(rèn)所有的參與者。在第一次迭代中有可能識別主要的參與者，而對系統(tǒng)了解更多之后，才能識別出次要的參與者。主要參與者直接且經(jīng)常使用軟件，和他們交互可以獲取所需的系統(tǒng)功能并導(dǎo)出系統(tǒng)的預(yù)期收益。次要參與者支持系統(tǒng)，以便主要參與者能夠完成他們的工作。第47頁/共71頁開發(fā)用例v一旦確認(rèn)了參與者，就可以開發(fā)用例。為了開發(fā)一個有效用例，可以考慮如下問題：v 誰是主要參與者、次要參與者？v 參與者的目標(biāo)是什么？v 故事開始前有什么前提條件？v 參與者完成的主要工作或功能是什么？v 按照故事所描

25、述的還可能需要考慮什么異常？v 參與者的交互中有什么可能的變化？v 參與者將獲得、產(chǎn)生或改變哪些系統(tǒng)信息？v 參與者必須通知系統(tǒng)外部環(huán)境的改變嗎？v 參與者希望從系統(tǒng)獲取什么信息？v 參與者希望得知意料之外的變更嗎？第48頁/共71頁SafeHome實例4第49頁/共71頁SafeHome實例5第50頁/共71頁SafeHome實例6第51頁/共71頁SafeHome實例7第52頁/共71頁SafeHome實例8第53頁/共71頁SafeHome實例9第54頁/共71頁SafeHome實例10第55頁/共71頁SafeHome實例11第56頁/共71頁構(gòu)建需求模型v分析模型的目的是為基于計算機

26、的系統(tǒng)提供必要的信息、功能和行為域的說明。隨著軟件工程師更多地了解將要實現(xiàn)的系統(tǒng)以及其他利益相關(guān)者更多地了解他們到底需要什么，模型將動態(tài)地變更。v當(dāng)需求模型演化時，某些元素將變得相對穩(wěn)定，為后續(xù)設(shè)計任務(wù)提供穩(wěn)固的基礎(chǔ)。但是，有些模型元素可能是不穩(wěn)定的，這表明利益相關(guān)者仍然沒有完全理解系統(tǒng)的需求。第57頁/共71頁需求模型的元素v有很多不同的方法考察計算機系統(tǒng)的需求。某些軟件人員堅持最好選擇一個表達模式（如用例）并排斥所有其他模式。有些專業(yè)人士則相信使用許多不同的表現(xiàn)模式來描述需求模型是值得的，不同的表達模式促使軟件團隊從不同的角度考慮需求一種方法更有可能造成需求遺漏、不一致性和歧義性。第58頁/共71頁基于場景的元素v使用基于場景的方法可以從用戶的視角描述系統(tǒng)。例如，基本的用例及其相應(yīng)的用例圖演化成更精細的基于模板的用例。課本圖4-3描繪了一張使用用例引發(fā)的需求并表達它們的UML活動圖。第59頁/共71頁導(dǎo)出需求的UML活動圖課本圖4-3 導(dǎo)出需求的UML活動圖第60頁/共71頁基于類的元素v每個使用場景都暗示著當(dāng)一個參與者和系統(tǒng)交互時所操作的一組對象，這些對象被分成類具有相似屬性和共同行為的事物集合。例如：可以用UML類圖描繪SafeHome安全功能的傳感器Sensor類如課本圖4-4所示。除了類圖，其他分析建模元素描繪了類相互