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

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