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