1、第3章需求工程、需求工程概要獲得需求分析、協(xié)商與建模需求規(guī)約與驗證需求管理、需求工程概要Alan Davis將需求工程概述為“將軟件分解為實際的體系結(jié)構(gòu)組件之前的所有活動(但不包括Herb Krasner定義了需求工程的五個生命周期。 需求的定義和分析、需求的決定、需求規(guī)格的形成、需求的實現(xiàn)和驗證、需求發(fā)展管理Matthias Jarke和Klaus Pohl提出了三階段循環(huán)的學(xué)說：獲取、表示和驗證、軟件需求工程分為需求獲取、需求分析和協(xié)議、系統(tǒng)建模、需求規(guī)約、需求驗證和需求管理六個階段系統(tǒng)分析師通過與用戶的交流，對系統(tǒng)或產(chǎn)品的范圍進行有限的說明，對系統(tǒng)或產(chǎn)品相關(guān)人員和特征的列表，對系統(tǒng)的技術(shù)

2、環(huán)境的說明，對系統(tǒng)功能的列表和適用于各種需求的領(lǐng)域的限制，對不同運行條件下的系統(tǒng)或產(chǎn)品的使用情況進行說明的一系列應(yīng)用程序需求獲得的工作產(chǎn)品提供進行需求分析的基礎(chǔ)，與需求分析進行協(xié)商，需求獲得結(jié)束后，分析活動對需求進行分類組織，分析各需求的其他需求的關(guān)系，檢查需求的一致性、重復(fù)和遺漏的情況，根據(jù)用戶的需求進行排序。 在需求獲得階段，用戶的要求超出軟件系統(tǒng)能夠?qū)崿F(xiàn)的范圍，或者實現(xiàn)能力的問題經(jīng)常發(fā)生。不同的用戶使用相互沖突的需求、系統(tǒng)建模、建模工具是用戶和系統(tǒng)分析師之間的統(tǒng)一語言常見的分析和建模方法包括面向數(shù)據(jù)流的方法、面向數(shù)據(jù)結(jié)構(gòu)的方法和面向?qū)ο蟮姆椒ā?需求規(guī)約、軟件需求規(guī)約是分析任務(wù)的最終產(chǎn)物

3、，通過完整的信息描述、詳細的功能和行為描述、性能需求和設(shè)置修訂約束的說明、確立適當?shù)臋z驗標準，給予目標軟件各種各樣的需求。 需求規(guī)約作為用戶和開發(fā)者之間的協(xié)議，在以后的軟件工程的各個階段發(fā)揮著重要的作用。 作為需求驗證、需求開發(fā)階段工作的重新審視手段，需求驗證評價功能的正確性、完整性和明確性，以及其他需求。 為了保證軟件需求定義的質(zhì)量，審查應(yīng)由專門指定的人員負責(zé)，按規(guī)程嚴格執(zhí)行。 在實際的開發(fā)過程中，用于獲取、分析、建模、協(xié)議創(chuàng)建和驗證這些需求的開發(fā)活動不是線性的，也不是順序的。 實際上，這些活動是交叉、增加和重復(fù)的。 需求管理、需求工程包括軟件需求的獲取、分析、規(guī)定、驗證、管理，軟件需求管理

4、是所有相關(guān)活動的修訂版和控制。 也就是說，需求管理是一個系統(tǒng)化方案，用于捕獲、組織和記錄系統(tǒng)需求，以及用戶和項目團隊針對不斷變化的系統(tǒng)需求達成一致的過程。 需求獲取、軟件需求包括功能需求性能需求用戶或人的要素環(huán)境需求接口需求文檔需求、數(shù)據(jù)需求資源使用需求安全保密請求可靠性請求軟件成本消耗和開發(fā)進度需求其他非功能需求、需求獲取方法和策略、順利的通信路徑采訪和調(diào)查建立用戶操作過程， 建立和確立平穩(wěn)的通信渠道，采訪和調(diào)查在具體實踐中通常采用權(quán)衡的方法。 也就是說，我們正在對采訪進行適當?shù)男抻?，但不太詳細，能夠具有一定的靈活性。一般按照以下原則準備：被提問題應(yīng)該逐步從整體方面開始提問，下一個問題應(yīng)該有

5、助于更好地理解和細分上一個問題。 不要限制用戶對問題的回答。 這可能會導(dǎo)致本來沒有注意到的問題。問題和回答總結(jié)后，應(yīng)該能夠反映用戶需求的整體情況。 例如：“賽艇比賽成績核算系統(tǒng)”初次面談的準備修訂計劃可以觀察用戶的操作流程，在用戶的實際工作環(huán)境中觀察用戶的工作流程，理解用戶的實際操作環(huán)境、操作過程和操作要求，并與用戶提出的問題陳述相對照，使用戶的需求更加全面、組成聯(lián)合組，方便應(yīng)用規(guī)約技術(shù)(FAST ) :提出足夠的正式議程，打破用戶(用戶)和開發(fā)者(供應(yīng)商)的界限，制定組成聯(lián)合組的會議準備和參與規(guī)則，提出用戶、開發(fā)者、 或者可能是其他外部人員的協(xié)調(diào)員控制會議使用工作表、圖表、貼墻紙、貼墻板等定

6、義機制的目標是確定問題、提出解決方案的要素、協(xié)商不同的方法，在有助于實現(xiàn)目標的氣氛中描繪初步需求FAST會議步驟，1 )在開發(fā)人員和用戶之間進行初步訪問后，確定FAST會議的時間位置，并在會議日期之前向所有參與者發(fā)布產(chǎn)品請求。 2 )每個FAST出席者需要列出環(huán)繞系統(tǒng)環(huán)境的一系列對象以及對這些對象的操作或?qū)ο笾g的交互，并開發(fā)約束列表(成本、規(guī)模、權(quán)重等)和性能標準列表(速度、精度等) 這些列表可以不是窮舉的，但是希望每個列表能夠反映每個人對該系統(tǒng)的感覺。 在舉行FAST會議時，如果小組的每個成員提出一個名單，整個小組就會制作一個小組名單，這個小組名單刪除冗長的項目，加上表達過程中出現(xiàn)的新思想

7、。 創(chuàng)建所有主題組合列表后，開始討論活動。 縮短、延長或重新組合列表，以便正確反映要開發(fā)的產(chǎn)品。FAST會議步驟(續(xù))、4 )如果創(chuàng)建意見一致的列表，則將小組分成更小的組，各組嘗試為各列表中的一個或多個項目開發(fā)小規(guī)章(即，列表中所包含的單詞、短語的細分)。 各組隨后將把他們開發(fā)的各項小規(guī)約提交所有FAST與會者討論，進行追加、刪除或進一步精化等工作。 (在所有討論過程中，小組可能會提出會議中無法解決的問題。 在這種情況下，請保留問題列表，以便這些想法對今后的活動有幫助。 5 )小規(guī)約完成后，各FAST出席者提交產(chǎn)品的準確標準清單，并將該清單提交小組，制作意見一致確定的標準清單。 獲得需求后，該

8、列表為需求分析和建模提供基礎(chǔ)信息。 另外，在將需求收集為非正式會議、Fast的一部分之后，分析師可以創(chuàng)建使用場景來標識要構(gòu)建的系統(tǒng)序列。創(chuàng)建用例模型的主要步驟是確定直接使用該系統(tǒng)的用戶，即參與者定義該參與者希望使用系統(tǒng)，針對該參與者希望使用系統(tǒng)的每一天使用該系統(tǒng)， 通常是指確定發(fā)生什么。需求分析原則1能夠表示理解問題信息域2軟件完成的功能3軟件的行為(外部事件的結(jié)果)必須表現(xiàn)出4數(shù)據(jù)、描述功能和行為的模型，詳細5分析過程從要素信息中包含詳細信息、信息域、信息域信息內(nèi)容代表單個數(shù)據(jù)和控制對象，目標軟件全部處理的信息集合由它們構(gòu)成。 例如，數(shù)據(jù)對象的“薪水”是重要的數(shù)據(jù)體的組合，如接收者的姓名、網(wǎng)

9、絡(luò)支付數(shù)、支付總額、扣除額等，信息流指示數(shù)據(jù)和系統(tǒng)流動的改變方式，輸入對象指向中間信息(數(shù)據(jù)和/或控制) 還是使用了別的構(gòu)造？ 一個信息結(jié)構(gòu)中的信息是如何與另一個結(jié)構(gòu)中的信息相關(guān)聯(lián)的，抽象、分解和多視點分析，問題抽象方法要求分析者在分析過程中捕捉用戶描述或問題本身固有的一般-特殊關(guān)系，首先關(guān)注一般問題的解決途徑，指導(dǎo)特殊問題的解決方法。問題分解的目的是能夠?qū)栴}分層分解、細分化。 可以將大型或復(fù)雜問題分解為若干子問題并進行理解和分析的分解是，直到子問題分解為易于分析理解的部分，例如需求協(xié)商為止，協(xié)商的過程是討論需求沖突，找到人人都滿意的權(quán)衡的協(xié)商不是單純的邏輯或技術(shù)上的爭論， 組織和行政要素不

10、一致的目標責(zé)任的喪失或者組織文化組織的管理態(tài)度和士氣部門的不同需要注意的是可以解決發(fā)現(xiàn)的問題的項目有關(guān)人員會議應(yīng)該討論非正式討論不能解決的問題。 一般會議分為三個階段：敘述階段討論階段決定階段、需求建模、軟件需求分析階段，建立的模型重點描述系統(tǒng)應(yīng)該做什么的一般分析方法：面向數(shù)據(jù)流的結(jié)構(gòu)化分析方法(SA )面向數(shù)據(jù)結(jié)構(gòu)的分析方法面向?qū)ο蟮姆治龇椒?OOA ) 需求規(guī)約和驗證、需求規(guī)約的原則1從現(xiàn)實中分離出功能，即記述的不是“如何實現(xiàn)”而是“做什么”。 期望使用面向二處理的協(xié)議語言(或系統(tǒng)定義的語言)來研究來自環(huán)境的各種刺激可能對系統(tǒng)產(chǎn)生什么樣的功能反應(yīng)，定義行為模型以獲得“做什么”的協(xié)議。 3如

11、果開發(fā)的軟件只是基于計算機的系統(tǒng)的一個要素，則整個大型系統(tǒng)也包括在規(guī)格說明中。 4規(guī)約必須包含系統(tǒng)的運行環(huán)境。 需求規(guī)約的原則(續(xù))，5規(guī)約不得為設(shè)定修訂或?qū)崿F(xiàn)的模式，而應(yīng)為認識模式。 6對于任何測試用例，協(xié)議必須能夠操作，以確定提議的解決方案是否能夠滿足協(xié)議。 七規(guī)約必須容許不完整和擴張。 8規(guī)約需要局部化和松散結(jié)合。 其中包含的信息需要本地化，在修改信息時修改各個段落即可(理想)。此外，條款必須是松散的(即松散聯(lián)接)的，以便于添加和刪除某些段落。需求規(guī)約、引言：闡述軟件目標，并在基于修訂機的系統(tǒng)語境內(nèi)描述。 信息說明：提供軟件必須解決的問題的詳細說明，記錄信息的內(nèi)容和關(guān)系，流和結(jié)構(gòu)。 功能

12、說明：說明解決問題所需的各項功能。 它以一個或多個圖形的形式表示軟件的整體結(jié)構(gòu)和軟件功能與其他系統(tǒng)元素之間的相互影響，這些軟件描述了每個功能的一個處理過程，描述了設(shè)置修訂約束的性能特性。 動作說明：對外部事件和內(nèi)部生成的控制特性即軟件動作進行說明。 檢驗標準：表示檢驗系統(tǒng)成功的標志。 也就是說，對系統(tǒng)進行了怎樣的測試，得到了什么樣的結(jié)果，這表明系統(tǒng)是成功的。 這是“確認測試”的基礎(chǔ)。 參考文獻：包含對與此軟件相關(guān)的所有文檔的引用。 其中包括其他軟件工程文檔、技術(shù)參考文獻、供應(yīng)商文獻、標準等。 附錄：包含規(guī)章的補充信息、表數(shù)據(jù)、算法的詳細說明、圖表和其他資料。 需求驗證、需求驗證的目的是，在驗證需求是否能夠反映用戶意愿審查員的審查時，檢查系統(tǒng)定義的目標是否與用戶的要求一致，即系統(tǒng)要求分析階段提供的文檔是否齊全，文檔內(nèi)的說明對用戶的要求是否準確反映確定了所開發(fā)項目的數(shù)據(jù)流和數(shù)據(jù)結(jié)