第三章需求工程概論

3.1軟件需求的概念

軟件需求的分類

軟件需求的質(zhì)量要素

3.2需求工程的預(yù)備知識(shí)

與用戶交流的技巧

需求調(diào)查的基本方法

需求建模的基本方法

3.3需求工程的過程模型

需求工程中的活動(dòng)

迭代式的過程模型

過程模型的裁剪

2023/2/61需求的任務(wù)：回答“系統(tǒng)必須做什么？”的問題What?2023/2/62第三章需求工程概論軟件需求的定義：是利益相關(guān)方（stakeholder，也稱“籌碼持有者”）對(duì)目標(biāo)軟件系統(tǒng)在功能、質(zhì)量等方面的期望，以及對(duì)目標(biāo)軟件系統(tǒng)在運(yùn)行環(huán)境、資源消耗等方面的要求或約束。2023/2/633.1軟件需求的概念3.1.1軟件需求的分類軟件需求:功能需求質(zhì)量需求約束性需求質(zhì)量需求和約束性需求可統(tǒng)稱為非功能需求。2023/2/64軟件需求的概念功能需求：指利益相關(guān)方要求目標(biāo)軟件系統(tǒng)應(yīng)該具有的功能。（主體）如“制訂選課計(jì)劃”、“接收并處理傳感器數(shù)據(jù)”等。功能需求還包括軟件系統(tǒng)在業(yè)務(wù)處理過程中完成這些功能時(shí)必須遵守的約定或限制。2023/2/65質(zhì)量需求:利益相關(guān)方對(duì)目標(biāo)軟件系統(tǒng)的質(zhì)量要求。性能：所有界面操作的響應(yīng)時(shí)間小于1.5秒”可靠性：任何故障不可導(dǎo)致用戶已提交的數(shù)據(jù)丟失”2023/2/66軟件需求的概念約束性需求:利益相關(guān)方對(duì)目標(biāo)軟件系統(tǒng)在項(xiàng)目預(yù)算、完成時(shí)間、技術(shù)選型、遵循的標(biāo)準(zhǔn)與規(guī)范等方面提出的要求，以及由預(yù)期的開發(fā)、運(yùn)行環(huán)境的特征而導(dǎo)致的針對(duì)目標(biāo)軟件系統(tǒng)的約束。如家庭保安系統(tǒng)中可供軟件使用的內(nèi)存為1M、必須采用特定的操作系統(tǒng)2023/2/67軟件需求的概念3.1.2軟件需求的質(zhì)量要素軟件需求的質(zhì)量要素：正確性包含真實(shí)性、一致性、精確性、無冗余四個(gè)質(zhì)量指標(biāo)。完全性指，所有需求項(xiàng)構(gòu)成的全集完整地覆蓋所有必須在目標(biāo)軟件產(chǎn)品中實(shí)現(xiàn)的利益相關(guān)方需求，不能遺漏重要或者緊迫的需求。可行性是指，在實(shí)際資源約束條件下，軟件需求能夠被完整實(shí)現(xiàn)的可能性。2023/2/683.2需求工程的預(yù)備知識(shí)與用戶交流的技巧利益相關(guān)方代表和需求工程師組成聯(lián)合工作組克服溝通障礙消彌利益沖突2023/2/69需求調(diào)查的基本方法訪談和會(huì)議系統(tǒng)分析員將提出一些事先準(zhǔn)備好的具體問題。調(diào)查問卷經(jīng)過仔細(xì)考慮寫出的書面回答可能比被訪者對(duì)問題的口頭回答更準(zhǔn)確。業(yè)務(wù)文檔分析現(xiàn)場(chǎng)觀摩2023/2/6103.2需求工程的預(yù)備知識(shí)需求建模的基本方法抽象分解多視點(diǎn)分析2023/2/6113.3需求工程的過程模型一個(gè)完整的需求工程過程一般包含以下活動(dòng):需求工程策劃需求獲取需求獲取的結(jié)果是軟件需求的最初模型。需求分析需求規(guī)范化需求驗(yàn)證總結(jié)

2023/2/612需求工程中的活動(dòng)2023/2/613圖3.1用UML活動(dòng)圖表示的需求工程過程的工作流圖3.2單次子過程中的缺陷追蹤及返工3.3.2迭代式的過程模型對(duì)于大中型軟件項(xiàng)目，前述的單次需求工程過程幾乎不可能獲得完整的、高質(zhì)量的軟件需求。2023/2/614圖3.3迭代式的需求工程過程模型迭代式的過程模型進(jìn)入每次迭代前，應(yīng)檢查入口條件是否滿足、輸入文檔是否齊備。在完成每次迭代前，應(yīng)檢查出口條件是否達(dá)到、輸出文檔是否齊備并符合預(yù)定的質(zhì)量標(biāo)準(zhǔn)。首次迭代的輸入為有關(guān)項(xiàng)目目標(biāo)、范圍的陳述性文檔；后續(xù)迭代時(shí)，輸入文檔還可以包括缺陷描述、待新增的需求項(xiàng)的概略性描述文檔，或者需求變更申請(qǐng)書。需求獲取活動(dòng)必須針對(duì)前次迭代的工作成果、需求變更或缺陷報(bào)告進(jìn)行理解和分析，由此導(dǎo)出新的需求獲取動(dòng)作。在一次迭代完成后進(jìn)入后續(xù)迭代的條件是，所有參與者對(duì)新需求的獲取或針對(duì)已有需求的變更之必要性達(dá)成共識(shí)。2023/2/6153.3.3過程模型的裁剪在實(shí)際的軟件項(xiàng)目中，針對(duì)前述的迭代式過程模型可以進(jìn)行因地制宜的裁剪或具體化。（一）應(yīng)用場(chǎng)景1：小型項(xiàng)目對(duì)于小型軟件項(xiàng)目或軟件需求容易確立的項(xiàng)目，迭代僅需進(jìn)行一次。因此，其需求工程的過程模型可簡(jiǎn)化為圖3.1或圖3.2所示的形式。2023/2/616過程模型的裁剪（二）應(yīng)用場(chǎng)景2：分解、并行如果一個(gè)軟件能夠分解成多個(gè)子系統(tǒng)，那么，針對(duì)各子系統(tǒng)的需求工程活動(dòng)可以并行地在各自的迭代子過程中進(jìn)行。此前必須通過至少一個(gè)迭代子過程給出整個(gè)軟件的概略性需求并確定分解結(jié)構(gòu)；最后必須通過至少一個(gè)迭代子過程對(duì)各部分的需求進(jìn)行整合并給出完整的軟件需求規(guī)約。2023/2/6172023/2/618圖3.4系統(tǒng)分解后針對(duì)子系統(tǒng)并行迭代的需求工程過程模型示意圖過程模型的裁剪需求工程各階段中的某些子活動(dòng)可以并行開展。如，可以將課程注冊(cè)管理系統(tǒng)劃分為面向?qū)W生、面向教師和面向教務(wù)管理員的三個(gè)子系統(tǒng)，安排三輪迭代分別針對(duì)它們進(jìn)行需求獲取和分析，最終整合為完整的需求規(guī)約。2023/2/619過程模型的裁剪（三）應(yīng)用場(chǎng)景3：需求缺陷更正在本次迭代的需求驗(yàn)證階段，如果發(fā)現(xiàn)了缺陷，或認(rèn)為某些需求項(xiàng)需要新增或變更，可以形成缺陷分析報(bào)告或需求變更申請(qǐng)報(bào)告，以此為輸入啟動(dòng)下次迭代。在迭代式過程模型中，缺陷更正和需求變更可以很自然地在后續(xù)迭代過程中實(shí)現(xiàn)。2023/2/620圖3.5通過迭代支持缺陷更正和需求變更的需求工程過程模型2023/2/621例3.1家庭保安系統(tǒng)需求工程過程成立聯(lián)合工作組由需求工程師和利益相關(guān)方代表組成制定工作制度如，每次會(huì)議開始前必須有確定的議程，參加者必須針對(duì)各項(xiàng)議程進(jìn)行充分的準(zhǔn)備，這種準(zhǔn)備不僅是思想上的，還應(yīng)形諸文字。經(jīng)過數(shù)次會(huì)議討論，全面列舉需求側(cè)面明確待解軟件問題的范圍、業(yè)務(wù)背景，并就開發(fā)軟件產(chǎn)品的必要性達(dá)成共識(shí)后，工作組負(fù)責(zé)人要求每位參加者列出應(yīng)用問題及環(huán)境中有關(guān)的對(duì)象，這些對(duì)象所施行的操作以及對(duì)象間的相互作用。這種列舉不一定完全，但應(yīng)盡可能全面地反映用戶熟悉的某個(gè)問題側(cè)面。2023/2/622需求工程過程可能分工市場(chǎng)營(yíng)銷人員可能列出控制面板、電話機(jī)、警報(bào)器等對(duì)象，以及用戶配置、電話拔號(hào)、報(bào)警等操作；負(fù)責(zé)策劃該系統(tǒng)的客戶可能列舉門窗監(jiān)視器、煙霧傳感器、警報(bào)器等對(duì)象。會(huì)議上，負(fù)責(zé)人要求他們對(duì)傳感器事件接收、異常情形判別、電話報(bào)警、用戶配置等操作進(jìn)行更詳細(xì)的描述，必要時(shí)示以業(yè)務(wù)處理流程圖。客戶可能還會(huì)提出一些約束條件，如造價(jià)不應(yīng)超過1,000元，對(duì)異常事件必須在1秒內(nèi)作出響應(yīng)，事件必須按優(yōu)先級(jí)順序進(jìn)行處理，等。會(huì)后，形成文檔由需求工程師對(duì)這些信息加以綜合、整理該文檔應(yīng)能反映家庭保安系統(tǒng)中的軟件產(chǎn)品的全貌2023/2/623需求工程過程該文檔的某個(gè)局部可能形如：2023/2/624家庭保安系統(tǒng)的軟件允許用戶在安裝時(shí)進(jìn)行系統(tǒng)配置，實(shí)施對(duì)傳感器上報(bào)數(shù)據(jù)的監(jiān)控并通過控制面板與用戶進(jìn)行信息交互。用戶配置操作包括：(1)指定每一傳感器的種類、編號(hào)和安裝位置；(2)設(shè)置開、關(guān)機(jī)密碼；(3)設(shè)定報(bào)警電話號(hào)碼；(4)指定報(bào)警延遲和電話重拔延遲時(shí)間。

當(dāng)軟件系統(tǒng)接收到傳感器發(fā)出的數(shù)據(jù)后判別是否出現(xiàn)異常事件。如果是，則在指定的延遲時(shí)間內(nèi)拔報(bào)警電話號(hào)碼，拔號(hào)操作將按照重拔延遲反復(fù)進(jìn)行，直至電話接通。然后軟件系統(tǒng)負(fù)責(zé)報(bào)告時(shí)間、位置和異常事件的性質(zhì)。開機(jī)后軟件系統(tǒng)負(fù)責(zé)顯示當(dāng)前工作狀態(tài)，接收并處理用戶指令。需求工程過程聯(lián)合工作組被分成兩個(gè)小組，分別處理用戶配置和傳感器監(jiān)測(cè)子系統(tǒng)。分組的目的是對(duì)子問題的需求進(jìn)行獲取、分析、規(guī)范化等項(xiàng)工作。在各子系統(tǒng)的需求已基本明確并形成需求模型后，聯(lián)合工作組還應(yīng)就子系統(tǒng)的整合及需求驗(yàn)證標(biāo)準(zhǔn)展開討論。子系統(tǒng)整合包括：子系統(tǒng)接口之間的一致性檢查、子系統(tǒng)合成后系統(tǒng)功能和行為的完整性檢查。需求驗(yàn)證標(biāo)準(zhǔn)應(yīng)該是可測(cè)試的以便開發(fā)人員在代碼生成后能夠通過測(cè)試結(jié)果向客戶表明軟件系統(tǒng)已完整地實(shí)現(xiàn)了所有需求。2023/2/625小結(jié)軟件需求指，利益相關(guān)方對(duì)目標(biāo)軟件系統(tǒng)在功能、性能、質(zhì)量等方面的期望，以及對(duì)目標(biāo)軟件系統(tǒng)在運(yùn)行環(huán)境、資源消耗等方面的約束。軟件需求可劃分為功能需求、質(zhì)量需求和約束性需求三種類型。質(zhì)量需求和約束性需求統(tǒng)稱為非功能需求。軟件需求的質(zhì)量要素包括正確性、完全性和可行性。為了獲得高質(zhì)量的需求模型，需求工程師必須掌握與用戶/客戶交流的技巧。2023/2/626小結(jié)與利益相關(guān)方代表組成目標(biāo)一致、榮辱與共的聯(lián)合工作組，克服開發(fā)方與利益相關(guān)方之間的溝通障礙、消彌他們之間的利益沖突。需求工程師必須熟練運(yùn)用需求調(diào)查和需求建模的基本方法，前者包括訪談和會(huì)議、調(diào)查問卷、業(yè)務(wù)文檔分析、現(xiàn)場(chǎng)觀摩，后者包括抽象、分解和多視點(diǎn)分析。為了獲得高質(zhì)量的需求模型，需求工程師還必須遵循系統(tǒng)化的需求工程過程模型，它通常包括策劃、需求獲取、需求分析、需求規(guī)范化、需求驗(yàn)證、總結(jié)等活動(dòng)。2023/2/627小結(jié)對(duì)大中型軟件項(xiàng)目以及初期需求不明朗的軟件項(xiàng)目，需求工程過程往往采用迭代方式，經(jīng)過反復(fù)發(fā)掘、分析、評(píng)審后才能日臻完善。除以上基本技能和方法外，需求工程師有必要進(jìn)一步掌握分別針對(duì)需求工程各階段的行之有效的具體技術(shù)和方法。第四至五章將依次介紹需求獲取、需求分析及需求驗(yàn)證的過程和技術(shù)。2023/2/628問題A圖書館管理(R.A.Kemmerer)一個(gè)小型圖書館管理系統(tǒng)，需完成以下工作：(1)借書、還書；(2)圖書館中增加/刪除一本書；(3)照作者名或?qū)I(yè)領(lǐng)域檢索一批書；(4)出被某位讀者借出的一批書；(5)出最近借走某本圖書的讀者。該系統(tǒng)有兩類用戶：圖書管理員與普通讀者。

功能(4)可供普通讀者查找他們自己借出的書目。

功能(1)、(2)、(5)只供圖書管理員使用。該系統(tǒng)必須滿足以下限制：(1)館中所有未借出的書籍能夠供讀者隨時(shí)借閱。(2)在同一時(shí)刻，一本書不能既被借出，又可供借閱。(3)一個(gè)讀者一次借出的書籍?dāng)?shù)目不能超過預(yù)定值。2023/2/629問題B保溫系統(tǒng)(S.White)如果主開關(guān)置于“加熱”狀態(tài)，保溫系統(tǒng)的控制器負(fù)責(zé)開關(guān)鍋爐，監(jiān)視鍋爐系統(tǒng)的燃油流率和燃燒狀態(tài)，進(jìn)而調(diào)節(jié)進(jìn)入房間的熱量流。當(dāng)室內(nèi)溫度降至T－2度以下，控制器啟動(dòng)鍋爐。這里T是用戶設(shè)定的理想室溫。鍋爐啟動(dòng)過程如下：(1)控制器向鍋爐的馬達(dá)發(fā)信號(hào)。(2)控制器監(jiān)視馬達(dá)速度。馬達(dá)達(dá)到正常操作速度時(shí)，啟動(dòng)點(diǎn)火并打開油閥。(3)控制器監(jiān)視水溫，一旦水溫達(dá)到預(yù)定值時(shí)，它發(fā)信號(hào)打開水流循環(huán)閥。熱水開始在室內(nèi)循環(huán)。(4)如果發(fā)生異常情況，燃油流率指示器和光感器向控制器發(fā)信號(hào)。此時(shí)控制器發(fā)信號(hào)關(guān)閉系統(tǒng)。(5)一旦室內(nèi)溫度達(dá)到T+2度，控制器首先關(guān)閉油閥，延遲5秒后關(guān)閉鍋爐馬達(dá)。系統(tǒng)須滿足以下限制：(1)鍋爐停機(jī)后重啟必須延遲5分鐘。(2)在主開關(guān)關(guān)閉或油閥關(guān)閉5秒內(nèi)應(yīng)指示鍋爐停機(jī)。2023/2/630問題C字符串格式化(A.Mili)給定非負(fù)整數(shù)MAXPOS和包含空格與換行作為分隔符的字符集。對(duì)字符串S，稱兩分隔符之間或分隔符到S的結(jié)尾處的非空字符串為字。程序以有窮字符串為輸入，輸出滿足以下條件的字符串：(1)如果輸入串包含長(zhǎng)度為MAXPOS+1的字，則輸出串為一空格。(2)如果輸入串的任何MAXPOS+1個(gè)相鄰字符至少含有一個(gè)分隔符，則：(2.1)輸入串的所有字以相同的次序出現(xiàn)在輸出串中；并且，輸出串不含有未在輸入串中出現(xiàn)的字；(2.2)此外，輸出串滿足以下限制：(2.2.1)輸出串中不出現(xiàn)前導(dǎo)和后導(dǎo)分隔符，也不出現(xiàn)相鄰的分隔符。(2.2.2)任何MAXPOS+1個(gè)相鄰字符中含有一個(gè)換行符；(2.2.3)對(duì)于輸出串中的任意子串S，如果：(a)S的長(zhǎng)度不超過MAXPOS；(b)S是輸出串的首部，或S的前一字符是換行符；(c)S是輸出串的尾部，或S的后一字符是空格符。那么，S中不包含換行符。2023/2/631問題D電梯問題(N.Davb)在M層的建筑物內(nèi)安裝N個(gè)電梯。電梯問題是指這些電梯的邏輯控制問題：(1)每個(gè)電梯有一些按鈕，每個(gè)按鈕對(duì)應(yīng)一個(gè)樓層。當(dāng)按下按鈕后，按扭燈亮，并指出電梯開往相應(yīng)的樓層。當(dāng)電梯到達(dá)該樓層后，按鈕燈熄滅。(2)除底層和頂層只有一個(gè)按鈕外，每個(gè)樓層有兩個(gè)按鈕，分別指示上樓和下樓請(qǐng)求。當(dāng)按下后，按鈕燈亮。如果電梯已到達(dá)該樓層