項目三需求分析任務一認識需求分析

任務二需求分析圖形工具任務三結構化分析技術

任務四編寫文檔

任務一認識需求分析

需求分析是軟件定義時期的最后一個階段，它的基本任務是準確地回答“系統必須做什么”這個問題。在需求分析階段產生的文檔是軟件需求規格說明書，它以書面形式準確地描述軟件需求。

在分析軟件需求和書寫軟件需求規格說明書的過程中，分析員和用戶都起著關鍵的、必不可少的作用：用戶不知道怎樣用軟件實現自己的需求，因此，用戶必須把他們對軟件的需求盡量準確、具體地描述出來；分析員對用戶的需求并不十分清楚，必須通過與用戶溝通獲取用戶對軟件的需求。需求分析和規格說明是一項十分艱巨復雜的工作。不僅在整個需求分析過程中應采用行之有效的通信技術，而且必須嚴格審查、驗證需求分析的結果。

目前，有很多用于需求分析的結構化分析方法，所有這些分析方法都遵守下述準則：

(1)必須理解并描述問題的信息域(建立數據模型)。

(2)必須定義軟件應完成的功能(建立功能模型)。

(3)必須描述作為外部事件結果的軟件行為(建立行為模型)。

(4)必須對描述信息、功能和行為的模型進行分解，用層次的方式展示細節。

操作一需求分析概述

需求分析是指開發人員要準確理解用戶的要求，進行細致的調查分析，將用戶非形式的需求陳述轉化為完整的需求定義，再由需求定義轉換到相應的形式功能規約(需求規格說明)的過程。需求分析雖處于軟件開發過程的開始階段，但它對于整個軟件開發過程以及軟件產品質量是至關重要的。在計算機發展的早期，所求解問題的規模小，需求分析未能得到重視。隨著軟件系統復雜性的提高及規模的擴大，需求分析在軟件開發中所處的地位愈加突出，從而也愈加困難，它的難點主要體現在以下幾個方面：

(1)問題的復雜性。這是由用戶需求所涉及的因素繁多引起的，如運行環境和系統功能等。

(2)交流障礙。需求分析涉及人員較多，如軟件系統用戶、問題領域專家、需求工程師和項目管理員等，這些人具備不同的背景知識、處于不同的角度、扮演不同角色，造成了相互之間交流的困難。

(3)不完備性和不一致性。由于各種原因，用戶對問題的陳述往往是不完備的，其各方面的需求還可能存在著矛盾，需求分析要消除其矛盾，形成完備及一致的定義。

(4)需求易變性。用戶需求的變動是一個極為普遍的問題，即使是部分變動，也往往會影響到需求分析的全部，導致不一致性和不完備性。為了克服上述困難，人們主要圍繞著需求分析的方法及自動化工具(如CASE技術)等方面進行研究。

近幾年來已提出許多軟件需求分析與說明的方法(如結構化分析方法和面向對象分析方法)，每一種分析方法都有獨特的觀點和表示法，但都適用下面的基本原則：

(1)必須能夠表達和理解問題的數據域和功能域。數據域包括數據流(即數據通過一個系統時的變化方式)、數據內容和數據結構，而功能域反映上述三方面的控制信息。

(2)可以把一個復雜問題按功能進行分解并可逐層細化。通常軟件要處理的問題如果太大太復雜就很難理解，若劃分成幾部分，并確定各部分間的接口，就可完成整體功能。在需求分析過程中，軟件領域中的數據、功能和行為都可劃分。

(3)可針對問題建模。模型可以幫助分析人員更好地理解軟件系統的信息、功能和行為，這些模型也是軟件設計的基礎。

1.需求分析的任務

軟件需求分析的任務是：深入描述軟件的功能和性能，確定軟件設計的約束和軟件同其他系統元素的接口細節，定義軟件的其他有效性需求，借助于當前系統的邏輯模型導出目標系統邏輯模型，解決目標系統“做什么”的問題(在可行性研究和項目開發計劃階段對這個問題的回答是概括的、粗略的)。

1)確定系統的綜合需求

系統分析員和用戶需共同確定對系統的綜合需求。表3-1給出了綜合需求的類別、定義和相關舉例，其中最重要的是功能需求，其應確定系統必須完成的所有功能。在確定功能需求的基礎上，還將根據組織機構和使用用戶的具體情況，確定系統在性能、運行等方面的一系列需求。

表3-1需?求?說?明?表

2)分析系統的數據要求

任何一個軟件系統本質上都是信息處理系統，系統必須處理的信息和系統應該產生的信息在很大程度上決定了系統的面貌，對軟件設計有深遠影響，因此，必須分析系統的數據要求，這是軟件需求分析的一個重要任務。分析系統的數據要求通常采用建立數據模型的方法。

軟件系統復雜的數據由許多基本的數據元素組成，數據元素之間的邏輯關系用數據結構來表示。利用數據字典可以全面準確地定義數據，但是數據字典的缺點是不夠直觀。為了提高可理解性，常常利用圖形工具輔助描繪數據結構。常用的圖形工具有層次方框圖和Warnier圖。

3)導出系統的邏輯模型

綜合上述兩項分析的結果可以導出系統詳細的邏輯模型，通常用數據流圖、實體-聯系圖、狀態轉換圖、數據字典和主要的處理算法描述這個邏輯模型。

4)修正系統開發計劃

根據在分析過程中獲得的對系統的更深入更具體的了解，可以比較準確地估計系統的成本和進度，修正以前制定的開發計劃。

5)開發原型系統

快速原型方法的核心思想是：在軟件開發的早期快速建立目標軟件的原型，讓用戶對原型進行評估并提出修改意見，當原型幾經改進最終確定后，它將由軟件設計和編碼階段進化成軟件產品；或者設計和編碼人員遵循原型所確立的外部特征實現軟件產品。

2.需求分析的步驟

1)問題識別

問題識別是指從系統的角度來理解軟件并評審軟件范圍是否恰當，確定對目標系統的綜合要求，即軟件的需求，提出這些需求的實現條件，以及需求應達到的標準。問題識別的另一項工作是建立分析所需要的通信途徑(如圖3-1所示)，以保證能順利地對問題進行分析。圖3-1問題識別的通信途徑

2)分析、綜合并導出軟件的邏輯模型

分析人員對獲取的需求進行一致性的分析檢查，在分析、綜合中逐步細分軟件功能，劃分各個子功能。這里也包括對數據域進行分解，并分配到各個子功能上，以確定系統的構成及主要成分，并用圖文結合的形式，建立起新系統的邏輯模型。

3)編寫文檔

編寫文檔的步驟如下：

(1)編寫“需求說明書”，把雙方共同的理解與分析結果用規范的方式描述出來，作為今后各項工作的基礎。

(2)編寫初步用戶使用手冊，著重反映被開發軟件的用戶功能界面和用戶使用的具體要求，用戶手冊能強制分析人員從用戶使用的觀點考慮軟件。

(3)編寫確認測試計劃，作為今后確認和驗收的依據。

(4)修改完善項目開發計劃。在需求分析階段對開發的系統有了更進一步的了解，所以能更準確地估計開發成本、進度及資源要求，因此對原計劃要進行適當修正。

4)需求評審

需求評審的內容包括：系統定義的目標是否與用戶的要求一致；系統需求分析階段提供的文檔資料是否齊全；文檔中的所有描述是否完整、清晰、準確反映用戶要求；與所有其他系統成分的重要接口是否都已經描述；被開發項目的數據流與數據結構是否足夠、確定；所有圖表是否清楚，在不補充說明時能否理解；主要功能是否已包括在規定的軟件范圍之內，是否都已充分說明；設計的約束條件或限制條件是否符合實際；開發的技術風險是什么；是否考慮過軟件需求的其他方案；是否考慮過將來可能會提出的軟件需求；是否詳細制定了檢驗標準，它們能否對系統定義是否成功進行確認。

操作二需求分析方法

需求分析的過程如圖3-2所示。需求分析方法有功能分解方法、結構化分析方法、信息建模方法和面向對象分析方法等。圖3-2需求分析的過程

1.功能分解方法

功能分解方法是將一個系統看成是由若干功能構成的一個集合，每個功能又可劃分成若干個加工(即子功能)，一個加工又可進一步分解成若干加工步驟(即子加工)。因此，功能分解方法有功能、子功能和功能接口三個組成要素。它的關鍵策略是利用已有的經驗，對一個新系統預先設定加工和加工步驟，著眼點放在這個新系統需要進行什么樣的加工上。

功能分解方法本質上是用過程抽象的觀點來看待系統需求，符合傳統程序設計人員的思維特征，而且分解的結果一般已經是系統程序結構的一個雛形，實際上它已經很難與軟件設計明確分離。這種方法存在一些問題，它需要人工來完成從問題空間到功能和子功能的映射，既沒有顯式地將問題空間表現出來，也無法對表現的準確程度進行驗證，而問題空間中的一些重要細節更是無法提示出來。可以看出，功能分解方法缺乏對客觀世界中相對穩定的實體結構進行描述，而將基點放在相對不穩定的實體行為上，因此，基點是不穩定的，難以適應需求的變化。

2.結構化分析方法

結構化分析方法是一種從問題空間到某種表示的映射方法，它由數據流圖表示，是結構化重要的、被普遍接受的表示系統，它由數據流圖和數據詞典構成。這種方法簡單實用，適用于數據處理領域問題。

該方法沿現實世界中的數據流進行分析，把數據流映射到分析結果中。但現實世界中的有些要求不是以數據流為主干的，就難于用此方法。如果分析是在現有系統的基礎上進行的，應先除去原來物理上的特性，增加新的邏輯要求，再追加新的物理上的考慮，這時，分析面對的并不是問題空間本身，而是過去對問題空間的某一映射，在這種焦點已經錯位的前提下，進行分析顯然是十分困難的。該方法的一個難點是確定數據流之間的變換，而且數據詞典的規模也是一個問題，它會引起所謂的“數據詞典爆炸”，同時對數據結構的強調很少。

3.信息建模方法

信息建模方法是從數據的角度來對現實世界建立模型的，它對問題空間的認識是很有幫助的。該方法的基本工具是ER圖(實體聯系圖)，其基本要素由實體、屬性和聯系構成。該方法的基本策略是從現實世界中找出實體，然后再用屬性來描述這些實體。信息模型和語義數據模型是緊密相關的，有時被看做是數據庫模型。在信息模型中，實體E是一個對象或一組對象，實體把信息收集在其中。關系R是實體之間的聯系或交互作用，有時在實體和關系之外，再加上屬性。實體和關系形成一個網絡，描述系統的信息狀況，給出系統的信息模型。

信息建模和面向對象分析很接近，但仍有很大差別。在ER圖中，數據不封閉，每個實體和它的屬性的處理需求不是組合在同一實體中的，沒有繼承性和消息傳遞機制來支持模型。但ER圖是面向對象分析的基礎。

4.面向對象分析方法

面向對象的分析是把ER圖中的概念與面向對象程序設計語言中的主要概念結合在一起而形成的一種分析方法。在該方法中采用了實體、關系和屬性等信息模型分析中的概念，同時采用了封閉、類結構和繼承性等面向對象程序設計語言中的概念。

操作三需求獲取方法

1.訪談

訪談是最早開始使用的獲取用戶需求的技術，也是迄今為止仍然廣泛使用的需求分析技術。

訪談有兩種基本形式，分別是正式的和非正式的訪談。正式訪談時，系統分析員將提出一些事先準備好的具體問題。在非正式訪談中，分析員將提出一些用戶可以自由回答的開放性問題，以鼓勵被訪問人員說出自己的想法。

當需要調查大量人員的意見時，向被調查人分發調查表是一個十分有效的做法。分析員仔細閱讀收回的調查表，然后再有針對性地訪問一些用戶，以便向他們詢問在分析調查表時發現的新問題。所謂情景分析，就是對用戶將來使用目標系統解決某個具體問題的方法和結果進行分析。在訪問用戶的過程中使用情景分析技術往往非常有效。主要體現在下述兩個方面：

(1)它能在某種程度上演示目標系統的行為，從而便于用戶理解，而且還可能進一步揭示出一些分析員目前還不知道的需求。

(2)由于情景分析較易為用戶所理解，使用戶在需求分析過程中始終扮演一個積極主動的角色，以獲得更多的用戶需求。

2.面向數據流自頂向下求精

軟件系統的基本功能都是把輸入數據轉變成需要的輸出數據。從本質看，數據決定了系統的處理和算法，因而，數據是需求分析的出發點。結構化分析方法就是面向數據流自頂向下逐步求精進行需求分析的方法。

采用結構化分析方法進行需求分析的目標之一就是把可行性研究得到數據流和數據存儲定義到元素級(足夠小數據)。為了達到這個目標，該方法通常從數據流圖的輸出端著手分析，分析輸出數據是由哪些元素組成的，每個輸出數據元素又是從哪里來的，沿數據流圖從輸出端往輸入端回溯，即可確定每個數據元素的組成和來源(是從外面輸入到系統中的，還是通過計算由系統中產生出的)，與此同時也就初步定義了有關的數據處理算法。通常把自頂向下逐步求精分析過程中得到的相關數據元素的信息記錄在數據字典中，把對算法的簡明描述記錄在IPO(輸入-處理-輸出)圖中。經過分析而補充的數據流、數據存儲和處理，也應該添加到數據流圖的適當位置上。

通過用戶對數據流的復查與驗證，可補充未知的數據元素，或修正原有的數據元素。

通過自頂向下逐步求精的功能分解，可以完成數據流圖的細化。

反復進行上述分析過程，分析員將越來越深入具體地定義目標系統，最終得到對系統數據和功能要求的滿意了解。圖3-3粗略地概括了上述分析過程。圖3-3自頂向下逐步求精分析過程

3.快速建立軟件原型

快速原型就是根據用戶需求，快速建立起可運行的目標系統。其要點是：它應該實現用戶看得見的功能(如：屏幕顯示或打印報表)，省略“隱含”的功能(如：修改文件)。快速建立軟件原型是最準確、最有效、最強大的需求分析技術。

快速原型應該具備如下特性：

(1)快速。目的是盡快向用戶提供一個可在計算機上運行的目標系統的模型，以便使用戶和開發者在目標系統應該“做什么”這個問題上盡可能快地達成共識。

(2)容易修改。根據用戶的意見迅速地修改，以便滿足用戶需求。原型的修改，是“修改—試用—反饋”過程。為了快速地構建和修改原型，通常使用下述三種方法和工具：

(1)第四代技術。第四代技術包括眾多數據庫查詢和報表語言、程序和應用系統生成器以及其他非常高級的非過程語言。

(2)可重用的軟件構件。快速構建原型的另一種方法，是使用一組已有的軟件構件(也稱為組件)來裝配(而不是從頭構造)原型。軟件構件可以是數據結構(或數據庫)，或軟件體系結構構件(即程序)，或過程構件(即模塊)。

(3)形式化規格說明和原型環境。形式化語言的倡導者正在開發交互式環境，以便可以調用自動工具把基于形式語言的規格說明翻譯成可執行的程序代碼，用戶能夠使用可執行的原型代碼去進一步精化形式化的規格說明。

任務二需求分析圖形工具

操作一數據流圖

數據流圖是一種圖形化技術，它對系統的邏輯功能進行描繪，圖中沒有任何具體的物理元素，只是描繪數據在軟件中流動和被處理的邏輯過程。

數據流圖是分析員與用戶之間極好的通信工具。作為交流信息的工具，分析員把系統的邏輯模型用數據流圖描繪出來，供有關人員審查確認。分析員用常用系統流程圖來表達對新系統的認識，這種描繪方法形象具體，比較容易驗證其正確性。當用數據流圖輔助物理系統的設計時，可根據系統的邏輯模型考慮系統的物理實現。

1.基本概念和符號

數據流圖有四種基本符號，如表3-2所示。表3-2數據流圖符號說明

2.繪制數據流圖的步驟

繪制數據流圖有以下兩步：

(1)首先繪制系統的輸入/輸出，即先繪制頂層數據流圖。

(2)繪制系統內部，即繪制下層數據流圖。一般將層號從0開始編號，采用自頂向下、由外向內的原則。

(3)其注意事項有：

①命名；

②編號；

③每個處理(加工)至少有一個輸入和輸出數據流；

④繪制數據流而不是控制流；

⑤父圖與子圖的平衡；

⑥局部數據存儲；

⑦可理解性。示例如圖3-4至圖3-6所示。圖3-5訂貨系統的功能級數據流圖(0層圖)圖3-4訂貨系統的基本模型(頂層圖)(突出表明了數據的源點和終點)

(4)命名。數據流圖中每個成分的命名是否恰當，直接影響數據流圖的可理解性。在命名時應注意，為數據流(或數據存儲)命名時，名字應代表整個數據流(或數據存儲)的內容,使人容易理解其含義，如庫存信息、訂貨報表等。為處理命名時，名字應該反映整個處理的功能，如處理訂貨、產生報表等。圖3-6把處理事務的功能進一步分解后的數據流圖(1層圖)

操作二數據字典

數據字典是關于數據信息的集合，也就是對數據流圖中包含的所有元素定義的集合。繪制數據流程圖以后，只是對數據處理和彼此之間的聯系進行了說明，為了進一步明確數據的詳細內容和數據加工過程，引入了數據字典。

數據字典的作用是給數據流程圖上每個成分加以定義和說明。換句話說，數據流程圖只能給出系統邏輯功能的一個總框架，而缺乏詳細、具體的內容。數據字典對數據流程圖的各種成分起注解、說明作用，給這些成分賦予實際的內容。除此以外，數據字典還要對系統分析中其他需要說明的問題進行定義和說明。數據流圖和數據字典共同構成系統的邏輯模型，沒有數據字典，數據流圖就不嚴格；沒有數據流圖，數據字典也難于發揮作用。

1.數據字典的內容

數據字典的內容包括五個方面：數據流、數據存儲、數據元素、外部項、加工。其中，數據元素是組成數據流的基本成分。

數據流：由一個或一組固定的數據元素組成。定義數據流時，不僅要說明數據流的名稱、組成等，還應指明它的來源、去向和流通量等。數據存儲：是數據結構停留的場所。數據存儲只是描述數據的邏輯存儲的結構，不涉及物理組織，通常包括編號、名稱、簡述、組成、關鍵字和相關聯的處理等。

數據元素：又稱為數據項，是數據的最小單位。對數據應從靜態及動態兩個方面去分析。在數據字典中，主要是對數據的靜態特性加以定義。

外部項：包括外部項名稱、編號、簡述及有關數據流的輸入和輸出。

加工：是對數據流程圖中最底層的處理邏輯加以說明，內容包括加工名稱、簡述、輸入、處理過程、輸出和處理頻率。

2.定義數據的方法

數據字典中的定義就是對數據自頂向下的分解，應把數據分解到什么程度，一般以其含義清楚作為標準。

由數據項(數據元素)組成數據的方式有四種類型：

(1)順序：以確定次序連接兩個或多個分量；

(2)選擇：從兩個或多個可能的元素中選擇一個；

(3)重復：指定的分量重復零次或多次；

(4)可選：一個分量是可有可無的。

數據字典中常用的一些符號如下所示：

“＝”：等價于(定義為)；

“＋”：和(連接兩個分量)；

“[]”：或(選其中之一)；

“{}”：重復；

“()”：可選(可有可無)。

3.實例

以下列出希望中學教務管理信息系統部分主要數據流、數據元素、數據存儲外部項及加工的數據字典。

(1)數據流的數據字典(如表3-3所示)。表3-3數據流的數據字典

(2)數據存儲的數據字典(如表3-4所示)。表3-4數據存儲的數據字典

(3)數據元素的數據字典(如表3-5所示)。表3-5數據元素的數據字典

(4)外部項的數據字典(如表3-6所示)。表3-6外部項的數據字典

(5)加工的數據字典(如表3-7所示)。表3-7加工的數據字典

操作三實體聯系圖

1.基本概念和符號

數據模型包含3種信息：數據對象、數據對象的屬性及數據對象彼此間相互連接的關系。

1)數據對象(實體)

數據對象是對軟件的復合信息的抽象，它是指具有一系列不同性質或屬性的事物，僅有單個值的事物(如：寬度)不是數據對象。

數據對象可以是外部實體(產生或使用信息的任何事物)、事物(如報表)、行為(如打電話)、事件(如響警報)、角色(如教師、學生)、單位(如會計科)、地點(如倉庫)或結構(如文件)等。數據對象彼此間是有關聯的，如：教師與學生之間有教或學的關系。

數據對象只封裝了數據而沒有對施加于數據上的操作進行引用。

2)屬性

屬性是數據對象或聯系所具有的性質。一個數據對象通常由若干個屬性來刻畫，如：學生有學號、姓名、性別、系、年級等。聯系也可能有屬性，如：學生“學”某門課程。

3)聯系

聯系是數據對象彼此之間相互連接的方式，也稱為關系。聯系分為3種類型：

(1)一對一聯系(1∶1)，如：一個部門有一個經理。

(2)一對多聯系(1∶N)，如：教師與課程。

(3)多對多聯系(M∶N)，如：學生與課程。

4)實體—聯系圖(Entity-RelationshipDiagram，E-R圖)的符號

通常用矩形框代表實體，菱形框表示聯系，用橢圓形或圓角矩形表示實體(或關系)的屬性，如圖3-7所示。圖3-7實體聯系圖的符號

2．E-R圖實例

數據庫設計中十分重視數據分析、抽象與概念結構的設計，概念結構的設計是整個數據庫設計的關鍵。用于描述概念結構模型的工具是E-R模型。需求分析采用自頂向下的結構設計方法，而概念結構設計通常采用自底向上的設計方法，這種方法是首先定義各局部應用的概念結構，然后將它們集成，得到全局的概念結構，即：需求分析的數據流圖(DFD)、數據字典(DD)→概念結構設計中的分E-R圖→總E-R圖。數據模型是數據庫設計的核心和基礎，概念結構模型是將現實世界中的客觀對象首先抽象成為不依賴任何具體機器的信息結構。概念結構不是數據庫管理系統CDBMS支持的數據模型，而是概念級模型。然后再把概念模型轉換為具體機器DBMS支持的數據模型。因此，概念模型可以看成是顯示世界到機器世界的一個過渡的中間層次。

概念結構模型的特點：是對現實世界的抽象和概括；簡潔、明晰、獨立于機器，很容易理解；易于更動；容易向關系、網狀、層次等各種數據模型轉換。

概念結構模型最常用的表示方法是實體-聯系方法。以希望中學的教務管理信息系統為例，按照數據庫的概念設計本系統的E-R圖(見圖3-8)。圖3-8教務管理信息系統的實體—聯系圖

操作四狀態轉換圖

狀態轉換圖簡稱狀態圖，是描述行為模型的常用工具。它通過描繪系統的狀態及引起系統狀態轉換的事件，來表示系統的行為。此外，狀態圖還指明了事件將做的動作(如：處理數據)。因此，狀態圖提供了在需求分析過程中建立軟件系統的行為模型的機制。狀態轉換圖的基本概念和符號如下所示：

1.狀態

狀態是系統行為模式，一個狀態代表系統的一種行為模式。

狀態規定了系統對事件的響應方式。系統對事件的響應，既可以是做一個(或一系列)動作，也可以是僅僅改變系統本身的狀態，還可以是既改變狀態又做動作。

在狀態圖中定義的狀態主要有：初態(即初始狀態)、終態(即最終狀態)和中間狀態。在一張狀態圖中只能有一個初態，而終態則可以有0至多個。

2.事件

事件是在某個特定時刻發生的事情，它是對引起系統做動作或(和)從一個狀態轉換到另一個狀態的外界事件的抽象，是一種控制信息，沒有持續時間，是瞬間完成的。

例如，敲擊鍵盤或點擊鼠標等都是事件。

3.符號

初態用實心圓表示：·?。

終態用一對同心圓(內圓為實心圓)表示：⊙。

中間狀態用圓角矩形表示，可以用兩條水平橫線把它分成上、中、下3個部分。上面部分為狀態的名稱，是必須有的；中間部分為狀態變量的名字和值，是可選的；下面部分是活動表，是可選的。

狀態轉換圖如圖3-9所示。圖3-9狀態轉換圖活動表的語法格式為：事件名(參數表)/動作表達式。

在活動表中經常使用3種標準事件：entry、exit和do。entry事件指定進入該狀態的動作，exit事件指定退出該狀態的動作，而do事件則指定在該狀態下的動作。

狀態圖中兩個狀態之間帶箭頭的連線稱為狀態轉換，箭頭指明了轉換方向。狀態轉換通常是由事件觸發的，因此，在箭頭線上要標出觸發狀態轉換的事件表達式。如果在箭頭線上未標明事件，則表示在源狀態的內部活動執行完之后自動觸發轉換。事件表達式的語法為：事件說明[守衛條件]/動作表達式。其中：

事件說明的語法為：事件名(參數表)；守衛條件是一個布爾表達式。如果同時使用事件說明和守衛條件，則當且僅當事件發生且布爾表達式為真時，狀態轉換才發生，如果只有守衛條件沒有事件說明，則只要守衛條件為真狀態轉換就發生。

動作表達式是一個過程表達式，當狀態轉換開始時執行該表達式。

圖3-10所示是電話系統的狀態轉換圖。圖3-10電話系統的狀態轉換圖圖3-10表明，沒有人打電話時電話處于閑置狀態；有人拿起聽筒則進入撥號音狀態，到達這個狀態后，電話的行為是響起撥號音并計時；這時如果拿起聽筒的人改變主意不想打了，他把聽筒放下(掛斷)，電話重又回到閑置狀態；如果拿起聽筒很長時間不撥號(超時)，則進入超時狀態；……。

任務三結構化分析技術

操作一結構化分析技術

人在求解問題時，首要需要做的是理解問題，并且對問題理解得越透徹，這個問題就越容易解決。所謂模型，就是為了理解問題而對問題做的一種符號抽象。可以把模型看做一種思維工具，利用這種工具可以把問題規范地表示出來。

模型一般由一組圖示符號和組織這些符號的規則組成。因此，分析時期的建模，就是針對用戶需求、系統需求等，采用圖示方式進行直觀描述。軟件問題往往是復雜的，而建模可以使問題簡化。人的頭腦每次只能處理一定數量的信息，模型通過把系統分解成人的頭腦一次能處理的若干個子部分，從而減少系統的復雜程度。分析時期建立軟件模型的作用是多方面的，可以通過模型實現由用戶需求向系統需求的過渡，并可通過模型獲得對系統需求的更具細節性的推論。實際上，分析時期產生的模型還可以被引用到系統設計中去，作為設計前導。

為了開發復雜的軟件系統，往往需要從不同角度去構造系統模型，例如：用于描述系統功能組織結構的層次模型，用于描述系統中數據加工流程的數據流模型，用于描述數據實體及其關系的數據關系模型，用于描述系統行為過程的系統狀態模型等。

結構化分析方法適用于數據處理類型軟件的需求分析。具體來說，結構化分析方法就是用抽象模型的概念，按照軟件內部數據傳遞、變換