《軟件工程基礎(chǔ)》第2章 軟件需求獲取與確定

1、2.1 軟件需求獲取的任務(wù) 軟件需求（software requirement）是為了解決用戶的問題或?qū)崿F(xiàn)用戶的目標(biāo)，用戶所需的軟件必須滿足的能力和條件 。獲取軟件需求要涉及到多種人員，每種人員對(duì)需求的描述是不同的 主要的需求種類 業(yè)務(wù)需求：描述了使用軟件系統(tǒng)要達(dá)到什么目標(biāo)。系統(tǒng)需求：為了滿足用戶解決問題需要的條件或能力，系統(tǒng)或系統(tǒng)成分必須滿足或具有的條件或能力。功能需求：規(guī)定了軟件必須實(shí)現(xiàn)的功能性需求。 非功能需求 :在滿足功能需求的基礎(chǔ)上，軟件系統(tǒng)還必須具有一定的特性和必須遵循一定的約束，非功能需求描述相應(yīng)的特性和約束。 2.2 軟件需求的獲取與確認(rèn)過程 2.3 快速原型化方法原型法（pr

2、ototyping）是這樣的一種軟件開發(fā)技術(shù)，通過開發(fā)軟件的初期版本讓用戶進(jìn)行反饋來確定軟件的可行性，研究開發(fā)技術(shù)或開發(fā)過程支持的其他問題。快速原型化（rapid prototyping）是一種原型法，它的重點(diǎn)是在開發(fā)過程的早期就開發(fā)出原型，使反饋和分析提前，以支持開發(fā)過程1。2.3 快速原型化方法（1）演示原型 通過演示原型向用戶展示一些界面，讓用戶判斷基于該原型的系統(tǒng)是否能夠滿足他們的要求。（2） 技術(shù)驗(yàn)證原型 該原型在技術(shù)層上實(shí)現(xiàn)軟件的部分功能，以驗(yàn)證技術(shù)上的可行性。2.4 基于用況的方法基于用況的方法通過建立用況模型來獲取與確定需求。在建立用況模型時(shí)，要確定系統(tǒng)邊界，找出在系統(tǒng)邊界以外

3、與系統(tǒng)交互的事物，然后從這些事物與系統(tǒng)進(jìn)行交互的角度，通過用況來描述這些事物怎樣使用系統(tǒng)，以及系統(tǒng)向它們提供什么功能。 2.4.1系統(tǒng)邊界系統(tǒng)邊界是系統(tǒng)的所有內(nèi)部成分與系統(tǒng)以外各種事物的分界線。 系統(tǒng)只通過邊界上的有限個(gè)接口與外部的系統(tǒng)使用者（人員、設(shè)備或外系統(tǒng)）進(jìn)行交互。 2.4.1系統(tǒng)邊界現(xiàn)實(shí)世界中的事物與系統(tǒng)的關(guān)系包括如下幾種情況：某些事物位于系統(tǒng)邊界內(nèi)，作為系統(tǒng)成分。 某些事物位于系統(tǒng)邊界外，作為參與者。某些事物可能既有一個(gè)對(duì)象作為其抽象描述，而本身（作為現(xiàn)實(shí)世界中的事物）又是在系統(tǒng)邊界以外與系統(tǒng)進(jìn)行交互的參與者。某些事物即使屬于問題域，也與系統(tǒng)責(zé)任沒有什么關(guān)系。認(rèn)識(shí)清楚上述事物之間的

4、關(guān)系，也就劃分出了系統(tǒng)邊界。2.4.2參與者參與者(actor)定義了一組在功能上密切相關(guān)的角色，當(dāng)一個(gè)事物與系統(tǒng)交互時(shí)，該事物可以扮演這樣的角色。 參與者的表示法 2.4.2參與者識(shí)別參與者 參與者是在系統(tǒng)之外的與系統(tǒng)進(jìn)行交互的任何事物。這些事物可為人員、外部系統(tǒng)或設(shè)備。 2.4.2參與者人員直接使用系統(tǒng)的人員是參與者。這里強(qiáng)調(diào)的是直接使用，而不是間接使用。外部系統(tǒng)所有與本系統(tǒng)交互的外部系統(tǒng)都是參與者。 相對(duì)于當(dāng)前在正在開發(fā)的系統(tǒng)而言，外部系統(tǒng)可以是其他子系統(tǒng)、下級(jí)系統(tǒng)或上級(jí)系統(tǒng)，也即任何與它進(jìn)行協(xié)作的系統(tǒng)，但對(duì)這樣的系統(tǒng)的開發(fā)并不是開發(fā)本系統(tǒng)的人員的責(zé)任。設(shè)備識(shí)別所有與系統(tǒng)交互的設(shè)備：這樣

5、的設(shè)備與系統(tǒng)相連并向系統(tǒng)提供外界信息，也可能系統(tǒng)要向這樣的設(shè)備提供信息，設(shè)備在系統(tǒng)的控制下運(yùn)行。2.4.3 用況用況(use case)是描述系統(tǒng)的一項(xiàng)功能的一組動(dòng)作序列，這樣的動(dòng)作序列表示參與者與系統(tǒng)間的交互，系統(tǒng)執(zhí)行該動(dòng)作序列要為參與者產(chǎn)生結(jié)果。用況名用況的表示法 2.4.3 用況使用用況來可視化、詳述、構(gòu)造和文檔化所希望的系統(tǒng)行為。盡管用況中描述的行為是系統(tǒng)級(jí)的，但在用況內(nèi)所描述的交互中的動(dòng)作應(yīng)該是詳細(xì)的，準(zhǔn)則是對(duì)用況的理解不產(chǎn)生歧義即可。若描述得過于綜合，則不易認(rèn)識(shí)清楚系統(tǒng)的功能。用況描述中的一個(gè)動(dòng)作應(yīng)該描述參與者或系統(tǒng)要完成的交互中的一個(gè)步驟。在用況中只描述參與者和系統(tǒng)彼此為對(duì)方直接

6、地做了些什么事，不描述怎么做，也不描述間接地做了些什么。系統(tǒng)所產(chǎn)生的結(jié)果，是指系統(tǒng)對(duì)參與者的動(dòng)作要做出響應(yīng)。用況描述的是參與者所使用的一項(xiàng)系統(tǒng)功能，該項(xiàng)功能應(yīng)該相對(duì)完整。也即應(yīng)該保證用況是某一項(xiàng)功能的完整的規(guī)格說明，而不能只是其中的一個(gè)片段。在用況描述中，由參與者首先發(fā)起交互的可能性較大，但有些交互也可能是由系統(tǒng)首先發(fā)起的。 收款員收款輸入開始本次收款的命令； 作好收款準(zhǔn)備，應(yīng)收款總 數(shù)置為0，輸出提示信息；for 顧客選購(gòu)的每種商品 do 輸入商品編號(hào)； if 此種商品多于一件 then 輸入商品數(shù)量 end if； 檢索商品名稱及單價(jià)； 貨架商品數(shù)減去售出數(shù)； if 貨架商品數(shù)低于下限th

7、en 通知供貨員請(qǐng)求上貨 end if； 計(jì)算本種商品總價(jià)并打印編號(hào)、 名稱、數(shù)量、單價(jià)、總價(jià)； 總價(jià)累加到應(yīng)收款總數(shù)；end for； 打印應(yīng)收款總數(shù)；輸入顧客交來的款數(shù)； 計(jì)算應(yīng)找回的款數(shù)， 打印以上兩個(gè)數(shù)目， 應(yīng)收款數(shù)計(jì)入帳冊(cè)。例2.4.3 用況用況與參與者之間的關(guān)系 一個(gè)參與者可以同多個(gè)用況交互，一個(gè)用況也可以同多個(gè)參與者交互。把參與者與用況間的這種交互關(guān)系稱為關(guān)聯(lián)。若沒做具體的規(guī)定，交互是雙向的，即參與者能夠?qū)ο到y(tǒng)進(jìn)行請(qǐng)求，系統(tǒng)也能夠要求參與者采取某些動(dòng)作。把參與者和用況之間的關(guān)聯(lián)表示成參與者和用況之間的一條實(shí)線。若要明確地指出參與者和用況之間的通訊是單向的，就在關(guān)聯(lián)線上接收通訊的那

8、端加一個(gè)箭頭，用以指示方向。 2.4.3 用況收款檢查售貨員統(tǒng)計(jì)員2.4.3 用況1）包含 A用況XA用況Y A(A)(A)用況X用況Y 2.4.3 用況 從基用況到被包含用況的包含關(guān)系表明：基用況在它內(nèi)部說明的某一（些）位置上顯式地使用供應(yīng)者用況的行為的結(jié)果。 通過一個(gè)敞開的虛線箭頭表示用況之間的包含關(guān)系，該箭頭從基用況指向被包含的用況。這個(gè)箭頭用關(guān)鍵字標(biāo)記。被包含用況基用況2.4.3 用況2.4.3 用況1）擴(kuò)展 If AIF CIF AIF C用況X用況Y A CIF (A)IF (C)IF(A)IF (C)用況X用況Y 2.4.3 用況 從基用況到擴(kuò)展用況的擴(kuò)展關(guān)系表明：按基用況中指定

9、的擴(kuò)展條件，把擴(kuò)展用況的行為插入到由基用況中的擴(kuò)展點(diǎn)定義的位置。 通過敞開的虛線箭頭表示用況之間的擴(kuò)展關(guān)系，該箭頭從提供擴(kuò)展的用況指向基用況。這個(gè)箭頭用關(guān)鍵字標(biāo)記?？梢栽谶@個(gè)關(guān)鍵字附近表示這個(gè)關(guān)系的條件。基用況擴(kuò)展用況基用況是可單獨(dú)存在的，但是在一定的條件下，它的行為可以被另一個(gè)用況的行為擴(kuò)展。在擴(kuò)展用況中可定義一組行為增量，在其中定義的行為離開基用況單獨(dú)是沒意義的。 一個(gè)擴(kuò)展用況可以擴(kuò)展多個(gè)用況，一個(gè)用況也可以被多個(gè)用況擴(kuò)展，甚至一個(gè)擴(kuò)展用況自身也可以被其他擴(kuò)展用況來擴(kuò)展。 2.4.3 用況 一個(gè)擴(kuò)展點(diǎn)是基用況中的一個(gè)位置，在這樣的位置上，如果擴(kuò)展條件為真，就在其中插入擴(kuò)展用況中描述的全部動(dòng)

10、作序列或其中的一部分，并予以執(zhí)行。執(zhí)行完后，基用況繼續(xù)執(zhí)行擴(kuò)展點(diǎn)下面的行為。如果擴(kuò)展條件為假，擴(kuò)展不會(huì)發(fā)生。 可以把擴(kuò)展點(diǎn)列在用況中的一個(gè)題頭為“擴(kuò)展點(diǎn)”的分欄中。以一種適當(dāng)?shù)姆绞浇o出擴(kuò)展點(diǎn)的位置描述，通常采用普通的文本。 基用況擴(kuò)展用況2.4.3 用況3）泛化 用況之間的泛化關(guān)系就像類之間的泛化關(guān)系一樣。子用況繼承父用況的行為和含義；子用況還可以增加或覆蓋父用況的行為；子用況可以出現(xiàn)在父用況出現(xiàn)的任何位置（父和子均有具體的實(shí)例）。 用一個(gè)指向父用況的帶有封閉的空心箭頭的實(shí)線來表示用況之間的泛化關(guān)系。 BA捕獲用況1）利用參與者捕獲用況 對(duì)所有的參與者（把自己作為參與者），提問下列問題： 每個(gè)

11、參與者的主要任務(wù)是什么？粗粒度它們參加了什么在本質(zhì)上是不同的過程？能完成特定功能的每一項(xiàng)活動(dòng)明確地是一個(gè)用況。這些參與者參與的活動(dòng)，通常會(huì)導(dǎo)致其它用況。 2.4.3 用況 2）從系統(tǒng)功能角度捕獲用況（1）以窮舉的方式檢查用戶對(duì)系統(tǒng)的功能需求是否能在各個(gè)用況中體現(xiàn)出來。（2）以窮舉的方式考慮每一個(gè)參與者與系統(tǒng)的交互情況，看看每個(gè)參與者要求系統(tǒng)提供什么功能，以及參與者的每一項(xiàng)輸入信息將要求系統(tǒng)作出什么反映，進(jìn)行什么處理。（3）考慮對(duì)例外情況的處理。針對(duì)用況描述的基本流，要詳盡地考慮各種其他的情況 （4） 一個(gè)用況描述一項(xiàng)功能，這項(xiàng)功能不能過大。例如，把一個(gè)企業(yè)信息管理系統(tǒng)粗略地分為生產(chǎn)管理、供銷管

12、理、財(cái)務(wù)管理和人事管理等幾大方面的功能，就顯得粒度太大了，應(yīng)該再進(jìn)行細(xì)化。（5）一個(gè)用況應(yīng)該是一個(gè)完整的任務(wù)，通常應(yīng)該在一個(gè)相對(duì)短的時(shí)間段內(nèi)完成。如果一個(gè)用況的各部分被分配在不同的時(shí)間段，尤其被不同的參與者執(zhí)行，最好還是將各部分作為單獨(dú)的用況對(duì)待。2.4.3 用況場(chǎng)景用況抽象3）、使用場(chǎng)景技術(shù) 如果不能順利地確定一個(gè)用況的描述，可 “角色扮演”技術(shù)。 2.4.3 用況描述用況用況文檔模板用況名描述：對(duì)該用況的一句或兩句的描述。參與者：該用況的參與者。包含：該用況所包含的用況，以及包含它的用況。擴(kuò)展：該用況可以擴(kuò)展的用況，以及擴(kuò)展它的用況。泛化：該用況的子用況和父用況。前置條件：?jiǎn)?dòng)該用況所必須

13、具備的條件。細(xì)節(jié)：該用況的細(xì)節(jié)。（基本流與可選流）后置條件：在該用況結(jié)束時(shí)確保成立的條件。例外：在該用況的執(zhí)行的過程中可能引起的例外*。限制：在應(yīng)用中可能出現(xiàn)的任何限制*。注釋：對(duì)該用況是重要的任何附加信息。2.4.3 用況2.4.4 用況圖用況圖是一幅由一組參與者、一組用況以及這些元素之間的關(guān)系組成的圖。 處理取款單業(yè)務(wù)員輸入處理取款命令I(lǐng)nclude 檢查口令收集客戶的取款單上的信息；加急（擴(kuò)展點(diǎn)）如果客戶選擇了加急 extend 處理加急取款單檢查口令基本流：系統(tǒng)提示客戶輸入密碼。客戶按鍵輸入密碼，并按“輸入”按鈕確認(rèn)。系統(tǒng)校驗(yàn)這個(gè)密碼，如果有效，系統(tǒng)承認(rèn)這次登錄?？蛇x流：客戶可以在任何

14、時(shí)間按“取消”按鈕取消輸入，然后該用況重新開始?？蛇x流：客戶可以在確認(rèn)之前的任何時(shí)刻清除密碼，并重新輸入密碼。可選流：如果客戶輸入了一個(gè)無效的密碼，用況重新開始。如果連續(xù)3次無效，系統(tǒng)將禁止用戶再次輸入口令。2.5 需求管理（1）需求標(biāo)識(shí)和分類若功能需求的數(shù)目較大且以后往往要發(fā)生變化，需要為每個(gè)功能性需求指定一個(gè)唯一的標(biāo)識(shí)，為以后的引用需求、變更需求、跟蹤需求和復(fù)用需求提供便利。最簡(jiǎn)單的方式是為每個(gè)需求賦予一個(gè)唯一的序列號(hào)?？梢詾樾蛄刑?hào)規(guī)定一個(gè)結(jié)構(gòu)，如用序列號(hào)的前2項(xiàng)描述需求的類型。也可以按功能需求的抽象層次來進(jìn)行數(shù)字編號(hào) 2.5 需求管理若需求量較大，則應(yīng)該進(jìn)行分類組織，以便編寫文檔和使用。采用數(shù)字編號(hào)的方式為需求指定標(biāo)識(shí)時(shí)，也可能涉及對(duì)需求分類的問題。常見的分類方式有：現(xiàn)場(chǎng)記錄下來的用戶工作場(chǎng)景；從場(chǎng)景抽象出來的用況；業(yè)務(wù)規(guī)則；功能性需求；軟件質(zhì)量的屬性，如安全、可靠和易用等；外部接口需求，如用戶界面、硬件接口與其它軟件的接口等；對(duì)設(shè)計(jì)與實(shí)現(xiàn)等約束；業(yè)務(wù)數(shù)據(jù)項(xiàng)的定義，如數(shù)據(jù)項(xiàng)的數(shù)據(jù)格式、數(shù)據(jù)類型、缺省值等；等等。2.5 需求管理（2）變更管理需求變化是不可避免的。在軟件利益相關(guān)者對(duì)軟件需求達(dá)到共識(shí)后，需要定義需求基線。需求基線是經(jīng)過正