軟件工程需求工程課件

軟件工程第3章需求工程軟件工程第3章需求工程內容摘要需求工程概述需求獲取需求分析、協(xié)商與建模需求規(guī)約與驗證需求管理內容摘要需求工程概述內容摘要需求工程概述需求獲取需求分析、協(xié)商與建模需求規(guī)約與驗證需求管理內容摘要需求工程概述AlanDavis把需求工程定義為“直到（但不包括）把軟件分解為實際架構構件之前的所有活動”Herb定義了需求工程的五階段生命周期：需求定義和分析、需求決策、形成需求規(guī)格、需求實現(xiàn)與驗證、需求演進管理MatthiasJarke和KlausPohl提出了三階段周期的說法：獲取、表示和驗證……需求工程AlanDavis把需求工程定義為“直到（但不包括）把軟本書將軟件需求工程細分為：需求獲取需求分析與協(xié)商系統(tǒng)建模需求規(guī)約需求驗證需求管理需求工程本書將軟件需求工程細分為：需求工程需求獲取系統(tǒng)分析人員通過與用戶的交流、對現(xiàn)有系統(tǒng)的觀察及對任務進行分析，確定:系統(tǒng)或產(chǎn)品范圍的限制性描述與系統(tǒng)或產(chǎn)品有關的人員特征列表系統(tǒng)的技術環(huán)境的描述系統(tǒng)功能的列表及應用于每個需求的領域限制描述不同運行條件下系統(tǒng)或產(chǎn)品使用狀況的應用場景為更好地定義需求而開發(fā)的任意原型。

需求獲取的工作產(chǎn)品為進行需求分析提供了基礎

需求獲取系統(tǒng)分析人員通過與用戶的交流、對現(xiàn)有系統(tǒng)的觀察及對需求分析與協(xié)商需求分析：對需求進行分類組織，分析每個需求之間的關系，檢查需求的一致性、重疊和遺漏的情況，并根據(jù)用戶的需要對需求進行排序。需求協(xié)商

在需求獲取階段，經(jīng)常出現(xiàn)以下問題：用戶提出的要求超出軟件系統(tǒng)可以實現(xiàn)的范圍或實現(xiàn)能力；不同的用戶提出了相互沖突的需求需求分析與協(xié)商需求分析：系統(tǒng)建模建模工具在用戶和系統(tǒng)分析人員之間建立了統(tǒng)一的語言和理解的橋梁.系統(tǒng)分析人員借助建模技術，對獲取的需求信息進行分析，排除錯誤和彌補不足，確保需求文檔正確反映用戶的真實意圖。常用的分析和建模方法有:面向數(shù)據(jù)流方法面向數(shù)據(jù)結構方法面向對象的方法。系統(tǒng)建模建模工具在用戶和系統(tǒng)分析人員之間建立了統(tǒng)一的語言和理需求規(guī)約需求規(guī)約是分析任務的最終產(chǎn)物，通過建立完整的信息描述、詳細的功能和行為描述、性能需求和設計約束的說明、合適的驗收標準，給出對目標軟件的各種需求。需求規(guī)約作為用戶和開發(fā)者之間的一個協(xié)議，在之后的軟件工程各個階段發(fā)揮重要作用。需求規(guī)約需求規(guī)約是分析任務的最終產(chǎn)物，通過建立完整的信息描需求驗證作為需求開發(fā)階段工作的復查手段，需求驗證對功能的正確性、完整性和清晰性，以及其它需求給予評價。為保證軟件需求定義的質量，評審應以專門指定的人員負責，并按規(guī)程嚴格進行。需求驗證作為需求開發(fā)階段工作的復查手段，需求驗證對功能的正在實際的開發(fā)過程中，獲取、分析、建模、編寫規(guī)約和驗證這些需求開發(fā)活動不會是線性地、順序地完成。實際上，這些活動是交叉的、遞增的和反復的。需求分析過程在實際的開發(fā)過程中，獲取、分析、建模、編寫規(guī)約和驗證這些需求需求管理需求工程包括獲取、分析、規(guī)定、驗證和管理軟件需求，而“軟件需求管理”則是對所有相關活動的規(guī)劃和控制。換句話說，需求管理就是：一種獲取、組織并記錄系統(tǒng)需求的系統(tǒng)化方案，以及一個使用戶與項目團隊對不斷變更的系統(tǒng)需求，達成并保持一致的過程。需求管理需求工程包括獲取、分析、規(guī)定、驗證和管理軟件需求，內容摘要需求工程概述需求獲取需求分析、協(xié)商與建模需求規(guī)約與驗證需求管理內容摘要需求工程概述軟件需求包括功能需求性能需求用戶或人的因素環(huán)境需求界面需求文檔需求數(shù)據(jù)需求資源使用需求安全保密要求可靠性需求軟件成本消耗與開發(fā)進度需求其他非功能性要求

軟件需求包括功能需求數(shù)據(jù)需求需求獲取方法與策略建立順暢的通信途徑

訪談與調查觀察用戶操作流程組成聯(lián)合小組用況（UseCase）需求獲取方法與策略建立順暢的通信途徑建立順暢的通信途徑建立分析所需要的通信途徑，以保證能順利地對問題進行分析。建立順暢的通信途徑建立分析所需要的通信途徑，以保證能順利地訪談與調查在具體的實踐中，通常采用折衷的方法，即適當?shù)赜媱澓妹嬲?，但不要過于詳細，允許有一定的靈活性。一般按照如下原則進行準備：所提問的問題應該循序漸進，從整體的方面開始提問，接下來的問題應有助于對前面的問題更好的理解和細化；不要限制用戶對問題的回答，這有可能會引出原先沒有注意的問題；提問和回答在匯總后應能夠反映用戶需求的全貌。訪談與調查在具體的實踐中，通常采用折衷的方法，即適當?shù)赜媱澯^察用戶操作流程到用戶的實際工作環(huán)境中:對用戶的工作流程進行觀察了解用戶實際的操作環(huán)境、操作過程和操作要求對照用戶提交的問題陳述，對用戶需求可以有更全面、更細致的認識。觀察用戶操作流程到用戶的實際工作環(huán)境中:組成聯(lián)合小組便利的應用規(guī)約技術(FacilitatedApplicationSpecificationTechniques,FAST)

：打破用戶（需方）和開發(fā)者（供方）的界限，共同組成一個聯(lián)合小組，發(fā)揮各自的長處，共同負責項目的推進，這樣有助于發(fā)揮各自優(yōu)勢并增進解和協(xié)調組成聯(lián)合小組便利的應用規(guī)約技術(FacilitatedAFAST基本原則在中立的地點舉行由開發(fā)者和用戶出席的會議；建立準備和參與會議的規(guī)則；建議一個足夠正式的議程以便可以進行自由的交流；一個“協(xié)調者”(他可以是用戶、開發(fā)者或其他外人)來控制會議；使用一種“定義機制”(它可以是工作表、圖表、墻上膠黏紙或墻板)；目標是標識問題、提出解決方案的要素、商議不同的方法、以及在有利于完成目標的氛圍中刻畫出初步的需求。FAST基本原則在中立的地點舉行由開發(fā)者和用戶出席的會議；FAST會議步驟1) 確定一個FAST會議的時間地點，并在會議日之前將產(chǎn)品請求發(fā)布給所有的與會者。2)要求每個FAST出席者，會前列出一組圍繞系統(tǒng)環(huán)境、對象的操作、對象之間的交互功能，并列出約束列表(如，成本、規(guī)模大小、權重)和性能標準列表(如，速度、精度)。這些列表可以不是窮盡的，但是，希望每套列表反映的是每個人對系統(tǒng)的感覺。3)進行FAST會議時，當團隊的每個成員提出單個列表后，整個團隊將創(chuàng)建一個組合的列表，該組合列表刪去冗余項，并加入在表達過程中出現(xiàn)的新思想。在建好所有主題的組合列表后，開始討論活動。縮短、加長或重新組合列表以適當?shù)胤从硨⒈婚_發(fā)的產(chǎn)品。FAST會議步驟1) 確定一個FAST會議的時間地點，并在FAST會議步驟(續(xù))一旦創(chuàng)建了意見一致的列表應該將團隊分為更小的小組，每個小組力圖為每個列表中的一個或多個項開發(fā)出小型的規(guī)約（即對包含在列表中的單詞或短語的精細化）。每個小組然后將他們開發(fā)的每個小規(guī)約提交給所有的FAST出席者討論，進行添加、刪除或進一步的精化等工作。在所有討論過程中，團隊可能提出某些不能在會議過程中解決的問題，此時要保留問題列表以使這些思想在以后的活動中產(chǎn)生作用。5) 在小規(guī)約完成后，每個FAST小組提出一個針對產(chǎn)品的確切標準列表，并將該列表提交給團隊，然后創(chuàng)建一個意見一致的確定的標準列表。這個列表作為需求獲取的結果，為需求分析和建模提供基礎信息。FAST會議步驟(續(xù))一旦創(chuàng)建了意見一致的列表用況（UseCase）當需求收集起來后，分析員就可以創(chuàng)建一組標識串，構造系統(tǒng)的使用場景。創(chuàng)建用況模型的主要步驟如下：確定誰會直接使用該系統(tǒng)，即參與者（Actor）選取其中一個參與者定義該參與者希望系統(tǒng)做什么，參與者希望系統(tǒng)作的每件事將成為一個用況對每件事來說，何時參與者會使用系統(tǒng)，通常會發(fā)生什么，這就是用況的基本過程描述該用況的基本過程用況（UseCase）當需求收集起來后，分析員就可以創(chuàng)建內容摘要需求工程概述需求獲取需求分析、協(xié)商與建模需求規(guī)約與驗證需求管理內容摘要需求工程概述需求分析原則1．必須能夠表示和理解問題的信息域2．必須能夠定義軟件將完成的功能3．必須能夠表示軟件的行為(作為外部事件的結果)4．必須劃分描述數(shù)據(jù)、功能和行為的模型，從而可以分層次地揭示細節(jié)5．分析過程應該從要素信息移向細節(jié)信息需求分析原則1．必須能夠表示和理解問題的信息域信息域信息域：包括信息內容、信息流、以及信息結構。信息內容表示了單個數(shù)據(jù)和控制對象，目標軟件所有處理的信息集合由它們構成。例如，數(shù)據(jù)對象“工資”是一組重要數(shù)據(jù)體的組合：領款人的姓名、凈付款數(shù)、付款總額、扣除額等等

信息流表示了數(shù)據(jù)和控制在系統(tǒng)中流動時的變化方式，輸入對象被變換為中間信息(數(shù)據(jù)和/或控制)，然后進一步被變換為輸出信息域信息域：包括信息內容、信息流、以及信息結構。信息結構表示了各種數(shù)據(jù)和控制項的內部組織數(shù)據(jù)或控制項將被組織為n維表還是樹形結構？在結構的語境內，什么信息是和其他信息相關的？信息包含在單個結構中，還是使用不同的結構？在某信息結構中的信息如何和在另一個結構中的信息相關？信息域信息結構表示了各種數(shù)據(jù)和控制項的內部組織信息域抽象、分解與多視點分析問題抽象方法要求分析人員在分析過程中捕捉用戶描述或問題本身固有的一般-特殊關系首先關注一般問題的解決途徑，進而指導特殊問題的解決方法。抽象、分解與多視點分析問題抽象方法要求分析人員在分析過程中問題分解的目的是要能以層次化的方式對問題進行分解和不斷細化。較大規(guī)?；蜉^為復雜的問題可以被分解為若干子問題進行理解和分析分解可以逐級進行，直至子問題被分解為一個容易分析理解的部分例如橫向分解縱向分解抽象、分解與多視點分析問題分解的目的是要能以層次化的方式對問題進行分解和不斷細化。需求協(xié)商協(xié)商的過程就是討論需求沖突，找出每個人都滿意的折衷方案協(xié)商不是簡單的邏輯或技術上的爭論要注意組織和行政方面的因素①不一致的目標②責任的喪失或轉移③組織文化④組織管理態(tài)度和士氣⑤部門差異需求協(xié)商協(xié)商的過程就是討論需求沖突，找出每個人都滿意的折衷通常會議是解決沖突最快的方式參加者應該包括發(fā)現(xiàn)沖突、遺漏或重疊的分析員，以及可以解決發(fā)現(xiàn)的問題的項目相關人員會議應該討論那些非正式討論不能解決的問題通常會議分為三個階段：敘述階段討論階段決策階段需求協(xié)商通常會議是解決沖突最快的方式需求協(xié)商需求建模在軟件需求分析階段，所創(chuàng)建的模型，要著重于描述系統(tǒng)要做什么，而不是如何去做目標軟件的模型不應涉及軟件實現(xiàn)細節(jié)需求建模在軟件需求分析階段，所創(chuàng)建的模型，要著重于描述系統(tǒng)要常用的分析方法：面向數(shù)據(jù)流的結構化分析方法(SA)面向數(shù)據(jù)結構的分析方法面向對象的分析方法(OOA)需求建模常用的分析方法：需求建模內容摘要需求工程概述需求獲取需求分析、協(xié)商與建模需求規(guī)約與驗證需求管理內容摘要需求工程概述需求規(guī)約的原則1． 從現(xiàn)實中分離功能，即描述要“做什么”而不是“怎樣實現(xiàn)”。2． 要求使用面向處理的規(guī)約語言，定義一個行為模型，從而得到“做什么”的規(guī)約。3． 整個系統(tǒng)都包括在規(guī)格說明的描述之中。4． 規(guī)約必須包括系統(tǒng)運行環(huán)境。需求規(guī)約的原則1． 從現(xiàn)實中分離功能，即描述要“做什么”而需求規(guī)約的原則(續(xù))5． 規(guī)約必須是一個認識模型，而不是設計或實現(xiàn)的模型。6． 規(guī)約必須是可操作的。7． 規(guī)約必須允許不完備性并允許擴充。8． 規(guī)約必須局部化和松散耦合。需求規(guī)約的原則(續(xù))5． 規(guī)約必須是一個認識模型，而不是設需求規(guī)約Ⅰ.引言A.系統(tǒng)參考文獻B.整體描述C.軟件項目約束Ⅱ.信息描述A.信息內容表示B.信息流表示：ⅰ數(shù)據(jù)流ⅱ控制流Ⅲ.功能描述A.功能劃分B.功能描述：ⅰ處理說明ⅱ限制∕局限ⅲ性能需求ⅳ設計約束ⅴ支撐圖C.控制描述ⅰ控制規(guī)約ⅱ設計約束Ⅳ.行為描述A.系統(tǒng)狀態(tài)B.事件和響應Ⅴ.檢驗標準A.性能范圍B.測試種類C.期望的軟件響應D.特殊的考慮Ⅵ.參考書目Ⅶ.附錄需求規(guī)約Ⅰ.引言A.系統(tǒng)參考文獻B.整體描述C.軟件項需求驗證需求驗證目的是要檢驗需求是否能夠反映用戶的意愿評審人員評審時往往需要檢查以下內容：系統(tǒng)定義的目標是否與用戶的要求一致；系統(tǒng)需求分析階段提供的文檔資料是否齊全；文檔中的描述是否完整、清晰、準確地反映了用戶要求；被開發(fā)項目的數(shù)據(jù)流與數(shù)據(jù)結構是否確定且充足；主要功能是否已包括在規(guī)定的軟件范圍之內，是否都已充分說明；設計的約束條件或限制條件是否符合實際；開發(fā)的技術風險是什么；是否詳細制定了檢驗標準，它們能否對系統(tǒng)定義是否成功進行確認。

需求驗證需求驗證目的是要檢驗需求是否能夠反映用戶的意愿內容摘要需求工程概述需求獲取需求分析、協(xié)商與建模需求規(guī)約與驗證需求管理內容摘要需求工程概述需求管理需求管理是一組用于幫助項目組在項目進展中的任何時候去標識、控制和跟蹤需求的活動需求跟蹤有兩種方式，正向跟蹤與逆向跟蹤正向跟蹤：以用戶需求為切入點，檢查《需求規(guī)約》中的每個需求是否都能在后繼工作產(chǎn)品中找到對應點逆向跟蹤：檢查設計文檔、代碼、測試用況等工作產(chǎn)品是否都能在《需求規(guī)約》中找到出處需求管理需求管理是一組用于幫助項目組在項目進展中的任何時候去軟件需求工程：需求獲取需求分析與協(xié)商系統(tǒng)建模需求規(guī)約需求驗證需求管理本章小結軟件需求工程：本章小結軟件工程第3章需求工程軟件工程第3章需求工程內容摘要需求工程概述需求獲取需求分析、協(xié)商與建模需求規(guī)約與驗證需求管理內容摘要需求工程概述內容摘要需求工程概述需求獲取需求分析、協(xié)商與建模需求規(guī)約與驗證需求管理內容摘要需求工程概述AlanDavis把需求工程定義為“直到（但不包括）把軟件分解為實際架構構件之前的所有活動”Herb定義了需求工程的五階段生命周期：需求定義和分析、需求決策、形成需求規(guī)格、需求實現(xiàn)與驗證、需求演進管理MatthiasJarke和KlausPohl提出了三階段周期的說法：獲取、表示和驗證……需求工程AlanDavis把需求工程定義為“直到（但不包括）把軟本書將軟件需求工程細分為：需求獲取需求分析與協(xié)商系統(tǒng)建模需求規(guī)約需求驗證需求管理需求工程本書將軟件需求工程細分為：需求工程需求獲取系統(tǒng)分析人員通過與用戶的交流、對現(xiàn)有系統(tǒng)的觀察及對任務進行分析，確定:系統(tǒng)或產(chǎn)品范圍的限制性描述與系統(tǒng)或產(chǎn)品有關的人員特征列表系統(tǒng)的技術環(huán)境的描述系統(tǒng)功能的列表及應用于每個需求的領域限制描述不同運行條件下系統(tǒng)或產(chǎn)品使用狀況的應用場景為更好地定義需求而開發(fā)的任意原型。

需求獲取的工作產(chǎn)品為進行需求分析提供了基礎

需求獲取系統(tǒng)分析人員通過與用戶的交流、對現(xiàn)有系統(tǒng)的觀察及對需求分析與協(xié)商需求分析：對需求進行分類組織，分析每個需求之間的關系，檢查需求的一致性、重疊和遺漏的情況，并根據(jù)用戶的需要對需求進行排序。需求協(xié)商

在需求獲取階段，經(jīng)常出現(xiàn)以下問題：用戶提出的要求超出軟件系統(tǒng)可以實現(xiàn)的范圍或實現(xiàn)能力；不同的用戶提出了相互沖突的需求需求分析與協(xié)商需求分析：系統(tǒng)建模建模工具在用戶和系統(tǒng)分析人員之間建立了統(tǒng)一的語言和理解的橋梁.系統(tǒng)分析人員借助建模技術，對獲取的需求信息進行分析，排除錯誤和彌補不足，確保需求文檔正確反映用戶的真實意圖。常用的分析和建模方法有:面向數(shù)據(jù)流方法面向數(shù)據(jù)結構方法面向對象的方法。系統(tǒng)建模建模工具在用戶和系統(tǒng)分析人員之間建立了統(tǒng)一的語言和理需求規(guī)約需求規(guī)約是分析任務的最終產(chǎn)物，通過建立完整的信息描述、詳細的功能和行為描述、性能需求和設計約束的說明、合適的驗收標準，給出對目標軟件的各種需求。需求規(guī)約作為用戶和開發(fā)者之間的一個協(xié)議，在之后的軟件工程各個階段發(fā)揮重要作用。需求規(guī)約需求規(guī)約是分析任務的最終產(chǎn)物，通過建立完整的信息描需求驗證作為需求開發(fā)階段工作的復查手段，需求驗證對功能的正確性、完整性和清晰性，以及其它需求給予評價。為保證軟件需求定義的質量，評審應以專門指定的人員負責，并按規(guī)程嚴格進行。需求驗證作為需求開發(fā)階段工作的復查手段，需求驗證對功能的正在實際的開發(fā)過程中，獲取、分析、建模、編寫規(guī)約和驗證這些需求開發(fā)活動不會是線性地、順序地完成。實際上，這些活動是交叉的、遞增的和反復的。需求分析過程在實際的開發(fā)過程中，獲取、分析、建模、編寫規(guī)約和驗證這些需求需求管理需求工程包括獲取、分析、規(guī)定、驗證和管理軟件需求，而“軟件需求管理”則是對所有相關活動的規(guī)劃和控制。換句話說，需求管理就是：一種獲取、組織并記錄系統(tǒng)需求的系統(tǒng)化方案，以及一個使用戶與項目團隊對不斷變更的系統(tǒng)需求，達成并保持一致的過程。需求管理需求工程包括獲取、分析、規(guī)定、驗證和管理軟件需求，內容摘要需求工程概述需求獲取需求分析、協(xié)商與建模需求規(guī)約與驗證需求管理內容摘要需求工程概述軟件需求包括功能需求性能需求用戶或人的因素環(huán)境需求界面需求文檔需求數(shù)據(jù)需求資源使用需求安全保密要求可靠性需求軟件成本消耗與開發(fā)進度需求其他非功能性要求

軟件需求包括功能需求數(shù)據(jù)需求需求獲取方法與策略建立順暢的通信途徑

訪談與調查觀察用戶操作流程組成聯(lián)合小組用況（UseCase）需求獲取方法與策略建立順暢的通信途徑建立順暢的通信途徑建立分析所需要的通信途徑，以保證能順利地對問題進行分析。建立順暢的通信途徑建立分析所需要的通信途徑，以保證能順利地訪談與調查在具體的實踐中，通常采用折衷的方法，即適當?shù)赜媱澓妹嬲?，但不要過于詳細，允許有一定的靈活性。一般按照如下原則進行準備：所提問的問題應該循序漸進，從整體的方面開始提問，接下來的問題應有助于對前面的問題更好的理解和細化；不要限制用戶對問題的回答，這有可能會引出原先沒有注意的問題；提問和回答在匯總后應能夠反映用戶需求的全貌。訪談與調查在具體的實踐中，通常采用折衷的方法，即適當?shù)赜媱澯^察用戶操作流程到用戶的實際工作環(huán)境中:對用戶的工作流程進行觀察了解用戶實際的操作環(huán)境、操作過程和操作要求對照用戶提交的問題陳述，對用戶需求可以有更全面、更細致的認識。觀察用戶操作流程到用戶的實際工作環(huán)境中:組成聯(lián)合小組便利的應用規(guī)約技術(FacilitatedApplicationSpecificationTechniques,FAST)

：打破用戶（需方）和開發(fā)者（供方）的界限，共同組成一個聯(lián)合小組，發(fā)揮各自的長處，共同負責項目的推進，這樣有助于發(fā)揮各自優(yōu)勢并增進解和協(xié)調組成聯(lián)合小組便利的應用規(guī)約技術(FacilitatedAFAST基本原則在中立的地點舉行由開發(fā)者和用戶出席的會議；建立準備和參與會議的規(guī)則；建議一個足夠正式的議程以便可以進行自由的交流；一個“協(xié)調者”(他可以是用戶、開發(fā)者或其他外人)來控制會議；使用一種“定義機制”(它可以是工作表、圖表、墻上膠黏紙或墻板)；目標是標識問題、提出解決方案的要素、商議不同的方法、以及在有利于完成目標的氛圍中刻畫出初步的需求。FAST基本原則在中立的地點舉行由開發(fā)者和用戶出席的會議；FAST會議步驟1) 確定一個FAST會議的時間地點，并在會議日之前將產(chǎn)品請求發(fā)布給所有的與會者。2)要求每個FAST出席者，會前列出一組圍繞系統(tǒng)環(huán)境、對象的操作、對象之間的交互功能，并列出約束列表(如，成本、規(guī)模大小、權重)和性能標準列表(如，速度、精度)。這些列表可以不是窮盡的，但是，希望每套列表反映的是每個人對系統(tǒng)的感覺。3)進行FAST會議時，當團隊的每個成員提出單個列表后，整個團隊將創(chuàng)建一個組合的列表，該組合列表刪去冗余項，并加入在表達過程中出現(xiàn)的新思想。在建好所有主題的組合列表后，開始討論活動。縮短、加長或重新組合列表以適當?shù)胤从硨⒈婚_發(fā)的產(chǎn)品。FAST會議步驟1) 確定一個FAST會議的時間地點，并在FAST會議步驟(續(xù))一旦創(chuàng)建了意見一致的列表應該將團隊分為更小的小組，每個小組力圖為每個列表中的一個或多個項開發(fā)出小型的規(guī)約（即對包含在列表中的單詞或短語的精細化）。每個小組然后將他們開發(fā)的每個小規(guī)約提交給所有的FAST出席者討論，進行添加、刪除或進一步的精化等工作。在所有討論過程中，團隊可能提出某些不能在會議過程中解決的問題，此時要保留問題列表以使這些思想在以后的活動中產(chǎn)生作用。5) 在小規(guī)約完成后，每個FAST小組提出一個針對產(chǎn)品的確切標準列表，并將該列表提交給團隊，然后創(chuàng)建一個意見一致的確定的標準列表。這個列表作為需求獲取的結果，為需求分析和建模提供基礎信息。FAST會議步驟(續(xù))一旦創(chuàng)建了意見一致的列表用況（UseCase）當需求收集起來后，分析員就可以創(chuàng)建一組標識串，構造系統(tǒng)的使用場景。創(chuàng)建用況模型的主要步驟如下：確定誰會直接使用該系統(tǒng)，即參與者（Actor）選取其中一個參與者定義該參與者希望系統(tǒng)做什么，參與者希望系統(tǒng)作的每件事將成為一個用況對每件事來說，何時參與者會使用系統(tǒng)，通常會發(fā)生什么，這就是用況的基本過程描述該用況的基本過程用況（UseCase）當需求收集起來后，分析員就可以創(chuàng)建內容摘要需求工程概述需求獲取需求分析、協(xié)商與建模需求規(guī)約與驗證需求管理內容摘要需求工程概述需求分析原則1．必須能夠表示和理解問題的信息域2．必須能夠定義軟件將完成的功能3．必須能夠表示軟件的行為(作為外部事件的結果)4．必須劃分描述數(shù)據(jù)、功能和行為的模型，從而可以分層次地揭示細節(jié)5．分析過程應該從要素信息移向細節(jié)信息需求分析原則1．必須能夠表示和理解問題的信息域信息域信息域：包括信息內容、信息流、以及信息結構。信息內容表示了單個數(shù)據(jù)和控制對象，目標軟件所有處理的信息集合由它們構成。例如，數(shù)據(jù)對象“工資”是一組重要數(shù)據(jù)體的組合：領款人的姓名、凈付款數(shù)、付款總額、扣除額等等

信息流表示了數(shù)據(jù)和控制在系統(tǒng)中流動時的變化方式，輸入對象被變換為中間信息(數(shù)據(jù)和/或控制)，然后進一步被變換為輸出信息域信息域：包括信息內容、信息流、以及信息結構。信息結構表示了各種數(shù)據(jù)和控制項的內部組織數(shù)據(jù)或控制項將被組織為n維表還是樹形結構？在結構的語境內，什么信息是和其他信息相關的？信息包含在單個結構中，還是使用不同的結構？在某信息結構中的信息如何和在另一個結構中的信息相關？信息域信息結構表示了各種數(shù)據(jù)和控制項的內部組織信息域抽象、分解與多視點分析問題抽象方法要求分析人員在分析過程中捕捉用戶描述或問題本身固有的一般-特殊關系首先關注一般問題的解決途徑，進而指導特殊問題的解決方法。抽象、分解與多視點分析問題抽象方法要求分析人員在分析過程中問題分解的目的是要能以層次化的方式對問題進行分解和不斷細化。較大規(guī)?；蜉^為復雜的問題可以被分解為若干子問題進行理解和分析分解可以逐級進行，直至子問題被分解為一個容易分析理解的部分例如橫向分解縱向分解抽象、分解與多視點分析問題分解的目的是要能以層次化的方式對問題進行分解和不斷細化。需求協(xié)商協(xié)商的過程就是討論需求沖突，找出每個人都滿意的折衷方案協(xié)商不是簡單的邏輯或技術上的爭論要注意組織和行政方面的因素①不一致的目標②責任的喪失或轉移③組織文化④組織管理態(tài)度和士氣⑤部門差異需求協(xié)商協(xié)商的過程就是討論需求沖突，找出每個人都滿意的折衷通常會議是解決沖突最快的方式參加者應該包括發(fā)現(xiàn)沖突、遺漏或重疊的分析員，以及可以解決發(fā)現(xiàn)的問題的項目相關人員會議應該討論那些非正式討論不能解決的問題通常會議分為三個階段：敘述階段討論階段決策階段需求協(xié)商通常會議是解決沖突最快的方式需求協(xié)商需求建模在軟件需求分析階段，所創(chuàng)建的模型，要著重于描述系統(tǒng)要做什么，而不是如何去做目標軟件的模型不應涉及軟件實現(xiàn)細節(jié)需求建模在軟件需求分析階段，所創(chuàng)建的模型，要著重于描述系統(tǒng)要常用的分析方法：面向數(shù)據(jù)流的結構化分析方法(SA)面向數(shù)據(jù)結構的分析方法面向對象的分析方法(OOA)需求建模常用的分析方法：需求建模內容摘要需求工程概述需求獲取需求分析、協(xié)商與建模需求規(guī)約與驗證