1、第三次需求工程、需求工程概要獲得需求分析、協(xié)商和建模需求規(guī)約和驗證需求管理需求確定的原則Alan Davis將需求工程定義為“將軟件分解為實際的體系結(jié)構(gòu)組件之前的所有活動(但不包括)”。 Herb Krasner定義了需求工程的五個生命周期。 需求的定義和分析、需求的決定、需求規(guī)格的形成、需求的實現(xiàn)和驗證、需求進化管理Matthias Jarke和Klaus Pohl提出了三階段循環(huán)的學(xué)說：獲取、顯示和驗證，本書將軟件需求工程分為需求獲取、需求分析和協(xié)議、系統(tǒng)建模、需求規(guī)約、需求驗證和需求管理六個階段需求的獲得，系統(tǒng)分析師通過與用戶的交流，現(xiàn)有系統(tǒng)的觀察和任務(wù)的分析，記述系統(tǒng)和產(chǎn)品的范圍的限制

2、，系統(tǒng)的技術(shù)環(huán)境的記述，系統(tǒng)功能的列表和適用于各需求的領(lǐng)域的限制，記述不同運行條件下的系統(tǒng)和產(chǎn)品的使用狀況的應(yīng)用場景和需求獲得的工作產(chǎn)品提供進行需求分析的基礎(chǔ)，與需求分析進行協(xié)商，需求獲得結(jié)束后，分析活動對需求進行分類組織，分析各需求的其他需求的關(guān)系，檢查需求的一致性、重復(fù)和遺漏的情況，根據(jù)用戶的需求進行排序。 在需求獲得階段，用戶的要求經(jīng)常超出軟件系統(tǒng)能夠?qū)崿F(xiàn)的范圍，或者實現(xiàn)能力的問題發(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)查觀察用戶操作流程配置聯(lián)合小組使用情況(Use Case )、流暢的通信路徑的建立、分析所需的通信路徑的建立、采訪和調(diào)查，在具體的實踐中通常采用權(quán)衡的方法。 也就是說，我們正在對采訪進行適當?shù)男抻?，但不太詳細，能夠具有一定的靈活性。一般按照以下原

5、則準備：被提問題應(yīng)該逐步從整體方面開始提問，下一個問題應(yīng)該有助于更好地理解和細分上一個問題。 不要限制用戶對問題的回答。 這可能會導(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ā)者、 或者可能是其他

6、外部人員的協(xié)調(diào)員控制會議使用工作表、圖表、貼墻紙、貼墻板等定義機制的目標是確定問題、提出解決方案的要素、協(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會議時，如果小組的每個成員提出一個名單，整個小組就會制作一個小組

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

8、意見一致確定的標準清單。 獲得需求后，該列表為需求分析和建模提供基礎(chǔ)信息。 另外，在將需求收集為非正式會議、Fast的一部分之后，分析師可以創(chuàng)建使用場景來標識要構(gòu)建的系統(tǒng)序列。創(chuàng)建使用模型的主要步驟是確定直接使用系統(tǒng)的參與者(Actor )。 參與者(Actor )定義參與者想對系統(tǒng)做什么，并決定參與者想對系統(tǒng)做什么，以及使用系統(tǒng)時通常會發(fā)生什么。 這是使用情況的基本過程是說明其使用情況的基本過程，是需求分析的原則。1能夠表現(xiàn)和理解問題的信息域2軟件必須能夠定義完成的功能(由于外部事件的結(jié)果) 4軟件的行為必須能夠表現(xiàn)。 4對描述數(shù)據(jù)、功能和行為的模型進行分割，詳細5分析過程包括從要素信息到詳

9、細信息、信息域、信息域。 信息內(nèi)容代表單個數(shù)據(jù)和控制對象，目標軟件全部處理的信息集合由它們構(gòu)成。 例如，數(shù)據(jù)對象的“工資”是重要的數(shù)據(jù)體的組合，如接收者的姓名、網(wǎng)絡(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ù)雜問題分解為若干子問題并進行理解和分析

10、的分解是，直到子問題分解為易于分析理解的部分，例如需求協(xié)商為止，協(xié)商的過程是討論需求沖突，找到人人都滿意的權(quán)衡的協(xié)商不是單純的邏輯或技術(shù)上的爭論， 組織和行政要素不一致的目標責(zé)任的喪失或者組織文化組織管理態(tài)度和士氣部門的不同需要注意的是發(fā)現(xiàn)的問題可以解決的項目有關(guān)人員會議應(yīng)該討論非正式討論不能解決的問題。 一般會議分為三個階段：敘述階段討論階段決定階段、需求建模、軟件需求分析階段，建立的模型重點描述系統(tǒng)應(yīng)該做什么的一般分析方法：數(shù)據(jù)流導(dǎo)向結(jié)構(gòu)化分析方法(SA )數(shù)據(jù)結(jié)構(gòu)導(dǎo)向分析方法面向?qū)ο蠓治龇椒?OOA )、需求規(guī)約期望使用面向二處理的協(xié)議語言(或系統(tǒng)定義的語言)來研究來自環(huán)境的各種刺激可能

11、對系統(tǒng)產(chǎn)生什么樣的功能反應(yīng)，定義行為模型以獲得“做什么”的協(xié)議。 3如果開發(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)描述。 信息說明：提

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

13、、算法的詳細說明、圖表和其他資料。 需求驗證、需求驗證的目的是，在驗證需求是否能夠反映用戶意愿審查員的審查時，檢查系統(tǒng)定義的目標是否與用戶的要求一致，即系統(tǒng)要求分析階段提供的文檔是否齊全，文檔內(nèi)的說明對用戶的要求是否準確反映確定了所開發(fā)項目的數(shù)據(jù)流和數(shù)據(jù)結(jié)構(gòu)，是否充分，主要功能是否包含在規(guī)定的軟件范圍內(nèi)，以及是否充分說明，修正的約束或約束是否實際滿足，開發(fā)的技術(shù)風(fēng)險是什么需求管理、需求管理是在項目進行中隨時由項目組識別、控制、跟蹤需求的活動需求跟蹤有兩種方式。 正向跟蹤和反向跟蹤正向跟蹤：以用戶需求為切入點，檢查需求規(guī)約中的每個需求是否能夠在后續(xù)工作產(chǎn)品中找到對應(yīng)點：設(shè)置修訂文檔、代碼， 測試

14、用情況等工作產(chǎn)品是否能夠出處需求規(guī)章的高中學(xué)分制選修課系統(tǒng)的學(xué)生根據(jù)學(xué)期開課列表填寫選修課表，學(xué)生選修課系統(tǒng)處理各學(xué)生的選修課表：根據(jù)教育修訂計劃檢查是否有該學(xué)生還沒有取得學(xué)分的必修課， 如果有，請求再修課程的這個學(xué)生課程的授課時間的沖突率修正：如果不發(fā)生沖突，或沖突率不足30%就可以選擇。 否則，根據(jù)必修課選項的優(yōu)先順序刪除所選課程。 最后，生成每個學(xué)生的個人課程表和每個課程的成績記錄表(列出該課程的學(xué)生列表)。 3.1需求確定的原則，(1)能夠表現(xiàn)和理解問題的信息域和功能域所有軟件開發(fā)的最終目的是解決數(shù)據(jù)處理的問題，數(shù)據(jù)處理的本質(zhì)是將一種形式的數(shù)據(jù)轉(zhuǎn)換為另一種形式的數(shù)據(jù)，其轉(zhuǎn)換過程必須輸入， 在需要經(jīng)過生成加入數(shù)據(jù)和結(jié)果數(shù)據(jù)等步驟的需求分析階段，必須明確系統(tǒng)應(yīng)具備的每個加工加工的處理對象和加工引起的數(shù)據(jù)形式的變化。 3.1需求確定原則，(2)能夠進行問題的分解和細分，確立問題的層次結(jié)構(gòu)便于問題的解決和實現(xiàn)，在需求分析過程中對原本復(fù)雜的問題以某種適當?shù)姆绞竭M行分解(對功能域和數(shù)據(jù)域雙方)，分解為幾個通俗的部分，各部分之間的間接分解可以是同一水平的橫向分解，也可以是多層的縱向分解。 各步驟的分解歷來細分系統(tǒng)，