軟件工程2章需求法分析33l.ppt

第三章 需求分析,軟件需求分析 需求分析是軟件定義時期的最后一個階段，它的基本任務(wù)不是確定系統(tǒng)怎樣完成它的工作，而是確定系統(tǒng)必須完成哪些工作，也就是對目標(biāo)系統(tǒng)提出完整、準(zhǔn)確、清晰、具體的要求。 并在在需求分析階段結(jié)束之前，由系統(tǒng)分析員寫出軟件需求規(guī)格說明書，以書面形式準(zhǔn)確地描述軟件需求。即： - 準(zhǔn)確地回答“系統(tǒng)必須做什么?”。 意義： 軟件需求的深入理解是軟件開發(fā)工作獲得成功的前提條件，不論我們把設(shè)計和編碼做得如何出色，不能真正滿足用戶需求的程序只會令用戶失望，給開發(fā)帶來煩惱。,軟件需求工程的活動（內(nèi)容）,軟件需求工程,需求開發(fā),需求管理,需求建模,需求獲取,需求規(guī)格說明,需求驗證,建立基線,變更控制,需求跟蹤,綜合了幾種觀點，可以把需求工程的活動劃分為以下5個獨立的階段： （1）需求獲?。荷钊雽嶋H，確定待開發(fā)的軟件系統(tǒng)的用戶類，通過與用戶的交流，對現(xiàn)有系統(tǒng)的觀察及對任務(wù)進(jìn)行分析，從而開發(fā)、捕獲和修訂用戶的需求； （2）需求分析及建模：主要對收集到的需求進(jìn)行提煉、分析和認(rèn)真審查，確保所有參加人員取得一致共識。找出錯誤、遺漏和不足，為最終用戶所看到的系統(tǒng)建立模型，根據(jù)軟件需求信息建立軟件系統(tǒng)的邏輯模型或需求模型。需求模型作為對需求的抽象描述，盡可能多的捕獲現(xiàn)實世界的語義，并確定非功能性需求和約束條件和限制。 （3）形成需求規(guī)格：根據(jù)收集的需求信息和邏輯模型生成需求模型構(gòu)件的精確的形式化的描述，作為用戶和開發(fā)者之間的一個協(xié)約編寫需求規(guī)格說明及其文檔。 （4）需求驗證：以需求規(guī)格說明為輸入，通過符號執(zhí)行、模擬或快速原型等途徑，分析需求規(guī)格的正確性和可行性； （5）需求管理：支持系統(tǒng)的需求演進(jìn)，如需求變化和可跟蹤性問題。當(dāng)需求發(fā)生變更時，對需求規(guī)格說明及需求變更實施進(jìn)行管理。需求工程也是一個項目工程，因此也包括了項目的管理。,軟件需求工程的活動（內(nèi)容）,3.1需求獲取,需求獲取是需求工程的主體內(nèi)容之一。獲取需求是一個確定和理解不同涉眾的需要和約束的過程。 涉眾團(tuán)體( 所有能夠影響軟件系統(tǒng)的實現(xiàn),或者被實現(xiàn)后的軟件系統(tǒng)所影響的個人和團(tuán)體 )之間的相互溝通，識別需要的過程。涉眾團(tuán)體通過這個過程提取、定義需求。需求獲取既涉及技術(shù)問題，也涉及社會交往問題。 難點：缺乏領(lǐng)域知識,應(yīng)用領(lǐng)域的問題常常是模糊的、不精確的； 存在默認(rèn)的知識,如難以描述的常識問題； 存在多個知識源,且多知識源之間可能有沖突； 客戶可能的偏見，如不能提供或不想告知你所需要了解的事情。,在分析軟件需求和書寫軟件需求規(guī)格說明書的過程中，分析員和用戶都起著關(guān)鍵的、必不可少的作用。 只有用戶才真正知道自己需要什么，但是他們并不知道怎樣用軟件實現(xiàn)自己的需求，用戶必須把他們對軟件的需求盡量準(zhǔn)確、具體地描述出來；分析員知道怎樣用軟件實現(xiàn)人們的需求，但是在需求分析開始時他們對用戶的需求并不十分清楚，必須與用戶溝通獲取用戶對軟件的需求,3.1需求獲取,業(yè)務(wù)需求,項目范圍文檔,用戶需求,文檔,功能需求,質(zhì)量屬性,其他非功能需求,設(shè)計約束,需求規(guī)約(specification),非功能需求,系統(tǒng)需求,需求組成的全景圖,軟件需求的層次, 業(yè)務(wù)需求：反映組織機(jī)構(gòu)和客戶對系統(tǒng)、產(chǎn)品高層次的目標(biāo)要求。 用戶需求：從用戶使用的角度給出需求的描述。 如一個小型超市需要一個商品的查詢系統(tǒng)。 業(yè)務(wù)需求：進(jìn)貨人員需要查詢商品庫存以便保證及時進(jìn)貨；收款員需要查詢商品的銷售價格以便結(jié)賬；經(jīng)理需要查詢商品的銷售及盈利情況。 用戶需求:這三類用戶怎樣去查詢系統(tǒng)，查詢哪些信息，還需要哪些操作。,軟件需求的層次, 系統(tǒng)需求：從系統(tǒng)的角度描述要提供的服務(wù)以及所受到的約束。 功能性需求：描述系統(tǒng)應(yīng)該做什么，即為用戶和其它系統(tǒng)完成的功能、提供的服務(wù)。 非功能性需求：產(chǎn)品必須具備的屬性或品質(zhì)。 設(shè)計約束：設(shè)計與實現(xiàn)必須遵循的標(biāo)準(zhǔn)、約束條件。如運行平臺、協(xié)議、選擇的技術(shù)、編程語言和工具等。,軟件需求的組成,需求獲取的過程：,確定需求開發(fā)計劃,建立項目前景與范圍,確定調(diào)查對象,實地收集用戶需求信息,確定非功能需求和約束條件,1.確定需求開發(fā)計劃,確定需求開發(fā)計劃的基本任務(wù)是確定需求開發(fā)的實施步驟，給出收集需求活動的人員、具體安排和進(jìn)度。需要重點注意的是： 針對不同層次的調(diào)查對象，安排的調(diào)查人員在閱歷和經(jīng)驗上的對等原則。 調(diào)查人員的溝通和業(yè)務(wù)理解能力必須適當(dāng)。 用戶的時間延誤、文檔確認(rèn)的時間要在計劃進(jìn)度中預(yù)留。,2.確定產(chǎn)品前景與項目范圍,本階段的任務(wù)是幫助投資管理人、產(chǎn)品經(jīng)理弄清楚“為什么要作這個項目？”，組織的業(yè)務(wù)目標(biāo)以及系統(tǒng)最終版本具備哪些功能的長遠(yuǎn)規(guī)劃。 產(chǎn)品前景（product vision）描述了產(chǎn)品用來干什么，它最終會是什么樣子。 項目范圍（project scope）確定當(dāng)前的項目要解決產(chǎn)品長遠(yuǎn)規(guī)劃中的哪一部分。項目范圍的細(xì)節(jié)體現(xiàn)于項目定義的需求基線。 產(chǎn)生文檔：前景與范圍文檔。,前景與范圍的關(guān)系,前景關(guān)系到整個產(chǎn)品。當(dāng)產(chǎn)品的戰(zhàn)略定位或業(yè)務(wù)目標(biāo)隨時間發(fā)生改變時，前景也會變化。范圍則只與一個特定項目，或?qū)崿F(xiàn)產(chǎn)品功能下一增量的某次迭代相關(guān)。 產(chǎn)品前景包括了每一個計劃產(chǎn)品版本的范圍,前景和范圍文檔的模板,1.業(yè)務(wù)需求 1.1 背景 1.2 業(yè)務(wù)機(jī)遇 1.3 業(yè)務(wù)目標(biāo)與成功標(biāo)準(zhǔn) 1.4 客戶和市場需要 1.5 業(yè)務(wù)風(fēng)險 2.解決方案的前景 2.1 前景陳述 2.2 主要的系統(tǒng)特征 2.3 假設(shè)和依賴條件,3.項目范圍與限制 3.1 第一個版本的范圍 3.2 各后續(xù)版本的范圍 3.3 限制和排除條件 4.業(yè)務(wù)背景 4.1 涉眾檔案 4.2 項目優(yōu)先級 4.3 運行環(huán)境,3.確定調(diào)查對象,本階段的基本任務(wù)是明確地確定來自不同層次的需求來源和用戶，并將其分類。(前景與范圍文檔可以幫助區(qū)分用戶分類) 由于軟件需求分為三個層次，業(yè)務(wù)需求、用戶需求、功能需求，故應(yīng)根據(jù)需求的層次來區(qū)分不同的用戶。 用戶分類：可分為三種不同類別 用戶方的領(lǐng)導(dǎo)者、項目規(guī)劃者、項目出資人 (目標(biāo)) 軟件的直接使用、操作人員 （功能,易用性） 未來軟件系統(tǒng)的技術(shù)管理、運行維護(hù)人員（性能,安裝,維護(hù)）,4. 實地收集用戶需求信息,實地收集需求信息面臨的困難 1）能提出軟件需求的用戶沒有時間 2）有時用戶希望通過簡單的說明和問答 3）用戶和開發(fā)人員只考慮自己的利益 4）用戶本身不能提出明確的需求 5）開發(fā)人員缺乏用戶的業(yè)務(wù)知識，而用戶缺乏計算機(jī)方面的知識，引起交流困難。,實地調(diào)查的步驟,1）向掌握“全局”的負(fù)責(zé)人調(diào)查：概貌,規(guī)劃,目標(biāo),范圍 2）向部門負(fù)責(zé)人調(diào)查：業(yè)務(wù)和業(yè)務(wù)流程,部門間相互關(guān)系。功能需求和非功能需求,與其他部門間的接口。 3）向業(yè)務(wù)人員調(diào)查：自身工作處理細(xì)節(jié)、具體數(shù)據(jù)或表格的作用來源和去向、類型、精度、處理要求和輸入/輸出格式。具體的功能和性能需求。,2019/7/16,17,實地收集需求信息的方式,需求獲取可能是軟件開發(fā)中最需要交流的一項工作。獲取涉眾的需求是需求工作的重要環(huán)節(jié)。 需求獲取只有通過客戶與開發(fā)者的有效合作才能成功。分析者必須為客戶建立一個對問題進(jìn)行徹底探討的環(huán)境，而這些問題與將要開發(fā)的產(chǎn)品有關(guān)。另外要讓用戶明確了解，對于某些功能的討論并不意味著即將在產(chǎn)品中實現(xiàn)它。對于想到的需求必須集中處理并設(shè)定優(yōu)先級，消除不必要的需求，以避免項目范圍無意義地膨脹。目前主要有以下的需求獲取方法。,面談法 重要而直接，簡單的需求獲取技術(shù)。 面談的對象主要有用戶和領(lǐng)域?qū)＜遥?1）面談前的準(zhǔn)備要充分； 2）面談后注意認(rèn)真分析總結(jié)； 3）注意掌握面談的人際交流技能。 提問題：a. 你所在部門的業(yè)務(wù)流程是怎樣的？ b. 你所在部門與其它部門的關(guān)系是怎樣的？ c. 本部門產(chǎn)生哪些表格及其輸入/輸出形式？ d. 在業(yè)務(wù)中使用什么計算方法？ 關(guān)于如何解決問題的提問： a. 當(dāng)某問題發(fā)生時，應(yīng)該如何解決？ b. 你現(xiàn)在工作中存在什么問題？如何解決？ c. 除了正常情況，還會發(fā)生什么異常情況？該如何應(yīng)對？,實地收集需求信息的方式,交談形式舉例,正向模擬：選擇典型業(yè)務(wù)情景（初始情況），請用戶說明工作過程；陳述過程中不斷提煉并提問新情況 案例分析：請用戶選擇有代表性的業(yè)務(wù)情景（初始情況），并說明工作過程；陳述過程中不斷提煉并提問新情況 局外評論：存在現(xiàn)有系統(tǒng)，請用戶對正在進(jìn)行的過程進(jìn)行評論 知識反教：在獲取一些信息后，按照自己的理解表述給用戶，請用戶判斷正確與否,問卷法調(diào)查法 是對面談法的補(bǔ)充。 是從多個用戶中收集需求信息的有效方式 ，一般問卷設(shè) 計形式： 1）多項選擇問題 ； 2）評分問題 ； 3）排序問題 。,實地收集需求信息的方式,需求專題討論會 最有力的需求獲取技術(shù)。有利于培養(yǎng)高效團(tuán)隊。 由開發(fā)方和用戶方共同召開,操作步驟： 開發(fā)方根據(jù)雙方制定的需求調(diào)研計劃召開相關(guān)需求主題溝通會； 會后開發(fā)方整理出需求調(diào)研記錄提交給用戶方確認(rèn)； 如果此主題還有未明確的問題則再次溝通,否則開始下一主題； 所有需求都溝通清楚后，開發(fā)方根據(jù)歷次需求調(diào)研記錄整理出用戶需求說明書，提交給用戶方確認(rèn)簽字。 會前發(fā)議題，控制參會人員規(guī)模、時間、討論范圍，會中 有記錄，會后整理。掌握方向不跑題。,實地收集需求信息的方式,需求信息的分類,如圖列出9種需求類別：,業(yè)務(wù)規(guī)則（領(lǐng)域需求）,當(dāng)客戶說只有特定的人在特定的條件下才能執(zhí)行某一動作時，他也許是在描述一條業(yè)務(wù)規(guī)則。業(yè)務(wù)規(guī)則舉例： 產(chǎn)品必須符合某項國際（或國家）標(biāo)準(zhǔn)。 必須根據(jù)（某個公式）計算。 如果（滿足某一條件），則（進(jìn)行某事）。 功能性需求 功能性需求描述了系統(tǒng)在特定條件下表現(xiàn)的可觀察的行為，以及系統(tǒng)允許用戶執(zhí)行的操作。如：所有的用戶界面操作都屬于功能性需求。 功能性需求占據(jù)了軟件需求規(guī)格說明的大部分篇幅。,質(zhì)量屬性,產(chǎn)品的易用性、可靠性、運行速度、出錯頻率、異常處理能力等等特性合稱為質(zhì)量屬性，它是系統(tǒng)非功能性需求的一部分。非功能需求是衡量軟件能否良好運行的定性指標(biāo)。舉例： 可靠性：規(guī)定條件下系統(tǒng)完成所要求功能的概率。定量指標(biāo)如平均無故障時間和平均修復(fù)時間。 可擴(kuò)充性：系統(tǒng)能方便和容易地增加新功能，可用增加新功能所需工作量大小來衡量。 安全性：如防止非法訪問,防止數(shù)據(jù)丟失，防止病毒入侵等。例如：身份驗證、用戶權(quán)限、訪問控制等。,互操作性：指系統(tǒng)與其他系統(tǒng)交換數(shù)據(jù)和服務(wù)的難易程度。 健壯性：指系統(tǒng)或組成部分遇到非法輸入數(shù)據(jù)以及在異常情況和非法操作下能繼續(xù)運行的程度。 易用性：指用戶學(xué)習(xí)和使用軟件系統(tǒng)功能的簡易程度,也包括對系統(tǒng)輸出結(jié)果的易于理解的程度。 可維護(hù)性：指系統(tǒng)中發(fā)現(xiàn)并糾正一個故障或進(jìn)行一次更改的簡易程度。 可移植性：指把一個軟件系統(tǒng)從一種運行環(huán)境移植到另一個運行環(huán)境所花費的工作量的度量。 可重用性：指組成軟件系統(tǒng)中的某個部件還可以在其他應(yīng)用系統(tǒng)中使用的程度。,質(zhì)量屬性,外部接口需求 描述了系統(tǒng)與外部世界的聯(lián)系。軟件需求規(guī)格說明中專門有一章描述系統(tǒng)與用戶、硬件、其它軟件系統(tǒng)之間接口的說明。,約束,對設(shè)計和實現(xiàn)的約束合理地限制了開發(fā)人員可用的選擇。如： 通過電子郵件傳送的文件大小不能超過10MB。 進(jìn)行安全交易時，必須使用128位的加密算法。 產(chǎn)品數(shù)據(jù)庫必須支持Oracle 11g,期末大作業(yè)之一：假設(shè)讓你開發(fā)一個在線交易平臺網(wǎng)站，分別從功能需求，質(zhì)量特性，約束3種需求類別進(jìn)行描述。,3.2 需求分析,需求分析和需求獲取是密切相關(guān)的兩個過程。需求分析的任務(wù)就是分析和綜合通過需求獲取階段收集到的需求信息，提煉出真正的需求，確保所有參加人員取得一致共識。找出錯誤、遺漏和不足，建立系統(tǒng)完整的邏輯模型。 需求分析是一種提煉與整合活動：需將用戶的原始需求合并到業(yè)務(wù)活動中去。 需求分析是一種規(guī)格化活動：要找到?jīng)_突、矛盾，并通過訪談手段解決問題。,劃分需求優(yōu)先級的用處： 可幫助判斷系統(tǒng)的核心需求，可用于風(fēng)險分析。 優(yōu)先級之間的關(guān)聯(lián)可以幫助決定軟件體系結(jié)構(gòu)、解決設(shè)計沖突。 幫助權(quán)衡項目范圍、進(jìn)度安排、預(yù)算、人力資源及質(zhì)量目標(biāo)要求。 使用方法：接受一個高優(yōu)先級的需求時，刪除低優(yōu)先級的需求，或?qū)⑵渫七t到下一版去實現(xiàn)。,3.2 需求分析,3.3 需求建模,目的：需求建模的工作就是導(dǎo)出目標(biāo)系統(tǒng)的邏輯模型，以明確目標(biāo)系統(tǒng)“做什么”的問題。 定義：所謂模型就是為了理解事務(wù)而對事物做出的一種抽象，是對事物的一種無歧義的書面描述。 組成：通常模型可由圖形符號或數(shù)字符號以及組織這些符號的規(guī)則組成。 注意：建立需求模型的目的是為了增強(qiáng)對用自然語言描述的需求規(guī)格說明的理解，而不是替換它。,軟件工程中常用模型分類 開發(fā)過程模型：瀑布、增量、螺旋模型等(規(guī)約性) 信息流模型：DFD、SADT等(描述性) 設(shè)計模型：類圖、功能層次圖等 交互作用模型：實例圖、交互作用圖、時序圖等 狀態(tài)遷移模型：狀態(tài)圖、Statecharts、Petri網(wǎng)等 用于構(gòu)造細(xì)節(jié)的原理模型：設(shè)計模式、實體關(guān)聯(lián)圖等,3.3 需求建模,3.4 需求文檔,規(guī)格說明(SRS) 通常用自然語言+模型，完整、準(zhǔn)確、具體地描述系統(tǒng)的數(shù)據(jù)要求、功能需求、性能需求、可靠性和可用性要求、出錯處理需求、接口需求、約束、逆向需求以及將來可能提出的要求。 軟件需求規(guī)格說明書，是需求分析階段得出的最主要的文檔。 需求規(guī)格說明書的作用在于： 提供一個用戶和開發(fā)者對開發(fā)軟件的共同的理解； 相當(dāng)于用戶和開發(fā)單位之間的一份技術(shù)合同； 是今后各階段設(shè)計的基本依據(jù)，起到控制系統(tǒng)演進(jìn)的作用； 是今后驗收測試階段對軟件進(jìn)行確認(rèn)和驗收的基準(zhǔn)。,3.4需求文檔,需求規(guī)格說明書主要內(nèi)容： 概述。從系統(tǒng)的角度描述軟件的目標(biāo)和任務(wù)。 數(shù)據(jù)描述 數(shù)據(jù)流圖 數(shù)據(jù)字典 系統(tǒng)接口說明 內(nèi)部接口說明 功能描述 功能 處理 設(shè)計的限制,3.4 需求文檔, 性能描述 性能指標(biāo) 測試種類 預(yù)期的軟件響應(yīng)性能 其它 參考文獻(xiàn)目錄 附錄,1 引言 1.1 編寫目的 1.2 背景 1.3 定義 1.4 參考資料,2 任務(wù)概述 2.1 目標(biāo) 2.2 用戶的特點 2.3 假定和約束,軟件需求說明書的編寫提示（GB856T88）,軟件需求說明書的編寫提示（GB856T88）,3 需求規(guī)定 3.1 對功能的規(guī)定 3.2 對性能的規(guī)定 3.2.1 精度 3.2.2 時間特性要求 3.2.3 靈活性 3.3 輸人輸出要求 3.4 數(shù)據(jù)管理能力要求 3.5 故障處理要求 3.6 其他專門要求,4 運行環(huán)境規(guī)定 4.1 設(shè)備 4.2 支持軟件 4.3 接口 4.4 控制,(一) 需求驗證的重要性 需求審查和管理復(fù)審是需求開發(fā)的最后一個環(huán)節(jié)，通過了這一環(huán)節(jié)，就等于暫時為需求分析階段畫上了一個“句號”。盡管后期可能還會有些對需求分析的反復(fù)，但有了這個“句號”，就可以進(jìn)入設(shè)計階段了。 經(jīng)過審批之后的文檔，在整個項目范圍內(nèi)，相當(dāng)于用戶與開發(fā)人員雙方對需求達(dá)成共識后作出承諾形成了一份合約，后期的系統(tǒng)設(shè)計和系統(tǒng)測試，都將以這份“規(guī)約”為準(zhǔn)。 任何對合約的修改，都將影響到整個項目的工期和開發(fā)成本，都需要經(jīng)過嚴(yán)格的審批和簽約。,3.5 需求的有效性驗證,(二) 需求驗證的內(nèi)容 1.有效性檢查指功能需求是否符合用戶所提出的需求 2.一致性檢查需求文檔中各個需求之間不會發(fā)生矛盾。矛盾常常潛伏在需求文檔的上下文中。 3.完備性檢查是指需求規(guī)約中沒有遺漏一些必要的需求。人們往往傾向于關(guān)注系統(tǒng)的特色功能，而忽視了其他一些不起眼的但卻是必需的功能。不完備的文檔將導(dǎo)致產(chǎn)生功能不完整的產(chǎn)品，用戶在使用該軟件時可能無法完成預(yù)期的任務(wù)。 4.可檢驗性檢查文檔中的各項需求對用戶方而言都應(yīng)當(dāng)是可驗證的。如果需求是不可驗證的，那么用戶就無法驗收軟件，可能會發(fā)生商業(yè)糾紛。 例如，摩天大樓的一項需求是“抗十二級臺風(fēng)”，這個需求看起來堂而皇之，但是如何驗證呢？當(dāng)摩天大樓完工后驗收時，用戶又不是巫師，他怎能造個十二級臺風(fēng)來試驗？如果雙方都認(rèn)可“采用計算機(jī)模擬十二級臺風(fēng)”等效于實際測試，那么這項需求就是“可驗證”的。,3.5 需求的有效性驗證,(二) 需求驗證的內(nèi)容 5.必要性檢查需求規(guī)格說明書中的各項需求對用戶而言應(yīng)當(dāng)都是必要的。 可以把必要比喻為“雪中送炭”?！氨匾蓖耙徊剑词恰爱嬌咛碜恪币词恰板\上添花”。 “畫蛇添足”顯然是壞事，會導(dǎo)致開發(fā)人員多干一些吃力不討好的工作。所以要盡量剔除需求規(guī)格說明書中“畫蛇添足”的那些需求。 “錦上添花”是好事，可能會讓用戶獲得比期望更多的喜悅，但是眼前用戶不會為此多付錢。開發(fā)者應(yīng)當(dāng)集中精力先完成必要的需求，如果條件允許則再做“錦上添花”的需求。為了避免主次顛倒，應(yīng)當(dāng)在需求規(guī)約中將那些“錦上添花”的需求設(shè)置為較底的優(yōu)先級。,3.5 需求的有效性驗證,用戶的需求分類,基本的需求：用戶明確提出的系統(tǒng)應(yīng)達(dá)到的目標(biāo)，如果產(chǎn)品實現(xiàn)了這些需求，用戶會感到滿意。例如，用戶所要求的圖形界面的類型，特定的系統(tǒng)功能，以及指定的性能。 期望的需求：這些需求隱含于產(chǎn)品或系統(tǒng)中，用戶沒有明確的陳述。但如果沒有實現(xiàn)這些需求，用戶會感到失望。例如產(chǎn)品的易于安裝，超負(fù)載時的正確性和可靠性等。 感興趣的需求：這些需求在用戶的期望之外，但如果被實現(xiàn)了，用戶會感到非常滿意。例如字處理軟件除了標(biāo)準(zhǔn)的特性之外，提供了許多頁面的排列功能。,3.6需求管理,需求管理需要“建立并維護(hù)在軟件工程中同客戶達(dá)成的契約”(CMU/SEI 1995)。這種契約都包含在編寫的需求規(guī)格說明與模型中， 需求管理貫穿需求分析全過程 通常的需求管理活動包括： 定義需求基線（迅速制定需求文檔的主體）。 所謂的基線是配置演化過程中的狀態(tài)標(biāo)識，是配置在某一時刻的快照，反映了它所描述的系統(tǒng)或者其組成部分在某一時刻的狀態(tài)；可以將配置的基線理解為配置的版本，是配置演化的里程碑，即軟件生命周期內(nèi)的階段里程碑。 所謂需求基線就是項目組成員一經(jīng)承諾將在某一特定產(chǎn)品版本中實現(xiàn)的功能性和非功能性需求的集合。需求基線的確定可以保證項目的涉眾各方可以對發(fā)布的產(chǎn)品中希望具有的功能和屬性有一個一致的理解。,3.6需求管理, 評審提出的需求變更、評估每項變更的可能影響從而決定是否實施它。以一種可控制的方式將需求變更融入到項目中。 1)隨著項目的進(jìn)展，人們（包括開發(fā)方和客戶方）對需求的了解越來越深入。原先的需求文檔可能存在這樣那樣的錯誤或不足，因此要變更需求。 2)市場發(fā)生了變化，原先的需求文檔可能跟不上當(dāng)前的市場需求，因此要變更需求。,(3)讓每項需求都能與其對應(yīng)的設(shè)計、源代碼和測試用例聯(lián)系起來以實現(xiàn)跟蹤。 需求跟蹤的目的是建立與維護(hù)“需求設(shè)計編程測試”之間的一致性，確保所有的工作成果符合用戶需求。 需求跟蹤有兩種方式: 正向跟蹤：檢查產(chǎn)品需求規(guī)格說明書中的每個需求是否都能在后繼工作成果中找到對應(yīng)點。 逆向跟蹤：檢查設(shè)計文檔、代碼、測試用例等工作成果是否都能在產(chǎn)品需求規(guī)格說明書中找到出處。,3.6 需求管理,3.6 需求管理,需求變更控制,案例 王先生剛出任項目經(jīng)理，并承接了一個中型軟件項目。上任時公司高層再三叮嚀他一定要尊重客戶，充分滿足客戶需求。項目開始比較順利，但進(jìn)入到后期，客戶頻繁的需求變更帶來很多額外工作。王先生動員大家加班，保持了項目的正常進(jìn)度，客戶相當(dāng)滿意。 但需求變更卻越來越多。為了節(jié)省時間，客戶的業(yè)務(wù)人員不再向王先生申請變更，而是直接找程序員商量。程序員疲于應(yīng)付，往往直接改程序而不做任何記錄，很多相關(guān)文檔也忘記修改。很快王先生就發(fā)現(xiàn)：需求、設(shè)計和代碼無法保持一致，甚至沒有人能說清楚現(xiàn)在系統(tǒng)“到底改成什么樣了”。版本管理也出現(xiàn)了混亂，很多人違反配置管理規(guī)定，直接在測試環(huán)境中修改和編譯程序。但在進(jìn)度壓力下，他也只能佯裝不知此事。但因頻繁出現(xiàn)“改好的錯誤又重新出現(xiàn)”的問題，客戶已經(jīng)明確表示“失去了耐心”。 而這還只是噩夢的開始。一個程序員未經(jīng)許可擅自修改了核心模塊，造成系統(tǒng)運行異常緩慢，大量應(yīng)用程序超時退出。雖然最終花費了整整3天的時間解決了這個問題，但客戶卻投訴了，表示“無法容忍這種低下的項目管理水平”。更糟糕的是，因為擔(dān)心系統(tǒng)中還隱含著其他類似的錯誤,公司高層對項目的質(zhì)量也疑慮重重。 隨后發(fā)生的事情讓王先生更加為難：客戶的兩個負(fù)責(zé)人對界面風(fēng)格的看法不一致，并為此發(fā)生了激烈爭執(zhí)。王先生知道如果發(fā)表意見可能會得罪其中一方，于是保持了沉默。最終客戶決定調(diào)整所有界面， 王先生只好立刻動員大家抓緊時間修改?？珊髞懋?dāng)聽說因修改界面而造成了項目一周的延誤后，客戶方原來發(fā)生爭執(zhí)的兩人這次卻非常一致，同時氣憤地質(zhì)問王先生：“為什么你不早點告訴我們要延期！早知這樣才不會讓你改呢！”王先生委屈極了，疑惑自己到底錯在哪里了。,需求活動之間關(guān)系,需求獲取和分析,需求描述,需求有效性驗證,系統(tǒng)模型,用戶需求和系統(tǒng)需求,需求規(guī)約,軟件需求過程,需求管理,3.7 結(jié)構(gòu)化分析方法,結(jié)構(gòu)化分析（Structured Analysis，SA）由美國YOURDON公司提出。 采用自頂向下、逐層進(jìn)行功能分解的系統(tǒng)分析方法來定義系統(tǒng)的需求。 適用于分析大型的數(shù)據(jù)處理系統(tǒng)。 方法的特點：利用數(shù)據(jù)流圖（Data Flow Diagram，DFD）來幫助理解問題，對問題進(jìn)行分析。 一般工具：DFD、數(shù)據(jù)字典、判定表、判定樹等。 功能分析工具：DFD、DD、判定表和判定樹。 數(shù)據(jù)分析工具：ER圖或者EER（擴(kuò)展ER）圖。 行為分析工具：狀態(tài)遷移圖、Petri網(wǎng)等。 SA主要針對數(shù)據(jù)處理領(lǐng)域，因此，系統(tǒng)分析的側(cè)重點在于功能分析和數(shù)據(jù)分析，而行為分析使用得較少。,結(jié)構(gòu)化分析方法的一些弊?。?基于功能分析和數(shù)據(jù)分析，將功能和數(shù)據(jù)分離，與人類現(xiàn)實世界環(huán)境不一樣，和人的自然思維也就不一致了。 以功能為主，數(shù)據(jù)只是被動的信息載體。當(dāng)系統(tǒng)行為發(fā)生變化時，系統(tǒng)維護(hù)非常困難。 DFD中不涉及系統(tǒng)的控制信息，因此，SA不適合于分析以控制信息為主的系統(tǒng)需求。,3.7 結(jié)構(gòu)化需求分析,分解：對于一個復(fù)雜的系統(tǒng)，為了將復(fù)雜性降低到可以掌握的程度，可以把大問題分解成若干小問題，然后分別解決（如右圖）。,一、SA法的基本思想 “分解”和“抽象”,抽象：分解可以分層進(jìn)行，即先考慮問題最本質(zhì)的屬性，暫把細(xì)節(jié)略去,以后再逐層添加細(xì)節(jié)，直至涉及到最詳細(xì)的內(nèi)容，這種用最本質(zhì)的屬性表示一個系統(tǒng)的方法就是“抽象”。,3.7 結(jié)構(gòu)化需求分析,三、SA法的描述方法 1、分層的數(shù)據(jù)流圖（DFD圖） 2、數(shù)據(jù)詞典 3、描述加工邏輯的結(jié)構(gòu)化語言、判定表及判定樹,二、SA法的步驟,深入調(diào)查 研究,分析用戶需求,用DFD圖描述,分析系統(tǒng)需求,用DFD圖描述,修改完善DFD圖,增添功能,3.7 結(jié)構(gòu)化需求分析,3.7 結(jié)構(gòu)化需求分析,四、SA總結(jié) 軟件系統(tǒng)開發(fā)中的結(jié)構(gòu)化分析方法就是面向數(shù)據(jù)流自頂向下逐步求精的需求分析方法。通過可行性研究已經(jīng)得出了目標(biāo)系統(tǒng)的高層數(shù)據(jù)流圖，需求分析的目標(biāo)之一就是把數(shù)據(jù)流和數(shù)據(jù)存儲定義到元素級。 要達(dá)到此目的，一般從數(shù)據(jù)流圖的輸出端入手，這是因為系統(tǒng)的基本功能是產(chǎn)生這些輸出，輸出數(shù)據(jù)決定了系統(tǒng)必須具有的最基本的組成元素。,3.8分析建模,3.8.1 建立模型 模型 -就是為了理解事物而對事物做出的一種抽象，是對事物的一種無歧義的書面描述。通常，由一組圖形符號和組織這些符號的規(guī)則組成。 -模型將作為軟件設(shè)計的基礎(chǔ)和編寫軟件規(guī)格說明的依據(jù)。一般的說明，在需求分析階段要寫出詳細(xì)的規(guī)格說明是不可能的。因為，用戶對什么是正確的需求沒有把握，開發(fā)人員對怎樣正確的完成所要取得功能和性能也沒把握，所以需求分析選擇模型開發(fā)方法。 需求分析過程應(yīng)該建立3種模型： 數(shù)據(jù)模型：實體聯(lián)系圖，描繪數(shù)據(jù)及數(shù)據(jù)對象之間的關(guān)系。 功能模型：數(shù)據(jù)流圖，描繪當(dāng)數(shù)據(jù)在軟件系統(tǒng)中移動時被變換的邏輯過程。 行為模型：狀態(tài)轉(zhuǎn)換圖，描繪系統(tǒng)各種行為模式和在不同狀態(tài)間的轉(zhuǎn)換。,概念模型和規(guī)范化,軟件系統(tǒng)的整個開發(fā)過程都必須考慮兩方面的問題：“數(shù)據(jù)”及對數(shù)據(jù)的“處理”。為了把用戶的數(shù)據(jù)要求清晰明確的表達(dá)出來，系統(tǒng)分析員要建立概念性的數(shù)據(jù)模型（也稱信息模型），它也是一種面向問題的數(shù)據(jù)模型，是按用戶的觀點來對數(shù)據(jù)和信息建模。 采用的方法是：實體聯(lián)系方法（EntityRelationship Approach）即ER模型。,表示概念模型最常用的是實體聯(lián)系方法（entity-relationship approach）。該方法用ER圖(ER模型或?qū)嶓w聯(lián)系模型)來描述。它是描述概念世界、建立概念模型的實用工具。 E-R模型獨立于具體的計算機(jī)系統(tǒng)。E-R模型的主要成分是實體、聯(lián)系和屬性。它用簡單的圖形反映了現(xiàn)實世界中存在的事物或數(shù)據(jù)及它們之間的關(guān)系。 E-R模型獨立于具體的計算機(jī)系統(tǒng)。E-R模型的主要成分是實體、聯(lián)系和屬性。它用簡單的圖形反映了現(xiàn)實世界中存在的事物或數(shù)據(jù)及它們之間的關(guān)系。,實體聯(lián)系模型,1.實體：客觀存在并且相互區(qū)別的事物稱為實體,2.實體屬性：實體所具有的某一特性稱為屬性。一個實體可以由若干個屬性來刻畫。,3.實體集和實體型：屬性值的集合表示一個實體，實體名和各個屬性名的集合來抽象和描述同類實體稱為實體型(Entity type)。同類型的實體的集合稱為實體集(有時也把它直接稱為實體)。,實體聯(lián)系模型,實體集之間的對應(yīng)關(guān)系稱為聯(lián)系，反映現(xiàn)實世界各種事物之間的相互關(guān)聯(lián)，一般有以下三種聯(lián)系。 （1） 一對一聯(lián)系（1:1） 如果對于實體集A中的每一個實體，實體集B中至多有一個實體與之對應(yīng)；反之亦然，則稱A與B具有一對一聯(lián)系。 （2） 一對多聯(lián)系（1:n） 如果對于實體集A中的每一個實體，實體集B中有n個實體（n0）與之對應(yīng)；反之，對于實體集B中的每一個實體,實體集A中至多只有一個實體與之對應(yīng)，則稱A與B具有一對多聯(lián)系。 （3）多對多聯(lián)系（m:n） 如果對于實體集A中的每一個實體，實體集B中有n個實體（n0）與之對應(yīng)；反之，對于實體集B中的每一個實體,實體集A中也有m個實體（m0）與之對應(yīng)，則稱A與B具有多對多聯(lián)系。,實體聯(lián)系模型,一對一聯(lián)系是一對多聯(lián)系的特例，一對多聯(lián)系又是多對多聯(lián)系的特例。 概念模型和各種數(shù)據(jù)模型(層次模型除外)均不支持多對多聯(lián)系，只支持一對一聯(lián)系或一對多聯(lián)系。 在復(fù)雜問題中，兩個以上的實體集之間也往往存在一對一、一對多或多對多聯(lián)系。多對多聯(lián)系直接處理起來很困難，通常是將多對多聯(lián)系轉(zhuǎn)化為兩個一對多聯(lián)系來處理。 聯(lián)系本身也是一種實體型（如老師-學(xué)生的聯(lián)系就是上課，而上課又具有上課時間，地點，課程名等屬性），也可以有屬性。,實體聯(lián)系模型,在ER圖中，實體、屬性和聯(lián)系的表示方法如下： (1) 實體型：用矩形表示，矩形框內(nèi)寫實體名； (2) 屬性：用橢圓表示，并用無向線段與相應(yīng)的實體連接； (3) 聯(lián)系：用菱形表示，菱形框內(nèi)寫明聯(lián)系名，并用無向線段與有關(guān)的實體連接。同時在無向線段旁標(biāo)上聯(lián)系的類型（1：1，1：n或m：n）。聯(lián)系本身也是一種實體型，也可以有屬性。如果一個聯(lián)系有屬性，也用無向線段將屬性與該聯(lián)系連接。,實體聯(lián)系模型,軟件教研室,信息學(xué)院,(a)1:1聯(lián)系 (b)1:n聯(lián)系 (c)m:n聯(lián)系 兩個實體之間的三類聯(lián)系,軟件教研室,實體聯(lián)系模型,學(xué)生實體、課程實體及其屬性 將多對多聯(lián)系轉(zhuǎn)化為一對多聯(lián)系的一般方法是：增加一個新的實體集，并且這個新的實體集和原來的兩個實體集之間都是一對多聯(lián)系。,實體聯(lián)系模型,教學(xué)信息管理概念模型,成績,考分,實體聯(lián)系模型,考,選,數(shù)據(jù)流圖DFD - Data Flow Diagram （功能模型）,一種圖形化技術(shù)，它描繪信息流和數(shù)據(jù)從輸入移動到輸出的過程中所經(jīng)受的變換。 在數(shù)據(jù)流圖中沒有任何具體的物理部件，它只是描繪數(shù)據(jù)在軟件中流動和被處理的邏輯過程，是系統(tǒng)邏輯功能的圖形表示。 設(shè)計數(shù)據(jù)流圖時只需考慮系統(tǒng)必須完成的基本邏輯功能，完全不需要考慮怎樣具體地實現(xiàn)這些功能，所以它也是今后進(jìn)行軟件設(shè)計的很好的出發(fā)點。,數(shù)據(jù)流圖四種基本符號,數(shù)據(jù)加工/處理/變換,數(shù)據(jù)源點或終點 (外部實體),數(shù)據(jù)流(data flow),數(shù)據(jù)存儲文件,或,或,或,源或宿,軟件系統(tǒng)外部環(huán)境中的實體（包括人員、組織或其他軟件系統(tǒng)），統(tǒng)稱為外部實體。表示軟件系統(tǒng)輸入數(shù)據(jù)的來源和輸出數(shù)據(jù)的去向，一般只出現(xiàn)在數(shù)據(jù)流圖的頂層圖中。因此也稱為源點和終點 源或宿用相同的圖形符號表示 當(dāng)數(shù)據(jù)流從該符號流出時表示是源 當(dāng)數(shù)據(jù)流流向該符號時表示是宿 當(dāng)兩者皆有時表示既是源又是宿,加工,加工：也稱為數(shù)據(jù)處理，它對數(shù)據(jù)流進(jìn)行某些操作或變換。描述了輸入數(shù)據(jù)流到輸出數(shù)據(jù)流的變換，即將輸入數(shù)據(jù)流加工成輸出數(shù)據(jù)流。每個加工也要有名字，通常是動詞短語，簡明地描述完成什么加工。在分層的數(shù)據(jù)流圖中，加工還應(yīng)有編號。 每個加工用一個定義明確的名字標(biāo)識 至少有一個輸入數(shù)據(jù)流和一個輸出流 可以有多個輸入數(shù)據(jù)流和多個輸出數(shù)據(jù)流,文件,文件：保存數(shù)據(jù)信息的外部單元。使用文件、數(shù)據(jù)庫等保存某些數(shù)據(jù)結(jié)果供以后使用。流向數(shù)據(jù)存儲的數(shù)據(jù)流可理解為寫入文件，或查詢文件，從數(shù)據(jù)存儲流出的數(shù)據(jù)可理解為從文件讀數(shù)據(jù)或得到查詢結(jié)果。 每個文件用一個定義明確的名字標(biāo)識 由加工進(jìn)行讀寫 DFD中稱為文件，但在具體實現(xiàn)時可以用文件系統(tǒng)實現(xiàn)也可以用數(shù)據(jù)庫系統(tǒng)等實現(xiàn),注意: 數(shù)據(jù)存儲和數(shù)據(jù)流都是數(shù)據(jù),僅僅所處的狀態(tài)不同。數(shù)據(jù)存儲是處于靜止?fàn)顟B(tài)的數(shù)據(jù)，數(shù)據(jù)流是處于運行中的數(shù)據(jù)。,數(shù)據(jù)流,每個數(shù)據(jù)流用由一組固定成分的數(shù)據(jù)組成并擁有一個定義明確的名字標(biāo)識 如：運動會管理系統(tǒng)中，報名單(數(shù)據(jù)流)由隊名、姓名、性別、參賽項目等數(shù)據(jù)組成 數(shù)據(jù)流的流向 從一個加工流向另一個加工 從加工流向文件(寫文件) 從文件流向加工(讀文件) 從源流向加工 從加工流向宿,注意：數(shù)據(jù)流和程序流程圖中用箭頭表示的控制流有本質(zhì)不同，在數(shù)據(jù)流圖中應(yīng)該描繪所有可能的數(shù)據(jù)流向，而不應(yīng)該描繪出現(xiàn)某個數(shù)據(jù)流的條件。,數(shù)據(jù)流圖的擴(kuò)充符號,描述一個加工的多個數(shù)據(jù)流之間的關(guān)系,數(shù)據(jù)流圖的層次結(jié)構(gòu),為了表達(dá)數(shù)據(jù)處理過程的數(shù)據(jù)加工情況，需要采用層次結(jié)構(gòu)的數(shù)據(jù)流圖。按照系統(tǒng)的層次結(jié)構(gòu)進(jìn)行逐步分解，并以分層的數(shù)據(jù)流圖反映這種結(jié)構(gòu)關(guān)系，能清楚地表達(dá)和容易理解整個系統(tǒng)。 在多層數(shù)據(jù)流圖中，頂層流圖僅包含一個加工，它代表被開發(fā)系統(tǒng)。它的輸入流是該系統(tǒng)的輸入數(shù)據(jù)，輸出流是系統(tǒng)所輸出數(shù)據(jù)。描述了軟件系統(tǒng)與外界(源或宿)之間的數(shù)據(jù)流。 中間層流圖則表示對其上層父圖的細(xì)化。中間層圖中至少有一個加工(也可以有多個)可能繼續(xù)細(xì)化，在下層圖中分解成一張子圖。 底層流圖是指其所有加工不需再做分解的數(shù)據(jù)流圖，它處在最底層。,分層的數(shù)據(jù)流圖,- 系統(tǒng)邏輯模型,數(shù)據(jù)流程圖應(yīng)用實例,某汽車配件公司設(shè)有銷售、采購、倉庫、會計等業(yè)務(wù)部門。公司每天都要處理大量的銷售訂單業(yè)務(wù)。當(dāng)配件缺貨或庫存量低于保險貯備量時，就要進(jìn)貨。如果暫不考慮配件公司內(nèi)部的倉庫和會計業(yè)務(wù)細(xì)節(jié)，那么，配件公司的TOP圖，如下圖所示。,發(fā)貨清單,系統(tǒng),2,數(shù)據(jù)流程圖應(yīng)用實例,第0層,第1層,缺貨數(shù)據(jù),到貨通知,發(fā)貨清單,發(fā)貨清單,系統(tǒng),銷售配件,采購配件,數(shù)據(jù)流程圖應(yīng)用實例,缺貨記錄,客戶檔案,第2層,補(bǔ)發(fā)清單,審核,客戶檔案,客戶信息,開發(fā)貨單,更新庫存,配件庫存,補(bǔ)發(fā)清單,銷售報表,數(shù)據(jù)流程圖應(yīng)用實例,第3層,. 便于實現(xiàn),. 便于使用,- 采用逐步細(xì)化的擴(kuò)展方法，可避免一 次引入過多的細(xì)節(jié)，有利于控制問題 的復(fù)雜度；,- 用一組圖代替一張總圖，方便用戶及 軟件開發(fā)人員閱讀。,分層 DFD 圖的優(yōu)點,1） 為數(shù)據(jù)流(或數(shù)據(jù)存儲)命名 (1) 名字應(yīng)代表整個數(shù)據(jù)流(或數(shù)據(jù)存儲)的內(nèi)容，而不是僅 僅反映它的某些成分。 (2) 不要使用空洞的、缺乏具體含義的名字(如“數(shù)據(jù)”、 “信息”、“輸入”之類)。 (3) 如果在為某個數(shù)據(jù)流(或數(shù)據(jù)存儲)起名字時遇到了困難 則很可能是因為對數(shù)據(jù)流圖分解不恰當(dāng)造成的，應(yīng)該試 試重新分解，看是否能克服這個困難。,1. 注意數(shù)據(jù)流圖中成分的命名,畫分層 DFD 的指導(dǎo)原則,2） 為加工命名 (1)通常先為數(shù)據(jù)流命名，然后再為與之相關(guān)聯(lián)的處理命名。這樣命名比較容易，而且體現(xiàn)了人類習(xí)慣的“由表及里”的思考過程。 (2)名字應(yīng)該反映整個加工的功能，而不是它的一部分功能。 (3)名字最好由一個具體的及物動詞加上一個具體的賓語組成。應(yīng)該盡量避免使用“加工”、“處理”等空洞籠統(tǒng)的動詞作名字。 (4)通常名字中僅包括一個動詞，如果必須用兩個動詞才能描述整個加工的功能，則把這個處理再分解成兩個處理可能更恰當(dāng)些。 (5)如果在為某個加工命名時遇到困難，則很可能是發(fā)現(xiàn)了分解不當(dāng)?shù)嫩E象，應(yīng)考慮重新分解。,1. 注意數(shù)據(jù)流圖中成分的命名,畫分層 DFD 的指導(dǎo)原則,畫分層 DFD 的指導(dǎo)原則,3. 掌握分解的速度,一般來說，每一個加工每次可分為 2-4個子加工，最多 不得超過 7 個。,4. 遵守加工編號規(guī)則,頂層加工不編號。第二層的加工編號為1,2,3,n號。 第三層編號為1.1,1.2,1.3 n.1,n.2等號，依此類 推。,父圖中某個加工的輸入輸出數(shù)據(jù)流應(yīng)該同相應(yīng)的子圖的輸入輸出相同(相對應(yīng)），分層數(shù)據(jù)流圖的這種特點稱為子圖與父圖“平衡”。,2. 注意父圖和子圖的平衡,5.數(shù)據(jù)流”一定是和“加工”有關(guān)聯(lián)的。一個數(shù)據(jù)流不是流入“加工”的就必然是從“加工”流出的。,數(shù)據(jù)流與加工的關(guān)系,6.一個加工的輸出數(shù)據(jù)流不能與該加工的輸入數(shù)據(jù)流同名,7.合理使用文件。頂層圖通常沒有文件,在其他層中當(dāng)文件作為某些加工之間的交界面時，文件必須畫出來，一旦文件作為數(shù)據(jù)流圖中的一個獨立成份畫出來了，那么他同其他成份之間的聯(lián)系也應(yīng)同時表達(dá)出來。,畫分層 DFD 的指導(dǎo)原則,案例,某醫(yī)院欲開發(fā)病人監(jiān)控系統(tǒng)，該系統(tǒng)通過各種設(shè)備監(jiān)控病人的生命體征，并在生命體征異常時向醫(yī)生和護(hù)理人員報警。該系統(tǒng)的主要功能如下： 1）本地監(jiān)控：定期獲取病人的生命體征，如體溫、血壓、心率等數(shù)據(jù)； 2）格式化生命體征：對病人的各項重要生命體征數(shù)據(jù)進(jìn)行格式化，然后存入日志文件并檢查生命體征； 3）檢查生命體征：將格式化后的生命體征與生命體征范圍文件中預(yù)設(shè)的正常范圍進(jìn)行比較，如果超出了預(yù)設(shè)范圍，系統(tǒng)就發(fā)送一條警告信息給醫(yī)生和護(hù)理人員； 4）維護(hù)生命體征范圍：醫(yī)生在必要時（如新的研究成果出現(xiàn)時）添加或更新生命體征值的正常范圍； 5）提取報告：在醫(yī)生或護(hù)理人員請求病人生命體征報告時，從日志文件中獲取病人生命體征生成體征報告，并返回給請求者；,6）生成病歷：根據(jù)日志文件中的生命體征，醫(yī)生對病人的病情進(jìn)行描述，形成病歷存入病歷文件； 7）查詢病歷：根據(jù)醫(yī)生的病歷查詢請求，查詢病歷文件，給醫(yī)生返回病歷報告； 8）生成治療意見：根據(jù)日志文件中的生命體征和病歷，醫(yī)生給出治療意見，如處方等，并存入治療意見文件； 9）查詢治療意見：醫(yī)生和護(hù)理人員查詢治療意見，據(jù)此對病人進(jìn)行治療。 現(xiàn)采用結(jié)構(gòu)化方法對病人監(jiān)控系統(tǒng)進(jìn)行分析和設(shè)計，獲得如圖1-1所示的頂層數(shù)據(jù)流圖和圖1-2所示的0層數(shù)據(jù)流圖。,案例,案例,在數(shù)據(jù)流圖中對一個數(shù)據(jù)流、數(shù)據(jù)存貯或加工只能標(biāo)明一個名字，沒有對這些元素的構(gòu)成細(xì)節(jié)、內(nèi)容、特性及加工過程詳細(xì)說明。分析人員僅靠“圖”來完整地理解一個系統(tǒng)的邏輯功能是不可能的。為了完整地描述這個系統(tǒng)，還需借助“數(shù)據(jù)詞典”和“小說明”對圖中的每個數(shù)據(jù)和加工給出解釋。 數(shù)據(jù)定典就是用來定義數(shù)據(jù)流圖中的各個成分的具體含義的工具，它以一種準(zhǔn)確的、無二義性的說明方式為系統(tǒng)的分析、設(shè)計及維護(hù)提供了有關(guān)元素的一致的定義和詳細(xì)的描述。 它和數(shù)據(jù)流圖共同構(gòu)成了系統(tǒng)的邏輯模型，是“需求規(guī)格說明書”的主要組成部分。,數(shù)據(jù)詞典(DD),A、數(shù)據(jù)流條目 給出某個數(shù)據(jù)流的定義，通常是列出該 數(shù)據(jù)流的各組成數(shù)據(jù)項。 例如：報名單姓名單位名年齡性別課程名 常用符號：、（）、,C、數(shù)據(jù)項條目（數(shù)據(jù)流分量） 數(shù)據(jù)項條目給出某個數(shù)據(jù)單項的定義，通常是數(shù)據(jù)項的值類型，允許的取值范圍。,B、文件條目 給出某個文件的定義，文件的定義通常是列出文件記錄的組成數(shù)據(jù)流。例如： 訂單文件訂單編號顧客名稱產(chǎn)品名稱訂貨數(shù)量交貨日期,D、加工條目 加工類條目就是“加工小說明”。一般應(yīng)該單獨列出。,數(shù)據(jù)詞典(DD),常用的描述數(shù)據(jù)結(jié)構(gòu)的關(guān)系算符,1.數(shù)據(jù)流條目,數(shù)據(jù)流條目通常列出組成該數(shù)據(jù)流的數(shù)據(jù)項數(shù)。,名稱：訂單 別名：無 簡述：顧客訂貨時填寫的項目 來源：顧客 去向：加工1.1.1“編輯檢查訂單” 數(shù)據(jù)流量：1000份/每周 組成：編號+訂貨日期+顧客編號+地址+電話+銀行 帳號+配件名稱+數(shù)量 其中：數(shù)據(jù)流量指單位時間內(nèi)（每小時或每天）傳輸 的次數(shù),數(shù)據(jù)流條目,由數(shù)據(jù)元素組成數(shù)據(jù)的方式只有如下三種基本類型： 順序 以一定的順序連接兩個或多的元素； 選擇 從兩個或多個可能的元素中選取一個； 重復(fù) 把指定的元素重復(fù)零次或多次。 可選 理論上，可以使用上述三種關(guān)系定義數(shù)據(jù)字典中的任何條目。因為，當(dāng)重復(fù)次數(shù)為0次或一次時，就構(gòu)成了一種可有可無的可選關(guān)系。但由于“可選”是由數(shù)據(jù)元素組成數(shù)據(jù)的一種常見方式，把它單獨列為一種關(guān)系會使數(shù)據(jù)字典的描述更清晰。,2. 數(shù)據(jù)項條目,名稱：配件編號 別名：配件號 簡述：本公司的所有配件編號 類型：字符型 長度：10位 取值范圍及含義： 第1位：進(jìn)口/國產(chǎn) 第2-4位：類別 第5-7位：規(guī)格 第8-10位：編號,3.數(shù)據(jù)存儲條目,名稱：配件庫存 別名：無 簡述：存放配件庫存信息 組成：配件編號+配件名稱+ 供應(yīng)商編號+單價+ 庫存量 組織方式：索引文件，以配件 編號為關(guān)鍵字 查詢要求：要求能立即查詢,4. 加工條目,由于下層的加工是由上層的基本加工分解而來的，只要有了基本加工的說明，就可理解上層的加工。因此，只有把加工分解到足夠具體以后，才對基本加工進(jìn)行描述。,具體格式舉例如下,名稱：確定能否供貨 編號：1.2 激發(fā)條件：收到合格訂單 優(yōu)先級：普通 輸入：合格訂單 輸出：可供貨訂單、缺貨訂單 加工邏輯：根據(jù)庫存記錄 IF 訂單項目的數(shù)量該配件庫存量的臨界值 THEN 可供貨處理 ELSE 此訂單缺貨，登記缺貨情況，待進(jìn)貨后再辦理補(bǔ)充訂貨 EDNIF,對數(shù)據(jù)流圖的每一個基本加工，必須有一個基本加工邏輯小說明，給出該加工的精確描述。 。 基本加工邏輯說明必須描述基本加工如何把輸入數(shù)據(jù)流變換為輸出數(shù)據(jù)流的加工規(guī)則。 加工邏輯說明必須描述實現(xiàn)加工的策略而不是實現(xiàn)加工的細(xì)節(jié)。 加工邏輯說明中包含的信息應(yīng)是充足的，完備的，有用的，無冗余的。對基本加工說明有三種描述方式：,加工邏輯說明,結(jié)構(gòu)化語言 判定表 判定樹,結(jié)構(gòu)化語言是介于自然語言和形式語言之間的一種半形式語言,是自然語言的一個受限制的子集。 一般分為兩層結(jié)構(gòu)：外層語法較具體，為控制結(jié)構(gòu)（順序、選擇、循環(huán)）,內(nèi)層較靈活，表達(dá)“做什么”。,（一） 結(jié)構(gòu)化語言,例如：外層可為以下結(jié)構(gòu)： 1、順序結(jié)構(gòu) 2、選擇結(jié)構(gòu) IFTHEN-ELSE; CASE-OF-ENDCASE； 3、循環(huán)結(jié)構(gòu) WHILE-DO; REPEAT-UNTIL,加工說明,自然語言+結(jié)構(gòu)化形式,商店業(yè)務(wù)處理系統(tǒng)中“檢查發(fā)貨單”,if 發(fā)貨單金額超過$500 then if 欠款超過了60天 then 在償還欠款前不予批準(zhǔn) else （欠款未超期） 發(fā)批準(zhǔn)書，發(fā)貨單 else （發(fā)貨單金額未超過$500） if 欠款超過60天 then 發(fā)批準(zhǔn)書，發(fā)貨單及賒欠報告 else （欠款未超期） 發(fā)批準(zhǔn)書，發(fā)貨單,例：一圖書銷售系統(tǒng)，其中一加工為“優(yōu)惠處理”，條件是：顧客的營業(yè)額大于1000元，同時必須信譽(yù)好，或者雖然信譽(yù)不好，但是20年以上的老主顧。,判定表是一種二維的表格，常用于較復(fù)雜的組合條件（與結(jié)構(gòu)化語言比較）。如果數(shù)據(jù)流圖的加工需要依賴于多個邏輯條件的取值，使用判定表來描述比較合適,（二） 判定表,特點：可處理較復(fù)雜的組合條件，但不易理解，不易輸入計算機(jī),通常由四部分組成。 條件框 條件定義。 操作框 操作的定義。 條件條目 各條件的取值及組合。 操作條目 在各條件取值組合下所執(zhí)行的操作。,加工說明,例：一圖書銷售系統(tǒng)，其中一加工為“優(yōu)惠處理”，條件是：顧客的營業(yè)額大于1000元，同時必須信譽(yù)好，或者雖然信譽(yù)不好，但是20年以上的老主顧。,加工說明,特點:描述一般組合條件較清晰，易理解。不易輸入計算機(jī)。,營業(yè)額, 1000元 1000元 正常處理,好的支付信譽(yù) 優(yōu)惠處理 壞的支付信譽(yù), 20年 優(yōu)惠處理 20年 正常處理,（三） 判定樹,加工說明,狀態(tài)轉(zhuǎn)化圖通過描繪系統(tǒng)的狀態(tài)及引起系統(tǒng)狀態(tài)轉(zhuǎn)換的事件，來表示系統(tǒng)的行為。此外，狀態(tài)圖還指明了作為特定事件的結(jié)果系統(tǒng)將做哪些動作（例如，處理數(shù)據(jù)）。因此，狀態(tài)圖提供了行為建模機(jī)制?？梢岳斫鉃樵谌我粋€時刻，系統(tǒng)處于有限可能的狀態(tài)中的一個狀態(tài)，當(dāng)某一個激勵（條件）到達(dá)時，它激發(fā)系統(tǒng)從一個狀態(tài)轉(zhuǎn)換到另一個新狀態(tài)。 1.狀態(tài) 狀態(tài)是任何可以被觀察到的系統(tǒng)行為模式，一個狀態(tài)代表系統(tǒng)的一個行為模式。狀態(tài)規(guī)定了系統(tǒng)對事件的響應(yīng)方式。系統(tǒng)對事件響應(yīng)，既可以是做一個（或一系列）動作，也可以是僅僅改變系統(tǒng)本身的狀態(tài)，還可以是既改變狀態(tài)又做動作。,狀態(tài)轉(zhuǎn)換圖（行為模型）,2.事件 事件是在某個特定時刻發(fā)生的事情，它是對引起系統(tǒng)做動作或從一個狀態(tài)轉(zhuǎn)換到另一個狀態(tài)的外界事件的抽象。例如，內(nèi)部時鐘表明某個規(guī)定的時間段已經(jīng)過去，用戶移動或點擊鼠標(biāo)等都是事件。簡而言之，事件就是引起系統(tǒng)做動作或轉(zhuǎn)換狀態(tài)的控制信息。,3. 符號 在狀態(tài)圖中，初態(tài)用實心圓表示，終態(tài)用一對同心圓（內(nèi)圓為實心圓）表示。 中間狀態(tài)用圓角矩形表示，可以用平衡線把它分割成上、中、下3個部分。上部分為狀態(tài)的名稱，該部分是必須的；中間部分為狀態(tài)變量的名字和值，該部分為可選；下面部分是活動表，該部分為可選。 狀態(tài)圖中兩個狀態(tài)之間帶箭頭的連線稱為狀態(tài)轉(zhuǎn)換，箭頭指明了轉(zhuǎn)換方向。如轉(zhuǎn)換過程中有事件觸發(fā)，可以用事件表達(dá)式標(biāo)明。,案例分析,一個具