軟件工程PPT電子教案課件-第4章需求分析基礎.ppt

軟件工程,哈爾濱工程大學,software engineering,第4章 需求分析基礎,分析的任務、過程、原則 初步需求獲取技術 需求建模 問題抽象、問題分解與多視點分析 支持需求分析的快速原型技術 需求規(guī)格說明與評審,軟件需求：用戶對目標軟件系統(tǒng)在功能、行為、 性能、設計約束等方面的期望,第4章 需求分析基礎,ieee軟件工程標準詞匯表(1997年)中定義需求為： (1)用戶解決問題或達到目標所需的條件或權能(capability)。 (2)系統(tǒng)或系統(tǒng)部件要滿足合同、標準、規(guī)范或其它正式規(guī)定文檔所需具有的條件或權能。 (3)一種反映上面(1)或(2)所描述的條件或權能的文檔說明。 準確、完整和規(guī)范化的軟件需求是軟件開發(fā)成功的關鍵。軟件項目中40%-60%的問題都是在需求階段埋下的禍根 主要障礙：用戶對應用問題的理解、描述以及他們對目標軟件的需求往往具有片面性、模糊性，甚至不一致性,第4章 需求分析基礎,不適當?shù)男枨筮^程所引起的一些風險： 調研的用戶不多，導致產品無法被接受 用戶需求的增加帶來過度的耗費和降低產品的質量 模棱兩可的需求說明可能導致時間的浪費和返工 用戶增加一些不必要的特性和開發(fā)人員畫蛇添足(gold-plating) 過分簡略的需求說明以致遺漏某些關鍵需求 忽略某類用戶的需求將導致眾多客戶的不滿 不完善的需求說明使得項目計劃和跟蹤無法準確進行,4.1 需求分析的任務與原則,軟件需求分析：對應用問題及環(huán)境的理解和分析，為問題涉及的信息、功能及系統(tǒng)行為建立模型。將用戶需求精確化、完全化，最終形成需求規(guī)格說明書 分析目標：準確理解用戶的要求，進行細致的調查分析，將用戶的非形式的要求轉化為完整的需求定義，再將需求定義轉換為相應的形式化的規(guī)格說明,深入描述軟件的功能和性能，確定軟件的設計約束、軟件同其他系統(tǒng)元素的接口細節(jié)，定義軟件的其他有效性需求,一方面必須全部理解用戶的各項要求但又不能全盤接受；另一方面要準確表達被接受的要求。只有經過確切描述的軟件需求才能成為軟件設計的基礎,需求分析的任務,需求分析的任務：就是借助于當前系統(tǒng)的邏輯模型導出目標系統(tǒng)的邏輯模型，解決目標系統(tǒng)的 “做什么” 的問題。,理 解 需 求,表 達 需 求,怎么做,做什么,需求分析的任務,需求分析階段要解決的問題，是讓用戶和開發(fā)者共同明確將要開發(fā)的是一個什么樣的系統(tǒng)。 主要兩個任務 （1）通過對問題及其環(huán)境的理解、分析和綜合，建立分析模型(analysis model)。 （2）在完全地弄清用戶對軟件系統(tǒng)的確切要求的基礎上，用“軟件需求規(guī)格說明書”（software requirement specification，srs）把用戶的需求表達出來。,需求分析的任務,建立分析模型 由于用戶群體的各個用戶往往會從不同的角度闡述他們對原始問題的理解和對目標軟件的需求，分析模型是描述軟件需求的一組模型。 一方面用于精確地記錄用戶對原始問題和目標軟件的描述 另一方面，它也將幫助分析人員發(fā)現(xiàn)用戶需求中的不一致性，排除不合理的部分，挖掘潛在的用戶需求 這種模型往往包含問題及其環(huán)境所涉及的信息流、處理功能、用戶界面、行為模型及設計約束等。是形成需求說明、進行軟件設計與實現(xiàn)的基礎,需求分析的任務,編寫需求說明 應該具有準確性和一致性。它是連接計劃時期和開發(fā)時期的橋梁，也是軟件設計的依據。 應該具有清晰性和無二義性。它是溝通用戶和系統(tǒng)分析員思想的媒介，雙方要用它來表達對于需要計算機解決的問題的共同理解。 應該直觀、易讀和易于修改。應盡量采用標準的圖形、表格和簡單的符號來表示，使不熟悉計算機的用戶也能一目了然。,需求分析過程,問題識別,分析與綜合,編寫文檔,分析評審,問題識別,從分析當前系統(tǒng)包含的數(shù)據開始 例如當前系統(tǒng)使用的賬冊、卡片和報表，手工處理當前信息的方法與不足，用戶需要改進的主要問題及其迫切性等 對軟件功能的需求和界面的需求 為了收集到全面完整的信息，需將客戶按使用頻率、使用特性、優(yōu)先及等方面進行分類，每類選擇若干用戶代表，從代表那里收集他們希望的軟件系統(tǒng)功能、用戶與系統(tǒng)間的交互和對話方式等需求 對質量的要求，包括性能、有效性、可靠性、可用性和設計約束等，提高用戶對軟件的滿足程度 如果客戶的要求和已有產品很相似，則需要考慮可否復用一些已有的軟件組件,分析與綜合（需求提煉：分析建模）,分析人員應了解問題及環(huán)境，應與用戶合作清除用戶需求的模糊性、岐義性和不一致性，并對相互沖突的需求進行折衷 分析人員與用戶合作對問題進行分析、綜合，結合軟件的特點及開發(fā)經驗，尋求軟件需求 為用戶的問題及準備開發(fā)的軟件建立模型，從不同的角度、不同的抽象級別精確地說明對問題的理解、對目標軟件的需求 圖形化的分析模型是說明軟件需求極好的手段，常用的模型包括數(shù)據流圖、實體關系圖、控制流圖、狀態(tài)轉換圖、用例圖、類對象關系及其行為圖文圖等。有些軟件還需要繪制系統(tǒng)關聯(lián)圖、創(chuàng)建用戶接口原型、確定需求優(yōu)先級別,編寫srs（需求描述）,以需求模型為基礎，考慮到軟件問題的可解性，生成需求規(guī)格說明和初步的用戶手冊。 需求規(guī)格說明包含對目標軟件系統(tǒng)的外部行為的完整描述、需求驗證標準以及用戶在性能、質量、可維護性等方面的要求。 初步用戶手冊包括用戶界面描述以及有關目標軟件使用方法的初步構想。 文檔 遵循規(guī)范，內容全面、結構清晰、措辭準確、格式嚴謹 將初步用戶手冊作為分析文檔,有助于分析人員從用戶角度考慮軟件需求，并鼓勵用戶盡早參予軟件開發(fā)活動 必須使用統(tǒng)一格式的文檔進行描述。為了使需求描述具有統(tǒng)一的風格，可以采用已有的且可滿足項目需要的模板，如ieee標準830-1998和gb9385中描述的srs模板,需求評審,分析人員在用戶和軟件設計人員的配合下，對自己生成的需求規(guī)格說明和初步的用戶手冊進行評審，確保軟件需求的完全性、精確性和一致性，并使用戶和軟件設計人員對需求規(guī)格說明及用戶手冊的理解達成一致。 需求規(guī)格說明得到用戶和軟件開發(fā)方的確認后，應成為用戶方與軟件開發(fā)方合同的一部分。,需求分析流程,需求分析的原則,原則 能夠表達和理解問題的信息域和功能域 能夠對問題進行分解和不斷細化，建立問題的層次結構 需要給出系統(tǒng)的邏輯視圖和物理視圖 方法 面向數(shù)據流的分析 面向數(shù)據的分析 面向對象的分析 需求的四項基本標準：明確(clear)、完整(complete)、一致(consistent)、可測試(testable),4.2 初步需求獲取技術,訪談與會議 深入調查研究 聯(lián)合小組 開發(fā)原型,訪談與會議,個別訪談或小組會議 分析人員應精心準備問題，通過用戶對問題的回答，逐步理解用戶對目標軟件的要求 (1)循序漸進 首先關心一般性、整體性問題，然后再討論細節(jié)問題。 (2)客觀、公正 不應限制用戶在回答問題過程中自由發(fā)揮。 (3)總結 問題匯總后應能反映軟件或其子系統(tǒng)的全貌，能覆蓋用戶對目標軟件或其子系統(tǒng)在功能、行為、性能諸方面的要求。細節(jié)問題留待以后解決。,深入調查研究,調查研究 考察用戶軟件或其子系統(tǒng)業(yè)務流程 學習用戶的有關業(yè)務知識，在用戶幫助下了解用戶的軟件或子系統(tǒng)業(yè)務流程，結合軟件開發(fā)和應用的經驗提出新的用戶需求 注意：開發(fā)軟件系統(tǒng)不僅是為了模擬手工操作過程，還必須將最好的經濟效益、最快的處理速度、最合理的操作流程、最友好的用戶界面作為軟件的目標,聯(lián)合小組,建立軟件開發(fā)方和用戶方共同組成的聯(lián)合小組，小組成員對分析負有相同的責任 聯(lián)合小組要制定自己的工作制度和計劃，確定專門的記錄員，另設專人負責會議的議程和資料的綜合、整理 選擇易于理解、比較簡潔、精確的表示機制作為描述語言，如輔以文字說明的流程圖,需求獲取一般過程,1、識別系統(tǒng)用戶 分析客戶方的所有用戶類型以及潛在的類型，然后根據他們的要求來確定系統(tǒng)的整體目標和系統(tǒng)的工作范圍。如有領導使用，則應該有領導查詢系統(tǒng)；如果是單機系統(tǒng)，則對安全性可以少考慮。 2、用戶調研與訪談 會議、電話、email、小組討論、模擬演示等，每次都要有記錄，確定功能需求、非功能需求(響應時間、自動恢復時間)、環(huán)境限制、設計約束等。 3、訪談結果整理 對于用戶提出的每個需求都要知道“為什么”，并判斷這種需求是否有充足的理由。 將那種以“如何實現(xiàn)”的表達方式轉換為“實現(xiàn)什么”。 分析由用戶需求衍生出的隱含需求，并識別用戶沒有明確提出來的隱含需求。如工時統(tǒng)計計算工資，生產系統(tǒng)工資系統(tǒng)。 4、訪談結果呈現(xiàn) 明確標識出那些未確定的需求項。 使需求符合系統(tǒng)的整體目標。 保證需求項之間的一致性，解決需求項之間可能存在的沖突。,出版社管理信息系統(tǒng)調查表,實例分析,家庭保安系統(tǒng) 家庭保安市場正以每年40%的速度增長。我們希望建立一種基于微處理器的家庭保安系統(tǒng)，它能夠識別異常事件并采取相應的防護措施。這些異常事件包括：非法入侵、火災、水淹，等等。一旦異常情況被相應的傳感器探測出來，系統(tǒng)應自動用電話向監(jiān)控中心報警。此外，系統(tǒng)應允許戶主對其行為實施程序式控制。 聯(lián)合小組首先制定工作制度，經過數(shù)次會議討論，明確問題的范圍、問題與環(huán)境的關系，并就開發(fā)軟件產品的必要性達成共識后，小組負責人要求每位參加人列出應用問題及環(huán)境中有關的對象、這些對象所實施的操作以及對象間的互相作用,實例分析,控制面板、電話機、監(jiān)控中心、煙霧報警器、門窗報警器、警報器等對象；用戶編程控制、電話撥號、報警等操作 要求對對象及操作進行詳細描述 用戶可能提出約束條件，如成本、響應時間優(yōu)先處理順序等 最后初步分析活動，綜合、整理，形成文檔，該文檔作為后續(xù)分析活動的基礎。部分需求文檔（不包括約束條件和測試標準）如下 “家庭保安系統(tǒng)”的軟件允許用戶在安裝時進行系統(tǒng)配置，實施對傳感器的監(jiān)控并通過控制面板與用戶進行信息交互。,實例分析,配置操作包括： （1）指定每一傳感器的種類和編號； （2）設置開、關機密碼； （3）指定報警電話號碼； （4）指定報警延遲和電話重撥延遲時間（以秒為單位）。 當軟件系統(tǒng)接收到傳感器發(fā)出的數(shù)據后，判別是否出現(xiàn)異常事件。如果是，則在指定的延遲時間內撥報警電話號碼，撥號操作將按照重撥延遲反復進行，直到電話接通。然后軟件系統(tǒng)負責報告時間、地點和異常事件的性質。 開機后，軟件系統(tǒng)負責顯示當前工作狀態(tài)，接收并處理用戶指令。,4.3 需求建模,建立軟件模型是分析活動的關鍵 目標軟件系統(tǒng)的模型用來刻劃系統(tǒng)所涉及的信息、處理功能及系統(tǒng)運行時的外部行為 模型不應涉及軟件實現(xiàn)細節(jié)，這樣會分散分析人員的注意力，限制軟件設計人員的聰明才智 分析人員應以簡潔、準確、清晰的方式，系統(tǒng)地描述軟件需求模型，如選擇圖形符號表示信息流、處理功能及系統(tǒng)行為，利用受限的自然語言給出用戶需求描述 為了處理大型問題，模型表示機制應具備良好的結構化能力,4.3 需求建模,通常由一組模型組成 信息(或數(shù)據)模型 功能模型 行為模型 最常用的兩種分析模型 結構化分析模型 面向對象分析模型 pressman用簡明的圖形介紹了這兩種分析模型的組成結構,4.3 需求建模,結構化分析模型,模型的核心是dd(data dictionary，數(shù)據字典)，它是系統(tǒng)所涉及的各種數(shù)據對象的總和。 從dd出發(fā)可以構建3種圖： 1）e-r圖(entity-relation diagram，實體關系圖)：用于描述數(shù)據對象間的關系，它代表軟件的數(shù)據模型，。,2）dfd(data flow diagram，數(shù)據流圖)：主要作用是指明系統(tǒng)中數(shù)據是如何流動和變換的，以及描述數(shù)據流進行變換的功能，在dfd中出現(xiàn)的每個功能的描述則寫在加工說明(pspec)中，一起構成軟件的功能模型。 3）std(status transfer diagram，狀態(tài)-變遷圖)：用于指明系統(tǒng)在外部事件的作用下將會如何動作，表明了系統(tǒng)的各種狀態(tài)以及各種狀態(tài)之間的變遷，從而構成行為模型的基礎，關于軟件控制方面的附加信息則包含在控制說明(cspec)中。 早期模型僅包括dd、dfd和pspec等3個組成部分，主要用于描述軟件的數(shù)據模型(用dd)與功能模型(用dfd和pspec),4.3 需求建模,面向對象分析模型,模型的核心是“使用實例”(use case)，簡稱“用例”。當通過fast小組獲得軟件的需求后，軟件分析員即可據此創(chuàng)建一組“場景”(scenario)，每個場景包含了一個使用實例。從這些用例出發(fā)，進一步抽取和定義ooa模型的3種模型，即： 1）類-對象模型：描述系統(tǒng)所涉及的全部類-對象，每一個類-對象都通過屬性、操作和協(xié)作者來進行進一步描述。,2）對象關系模型：描述對象之間的靜態(tài)關系，同時定義了系統(tǒng)中所有重要的消息路徑，它也可以具體化到對象的屬性、操作和協(xié)作者。 3）對象行為模型：描述了系統(tǒng)的動態(tài)行為，即對象在特定的狀態(tài)下如何反映外界的事件。 與結構化分析模型相類似，上述3種模型大體上相當于e-r圖、dfd圖和std圖，分別起到描述數(shù)據模型、功能模型與行為模型的作用。,4.4 問題的抽象、分解與多視點分析,抽象：關注一般問題的解決途徑，以此指導特殊問題的求解。 分析人員應該注意用戶描述的抽象級別，統(tǒng)一規(guī)劃系統(tǒng)行為。 避免不一致性，減少分析的工作量。,分解,根據問題的規(guī)模和復雜性進行分解，并對子問題展開進一步的分析 逐級分解，直至子問題的規(guī)模降至合適程度 在問題分解過程中，要建立子問題之間的相互聯(lián)系 必須遵循子問題內部緊藕合，子問題之間松藕合的原則,視點分解法,視點分解法 在分析的初期，整體地把握一個大型問題的軟件需求是困難的。需要從各個角度分別對問題進行理解和分析，然后再綜合，達到全面理解的目的 需求分析視點 系統(tǒng)觀點 用戶觀點 信息觀點 功能觀點 行為觀點等 整理、綜合用戶描述，應注意用戶視點的變化，避免遺漏,4 .5 支持需求分析的快速原型技術,按照傳統(tǒng)的軟件開發(fā)方法，目標軟件要等到木已成舟才能交用戶認可。 分析、設計及編碼積累的各種問題，導致用戶對目標軟件提出諸多修改，甚至全盤否決，造成人力、物力的巨大浪費。 軟件開發(fā)早期，快速建立目標軟件系統(tǒng)原型，讓用戶對原型進行評估并提出意見。 原型幾經改進最終確定，它將進化成軟件產品。 設計和編碼人員遵循原型確立的外部特征實現(xiàn)軟件產品。 如果軟件產品含有大量人機交互、可視輸出、或者涉及復雜的算法，應采用快速原型技術。,支持需求分析的快速原型技術,分析階段使用快速原型技術與問題本身的復雜度以及可用的開發(fā)工具、環(huán)境有關。 如果問題非常復雜，在當前工具、環(huán)境的支持下開發(fā)可運行的原型需要投入太多人力或占用太多時間，那么可對某些子問題，尤其是用戶界面，使用快速原型技術進行部分分析。 某些軟件項目，雖不能構造實際可運行的快速原型，但可以采用幻燈片演示等方法，向用戶直觀描述目標軟件系統(tǒng)的外部行為。,快速建造原型過程,(1)利用需求分析技術、方法，生成簡化的需求規(guī)格說明 (2)對簡化的需求規(guī)格說明進行檢查、修訂，生成設計規(guī)格說明。為了快速生成原型,只關心軟件的總體結構、用戶界面和數(shù)據設計，而不注重過程內部的控制流。 (3)在快速原型工具或環(huán)境的幫助下，快速生成可運行的軟件原型并進行測試、改進。主要工具有：可重用軟部件庫、用戶界面自動生成器等。,快速建造原型過程,(4)將原型提交用戶評估并征求改進意見。 (5)迭代上述過程，直到用戶滿意。 通過評審的原型應全面、準確地反映用戶對目標軟件在外部行為方面的需求，可以作為需求規(guī)格說明的一部分并成為軟件設計和編碼的基礎。,軟件原型的分類,探索型：目的是要弄清對目標系統(tǒng)的要求，確定所希望的特性，并探討多種方案的可行性。 實驗型：這種原型用于大規(guī)模開發(fā)和實現(xiàn)之前，考核方案是否合適，規(guī)格說明是否可靠。 進化型：這種原型的目的不在于改進規(guī)格說明，而是將系統(tǒng)建造得易于變化，在改進原型的過程中，逐步將原型進化成最終系統(tǒng)。,原型開發(fā)模型,原型開發(fā)技術,可執(zhí)行規(guī)格說明 基于腳本(scenario)的設計 自動程序設計 專用語言 可復用(reusable)的軟件 簡化假設,4.6 需求規(guī)格說明與評審,產生需求規(guī)格說明并進行評審 需求規(guī)格說明應成為開發(fā)過程必須遵循的指導原則,需求規(guī)格說明,目標 (1) 用戶通過需求規(guī)格說明可初步判定目標軟件能否滿足需求，設計人員將需求規(guī)格說明作為軟件設計的基礎 (2)支持目標軟件系統(tǒng)的確認，需求規(guī)格說明的各項需求應該是可測試的 (3)控制系統(tǒng)進化過程，需求分析完成后，如果用戶追加需求，開發(fā)人員再次進行需求分析，擴充需求規(guī)格說明，進行軟件設計等,需求規(guī)格說明,內容 功能、行為需求 描述系統(tǒng)的輸入、輸出及相互關系 非行為需求 描述軟件系統(tǒng)工作時應具備的各種屬性，如效率、可靠性、安全性、可維護性、可移植性等 為使需求規(guī)格說明更加簡潔，其它內容不應寫入，如人員、成本、進度、設計方案、質量控制等。這些內容單獨形成文檔,需求規(guī)格說明,1 引言 1.1 需求規(guī)格說明的目的 1.2 軟件產品的作用范圍 1.3 定義、同義詞與縮寫 1.4 參考文獻 1.5 需求規(guī)格說明概覽 2 一般性描述 2.1 產品與其環(huán)境之間的關 2.2 產品功能,2.3 用戶特征 2.4 限制與約束 2.5 假設與前提條件 3 特殊需求 附錄 索引,特殊需求描述,3 特殊需求 3.1 功能或行為需求 3.1.1 功能或行為需求1 3.1.1.1 引言 3.1.1.2 輸入 3.1.1.3 處理過程描述 3.1.1.4 輸出 3.1.2 功能或行為需求2 3.1.n 功能或行為需求n 3.2 外部界面需求 3.2.1 用戶界面 3.2.2 硬件界面 3.2.3 軟件界面,3.3 性能需求 3.4 設計約束 3.4.1 標準化約束 3.4.2 硬件約束 3.5 屬性 3.5.1 可用性 3.5.2安全性 3.5.3 可維護性 3.5.4 可移植性 3.6 其它需求 3.6.1 數(shù)據庫需求 3.6.2 用戶操作需求 3.6.3 工作場地需求,需求評審,需求規(guī)格說明進入設計階段之前，必須進行評審。如果發(fā)現(xiàn)錯誤或缺陷，應及時糾正或更改需求分析、模型，需求規(guī)格說明，并重新評審。 衡量需求規(guī)格說明的標準 正確性 無歧義性 完全性 可驗證性 一致性 可理解性 可修改性 可追蹤性,需求評審,(1)正確性。需求規(guī)格說明書的功能、行為、性能描述必須與用戶對目標軟件產品的期望相吻合。 (2)無歧義性。需求規(guī)格說明的任何語法單位只能有唯一的語義解釋。確保無歧義性的一種有效措施是在需求規(guī)格說明中使用標準化術語，并對術語的語義進行顯式的、統(tǒng)一解釋。 (3)完全性。需求規(guī)格說明書不能遺漏