軟件工程：實踐者的研究方法第七版講義第四章

1、軟件工程第4章 理解需求主要內(nèi)容v需求工程需求工程v建立根基建立根基v導出需求導出需求v開發(fā)用例開發(fā)用例v構(gòu)建需求模型構(gòu)建需求模型v協(xié)商需求協(xié)商需求v確認需求確認需求v小結(jié)小結(jié)需求工程v需求工程幫助軟件工程師更好地理解他們需求工程幫助軟件工程師更好地理解他們將要解決的問題。其中所包含的一系列任將要解決的問題。其中所包含的一系列任務有助于理解軟件將如何影響業(yè)務、客戶務有助于理解軟件將如何影響業(yè)務、客戶想要什么以及最終用戶將如何和軟件交互。想要什么以及最終用戶將如何和軟件交互。v軟件工程師軟件工程師和和項目共利益者項目共利益者都將參與需求都將參與需求工程。工程。需求工程v在設(shè)計和開發(fā)某個一流的計算

2、機軟件時，在設(shè)計和開發(fā)某個一流的計算機軟件時，如果軟件解決的問題不對，那么即使軟件如果軟件解決的問題不對，那么即使軟件再精巧也滿足不了任何人的要求。這就是再精巧也滿足不了任何人的要求。這就是在設(shè)計和開發(fā)一個基于計算機的系統(tǒng)之前，在設(shè)計和開發(fā)一個基于計算機的系統(tǒng)之前，理解客戶需求的重要性。理解客戶需求的重要性。需求工程v理解問題的需求是軟件工程師所面對的最理解問題的需求是軟件工程師所面對的最困難的任務之一。困難的任務之一。v客戶難道不知道需要什么？客戶難道不知道需要什么？v最終用戶難道對給他們帶來實際收益的特最終用戶難道對給他們帶來實際收益的特征和功能沒有清楚的認識？征和功能沒有清楚的認識？v很

3、多情況下很多情況下的確是這樣的的確是這樣的。甚至即使用戶。甚至即使用戶和最終用戶清楚地知道他們的要求，這些和最終用戶清楚地知道他們的要求，這些要求也會在項目的實施過程中改變。要求也會在項目的實施過程中改變。需求工程v需求工程是指致力于不斷理解需求的大量任務和技術(shù)。需求工程是指致力于不斷理解需求的大量任務和技術(shù)。從軟件過程的角度來看，需求工程是一個軟件工程動作，從軟件過程的角度來看，需求工程是一個軟件工程動作，開始于溝通并持續(xù)至建模。開始于溝通并持續(xù)至建模。v需求工程在設(shè)計和構(gòu)造之間建立起聯(lián)系的橋梁。有人認需求工程在設(shè)計和構(gòu)造之間建立起聯(lián)系的橋梁。有人認為開始于為開始于項目共利益者項目共利益者，

4、即在那里定義業(yè)務需求，刻畫，即在那里定義業(yè)務需求，刻畫用戶場景，描述功能和特性，識別項目約束條件。另外用戶場景，描述功能和特性，識別項目約束條件。另外一些人可能會建議從寬泛的系統(tǒng)定義開始，此時軟件只一些人可能會建議從寬泛的系統(tǒng)定義開始，此時軟件只是更大的系統(tǒng)范圍中的一個構(gòu)件。但是不管起始點在哪是更大的系統(tǒng)范圍中的一個構(gòu)件。但是不管起始點在哪里，橫跨這個橋梁將把我們帶到項目之上更高的層次：里，橫跨這個橋梁將把我們帶到項目之上更高的層次：由軟件團隊檢查將要進行的軟件工作的內(nèi)容，必須提交由軟件團隊檢查將要進行的軟件工作的內(nèi)容，必須提交設(shè)計和構(gòu)建需要的特定要求，完成指導工作順序的優(yōu)先設(shè)計和構(gòu)建需要的特

5、定要求，完成指導工作順序的優(yōu)先級定義以及將深切影響隨后設(shè)計的信息、功能和行為。級定義以及將深切影響隨后設(shè)計的信息、功能和行為。需求工程任務v需求工程為以下工作提供了良好的機制：需求工程為以下工作提供了良好的機制：理解客戶需要什么，分析要求，評估可行理解客戶需要什么，分析要求，評估可行性，協(xié)商合理的方案，無歧義地詳細說明性，協(xié)商合理的方案，無歧義地詳細說明方案，確認規(guī)格說明，管理需求以至將這方案，確認規(guī)格說明，管理需求以至將這些需求轉(zhuǎn)化為可運行系統(tǒng)。需求工程過程些需求轉(zhuǎn)化為可運行系統(tǒng)。需求工程過程通過執(zhí)行七個不同的活動來完成：通過執(zhí)行七個不同的活動來完成：起始、起始、導出、精化、協(xié)商、規(guī)格說明、

6、確認和管導出、精化、協(xié)商、規(guī)格說明、確認和管理。理。起始v通常都是當確定了商業(yè)要求或發(fā)現(xiàn)了潛在通常都是當確定了商業(yè)要求或發(fā)現(xiàn)了潛在的新市場、新服務時項目才開始。業(yè)務領(lǐng)的新市場、新服務時項目才開始。業(yè)務領(lǐng)域的共利益者定義業(yè)務用例，確定市場的域的共利益者定義業(yè)務用例，確定市場的寬度和深度，進行粗略的可行性分析，并寬度和深度，進行粗略的可行性分析，并確定項目范圍的工作說明。確定項目范圍的工作說明。v在項目起始階段，軟件工程師會詢問一些在項目起始階段，軟件工程師會詢問一些似乎與項目無直接關(guān)系的問題。目的是對似乎與項目無直接關(guān)系的問題。目的是對問題、方案需求方、期望方案的本質(zhì)、客問題、方案需求方、期望方

7、案的本質(zhì)、客戶和開發(fā)人員之間初步的交流和合作的效戶和開發(fā)人員之間初步的交流和合作的效果建立基本的諒解。果建立基本的諒解。導出v系統(tǒng)或產(chǎn)品的目標是什么？系統(tǒng)或產(chǎn)品的目標是什么？v想要實現(xiàn)什么？想要實現(xiàn)什么？v系統(tǒng)和產(chǎn)品如何滿足業(yè)務的要求，最終系系統(tǒng)和產(chǎn)品如何滿足業(yè)務的要求，最終系統(tǒng)或產(chǎn)品如何用于日常工作？統(tǒng)或產(chǎn)品如何用于日常工作？v而實際上導出需求卻是異常的困難。而實際上導出需求卻是異常的困難。導出v范圍問題范圍問題：系統(tǒng)的邊界不清楚，或客戶：系統(tǒng)的邊界不清楚，或客戶/用戶的用戶的說明帶有多余的技術(shù)細節(jié)，這些細節(jié)可能會混說明帶有多余的技術(shù)細節(jié)，這些細節(jié)可能會混淆而不是澄清系統(tǒng)的整體目標。淆而不是

8、澄清系統(tǒng)的整體目標。v理解問題理解問題：客戶：客戶/用戶并不完全確定需要什么，用戶并不完全確定需要什么，對其計算環(huán)境的能力和限制所知甚少，對問題對其計算環(huán)境的能力和限制所知甚少，對問題域沒有完整的認識，與系統(tǒng)工程師在溝通上有域沒有完整的認識，與系統(tǒng)工程師在溝通上有問題，省略那些他們認為是問題，省略那些他們認為是“明顯的明顯的”信息，信息，確定的需求和其他客戶確定的需求和其他客戶/用戶的需求相沖突，需用戶的需求相沖突，需求說明有歧義或不可測試。求說明有歧義或不可測試。v易變問題易變問題：需求隨時間變化。：需求隨時間變化。精化v精化是一個精化是一個分析建模分析建模動作，由一系列的建模和動作，由一系

9、列的建模和求精任務構(gòu)成。當描述最終用戶如何與系統(tǒng)交求精任務構(gòu)成。當描述最終用戶如何與系統(tǒng)交互的用戶場景創(chuàng)建和求精時，就會發(fā)生精化動互的用戶場景創(chuàng)建和求精時，就會發(fā)生精化動作，每個用戶場景被分解為精煉分析類作，每個用戶場景被分解為精煉分析類最最終用戶可見的業(yè)務域?qū)嶓w。應該定義每個分析終用戶可見的業(yè)務域?qū)嶓w。應該定義每個分析類的類的屬性屬性，確定每個類所需要的，確定每個類所需要的服務服務，確定類，確定類之間的之間的關(guān)聯(lián)和協(xié)作關(guān)聯(lián)和協(xié)作關(guān)系，并完成各種關(guān)系，并完成各種UML圖作圖作為補充。為補充。v精化的最終結(jié)果是形成一個精確的精化的最終結(jié)果是形成一個精確的需求模型需求模型，用以說明軟件的用以說明軟

10、件的功能功能、特征特征和和信息信息的各個方面。的各個方面。 協(xié)商v需求工程師必須通過協(xié)商過程來需求工程師必須通過協(xié)商過程來調(diào)解調(diào)解客戶客戶提出的過高的目標要求和相互沖突的需求。提出的過高的目標要求和相互沖突的需求。應該讓客戶、用戶和其他共利益者對各自應該讓客戶、用戶和其他共利益者對各自的需求排序，然后按的需求排序，然后按優(yōu)先級優(yōu)先級討論沖突。識討論沖突。識別和分析與每項需求相關(guān)聯(lián)的別和分析與每項需求相關(guān)聯(lián)的風險風險；粗略；粗略“估算估算”開發(fā)工作量，并用于評估需求對開發(fā)工作量，并用于評估需求對項目項目成本和交付時間成本和交付時間的影響；的影響；使用迭代的使用迭代的方法、刪除、組合或修改需求方法

11、、刪除、組合或修改需求，以便相關(guān)，以便相關(guān)各方均能達到一定的滿意度。各方均能達到一定的滿意度。規(guī)格說明v一個規(guī)格說明可以是一份寫好的文檔、一一個規(guī)格說明可以是一份寫好的文檔、一套圖形化的模型、一個形式化的數(shù)學模型，套圖形化的模型、一個形式化的數(shù)學模型，一組使用場景、一個原型或上述各項的任一組使用場景、一個原型或上述各項的任意組合。意組合。v在開發(fā)規(guī)格說明時保持靈活性有時是必要在開發(fā)規(guī)格說明時保持靈活性有時是必要的，對大型系統(tǒng)而言，文檔最好采用自然的，對大型系統(tǒng)而言，文檔最好采用自然語言描述和圖形化模型來編寫。而對于技語言描述和圖形化模型來編寫。而對于技術(shù)環(huán)節(jié)明確的較小產(chǎn)品或系統(tǒng)，使用場景術(shù)環(huán)節(jié)

12、明確的較小產(chǎn)品或系統(tǒng)，使用場景可能就足夠了?？赡芫妥銐蛄?。確認v確認確認將對需求工程的工作產(chǎn)品進行質(zhì)量評估。將對需求工程的工作產(chǎn)品進行質(zhì)量評估。需求確認要檢查規(guī)格說明以保證：所有的系統(tǒng)需求確認要檢查規(guī)格說明以保證：所有的系統(tǒng)需求已被無歧義地說明；不一致性、疏漏和錯需求已被無歧義地說明；不一致性、疏漏和錯誤已被檢測出并被糾正；工作產(chǎn)品符合為過程、誤已被檢測出并被糾正；工作產(chǎn)品符合為過程、項目和產(chǎn)品建立的標準。項目和產(chǎn)品建立的標準。v正式技術(shù)評審正式技術(shù)評審是最主要的需求確認機制。確認是最主要的需求確認機制。確認需求的評審小組包括軟件工程師、客戶、用戶需求的評審小組包括軟件工程師、客戶、用戶和其他

13、共利益者，他們檢查系統(tǒng)規(guī)格說明，查和其他共利益者，他們檢查系統(tǒng)規(guī)格說明，查找內(nèi)容或解釋上的錯誤，以及可能需要進一步找內(nèi)容或解釋上的錯誤，以及可能需要進一步解釋澄清的地方、丟失的信息、不一致性、沖解釋澄清的地方、丟失的信息、不一致性、沖突的需求或不現(xiàn)實的需求。突的需求或不現(xiàn)實的需求。需求確認檢查表v需求說明清晰嗎？有沒有可能造成誤解？需求說明清晰嗎？有沒有可能造成誤解？v需求的來源（如人員、規(guī)則、文檔）弄清了嗎？需求的最終說明是需求的來源（如人員、規(guī)則、文檔）弄清了嗎？需求的最終說明是否已經(jīng)根據(jù)或?qū)φ兆畛鮼碓礄z查過？否已經(jīng)根據(jù)或?qū)φ兆畛鮼碓礄z查過？v需求是否用定量的術(shù)語界定？需求是否用定量的術(shù)語

14、界定？v其他哪些需求與此需求相關(guān)？是否已經(jīng)使用交叉索引或其他機制清其他哪些需求與此需求相關(guān)？是否已經(jīng)使用交叉索引或其他機制清楚地加以說明了？楚地加以說明了？v需求是否違背某個系統(tǒng)領(lǐng)域的約束？需求是否違背某個系統(tǒng)領(lǐng)域的約束？v需求是否可以測試？如果可以，能否說明測試檢驗了需求？需求是否可以測試？如果可以，能否說明測試檢驗了需求？v對已經(jīng)創(chuàng)建的任何系統(tǒng)模型，需求是否可跟蹤？對已經(jīng)創(chuàng)建的任何系統(tǒng)模型，需求是否可跟蹤？v對整體系統(tǒng)對整體系統(tǒng)/產(chǎn)品目標，需求是否可跟蹤？產(chǎn)品目標，需求是否可跟蹤？v規(guī)格說明的構(gòu)造方式是否有助于理解、引用和翻譯成更技術(shù)性的工規(guī)格說明的構(gòu)造方式是否有助于理解、引用和翻譯成更技

15、術(shù)性的工作產(chǎn)品？作產(chǎn)品？v對已創(chuàng)建的規(guī)格說明是否建立了索引？對已創(chuàng)建的規(guī)格說明是否建立了索引？v和系統(tǒng)性能、行為及運行特征相關(guān)的需求的說明是否清楚？哪些需和系統(tǒng)性能、行為及運行特征相關(guān)的需求的說明是否清楚？哪些需求是隱含出現(xiàn)的？求是隱含出現(xiàn)的？需求管理v基于計算機的系統(tǒng)其需求會變更，而且變基于計算機的系統(tǒng)其需求會變更，而且變更的要求貫穿于系統(tǒng)的整個生存期。更的要求貫穿于系統(tǒng)的整個生存期。v需求管理是用于幫助項目組在項目進展中需求管理是用于幫助項目組在項目進展中標識、控制和跟蹤需求以及變更需求的一標識、控制和跟蹤需求以及變更需求的一組活動。組活動。v需求管理從標識開始。每個需求被賦予唯需求管理從

16、標識開始。每個需求被賦予唯一的標識符。一旦需求被標識，便開始建一的標識符。一旦需求被標識，便開始建立跟蹤表，每個跟蹤表將標識的需求與系立跟蹤表，每個跟蹤表將標識的需求與系統(tǒng)或其環(huán)境的一個或多個方面相關(guān)聯(lián)。統(tǒng)或其環(huán)境的一個或多個方面相關(guān)聯(lián)。建立根基v在理想情況下，利益相關(guān)者和軟件工程師在理想情況下，利益相關(guān)者和軟件工程師在同一個小組中工作。在這種情況下，需在同一個小組中工作。在這種情況下，需求工程就只是和組里熟悉的同事進行有意求工程就只是和組里熟悉的同事進行有意義的交談。義的交談。但實際情況往往不是這樣。但實際情況往往不是這樣。v客戶可能正在不同的城市或國家，對于想客戶可能正在不同的城市或國家，

17、對于想要什么可能僅有模糊的想法，對于將要構(gòu)要什么可能僅有模糊的想法，對于將要構(gòu)建的系統(tǒng)可能存在不同的意見，技術(shù)知識建的系統(tǒng)可能存在不同的意見，技術(shù)知識可能很有限，可能僅有有限的時間與需求可能很有限，可能僅有有限的時間與需求工程師溝通。工程師溝通。軟件開發(fā)團隊經(jīng)常被迫在這軟件開發(fā)團隊經(jīng)常被迫在這種環(huán)境的限制下工作。種環(huán)境的限制下工作。確認利益相關(guān)者v利益相關(guān)者可定義為利益相關(guān)者可定義為“直接或間接從正在直接或間接從正在開發(fā)的系統(tǒng)中獲益的人開發(fā)的系統(tǒng)中獲益的人”?？梢源_定如下。可以確定如下幾個容易理解的利益相關(guān)者：幾個容易理解的利益相關(guān)者：業(yè)務操作管業(yè)務操作管理人員、產(chǎn)品管理人員、市場營銷人員、理

18、人員、產(chǎn)品管理人員、市場營銷人員、內(nèi)部和外部客戶、最終用戶、顧問、產(chǎn)品內(nèi)部和外部客戶、最終用戶、顧問、產(chǎn)品工程師、軟件工程師、支持和維護工程師工程師、軟件工程師、支持和維護工程師以及其他人員以及其他人員。每個共利益者對系統(tǒng)都有。每個共利益者對系統(tǒng)都有不同的考慮，當系統(tǒng)成功開發(fā)后所能獲得不同的考慮，當系統(tǒng)成功開發(fā)后所能獲得的利益也不相同，同樣地，當系統(tǒng)開發(fā)失的利益也不相同，同樣地，當系統(tǒng)開發(fā)失敗時所面臨的風險也不同。敗時所面臨的風險也不同。確認利益相關(guān)者v在開始階段，需求工程師應該創(chuàng)建一個人在開始階段，需求工程師應該創(chuàng)建一個人員列表，列出那些有助于誘導出需求的人員列表，列出那些有助于誘導出需求的

19、人員。最初的人員列表將隨著接觸的共利益員。最初的人員列表將隨著接觸的共利益者人數(shù)增多而增加，因為每個共利益者都者人數(shù)增多而增加，因為每個共利益者都將被詢問將被詢問“你認為我還應該和誰交談你認為我還應該和誰交談”。識別多種觀點v因為存在很多不同的利益相關(guān)者，所以系因為存在很多不同的利益相關(guān)者，所以系統(tǒng)需求調(diào)研也將從很多不同的視角展開。統(tǒng)需求調(diào)研也將從很多不同的視角展開。v這些參與者中的每一個人都將為需求工程這些參與者中的每一個人都將為需求工程貢獻信息。當從多個角度收集信息時，所貢獻信息。當從多個角度收集信息時，所形成的需求可能存在不一致性或相互矛盾。形成的需求可能存在不一致性或相互矛盾。需求工程

20、師的工作就是需求工程師的工作就是把所有共利益者提把所有共利益者提供的信息分類，供的信息分類，分類的方法應該便于決策分類的方法應該便于決策制定者為系統(tǒng)選擇一個制定者為系統(tǒng)選擇一個內(nèi)部一致的需求集內(nèi)部一致的需求集合合。協(xié)同合作v需求工程師的工作是標識需求工程師的工作是標識公共區(qū)域公共區(qū)域（即所（即所有共利益者都同意的需求）和有共利益者都同意的需求）和矛盾區(qū)域矛盾區(qū)域或或不一致區(qū)域不一致區(qū)域（即某個共利益者提出的需求（即某個共利益者提出的需求和其他共利益者的需求相矛盾）。和其他共利益者的需求相矛盾）。v很多情況下，共利益者的協(xié)作是很多情況下，共利益者的協(xié)作是提供他們提供他們各自關(guān)于需求的觀點各自關(guān)于

21、需求的觀點，而一個有力的，而一個有力的“項項目領(lǐng)導者目領(lǐng)導者”可能要對刪減哪些需求做出最可能要對刪減哪些需求做出最終判斷。終判斷?；凇皟?yōu)先點”的投票方案v所有的共利益者都會分配到一定數(shù)量的優(yōu)所有的共利益者都會分配到一定數(shù)量的優(yōu)先點，這些優(yōu)先點可以適用于很多需求。先點，這些優(yōu)先點可以適用于很多需求。每個共利益者在一個需求列表上，通過向每個共利益者在一個需求列表上，通過向每個需求分配一個或多個優(yōu)先點來表明該每個需求分配一個或多個優(yōu)先點來表明該需求的相對重要性（從他或她的個人觀需求的相對重要性（從他或她的個人觀點）。優(yōu)先點用過之后就不能再次使用，點）。優(yōu)先點用過之后就不能再次使用，一旦某個共利益者

22、的優(yōu)先點用完，他就不一旦某個共利益者的優(yōu)先點用完，他就不能再對需求實施進一步的操作。所有共利能再對需求實施進一步的操作。所有共利益者在益者在每項需求上的優(yōu)先點總數(shù)每項需求上的優(yōu)先點總數(shù)顯示了該顯示了該需求的綜合重要性。需求的綜合重要性。首次提問v第一組與環(huán)境無關(guān)的問題集中于客戶和其第一組與環(huán)境無關(guān)的問題集中于客戶和其他共利益者、整體目標、收益。他共利益者、整體目標、收益。v誰是這項工作的最初提出者？誰是這項工作的最初提出者？v誰將使用該解決方案？誰將使用該解決方案？v成功的解決方案將帶來什么樣的經(jīng)濟收益？成功的解決方案將帶來什么樣的經(jīng)濟收益？v對于這個解決方案你還需要其他資源嗎？對于這個解決方

23、案你還需要其他資源嗎？首次提問v下一組問題有助于軟件開發(fā)組更好地理解下一組問題有助于軟件開發(fā)組更好地理解問題，并允許客戶表達其對解決方案的看問題，并允許客戶表達其對解決方案的看法。法。v如何描述由某成功的解決方案產(chǎn)生的如何描述由某成功的解決方案產(chǎn)生的“良好良好的的”輸出？輸出？v該解決方案強調(diào)了什么問題？該解決方案強調(diào)了什么問題？v能向我們展示（或描述）解決方案的使用環(huán)能向我們展示（或描述）解決方案的使用環(huán)境嗎？境嗎？v存在影響解決方案的特殊性能問題或約束嗎？存在影響解決方案的特殊性能問題或約束嗎？首次提問v最后一組問題關(guān)注于溝通活動本身的效率。最后一組問題關(guān)注于溝通活動本身的效率。v你是回答

24、這些問題的合適人選嗎？你的回答你是回答這些問題的合適人選嗎？你的回答是是“正式的正式的”嗎？嗎？v我的提問和你想解決的問題相關(guān)嗎？我的提問和你想解決的問題相關(guān)嗎？v我的問題是否太多了？我的問題是否太多了？v還有其他人員可以提供更多的信息嗎？還有其他人員可以提供更多的信息嗎？v還有我應該問的其他問題嗎？還有我應該問的其他問題嗎？首次提問v這些問題將有助于這些問題將有助于“打破堅冰打破堅冰”，并有助，并有助于交流的開始，而且這樣的交流對需求導于交流的開始，而且這樣的交流對需求導出的成功至關(guān)重要。但是，會議形式的問出的成功至關(guān)重要。但是，會議形式的問與答并非一定是會取得成功的好方法。事與答并非一定是

25、會取得成功的好方法。事實上，實上，Q&A會議會議應該僅僅用于首次接觸，應該僅僅用于首次接觸，然后就應該用然后就應該用需求誘導需求誘導形式（包括問題求形式（包括問題求解、協(xié)商和規(guī)格說明）取代。解、協(xié)商和規(guī)格說明）取代。導出需求v導出需求是與問題求解、精化、談判和規(guī)導出需求是與問題求解、精化、談判和規(guī)格說明等方面的元素結(jié)合在一起的。為了格說明等方面的元素結(jié)合在一起的。為了鼓勵合作，一個包括利益相關(guān)者和開發(fā)人鼓勵合作，一個包括利益相關(guān)者和開發(fā)人員的團隊共同完成如下任務：確認問題，員的團隊共同完成如下任務：確認問題，為解決方案的要素提供建議，商討不同的為解決方案的要素提供建議，商討不同的方法并

26、描述初步的需求解決方案。方法并描述初步的需求解決方案。協(xié)同需求收集v提出面向團隊的需求收集方法是為了鼓勵提出面向團隊的需求收集方法是為了鼓勵合作，即一個包括共利益者和開發(fā)人員的合作，即一個包括共利益者和開發(fā)人員的團隊共同完成如下任務：確認問題，為解團隊共同完成如下任務：確認問題，為解決方案的要素提供建議，協(xié)商不同的方法，決方案的要素提供建議，協(xié)商不同的方法，以及說明初步的解決方案需求集合。以及說明初步的解決方案需求集合。協(xié)同需求收集會議的基本原則v會議由軟件工程師和其他的利益相關(guān)者共同舉辦會議由軟件工程師和其他的利益相關(guān)者共同舉辦和參與。和參與。v制定籌備和參與會議的規(guī)則。制定籌備和參與會議的

27、規(guī)則。v建議擬定一個會議議程，這個議程既要足夠正式，建議擬定一個會議議程，這個議程既要足夠正式，使其涵蓋所有的重要點；但也不能太正式，以鼓使其涵蓋所有的重要點；但也不能太正式，以鼓勵思想的自由交流。勵思想的自由交流。v由一個由一個“調(diào)解人調(diào)解人”(可以是客戶、開發(fā)人員或其可以是客戶、開發(fā)人員或其他人他人)控制會議。控制會議。v采用采用“方案論證手段方案論證手段”。v目的是識別問題，提出要解決方案的要素，協(xié)商目的是識別問題，提出要解決方案的要素，協(xié)商不同的方法以及在有利于完成目標的氛圍中確定不同的方法以及在有利于完成目標的氛圍中確定一套解決需求問題的初步方案。一套解決需求問題的初步方案。 協(xié)同需

28、求收集v在需求的起始階段，基本問題和問題的答在需求的起始階段，基本問題和問題的答案確定了問題的范圍和對解決方案的整體案確定了問題的范圍和對解決方案的整體理解。除了這些最初的會議之外，理解。除了這些最初的會議之外，共利益共利益者要寫一個者要寫一個12頁的頁的“產(chǎn)品要求產(chǎn)品要求”。此外此外還要選擇會議地點、時間和日期，并選舉還要選擇會議地點、時間和日期，并選舉“調(diào)解人調(diào)解人”。來自開發(fā)組和其他共利益者。來自開發(fā)組和其他共利益者組織的代表被邀請出席會議，在會議召開組織的代表被邀請出席會議，在會議召開之前應將產(chǎn)品要求分發(fā)給所有的與會者。之前應將產(chǎn)品要求分發(fā)給所有的與會者。SafeHome實例1協(xié)同需求

29、收集v在召開會議評審產(chǎn)品要求的前幾天，要求在召開會議評審產(chǎn)品要求的前幾天，要求每個與會者列出每個與會者列出構(gòu)成系統(tǒng)周圍環(huán)境的對象、構(gòu)成系統(tǒng)周圍環(huán)境的對象、由系統(tǒng)產(chǎn)生的其他對象以及系統(tǒng)用來完成由系統(tǒng)產(chǎn)生的其他對象以及系統(tǒng)用來完成功能的對象功能的對象。此外，要求每個與會者列出。此外，要求每個與會者列出服務操作或與對象交互的服務服務操作或與對象交互的服務（過程或功（過程或功能）能）列表列表。最后，還要開發(fā)。最后，還要開發(fā)約束列表約束列表（如（如成本、規(guī)模大小、業(yè)務規(guī)則）和成本、規(guī)模大小、業(yè)務規(guī)則）和性能標準性能標準（如速度、精確度）。這些列表不要求完（如速度、精確度）。這些列表不要求完美無缺，但要反

30、映每個人對系統(tǒng)的理解。美無缺，但要反映每個人對系統(tǒng)的理解。SafeHome實例2協(xié)同需求收集v這些對象列表可以用大的紙張釘在房間的這些對象列表可以用大的紙張釘在房間的墻上或用便簽紙貼在墻上或?qū)懺趬Π迳?。墻上或用便簽紙貼在墻上或?qū)懺趬Π迳??；蛘?，列表也可以貼在內(nèi)部網(wǎng)站的電子公或者，列表也可以貼在內(nèi)部網(wǎng)站的電子公告牌上或聊天室中，便于會議前的評審。告牌上或聊天室中，便于會議前的評審。理想情況下，應該能夠分別操作每個列表理想情況下，應該能夠分別操作每個列表項，以便于合并列表、刪除項以及加入新項，以便于合并列表、刪除項以及加入新項。在本階段，項。在本階段，嚴禁批評和爭論。嚴禁批評和爭論。協(xié)同需求收集v

31、當某個話題域的各個列表被提出后，小組當某個話題域的各個列表被提出后，小組將生成一個將生成一個組合列表組合列表。該組合列表將。該組合列表將刪除刪除冗余項冗余項，并加入在討論過程中出現(xiàn)的一些，并加入在討論過程中出現(xiàn)的一些新的想法新的想法，但是，但是不刪除任何東西不刪除任何東西。在所有。在所有話題域的組合列表都生成后，主持人開始話題域的組合列表都生成后，主持人開始討論協(xié)調(diào)。組合列表可能會縮短、加長或討論協(xié)調(diào)。組合列表可能會縮短、加長或重新措詞，以求更恰當?shù)胤从臣磳㈤_發(fā)的重新措詞，以求更恰當?shù)胤从臣磳㈤_發(fā)的產(chǎn)品產(chǎn)品/系統(tǒng)，目標是為每個話題域（對象、系統(tǒng)，目標是為每個話題域（對象、服務、約束或性能）提交

32、一個意見一致的服務、約束或性能）提交一個意見一致的列表，在后面的工作中將用到這個列表。列表，在后面的工作中將用到這個列表。協(xié)同需求收集v一旦完成意見一致的列表，一旦完成意見一致的列表，團隊被分為更團隊被分為更小的子團隊小的子團隊，每個子團隊試圖為每個列表，每個子團隊試圖為每個列表中的一個或多個項目編寫中的一個或多個項目編寫小規(guī)格說明小規(guī)格說明。每。每個小規(guī)格說明是對包含在列表中的單詞或個小規(guī)格說明是對包含在列表中的單詞或短語的精煉。短語的精煉。SafeHome實例3vSafeHome對象控制面板的小規(guī)格說明：對象控制面板的小規(guī)格說明：控制面板是一個安裝在墻上的裝置，尺寸控制面板是一個安裝在墻上

33、的裝置，尺寸大概是大概是95英寸；控制面板和傳感器、計英寸；控制面板和傳感器、計算機之間是無線連接；通過一個算機之間是無線連接；通過一個12鍵的鍵鍵的鍵盤與用戶交互，通過一個盤與用戶交互，通過一個33的的LCD彩色彩色顯示器為用戶提供反饋信息；軟件將提供顯示器為用戶提供反饋信息；軟件將提供交互提示、回顯以及類似的功能。交互提示、回顯以及類似的功能。協(xié)同需求收集v然后，每個子團隊將他們完成的每個小規(guī)然后，每個子團隊將他們完成的每個小規(guī)格說明提交給所有的與會者討論，進行格說明提交給所有的與會者討論，進行添添加、刪除和進一步細化加、刪除和進一步細化等工作。在某些情等工作。在某些情況下，編寫小規(guī)格說明

34、可能況下，編寫小規(guī)格說明可能會發(fā)現(xiàn)新的對會發(fā)現(xiàn)新的對象、服務、約束或性能需求象、服務、約束或性能需求，可以將這些，可以將這些新發(fā)現(xiàn)加入到原始列表中。在所有的討論新發(fā)現(xiàn)加入到原始列表中。在所有的討論過程中，團隊可能會提出某些在會議上過程中，團隊可能會提出某些在會議上不不能解決的問題能解決的問題，將這些問題列表保留起來，將這些問題列表保留起來以便這些意見在以后的工作中發(fā)揮作用。以便這些意見在以后的工作中發(fā)揮作用。質(zhì)量功能部署v質(zhì)量功能部署質(zhì)量功能部署QFD是一種將客戶要求轉(zhuǎn)化是一種將客戶要求轉(zhuǎn)化成軟件技術(shù)需求的質(zhì)量管理技術(shù)。成軟件技術(shù)需求的質(zhì)量管理技術(shù)。QFD強強調(diào)理解調(diào)理解“什么是對客戶有價值的

35、什么是對客戶有價值的”，然后，然后在整個工程活動中部署這些價值。在整個工程活動中部署這些價值。QFD確認的需求v正常需求正常需求：這些需求反映了在和客戶開會：這些需求反映了在和客戶開會時確定的針對某產(chǎn)品或系統(tǒng)的目標。如果時確定的針對某產(chǎn)品或系統(tǒng)的目標。如果實現(xiàn)了這些需求，將滿足客戶。實現(xiàn)了這些需求，將滿足客戶。v期望需求期望需求：這些需求隱含在產(chǎn)品或系統(tǒng)中，：這些需求隱含在產(chǎn)品或系統(tǒng)中，并且可能是非?；A(chǔ)的以至于客戶沒有顯并且可能是非?；A(chǔ)的以至于客戶沒有顯式地說明，但是缺少這些將導致客戶明顯式地說明，但是缺少這些將導致客戶明顯不滿。不滿。v令人興奮的需求令人興奮的需求：這些需求反映了客戶期：

36、這些需求反映了客戶期望之外的特點，但是如果實現(xiàn)這些特點的望之外的特點，但是如果實現(xiàn)這些特點的話將會使客戶非常滿意。話將會使客戶非常滿意。質(zhì)量功能部署vQFD通過通過客戶訪談和觀察、調(diào)查以及檢查客戶訪談和觀察、調(diào)查以及檢查歷史數(shù)據(jù)歷史數(shù)據(jù)（如問題報告）為需求收集活動（如問題報告）為需求收集活動獲取原始數(shù)據(jù)。然后把這些數(shù)據(jù)翻譯成獲取原始數(shù)據(jù)。然后把這些數(shù)據(jù)翻譯成需需求表求表稱為稱為客戶意見表客戶意見表，并由客戶評審。，并由客戶評審。接下來使用接下來使用各種圖表、矩陣和評估方法各種圖表、矩陣和評估方法抽抽取期望的需求并努力導出令人興奮的需求。取期望的需求并努力導出令人興奮的需求。用戶場景v當收集需求

37、時，系統(tǒng)功能和特點的整體愿當收集需求時，系統(tǒng)功能和特點的整體愿景開始具體化。但是在軟件團隊弄清楚不景開始具體化。但是在軟件團隊弄清楚不同類型的最終用戶如何使用這些功能和特同類型的最終用戶如何使用這些功能和特征之前，很難轉(zhuǎn)移到更技術(shù)化的軟件工程征之前，很難轉(zhuǎn)移到更技術(shù)化的軟件工程活動。為實現(xiàn)這一點，開發(fā)人員和用戶可活動。為實現(xiàn)這一點，開發(fā)人員和用戶可以創(chuàng)建一系列的以創(chuàng)建一系列的場景場景場景可以識別對場景可以識別對將要構(gòu)建的系統(tǒng)的使用線索將要構(gòu)建的系統(tǒng)的使用線索。場景通常稱。場景通常稱為為用例用例，它，它提供了系統(tǒng)將如何被使用的描提供了系統(tǒng)將如何被使用的描述述。導出工作產(chǎn)品v要求和可行性陳述。要求

38、和可行性陳述。v系統(tǒng)或產(chǎn)品范圍的界限說明。系統(tǒng)或產(chǎn)品范圍的界限說明。v參與需求導出的客戶、用戶和其他共利益參與需求導出的客戶、用戶和其他共利益者的列表。者的列表。v系統(tǒng)技術(shù)環(huán)境的說明。系統(tǒng)技術(shù)環(huán)境的說明。v需求列表以及每個需求適用的領(lǐng)域限制。需求列表以及每個需求適用的領(lǐng)域限制。v一系列使用場景，有助于深入了解系統(tǒng)或一系列使用場景，有助于深入了解系統(tǒng)或產(chǎn)品在不同運行環(huán)境下的使用。產(chǎn)品在不同運行環(huán)境下的使用。v任何能夠更好地定義需求的原型任何能夠更好地定義需求的原型。開發(fā)用例v一個一個用例用例捕獲一個合同，即說明當對某個捕獲一個合同，即說明當對某個共利益者的請求響應時，在各種條件下系共利益者的請求

39、響應時，在各種條件下系統(tǒng)的行為。本質(zhì)上，用例講述了能表達主統(tǒng)的行為。本質(zhì)上，用例講述了能表達主體場景的故事：體場景的故事：最終用戶如何在一特定環(huán)最終用戶如何在一特定環(huán)境下和系統(tǒng)交互境下和系統(tǒng)交互。這個故事可以是敘述性。這個故事可以是敘述性的文本、任務或交互的概要、基于模板的的文本、任務或交互的概要、基于模板的說明或圖表顯示。不管形式如何，用例從說明或圖表顯示。不管形式如何，用例從最終用戶的角度描述了軟件或系統(tǒng)最終用戶的角度描述了軟件或系統(tǒng)。開發(fā)用例v撰寫用例的第一步是定義各類故事中所包撰寫用例的第一步是定義各類故事中所包含的含的“參與者參與者”。參與者是在將要說明的。參與者是在將要說明的功能和

40、行為環(huán)境內(nèi)使用系統(tǒng)或產(chǎn)品的功能和行為環(huán)境內(nèi)使用系統(tǒng)或產(chǎn)品的各類各類人員（或設(shè)備）人員（或設(shè)備）。參與者是任何與系統(tǒng)或。參與者是任何與系統(tǒng)或產(chǎn)品通信的事物，且對系統(tǒng)本身而言參與產(chǎn)品通信的事物，且對系統(tǒng)本身而言參與者是外部的。當使用系統(tǒng)時，者是外部的。當使用系統(tǒng)時，每個參與者每個參與者都有一個或多個目標都有一個或多個目標。開發(fā)用例v參與者與最終用戶并非一回事。典型的用戶可能參與者與最終用戶并非一回事。典型的用戶可能在使用系統(tǒng)時扮演了許多不同的角色，而參與者在使用系統(tǒng)時扮演了許多不同的角色，而參與者表示了一類外部實體（經(jīng)常是人員，但不限于人表示了一類外部實體（經(jīng)常是人員，但不限于人員），在用例中他們

41、僅扮演一種角色。例如，員），在用例中他們僅扮演一種角色。例如，考考慮一個機床操作員（一個用戶），他和生產(chǎn)車間慮一個機床操作員（一個用戶），他和生產(chǎn)車間（其中布置了許多機器人和數(shù)控機床）內(nèi)的某個（其中布置了許多機器人和數(shù)控機床）內(nèi)的某個控制計算機交互?？刂朴嬎銠C交互。在仔細考察需求后，控制計算在仔細考察需求后，控制計算機的軟件需要四種不同的交互模式（角色）：機的軟件需要四種不同的交互模式（角色）：編編程模式、測試模式、監(jiān)測模式和糾錯模式。程模式、測試模式、監(jiān)測模式和糾錯模式。4個個參與者可定義為：參與者可定義為：程序員、測試員、監(jiān)控員和故程序員、測試員、監(jiān)控員和故障檢修員障檢修員。有些情況下，。

42、有些情況下，機床操作員可以扮演所機床操作員可以扮演所有這些角色有這些角色，而有些情況下，而有些情況下，每個參與者的角色每個參與者的角色可能由不同的人員扮演?？赡苡刹煌娜藛T扮演。開發(fā)用例v需求導出是一個逐步演化的活動，第一次需求導出是一個逐步演化的活動，第一次迭代中并不能確認所有的參與者。在第一迭代中并不能確認所有的參與者。在第一次迭代中有可能識別次迭代中有可能識別主要的參與者主要的參與者，而對，而對系統(tǒng)了解更多之后，才能識別出系統(tǒng)了解更多之后，才能識別出次要的參次要的參與者與者。主要參與者直接且經(jīng)常使用軟件，。主要參與者直接且經(jīng)常使用軟件，和他們交互可以獲取所需的系統(tǒng)功能并導和他們交互可以獲

43、取所需的系統(tǒng)功能并導出系統(tǒng)的預期收益。次要參與者支持系統(tǒng)，出系統(tǒng)的預期收益。次要參與者支持系統(tǒng)，以便主要參與者能夠完成他們的工作。以便主要參與者能夠完成他們的工作。開發(fā)用例v一旦確認了參與者，就可以開發(fā)用例。為了開發(fā)一旦確認了參與者，就可以開發(fā)用例。為了開發(fā)一個有效用例，可以考慮如下問題：一個有效用例，可以考慮如下問題：v誰是主要參與者、次要參與者？誰是主要參與者、次要參與者？v參與者的目標是什么？參與者的目標是什么？v故事開始前有什么前提條件？故事開始前有什么前提條件？v參與者完成的主要工作或功能是什么？參與者完成的主要工作或功能是什么？v按照故事所描述的還可能需要考慮什么異常？按照故事所描

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

45、統(tǒng)提分析模型的目的是為基于計算機的系統(tǒng)提供必要的信息、功能和行為域的說明。隨供必要的信息、功能和行為域的說明。隨著軟件工程師更多地了解將要實現(xiàn)的系統(tǒng)著軟件工程師更多地了解將要實現(xiàn)的系統(tǒng)以及其他利益相關(guān)者更多地了解他們到底以及其他利益相關(guān)者更多地了解他們到底需要什么，模型將動態(tài)地變更。需要什么，模型將動態(tài)地變更。v當需求模型演化時，某些元素將變得相對當需求模型演化時，某些元素將變得相對穩(wěn)定，為后續(xù)設(shè)計任務提供穩(wěn)固的基礎(chǔ)。穩(wěn)定，為后續(xù)設(shè)計任務提供穩(wěn)固的基礎(chǔ)。但是，有些模型元素可能是不穩(wěn)定的，這但是，有些模型元素可能是不穩(wěn)定的，這表明利益相關(guān)者仍然沒有完全理解系統(tǒng)的表明利益相關(guān)者仍然沒有完全理解系統(tǒng)

46、的需求。需求。需求模型的元素v有很多不同的方法考察計算機系統(tǒng)的需求。有很多不同的方法考察計算機系統(tǒng)的需求。某些軟件人員堅持最好選擇一個表達模式某些軟件人員堅持最好選擇一個表達模式（如用例）并排斥所有其他模式。有些專（如用例）并排斥所有其他模式。有些專業(yè)人士則相信使用許多不同的表現(xiàn)模式來業(yè)人士則相信使用許多不同的表現(xiàn)模式來描述需求模型是值得的，不同的表達模式描述需求模型是值得的，不同的表達模式促使軟件團隊從不同的角度考慮需求促使軟件團隊從不同的角度考慮需求一種方法更有可能造成需求遺漏、不一致一種方法更有可能造成需求遺漏、不一致性和歧義性。性和歧義性。基于場景的元素v使用基于場景的方法可以從用戶的

47、視角描使用基于場景的方法可以從用戶的視角描述系統(tǒng)。例如，基本的用例及其相應的用述系統(tǒng)。例如，基本的用例及其相應的用例圖演化成更精細的基于模板的用例。課例圖演化成更精細的基于模板的用例。課本圖本圖4-3描繪了一張使用用例引發(fā)的需求并描繪了一張使用用例引發(fā)的需求并表達它們的表達它們的UML活動圖?；顒訄D。導出需求的UML活動圖課本圖4-3 導出需求的UML活動圖基于類的元素v每個使用場景都暗示著當一個參與者和系每個使用場景都暗示著當一個參與者和系統(tǒng)交互時所操作的一組對象，這些對象被統(tǒng)交互時所操作的一組對象，這些對象被分成類分成類具有相似屬性和共同行為的事具有相似屬性和共同行為的事物集合。例如：可以用物集合。例如：