軟件工程課件：第03章 需求分析

1、第三章 需求分析第3章 需求分析3.0 需求分析概述3.1 需求分析的任務(wù)3.2 與用戶溝通獲取需求的方法3.3 分析建模與規(guī)格說明3.4 實(shí)體-聯(lián)系圖3.5 數(shù)據(jù)規(guī)范化3.6 狀態(tài)轉(zhuǎn)換圖+有窮狀態(tài)機(jī)3.7 其他圖形工具3.8 驗(yàn)證軟件需求3.9 小結(jié)3.0 需求分析概述需求分析的意義需求分析的目的需求分析的相關(guān)人需求分析的意義軟件需求的深入理解是軟件開發(fā)工作獲得成功的前提條件，不論我們把設(shè)計(jì)和編碼做得如何出色，不能真正滿足用戶需求的程序只會(huì)令用戶失望，給開發(fā)帶來煩惱。需求分析的目的需求分析是軟件定義時(shí)期的最后一個(gè)階段，它的基本任務(wù)不是確定系統(tǒng)怎樣完成它的工作，而是確定系統(tǒng)必須完成哪些工作，也

2、就是對目標(biāo)系統(tǒng)提出完整、準(zhǔn)確、清晰、具體的要求。并在在需求分析階段結(jié)束之前，由系統(tǒng)分析員寫出軟件需求規(guī)格說明書，以書面形式準(zhǔn)確地描述軟件需求。- 準(zhǔn)確地回答“系統(tǒng)必須做什么?”需求分析的相關(guān)人 在分析軟件需求和書寫軟件需求規(guī)格說明書的過程中，分析員和用戶都起著關(guān)鍵的、必不可少的作用。 業(yè)務(wù)需求項(xiàng)目范圍文檔用戶需求可研文檔功能需求質(zhì)量屬性其他非功能需求設(shè)計(jì)約束需求規(guī)約(規(guī)格)(specification)非功能需求系統(tǒng)需求需求組成的全景圖軟件需求的組成（圖）問題的定義可行性研究需求分析軟件需求的組成部分業(yè)務(wù)需求：反映組織機(jī)構(gòu)和客戶對系統(tǒng)、產(chǎn)品高層次的目標(biāo)要求。用戶需求：從用戶使用的角度給出需求的

3、描述。系統(tǒng)需求：從系統(tǒng)的角度描述要提供的服務(wù)以及所受到的約束。功能需求：描述系統(tǒng)應(yīng)該做什么，即為用戶和其它系統(tǒng)完成的功能、提供的服務(wù)。性能需求存儲(chǔ)容量、處理速度、用戶數(shù)、并發(fā)能力等。接口需求本系統(tǒng)與其他系統(tǒng)的接口。出錯(cuò)處理需求系統(tǒng)可能的錯(cuò)誤及其處理方法。非功能性需求：系統(tǒng)必須具備的屬性或品質(zhì)?？煽啃院涂捎眯孕枨罂煽啃灾笜?biāo)、可用性指標(biāo)設(shè)計(jì)約束：設(shè)計(jì)與實(shí)現(xiàn)必須遵循的標(biāo)準(zhǔn)、約束條件。如運(yùn)行平臺(tái)、協(xié)議、選擇的技術(shù)、編程語言和工具等。例：小型超市商品查詢系統(tǒng)的需求業(yè)務(wù)需求：進(jìn)貨人員需要查詢商品庫存以便保證及時(shí)進(jìn)貨；收款員需要查詢商品的銷售價(jià)格以便結(jié)賬；經(jīng)理需要查詢商品的銷售及盈利情況。用戶需求:三類用戶

4、（進(jìn)貨人員、收款員、經(jīng)理）怎樣去查詢系統(tǒng)，查詢哪些信息，還需要哪些操作。軟件需求的描述語言描述自然語言、結(jié)構(gòu)化語言、過程描述語言PDL.圖形/表格化描述數(shù)據(jù)流圖、數(shù)據(jù)字典、IPO圖、判定表、判定樹、狀態(tài)圖.數(shù)學(xué)描述形式化語言、函數(shù)、狀態(tài)機(jī)確定對系統(tǒng)的綜合要求功能需求、性能需求、可靠性和可用性需求、出錯(cuò)處理需求、接口需求、約束、 逆向需求、將來可能提出的要求。分析系統(tǒng)的數(shù)據(jù)要求用直觀和定義的形式建立系統(tǒng)的數(shù)據(jù)模型，優(yōu)化和規(guī)范化數(shù)據(jù)結(jié)構(gòu)。 常用工具：圖形工具（層次方框圖、Warnier圖）、數(shù)據(jù)字典。導(dǎo)出系統(tǒng)的邏輯模型綜合上述分析結(jié)果，導(dǎo)出系統(tǒng)的詳細(xì)邏輯模型。常用工具：數(shù)據(jù)流圖、實(shí)體-聯(lián)系圖、狀態(tài)

5、轉(zhuǎn)換圖、數(shù)據(jù)字典、主要處理算法。修正系統(tǒng)開發(fā)計(jì)劃以詳細(xì)邏輯模型為基礎(chǔ)，與用戶交流，跟深入地了解和明確用戶的需求，估算系統(tǒng)開發(fā)成本、進(jìn)度等，修訂項(xiàng)目開發(fā)計(jì)劃。3.1 需求分析的任務(wù)軟件需求獲取和分析過程（圖）需求分析是一個(gè)包括創(chuàng)建和維持系統(tǒng)需求文檔所必需的一切活動(dòng)的過程。它包含了如下活動(dòng)：軟件需求過程需求獲取和分析需求描述需求有效性驗(yàn)證系統(tǒng)模型用戶需求和系統(tǒng)需求需求規(guī)約需求管理軟件需求獲取和分析需求獲取是開發(fā)人員與客戶或用戶一起對應(yīng)用領(lǐng)域進(jìn)行調(diào)查研究，收集系統(tǒng)需求的過程。需求分析是將獲取到的需求準(zhǔn)確的理解、求精，并將其轉(zhuǎn)化為完整的需求定義（包括建模），進(jìn)而生成需求規(guī)約的過程。需求描述和文檔編寫按

6、照規(guī)范的格式（標(biāo)準(zhǔn)指南，如國標(biāo)）和采用常用的工具編制軟件需求分析說明書。需求管理管理需求工程的變更。 需求有效性驗(yàn)證提交用戶反饋，召開需求評審會(huì)。需求獲取和分析的難度1）需求難以表達(dá)出來項(xiàng)目相關(guān)人員通常并不真正知道希望計(jì)算機(jī)做什么，讓他們清晰的表達(dá)出需要系統(tǒng)做什么是件困難的事，他們或許提出不切實(shí)際的要求。2）需求具有專業(yè)性項(xiàng)目相關(guān)人員用自己的語言表達(dá)需求，這些語言包含很多工作中的專業(yè)術(shù)語和專業(yè)知識(shí)。系統(tǒng)分析員沒有這些知識(shí)和經(jīng)驗(yàn)，而他們又必須了解這些需求。3）需求的不一致性不同的項(xiàng)目相關(guān)人員有不同的需求，可能以不同的方式表達(dá)，分析人員必須發(fā)現(xiàn)所有潛在的需求資源，而且能夠發(fā)現(xiàn)這些需求的相容或沖突之

7、處。4）需求的變化性經(jīng)濟(jì)和業(yè)務(wù)環(huán)境決定了分析是動(dòng)態(tài)的，需求在分析過程中會(huì)發(fā)生變更。個(gè)別需求的重要程度可能會(huì)改變，新的需求可能會(huì)從新的項(xiàng)目相關(guān)人員那里得到。需求分析小組建立由客戶（用戶）、系統(tǒng)分析員、領(lǐng)域?qū)＜覅⒓拥穆?lián)合小組。需求獲取的方法個(gè)別訪談、召集會(huì)議、文檔研究、問卷調(diào)查、觀察用戶工作流程、建立原型。需求表達(dá)的技術(shù)（1）需求列表：需求與系統(tǒng)的特殊視角或環(huán)境的關(guān)系（2）業(yè)務(wù)流程圖（狀態(tài)/活動(dòng)圖）（3）數(shù)據(jù)流圖（4）實(shí)體-聯(lián)系圖需求獲取方法與技術(shù)3.2 與用戶溝通獲取需求的方法3.2.1 訪談3.2.2 面向數(shù)據(jù)流自頂向下求精3.2.3 簡易的應(yīng)用規(guī)格說明技術(shù)3.2.4 快速建立軟件原型3.2.

8、1 訪談訪談的基本形式非正式訪談：獲取用戶(高端用戶)的想法、理念;正式訪談：獲取用戶（業(yè)務(wù)部門用戶）的具體需求，如功能需求、數(shù)據(jù)需求等。訪談技術(shù)開放性問題（非正式訪談）具體問題（正式訪談）問卷調(diào)查表情景分析技術(shù)座談會(huì)3.2.2 面向數(shù)據(jù)流自頂向下求精數(shù)據(jù)流分析重要性數(shù)據(jù)是需求分析的出發(fā)點(diǎn)和落腳點(diǎn)信息系統(tǒng)的基本模型：輸入數(shù)據(jù)數(shù)據(jù)處理輸出數(shù)據(jù)數(shù)據(jù)在流動(dòng)中被處理，數(shù)據(jù)決定了處理所需的算法結(jié)構(gòu)化分析方法可實(shí)現(xiàn)數(shù)據(jù)流自頂向下逐步求精從可行性研究得出的頂層模型（頂層數(shù)據(jù)流圖）開始，將數(shù)據(jù)流和數(shù)據(jù)存儲(chǔ)及其處理向下分解，直到元素級。數(shù)據(jù)流分析的結(jié)果清晰地定義了可實(shí)際操作的個(gè)數(shù)據(jù)元素；明確地展現(xiàn)了數(shù)據(jù)的來源與

9、去處；初步描繪了數(shù)據(jù)處理的可能算法（方法）。數(shù)據(jù)流描述方法數(shù)據(jù)流圖：數(shù)據(jù)及其處理關(guān)系數(shù)據(jù)字典：數(shù)據(jù)元素IPO圖：處理算法面向數(shù)據(jù)流自頂向下求精迭代過程（圖）3.2.3 簡易的應(yīng)用規(guī)格說明技術(shù)前敘方法的缺陷問題面談?wù){(diào)研、數(shù)據(jù)流圖、數(shù)據(jù)字典等是具有一定技術(shù)性的、形式性方法，一般用于難以掌握，不好交流，不難有效地構(gòu)建需求分析團(tuán)隊(duì)。簡易的應(yīng)用規(guī)格說明技術(shù)這是一種面向團(tuán)隊(duì)的需求收集方法。提倡用戶與開發(fā)者密切合作，共同標(biāo)識(shí)問題，提出解決方案要素，商討不同方案并指定基本需求。簡易的應(yīng)用規(guī)格說明技術(shù)的過程確定問題進(jìn)行初步的訪談，初步確定問題范圍和解決方案；編制“產(chǎn)品需求”開發(fā)者、用戶分別寫出“產(chǎn)品需求”，發(fā)給

10、雙方有關(guān)人員預(yù)審；“產(chǎn)品需求” 預(yù)審相關(guān)預(yù)審人員分別列出系統(tǒng)有關(guān)對象、服務(wù)要求、約束條件、性能要求召開協(xié)調(diào)會(huì)開發(fā)者和用戶雙方組織的代表出席會(huì)議確定是否開發(fā)該新軟件產(chǎn)品討論各自提出的“產(chǎn)品需求” 預(yù)審表項(xiàng)：保留、增加、刪除、修改針對每一個(gè)子項(xiàng)目（對象、服務(wù)、約束、性能）創(chuàng)建一張組合列表小組制定每個(gè)子項(xiàng)目小型規(guī)格說明按子項(xiàng)目劃分小組，每個(gè)小組為每張列表中的項(xiàng)目制定小型規(guī)格說明各小組向項(xiàng)目全體人員說明制定的小型規(guī)格說明，討論、修改、細(xì)化、規(guī)范化項(xiàng)目組起草完整的軟件需求規(guī)格說明書由專人或?qū)ｉT小組整合各小型規(guī)格說明，起草起草完整的軟件需求規(guī)格說明書?！爱a(chǎn)品需求” 預(yù)審內(nèi)容對象組成系統(tǒng)的對象、系統(tǒng)將產(chǎn)生的

11、對象、完成功能將用到的其他對象；服務(wù)要求操作這些對象或與這些對象交互的服務(wù)（處理功能）；約束條件成本、工期、規(guī)模等；性能要求系統(tǒng)的技術(shù)性能，如容量、速度等。其他3.2.4 快速建立軟件原型構(gòu)建軟件原型按照“快速原型法”構(gòu)建系統(tǒng)的軟件原型，這是最準(zhǔn)確、最有效、最強(qiáng)大的需求分析技術(shù)。軟件原型的要點(diǎn)是展現(xiàn)用戶看得見、直接交互的功能，如輸入、輸出、檢索、顯示、打印等。軟件原型構(gòu)建特性快速易于修改軟件原型構(gòu)建方法和工具（綜合使用）第四代程序設(shè)計(jì)技術(shù)可重用的軟件構(gòu)建形式化規(guī)格說明工具和軟件環(huán)境工具3.3 分析建模與規(guī)格說明3.3.1 分析建模采用有效的建模技術(shù)及工具，分析和構(gòu)建系統(tǒng)的邏輯模型。3.3.2

12、規(guī)格說明按照確定的文檔規(guī)范（國家、行業(yè)、企業(yè)），使用自然語言和系統(tǒng)模型，完整準(zhǔn)確地描述軟件需求。3.3.1 分析建模模型“模型”是為了理解事物而對事物做出的一種抽象，是對事物的一種無歧義的書面描述。通常，由一組圖形符號和組織這些符號的規(guī)則組成。結(jié)構(gòu)化分析建模方法結(jié)構(gòu)化分析 (Structured Analysis，SA)的基本原理是自頂向下、逐步求精。它是70年代末由DeMarco等人提出，這是傳統(tǒng)的建模方法。該方法不是被所有的使用者一致地使用的單一方法，眾多科學(xué)家對其進(jìn)行了擴(kuò)充。 三種模型面向流的建模：數(shù)據(jù)流圖（DFD/CFD）數(shù)據(jù)建模：實(shí)體關(guān)系圖（ERD）基于行為的建模： Petri網(wǎng)、狀

13、態(tài)轉(zhuǎn)換圖3.3.2 軟件需求規(guī)格說明(SRS) Software Requirement Specification 通常用自然語言+模型，完整、準(zhǔn)確、具體地描述系統(tǒng)的數(shù)據(jù)要求、功能需求、性能需求、可靠性和可用性要求、出錯(cuò)處理需求、接口需求、約束、逆向需求以及將來可能提出的要求。 軟件需求規(guī)格說明書，是需求分析階段得出的最主要的文檔。軟件需求說明書的編寫提示（GB856T880）1 引言 1.1 編寫目的 1.2 背景 1.3 定義 1.4 參考資料2 任務(wù)概述 2.1 目標(biāo) 2.2 用戶的特點(diǎn) 2.3 假定和約束3 需求規(guī)定 3.1 對功能的規(guī)定 3.2 對性能的規(guī)定 3.2.1 精度 3.

14、2.2 時(shí)間特性要求 3.2.3 靈活性 3.3 輸人輸出要求 3.4 數(shù)據(jù)管理能力要求 3.5 故障處理要求 3.6 其他專門要求4 運(yùn)行環(huán)境規(guī)定 4.1 設(shè)備 4.2 支持軟件 4.3 接口 4.4 控制3.4 實(shí)體-聯(lián)系圖(ER)ER圖（Entity Relationship Diagram）ER圖是用來建立概念型數(shù)據(jù)模型的工具。數(shù)據(jù)模型是一種面向問題的數(shù)據(jù)模型，是按照用戶的觀點(diǎn)對數(shù)據(jù)建立的模型。它描述了從用戶角度看到的數(shù)據(jù)，反映了用戶的現(xiàn)實(shí)環(huán)境，它與在軟件系統(tǒng)中的實(shí)現(xiàn)方法無關(guān)。數(shù)據(jù)模型中包含3種相互關(guān)聯(lián)的信息數(shù)據(jù)對象（實(shí)體）數(shù)據(jù)對象的屬性（實(shí)體的屬性）數(shù)據(jù)對象彼此間相互連接的關(guān)系（實(shí)體

15、之間的聯(lián)系）。3.4.1 數(shù)據(jù)對象數(shù)據(jù)對象定義是對軟件必須理解的復(fù)合信息的抽象。復(fù)合信息是指具有一系列不同性質(zhì)或?qū)傩缘氖挛?，僅有單個(gè)值的事物(例如，寬度)不是數(shù)據(jù)對象（而是屬性）。數(shù)據(jù)對象種類及其屬性可以是外部實(shí)體、事物、行為、事件、角色、單位、地點(diǎn)或結(jié)構(gòu)等。可以由一組屬性來定義的實(shí)體都可以被認(rèn)為是數(shù)據(jù)對象。數(shù)據(jù)對象彼此間是有關(guān)聯(lián)的。數(shù)據(jù)對象只是封裝了“數(shù)據(jù)”，而沒有描述施加于數(shù)據(jù)之上的操作。3.4.2 屬 性屬性屬性定義了數(shù)據(jù)對象的性質(zhì)。必須把一個(gè)或多個(gè)屬性定義為“標(biāo)識(shí)符”，當(dāng)我們希望找到數(shù)據(jù)對象的一個(gè)實(shí)例時(shí)，用標(biāo)識(shí)符屬性作為“關(guān)鍵字”(通常簡稱為“鍵”)。數(shù)據(jù)對象的屬性選取應(yīng)該根據(jù)對所要解

16、決的問題的理解，來確定特定數(shù)據(jù)對象的一組合適的屬性。 例如 “學(xué)生”：具有學(xué)號、姓名、性別、年齡、專業(yè)等屬性；“課程”：具有課程號、課程名、學(xué)分、學(xué)時(shí)數(shù)等屬性；“教師”：具有職工號、姓名、年齡、職稱等屬性。3.4.3 聯(lián) 系聯(lián)系數(shù)據(jù)對象彼此之間相互連接的方式稱為聯(lián)系，也稱為關(guān)系。聯(lián)系可分為以下3種類型：一對一聯(lián)系(11)如：一個(gè)部門有一個(gè)經(jīng)理，而每個(gè)經(jīng)理只在一個(gè)部門任職，則部門與經(jīng)理的聯(lián)系是一對一的。一對多聯(lián)系(1N)如：某校教師與課程之間存在一對多的聯(lián)系“教”，即每位教師可以教多門課程，但是每門課程只能由一位教師來教。多對多聯(lián)系(MN)如：學(xué)生與課程間的聯(lián)系(“學(xué)”)是多對多的，即一個(gè)學(xué)生可

17、以學(xué)多門課程，而每門課程可以有多個(gè)學(xué)生來學(xué)。聯(lián)系也可能有屬性如：學(xué)生“學(xué)”某門課程所取得的成績，既不是學(xué)生的屬性也不是課程的屬性。由于“成績”既依賴于某名特定的學(xué)生又依賴于某門特定的課程，所以它是學(xué)生與課程之間的聯(lián)系“學(xué)”的屬性。3.4.4 實(shí)體-聯(lián)系圖的符號ER圖的基本成分ER圖中包含了實(shí)體(即數(shù)據(jù)對象)、關(guān)系和屬性等3種基本成分。矩形框通常用矩形框代表實(shí)體；菱形框用連接相關(guān)實(shí)體的菱形框表示關(guān)系；橢圓形或圓角矩形用橢圓形或圓角矩形表示實(shí)體(或關(guān)系)的屬性；直線用直線把實(shí)體(或關(guān)系)與其屬性連接起來。實(shí)體關(guān)系屬性例：某校教學(xué)管理ER圖對象教師屬性學(xué)生屬性課程屬性聯(lián)系屬性關(guān)系3.5 數(shù)據(jù)規(guī)范化軟

18、件系統(tǒng)中經(jīng)常要維護(hù)和使用長期保存的數(shù)據(jù)，這些數(shù)據(jù)按某種方式組織并存儲(chǔ)在數(shù)據(jù)庫或文件中。為了減少數(shù)據(jù)冗余，避免插入異常或刪除異常，通常需要把數(shù)據(jù)結(jié)構(gòu)規(guī)范化。規(guī)范數(shù)據(jù)組織結(jié)構(gòu)和消除數(shù)據(jù)冗余是數(shù)據(jù)規(guī)范化的要點(diǎn)。在數(shù)據(jù)庫中，通常用“范式”來定義消除數(shù)據(jù)冗余的程度。規(guī)范化的目的消除數(shù)據(jù)冗余消除數(shù)據(jù)庫中/表格中數(shù)據(jù)的重復(fù)；消除多義性使關(guān)系中的屬性含義清楚、單一；使關(guān)系的“概念”單一化讓每個(gè)數(shù)據(jù)項(xiàng)只是一個(gè)簡單的數(shù)或字符串，而不是一個(gè)組項(xiàng)或重復(fù)組；方便操作使數(shù)據(jù)的插入、刪除與修改操作可行并方便；使關(guān)系模式更靈活易于實(shí)現(xiàn)接近自然語言的查詢方式。規(guī)范化規(guī)范化 - 將數(shù)據(jù)的邏輯結(jié)構(gòu)歸結(jié)為滿足一定條件的二維表（數(shù)據(jù)庫

19、中的關(guān)系），即：1. 表格中每個(gè)信息項(xiàng)必須是一個(gè)不可分割的數(shù)據(jù)項(xiàng)，不可是組項(xiàng)。2. 表格中每一列 (列表示屬性)中所有信息項(xiàng)必須是同一類型，各列的名字 (屬性名) 互異，列的次序任意。3. 表格中各行 (行表示元組) 互不相同，行的次序任意。教工號姓名性別職稱職務(wù)001張毅坤男教授院長002李 林女講師有三個(gè)實(shí)體型，即課程、學(xué)生和教師，用三個(gè)數(shù)據(jù)庫關(guān)系保存它們的信息：學(xué)生(學(xué)號，姓名，性別，年齡，年級，專業(yè)，籍貫)教師(職工號，姓名，年齡，職稱，職務(wù)，工資級別，工資)課程(課程號，課程名，學(xué)分，學(xué)時(shí)，課程類型)為表示實(shí)體型之間的聯(lián)系，又建立兩個(gè)數(shù)據(jù)庫關(guān)系：選課 (學(xué)號，課程號，聽課出勤率，作業(yè)

20、完成率，分?jǐn)?shù))教課 (職工號，課程號，授課效果)這五個(gè)數(shù)據(jù)庫關(guān)系，組成了數(shù)據(jù)庫的模型。在每個(gè)關(guān)系中，屬性名下加（下劃線）指明關(guān)鍵字。并規(guī)定關(guān)鍵字能唯一地標(biāo)識(shí)一個(gè)元組（記錄）。規(guī)范化例：教學(xué)管理范式(Normal Forms)范式(Normal Forms)”通常用“范式”定義消除數(shù)據(jù)冗余的程度。按照屬性間的依賴程度，范式分為第一范式至第五范式。第一范式(1 NF)數(shù)據(jù)冗余程度最大，第五范式(5 NF)數(shù)據(jù)冗余程度最小。范式級別確定范式級別越高，存儲(chǔ)同樣數(shù)據(jù)就需要分解成更多張表，因此 “存儲(chǔ)自身”的過程也就越復(fù)雜。隨著范式級別的提高，數(shù)據(jù)的存儲(chǔ)結(jié)構(gòu)與基于問題域的結(jié)構(gòu)間的匹配程度也隨之下降，因此，

21、在需求變化時(shí)數(shù)據(jù)的穩(wěn)定性較差。范式級別提高需要訪問的表增多，因此性能(速度)將下降。從實(shí)用角度看來，在大多數(shù)場合選用第三范式都比較恰當(dāng)。第一范式（1NF）每個(gè)屬性值都必須是原子值，即僅僅是一個(gè)簡單值而不含內(nèi)部結(jié)構(gòu)。如：學(xué)生(學(xué)號，姓名，性別，年齡，年級，專業(yè)，籍貫)教師(職工號，姓名，年齡，職稱，職務(wù)，工資級別，工資)課程(課程號，課程名，學(xué)分，學(xué)時(shí)，課程類型)問題：嚴(yán)格來說，“姓名” （如張偉、令狐沖）符合1NF嗎？“班級”（如“信息工程2009(1)班）符合1NF嗎？第二范式（2NF）滿足第一范式條件，而且每個(gè)非關(guān)鍵字屬性都由整個(gè)關(guān)鍵字決定(而不是由關(guān)鍵字的一部分來決定)。如：選課 ( 學(xué)

22、號，課程號，聽課出勤率，作業(yè)完成率，分?jǐn)?shù) )教課 ( 職工號，課程號，授課效果 )問題學(xué)生情況（姓名、性別、出生日期、專業(yè)、年級、班號）符合2NF嗎？一個(gè)表（關(guān)系）中必須有主關(guān)鍵字！第三范式（3NF）第三范式（3NF）首先應(yīng)符合第二范式的條件，且要求一個(gè)數(shù)據(jù)庫表中不包含已在其它表中已包含的非主關(guān)鍵字信息。例如存在一個(gè)部門信息表，其中每個(gè)部門有部門編號（dept_id）、部門名稱、部門簡介等信息。那么員工信息表中列出部門編號后就不能再將部門名稱、部門簡介等與部門有關(guān)的信息再加入員工信息表中。如果不存在部門信息表，則根據(jù)第三范式（3NF）也應(yīng)該構(gòu)建它，否則就會(huì)有大量的數(shù)據(jù)冗余。簡而言之，第三范式就

23、是屬性不依賴于其它非主屬性。部門信息(部門編號、部門名稱、部門簡介)員工信息(員工編號、姓名、性別、身份證號、部門名稱)3.6 狀態(tài)轉(zhuǎn)換圖狀態(tài)轉(zhuǎn)換圖(簡稱為狀態(tài)圖)通過描繪系統(tǒng)的狀態(tài)及引起系統(tǒng)狀態(tài)轉(zhuǎn)換的事件，來表示系統(tǒng)的行為。此外，狀態(tài)圖還指明了作為特定事件的結(jié)果系統(tǒng)將做哪些動(dòng)作(例如，處理數(shù)據(jù))。3.6.1 狀態(tài)狀態(tài)是任何可以被觀察到的系統(tǒng)行為模式，一個(gè)狀態(tài)代表系統(tǒng)的一種行為模式。狀態(tài)規(guī)定了系統(tǒng)對事件的響應(yīng)方式。系統(tǒng)對事件的響應(yīng)，既可以是做一個(gè)(或一系列)動(dòng)作，也可以是僅僅改變系統(tǒng)本身的狀態(tài)，還可以是既改變狀態(tài)又做動(dòng)作。 初態(tài) (即初始狀態(tài)) 狀態(tài) 終態(tài) (即最終狀態(tài)) 中間狀態(tài)一張狀態(tài)圖中

24、只能有一個(gè)初態(tài)，而終態(tài)則可以有0至多個(gè)。3.6.2 事件 事件是在某個(gè)特定時(shí)刻發(fā)生的事情，它是對引起系統(tǒng)做動(dòng)作或(和)從一個(gè)狀態(tài)轉(zhuǎn)換到另一個(gè)狀態(tài)的外界事件的抽象。簡而言之，事件就是引起系統(tǒng)做動(dòng)作或(和)轉(zhuǎn)換狀態(tài)的控制信息?！笆录崩觾?nèi)部時(shí)鐘表明某個(gè)規(guī)定的時(shí)間段已經(jīng)過去，引發(fā)某種操作。用戶移動(dòng)或點(diǎn)擊鼠標(biāo)，啟動(dòng)某個(gè)功能。3.6.3 符 號初態(tài)用實(shí)心圓表示終態(tài)用一對同心圓(內(nèi)圓為實(shí)心圓)表示。中間狀態(tài)用圓角矩形表示，可以用兩條水平橫線把它分成上、中、下3個(gè)部分。上面部分為狀態(tài)的名稱，這部分是必須有的；中間部分為狀態(tài)變量的名字和值，這部分是可選的；下面部分是活動(dòng)表，這部分也是可選的。狀態(tài)轉(zhuǎn)換狀態(tài)圖中

25、兩個(gè)狀態(tài)之間帶箭頭連線稱為狀態(tài)轉(zhuǎn)換，箭頭指明轉(zhuǎn)換方向。3.6.3 符 號（續(xù)）活動(dòng)表活動(dòng)表的語法格式：事件名(參數(shù)表)/動(dòng)作表達(dá)式“事件名”可以是任何事件的名稱。在活動(dòng)表中經(jīng)常使用下述3種標(biāo)準(zhǔn)事件：entry，exit和do。entry事件指定進(jìn)入該狀態(tài)的動(dòng)作，exit事件指定退出該狀態(tài)的動(dòng)作，而do事件則指定在該狀態(tài)下的動(dòng)作。需要時(shí)可以為事件指定參數(shù)表?；顒?dòng)表中的動(dòng)作表達(dá)式描述應(yīng)做的具體動(dòng)作。3.6.3 符 號（續(xù)）事件狀態(tài)變遷通常是由事件觸發(fā)的，在這種情況下應(yīng)在表示狀態(tài)轉(zhuǎn)換的箭頭線上標(biāo)出觸發(fā)轉(zhuǎn)換的事件表達(dá)式；如果在箭頭線上未標(biāo)明事件，則表示在源狀態(tài)的內(nèi)部活動(dòng)執(zhí)行完之后自動(dòng)觸發(fā)轉(zhuǎn)換。事件表達(dá)

26、式的語法：事件說明守衛(wèi)條件動(dòng)作表達(dá)式事件說明的語法為：事件名(參數(shù)表)。守衛(wèi)條件是一個(gè)可選的布爾表達(dá)式。如果同時(shí)使用事件說明和守衛(wèi)條件，則當(dāng)且僅當(dāng)事件發(fā)生且布爾表達(dá)式為真時(shí)，狀態(tài)轉(zhuǎn)換才發(fā)生。如果只有守衛(wèi)條件沒有事件說明，則只要守衛(wèi)條件為真狀態(tài)轉(zhuǎn)換就發(fā)生。動(dòng)作表達(dá)式是一個(gè)過程表達(dá)式，當(dāng)狀態(tài)轉(zhuǎn)換開始時(shí)執(zhí)行該表達(dá)式。3.6.4 例子：電話系統(tǒng)的狀態(tài)圖3.7 其他圖形工具 層次方框圖 Warnier圖 IPO圖3.7.1 層次方框圖層次方框圖用樹形結(jié)構(gòu)的一系列多層次的矩形框描繪數(shù)據(jù)的層次結(jié)構(gòu)。樹形結(jié)構(gòu)的頂層是一個(gè)單獨(dú)的矩形框，它代表完整的數(shù)據(jù)結(jié)構(gòu)，下面的各層矩形框代表這個(gè)數(shù)據(jù)的子集，最底層的各個(gè)框代表

27、組成這個(gè)數(shù)據(jù)的實(shí)際數(shù)據(jù)元素(不能再分割的元素)。隨著結(jié)構(gòu)的精細(xì)化，層次方框圖對數(shù)據(jù)結(jié)構(gòu)也描繪得越來越詳細(xì)，這種模式非常適合于需求分析階段的需要。系統(tǒng)分析員從對頂層信息的分類開始，沿圖中每條路徑反復(fù)細(xì)化，直到確定了數(shù)據(jù)結(jié)構(gòu)的全部細(xì)節(jié)時(shí)為止。層次方框圖 例-1：公司產(chǎn)品數(shù)據(jù)結(jié)構(gòu)領(lǐng)導(dǎo)層輔助決策系統(tǒng)查詢輔助決策物資信息重點(diǎn)供料信息商情信息人員狀況合同監(jiān)視財(cái)務(wù)信息計(jì)劃執(zhí)行情況工程進(jìn)展情況超儲(chǔ)低儲(chǔ)情況經(jīng)營指標(biāo)歷年對比價(jià)格預(yù)測物資用量預(yù)測庫存定額核定庫存結(jié)構(gòu)分析經(jīng)濟(jì)采購批量保本保利分析層次方框圖 例-2：輔助決策系統(tǒng)功能結(jié)構(gòu)3.7.2 Warnier圖法國計(jì)算機(jī)科學(xué)家Warnier提出了表示信息層次結(jié)構(gòu)的另

28、外一種圖形工具。Warnier圖也用樹形結(jié)構(gòu)描繪信息，但是這種圖形工具比層次方框圖提供了更豐富的描繪手段。用Warnier圖可以表明信息的邏輯組織。它可以指出一類信息或一個(gè)信息元素是重復(fù)出現(xiàn)的，也可以表示特定信息在某一類信息中是有條件地出現(xiàn)的。重復(fù)和條件約束是說明軟件處理過程的基礎(chǔ)，所以很容易把Warnier圖轉(zhuǎn)變成軟件設(shè)計(jì)的工具。Warnier圖 舉例：軟件產(chǎn)品類別圖中表示一種軟件產(chǎn)品要么是系統(tǒng)軟件要么是應(yīng)用軟件。系統(tǒng)軟件中有P1種操作系統(tǒng)，P2種編譯程序，此外還有軟件工具。軟件工具是系統(tǒng)軟件的一種，它又可以進(jìn)一步細(xì)分為編輯程序、測試驅(qū)動(dòng)程序和設(shè)計(jì)輔助工具，圖中標(biāo)出了每種軟件工具的數(shù)量。3.

29、7.3 IPO圖左邊的框中列出有關(guān)的輸入數(shù)據(jù)。中間的框內(nèi)列出主要的處理，處理框中列出處理的次序暗示了執(zhí)行的順序，但是用這些基本符號還不足以精確描述執(zhí)行處理的詳細(xì)情況。在右邊的框內(nèi)列出產(chǎn)生的輸出數(shù)據(jù)。在IPO圖中還用類似向量符號的粗大箭頭清楚地指出數(shù)據(jù)通信的情況。一種改進(jìn)的IPO圖(IPO表)在需求分析階段可以使用IPO表簡略地描述系統(tǒng)的主要算法(即數(shù)據(jù)流圖中各個(gè)處理的基本算法)。需求分析階段，IPO表中的許多附加信息暫時(shí)還不具備，但在設(shè)計(jì)階段可以進(jìn)一步補(bǔ)充修正這些圖，作為設(shè)計(jì)階段的文檔。這正是在需求分析階段用IPO表作為描述算法的工具的重要優(yōu)點(diǎn)。3.8 驗(yàn)證軟件需求3.8.1 從哪些方面驗(yàn)證軟

30、件需求的正確性3.8.2 驗(yàn)證軟件需求的方法1. 驗(yàn)證需求的一致性2. 驗(yàn)證需求的現(xiàn)實(shí)性3. 驗(yàn)證需求的完整性4. 驗(yàn)證需求的有效性3.8.3 用于需求分析的軟件工具3.8.1 從哪些方面驗(yàn)證軟件需求的正確性(1) 一致性所有需求必須是一致的，任何一條需求不能和其他需求互相矛盾。(2) 完整性需求必須是完整的，規(guī)格說明書應(yīng)該包括用戶需要的每一個(gè)功能或性能。(3) 現(xiàn)實(shí)性指定的需求應(yīng)該是用現(xiàn)有的硬件技術(shù)和軟件技術(shù)基本上可以實(shí)現(xiàn)的。(4) 有效性必須證明需求是正確有效的，確實(shí)能解決用戶面對的問題。3.8.2 驗(yàn)證軟件需求的方法(1) 一致性所有需求必須是一致的，任何一條需求不能和其他需求互相矛盾。

31、(2) 現(xiàn)實(shí)性指定的需求應(yīng)該是用現(xiàn)有的硬件技術(shù)和軟件技術(shù)基本上可以實(shí)現(xiàn)的。(3) 完整性需求必須是完整的，規(guī)格說明書應(yīng)該包括用戶需要的每一個(gè)功能或性能。(4) 有效性必須證明需求是正確有效的，確實(shí)能解決用戶面對的問題。3.8.3 用于需求分析的軟件工具需求分析軟件工具為了更有效地保證軟件需求的正確性，特別是為了保證需求的一致性，需要有適當(dāng)?shù)能浖ぞ咧С中枨蠓治龉ぷ?。需求分析軟件工具例RSL(需求陳述語言)PSL/PSA(問題陳述語言/問題陳述分析器)需求分析軟件工具要求(1) 必須有形式化的語法(或表)，因此可以用計(jì)算機(jī)自動(dòng)處理使用這種語法說明的內(nèi)容；(2) 使用這個(gè)軟件工具能夠?qū)С鲈敿?xì)的文檔；(3) 必須提供分析(測試)規(guī)格說明書的不一致性和冗余性的手段，并且應(yīng)該能夠產(chǎn)生一組報(bào)告指明對完整性分析的結(jié)果；(4) 使用這個(gè)軟件工具之后，應(yīng)該能夠改進(jìn)交流狀況。RSL(需求陳述語言)用RSL語言描述需求，RSL可有相應(yīng)的計(jì)算機(jī)軟件處理；