軟件需求分析與總體設計課件

軟件需求分析與總體設計講座教師：殷鋒博士西南民族大學圖書館副館長西南民族大學計算機科學與技術(shù)學院教授（原副院長）軟件需求分析與總體設計講座教師：殷鋒博士1需求工程概述2需求分析及其任務3獲取需求的方法4需求分析與軟件設計的關(guān)系5規(guī)格說明的工具（實體－聯(lián)系圖、數(shù)據(jù)規(guī)范化、狀態(tài)轉(zhuǎn)換圖、其它圖形工具）6驗證軟件需求軟件需求分析1需求工程概述軟件需求分析

1需求工程概述

需求工程是指應用已證實有效的技術(shù)、方法進行需求分析，確定客戶需求，幫助分析人員理解問題并定義目標系統(tǒng)的所有外部特征的一門學科。需求工程的活動：需求獲取需求建模形成需求規(guī)格（規(guī)約）需求驗證需求管理1需求工程概述需求工程是指應用已證實有效的技需求工程的層次分解示意圖

需求工程

需求活動

需求管理

問題獲取分析編寫規(guī)格說明

驗證需求工程的層次分解示意圖需求工程需求活動需求管理2需求分析及其任務

準確地定義未來系統(tǒng)的目標，確定為了滿足用戶的需求，系統(tǒng)必須要做的工作和應完成的功能。然后以《需求規(guī)格說明書》的形式準確、規(guī)范地表達用戶的需求。2需求分析及其任務需求分析的步驟需求獲取需求提煉：分析建模(通過數(shù)學建模、有窮狀態(tài)機、Z語言、Petri網(wǎng)等形式或半形式化方法導出軟件的邏輯模型)需求描述：編寫《需求規(guī)格說明書》需求驗證需求分析的步驟需求獲取軟件需求分析的幾個階段問題分析問題評估和方案綜合建模規(guī)約復審注意：軟件“系統(tǒng)分析員”的主要工作焦點是“做什么(what)”，不是“怎樣做(how)”。軟件需求分析的幾個階段問題分析（1）確定對系統(tǒng)的綜合要求功能需求性能需求可靠性和可用性需求出錯處理需求接口需求約束逆向需求將來可能的需求（2）

分析系統(tǒng)的數(shù)據(jù)要求（3）

導出系統(tǒng)的邏輯模型（4）修正系統(tǒng)開發(fā)計劃軟件需求分析的重要內(nèi)容（1）確定對系統(tǒng)的綜合要求軟件需求分析的重要內(nèi)容3需求獲取需求獲取的目的

清楚地理解所要解決的問題完整地獲取用戶需求3需求獲取需求獲取的目的需求獲取面臨的挑戰(zhàn)：(1)問題空間理解；(2)人與人之間的通信與交流困難；(3)需求隨著時間的不斷變化。需求獲取面臨的挑戰(zhàn)：(1)問題空間理解；需求獲取的方法訪談面向數(shù)據(jù)流自頂向下求精簡易的應用規(guī)格說明書快速建立軟件原型需求獲取的方法訪談某出版社系統(tǒng)調(diào)查表編號提出問題1您在哪個部門工作？2出版業(yè)務流程是什么？3您每日都處理那些文件、數(shù)據(jù)、報表？4工作中手工處理特別麻煩的事情是什么？5工作中手工處理什么問題解決不了？影響效率的問題有哪些？6您認為提高工作效率，節(jié)省工作時間，減輕工作強度可采取哪些辦法？某出版社系統(tǒng)調(diào)查表編號提出問題1您在哪個部門工作？2出版業(yè)務某出版社系統(tǒng)調(diào)查表編號提出問題7您的部門需要成本核算和統(tǒng)計的內(nèi)容有哪些？8您的部門采用計算機管理工作情況如何？9如何改進業(yè)務流程使之更合理？10哪些問題是目前傳統(tǒng)手工方法根本無法解決的？11出版社計算機管理信息系統(tǒng)需要解決什么問題？某出版社系統(tǒng)調(diào)查表編號提出問題7您的部門需要成本核算和統(tǒng)計的需求所要獲取的內(nèi)容

（1）用戶需求分類

1)功能性需求:

定義系統(tǒng)需要做什么（描述系統(tǒng)必須支持的功能和過程）；

2)非功能性需求（技術(shù)需求）:

定義系統(tǒng)工作時的特性（描述操作環(huán)境和性能目標）。需求所要獲取的內(nèi)容（1）用戶需求分類兩類需求應包括的具體內(nèi)容1)功能2)性能3)環(huán)境4)界面5)用戶或人的因素6)文檔7)數(shù)據(jù)8)資源9)安全保密10)軟件成本消耗與開發(fā)進度11)質(zhì)量保證兩類需求應包括的具體內(nèi)容1)功能1)功能需求

系統(tǒng)做什么？系統(tǒng)何時做什么？系統(tǒng)何時及如何修改或升級？1)功能需求系統(tǒng)做什么？2)性能需求

軟件開發(fā)的技術(shù)性指標例如：存儲容量限制執(zhí)行速度、相應時間吞吐量2)性能需求軟件開發(fā)的技術(shù)性指標3)環(huán)境需求

硬件設備：機型、外設、接口、地點、分布、溫度、濕度、磁場干擾等軟件：操作系統(tǒng)網(wǎng)絡數(shù)據(jù)庫3)環(huán)境需求硬件設備：機型、外設、接口、4)界面需求

有來自其它系統(tǒng)的輸入嗎？到自其它系統(tǒng)的輸出嗎？對數(shù)據(jù)格式有規(guī)定嗎？對數(shù)據(jù)存儲介質(zhì)有規(guī)定嗎？4)界面需求有來自其它系統(tǒng)的輸入嗎？5)用戶或人的因素

用戶類型？各種用戶熟練程度？需受何種訓練？用戶理解、使用系統(tǒng)的難度？用戶錯誤操作系統(tǒng)的可能性？5)用戶或人的因素用戶類型？6)文檔需求

需哪些文檔？文檔針對哪些讀者？6)文檔需求需哪些文檔？7)數(shù)據(jù)需求

輸入、輸出數(shù)據(jù)的格式？接收、發(fā)送數(shù)據(jù)的頻率？數(shù)據(jù)的準確性和精度？數(shù)據(jù)流量？數(shù)據(jù)需保持的時間？7)數(shù)據(jù)需求輸入、輸出數(shù)據(jù)的格式？8)資源需求

軟件運行時所需的數(shù)據(jù)、軟件。內(nèi)存空間等資源。軟件開發(fā)、維護所需的人力、支撐軟件、開發(fā)設備等。8)資源需求軟件運行時所需的數(shù)據(jù)、軟件。9)安全保密要求

需對訪問系統(tǒng)或系統(tǒng)信息加以控制嗎？如何隔離用戶之間的數(shù)據(jù)？用戶程序如何與其它程序和操作系統(tǒng)隔離？系統(tǒng)備份要求？9)安全保密要求需對訪問系統(tǒng)或系統(tǒng)信息加以控10)軟件成本消耗與開發(fā)進度需求開發(fā)有規(guī)定的時間表嗎？軟硬件投資有無限制？10)軟件成本消耗與開發(fā)進度需求開發(fā)有規(guī)定的時間表嗎？11)質(zhì)量保證

系統(tǒng)的可靠性要求？系統(tǒng)必須監(jiān)測和隔離錯誤嗎？規(guī)定系統(tǒng)平均出錯時間？出錯后，重啟系統(tǒng)允許的時間？系統(tǒng)變化如何反映到設計中？維護是否包括對系統(tǒng)的改進？系統(tǒng)的可移植性？11)質(zhì)量保證系統(tǒng)的可靠性要求？分析方法與方案綜合分析員從數(shù)據(jù)流向數(shù)據(jù)結(jié)構(gòu)出發(fā)，逐步細化所有的軟件功能，找出系統(tǒng)各元素之間的聯(lián)系、接口特性和設計上的限制，分析它們是否滿足功能要求，是否合理。依據(jù)功能需求、性能需求運行環(huán)境需求等，剔除其不合理的部分，增加其需要部分。最終合成系統(tǒng)的解決方案，給出目標系統(tǒng)的詳細邏輯模型。常用的分析方法有SA、JSD、OOA分析方法與方案綜合分析員從數(shù)據(jù)流向數(shù)據(jù)結(jié)構(gòu)出發(fā)，逐步細化所有4需求分析與軟件設計的關(guān)系需求分析：系統(tǒng)需要做什么

(對問題的調(diào)查與描述)軟件設計：系統(tǒng)如何做

(邏輯解決方案)當前的需求使我們考慮選擇某種設計選項選擇設計選項可能引發(fā)新的需求需求分析與軟件設計的界限：存在、模糊、迭代4需求分析與軟件設計的關(guān)系需求分析：系統(tǒng)需要做什么軟件設計需求的類型需求類型軟件需求設計約束功能性需求非功能性需求父需求子需求1子需求2子需求3例：父需求：系統(tǒng)安全性使用行業(yè)標準子需求1：數(shù)據(jù)安全性采用事務日志鏡象方法。子需求2：數(shù)據(jù)保密性根據(jù)身份等級分配相應數(shù)據(jù)庫存取權(quán)限子需求3：……需求的類型需求類型軟件需求設計約束功能性需求非功能性需求父需需求分析的過程(1)通過對現(xiàn)實環(huán)境的調(diào)查，

獲得當前系統(tǒng)的物理模型

學生學生購書申請購書單發(fā)票領書單書信北107張教務科信北206王會計室信北206李出納員(二實南)趙教材科學生購買教材的實際處理流程—當前系統(tǒng)物理模型需求分析的過程(1)通過對現(xiàn)實環(huán)境的調(diào)查，學學購購書(2)

去掉具體模型中的非本質(zhì)因素，

抽取現(xiàn)實系統(tǒng)的實質(zhì)，抽象出當前系統(tǒng)的邏輯模型。

學生購買教材的邏輯模型學生學生購書申請購書單發(fā)票領書單書審查有效性開發(fā)票開領書單發(fā)書需求分析的過程(2)去掉具體模型中的非本質(zhì)因素，學生購買教材的邏輯模型學需求分析的過程(3)分析當前系統(tǒng)與目標系統(tǒng)的差別，

建立目標系統(tǒng)的邏輯模型

計算機教材管理系統(tǒng)的邏輯模型學生購書單發(fā)票領書單審查并開發(fā)票開領書單無效書單學生需求分析的過程(3)分析當前系統(tǒng)與目標系統(tǒng)的差別，計算機教需求分析過程示意(4)對目標系統(tǒng)的邏輯模型進行改進與優(yōu)化(5)需求分析的驗證

需求分析過程示意(4)對目標系統(tǒng)的邏輯模型進行改進與優(yōu)化需求分析的步驟當前系統(tǒng)目標系統(tǒng)物理模型邏輯模型邏輯模型物理模型模型化抽象化具體化實例化怎么做做什么當前系統(tǒng)目標系統(tǒng)需求定義需求分析的步驟當前目標物理邏輯邏輯物理模型化抽象化具體化實例

邏輯模型和物理模型

模型是對對象系統(tǒng)的形式化的特征抽象，概括性或近似地表示；

構(gòu)造模型的過程是一個抽象、分析的過程。對象系統(tǒng)模型系統(tǒng)抽象（映射）模型應用模型構(gòu)造的過程邏輯模型和物理模型對象模型抽象（映射）模型應用模型

邏輯模型物理模型

(本質(zhì)模型、概念模型)

(實施模型、技術(shù)模型)現(xiàn)行系統(tǒng)目標系統(tǒng)描述重要的業(yè)務功能，無論系統(tǒng)是如何實施的。描述現(xiàn)實系統(tǒng)是如何在物理上實現(xiàn)的。描述新系統(tǒng)的主要業(yè)務功能和用戶新的需求，無論系統(tǒng)應如何實施。描述新系統(tǒng)是如何實施的（包括技術(shù)）。邏輯模型物理模型現(xiàn)目描述重要的業(yè)務3.1需求分析的任務3.2與用戶溝通獲取需求的方法3.3分析建模與規(guī)格說明3.4實體－聯(lián)系圖3.5數(shù)據(jù)規(guī)范化3.6狀態(tài)轉(zhuǎn)換圖3.7其它圖形工具3.8驗證軟件需求3.1需求分析的任務（1）實體－聯(lián)系圖數(shù)據(jù)模型工具數(shù)據(jù)對象屬性聯(lián)系實體－聯(lián)系圖的符號5規(guī)格說明工具（1）實體－聯(lián)系圖數(shù)據(jù)模型工具5規(guī)格說明工具圖3.2某校教學管理ER圖軟件需求分析與總體設計課件為減少數(shù)據(jù)冗余，避免出現(xiàn)插入異?；騽h除異常，簡化修改數(shù)據(jù)的過程，通常需要把數(shù)據(jù)結(jié)構(gòu)規(guī)范化。通常用“范式(normalforms)”定義消除數(shù)據(jù)冗余的程度。第一范式(1NF)數(shù)據(jù)冗余程度最大，第五范式(5NF)數(shù)據(jù)冗余程度最小。(1)第一范式每個屬性值都必須是原子值，即僅僅是一個簡單值而不含內(nèi)部結(jié)構(gòu)。(2)第二范式滿足第一范式條件，而且每個非關(guān)鍵字屬性都由整個關(guān)鍵字決定(而不是由關(guān)鍵字的一部分來決定)。(3)第三范式符合第二范式的條件，每個非關(guān)鍵字屬性都僅由關(guān)鍵字決定，而且一個非關(guān)鍵字屬性不能僅僅是對另一個非關(guān)鍵字屬性的進一步描述(即一個非關(guān)鍵字屬性值不依賴于另一個非關(guān)鍵字屬性值)。（2）

數(shù)據(jù)規(guī)范化為減少數(shù)據(jù)冗余，避免出現(xiàn)插入異常或刪除異常，簡化修改數(shù)據(jù)的過（3）狀態(tài)轉(zhuǎn)換圖1狀態(tài)：可被觀察到的系統(tǒng)的行為模式2事件：引起系統(tǒng)動作或（和）狀態(tài)轉(zhuǎn)換的控制信息3符號：4例子：下頁（3）狀態(tài)轉(zhuǎn)換圖1狀態(tài)：可被觀察到的系統(tǒng)的行為模式圖

狀態(tài)圖中使用的主要符號軟件需求分析與總體設計課件1）UML面向?qū)ο蟮姆治雠c設計(OOA&D)方法的發(fā)展在80年代末至90年代中出現(xiàn)了一個高潮,UML是這個高潮的產(chǎn)物。它不僅統(tǒng)一了Booch、Rumbaugh和Jacobson的表示方法,而且對其作了進一步的發(fā)展,并最終統(tǒng)一為大眾所接受的標準建模語言。

其它圖形工具1）UML面向?qū)ο蟮姆治雠c設計(OOA&D)方法的發(fā)展在8面向?qū)ο蠹夹g(shù)和UML的發(fā)展過程可用下圖來表示,標準建模語言的出現(xiàn)是其重要成果。在美國,截止1996年10月,UML獲得了工業(yè)界、科技界和應用界的廣泛支持,已有700多個公司表示支持采用UML作為建模語言。1996年底,UML已穩(wěn)占面向?qū)ο蠹夹g(shù)市場的85%,成為可視化建模語言事實上的工業(yè)標準。1997年11月17日,OMG采納UML1.1作為基于面向?qū)ο蠹夹g(shù)的標準建模語言。UML代表了面向?qū)ο蠓椒ǖ能浖_發(fā)技術(shù)的發(fā)展方向,具有巨大的市場前景,也具有重大的經(jīng)濟價值和國防價值。面向?qū)ο蠹夹g(shù)和UML的發(fā)展過程可用下圖來表示,標準建模語言的軟件需求分析與總體設計課件作為一種建模語言,UML的定義包括UML語義和UML表示法兩個部分。

(1)UML語義描述基于UML的精確元模型定義。元模型為UML的所有元素在語法和語義上提供了簡單、一致、通用的定義性說明,使開發(fā)者能在語義上取得一致,消除了因人而異的最佳表達方法所造成的影響。此外UML還支持對元模型的擴展定義。

(2)UML表示法定義UML符號的表示法,為開發(fā)者或開發(fā)工具使用這些圖形符號和文本語法為系統(tǒng)建模提供了標準。這些圖形符號和文字所表達的是應用級的模型,在語義上它是UML元模型的實例。作為一種建模語言,UML的定義包括UML語義和UML表示法兩標準建模語言UML的重要內(nèi)容可以由下列五類圖(共9種圖形)來定義:

·第一類是用例圖,從用戶角度描述系統(tǒng)功能,并指出各功能的操作者。

·第二類是靜態(tài)圖(Staticdiagram),包括類圖、對象圖和包圖。其中類圖描述系統(tǒng)中類的靜態(tài)結(jié)構(gòu)。不僅定義系統(tǒng)中的類,表示類之間的聯(lián)系如關(guān)聯(lián)、依賴、聚合等,也包括類的內(nèi)部結(jié)構(gòu)(類的屬性和操作)。類圖描述的是一種靜態(tài)關(guān)系,在系統(tǒng)的整個生命周期都是有效的。對象圖是類圖的實例,幾乎使用與類圖完全相同的標識。他們的不同點在于對象圖顯示類的多個對象實例,而不是實際的類。一個對象圖是類圖的一個實例。由于對象存在生命周期,因此對象圖只能在系統(tǒng)某一時間段存在。包由包或類組成,表示包與包之間的關(guān)系。包圖用于描述系統(tǒng)的分層結(jié)構(gòu)。標準建模語言UML的重要內(nèi)容可以由下列五類圖(共9種圖形)來

·第三類是行為圖(Behaviordiagram),描述系統(tǒng)的動態(tài)模型和組成對象間的交互關(guān)系。其中狀態(tài)圖描述類的對象所有可能的狀態(tài)以及事件發(fā)生時狀態(tài)的轉(zhuǎn)移條件。通常,狀態(tài)圖是對類圖的補充。在實用上并不需要為所有的類畫狀態(tài)圖,僅為那些有多個狀態(tài)其行為受外界環(huán)境的影響并且發(fā)生改變的類畫狀態(tài)圖。而活動圖描述滿足用例要求所要進行的活動以及活動間的約束關(guān)系,有利于識別并行活動。

·第四類是交互圖(Interactivediagram),描述對象間的交互關(guān)系。其中順序圖顯示對象之間的動態(tài)合作關(guān)系,它強調(diào)對象之間消息發(fā)送的順序,同時顯示對象之間的交互;合作圖描述對象間的協(xié)作關(guān)系,合作圖跟順序圖相似,顯示對象間的動態(tài)合作關(guān)系。除顯示信息交換外,合作圖還顯示對象以及它們之間的關(guān)系。如果強調(diào)時間和順序,則使用順序圖;如果強調(diào)上下級關(guān)系,則選擇合作圖。這兩種圖合稱為交互圖。

·第五類是實現(xiàn)圖(Implementationdiagram)。其中構(gòu)件圖描述代碼部件的物理結(jié)構(gòu)及各部件之間的依賴關(guān)系。一個部件可能是一個資源代碼部件、一個二進制部件或一個可執(zhí)行部件。它包含邏輯類或?qū)崿F(xiàn)類的有關(guān)信息。部件圖有助于分析和理解部件之間的相互影響程度?！さ谌愂切袨閳D(Behaviordiagra需求建模實例：某金融貿(mào)易系統(tǒng)用例圖(UML)風險分析交易估計進行交易進行交易接待員酒店系統(tǒng)財務系統(tǒng)需求建模實例：某金融貿(mào)易系統(tǒng)用例圖(UML)風險分析交易估計需求建模實例：用例圖舉例（UML）簽定一份保險單客戶保險銷售人員銷售統(tǒng)計客戶統(tǒng)計需求建模實例：用例圖舉例（UML）簽定一份客戶保險銷銷售統(tǒng)計

需求建模實例：描述客房狀態(tài)的狀態(tài)圖取消預定入住已預訂空閑占用維修維修完成退房換房入住換房？事件創(chuàng)建需求建模實例：描述客房狀態(tài)的狀態(tài)圖取消預定入住已預訂空閑占圖

層次方框圖的一個例子2）層次方框圖（SC圖）2）層次方框圖（SC圖）圖Warnier圖的一個例子3）Warnier圖3）Warnier圖圖IPO圖的一個例子圖4)IPO圖4)IPO圖圖3.8改進的IPO圖的形式軟件需求分析與總體設計課件3.1需求分析的任務3.2與用戶溝通獲取需求的方法3.3分析建模與規(guī)格說明3.4實體－聯(lián)系圖3.5數(shù)據(jù)規(guī)范化3.6狀態(tài)轉(zhuǎn)換圖3.7其它圖形工具3.8驗證軟件需求3.1需求分析的任務6驗證軟件需求

(1)

從哪些方面驗證軟件需求的正確性1)一致性：所有需求必須是一致的，任何一條需求不能和其他需求互相矛盾。2)完整性：需求必須是完整的，規(guī)格說明書應該包括用戶需要的每一個功能或性能。3)現(xiàn)實性：指定的需求應該是用現(xiàn)有的硬件技術(shù)和軟件技術(shù)基本上可以實現(xiàn)的。對硬件技術(shù)的進步可以做些預測，對軟件技術(shù)的進步則很難做出預測，只能從現(xiàn)有技術(shù)水平出發(fā)判斷需求的現(xiàn)實性。4)有效性：必須證明需求是正確有效的，確實能解決用戶面對的問題6驗證軟件需求

(1)從哪些方面驗證軟件需求的正確性1)(2)驗證軟件需求的方法1.驗證需求的一致性2.驗證需求的現(xiàn)實性3.驗證需求的完整性和有效性(2)驗證軟件需求的方法1.驗證需求的一致性OMT方法的特點：

開發(fā)重點在分析階段強調(diào)數(shù)據(jù)結(jié)構(gòu)而不是功能形式化描述能力強開發(fā)步驟的銜接良好重復性的開發(fā)過程OMT方法的特點：開發(fā)重點在分析階段系統(tǒng)分析報告

新系統(tǒng)邏輯方案的建立是：對業(yè)務流程分析整理的結(jié)果對數(shù)據(jù)和數(shù)據(jù)流分析整理的結(jié)果子系統(tǒng)劃分的結(jié)果在具體業(yè)務處理中應建立的管理模型和管理方法對新系統(tǒng)相配套的管理制度和運行體制建立的建議最后寫出系統(tǒng)分析報告系統(tǒng)分析報告新系統(tǒng)邏輯方案的建立是：系統(tǒng)分析報告格式

一：引言部分（名稱，開發(fā)目標，主要功能，開發(fā)背景等）二：現(xiàn)行系統(tǒng)概況

A．現(xiàn)行系統(tǒng)現(xiàn)狀詳細調(diào)查說明：包括組織機構(gòu)圖，系統(tǒng)目標、功能一覽表、業(yè)務流程圖、業(yè)務流量以及存在的薄弱環(huán)節(jié)，數(shù)據(jù)，主要算法等。

B．現(xiàn)行系統(tǒng)分析：用戶需求及主要存在的問題等。三：新系統(tǒng)邏輯方案

1：新系統(tǒng)目標（要求具體）；

2：新系統(tǒng)邏輯模型（數(shù)據(jù)流程圖、數(shù)據(jù)字典、實體關(guān)系圖

)3：新系統(tǒng)功能分析（改進，補充，優(yōu)越之處）；

4：新系統(tǒng)在各個處理環(huán)節(jié)上采用的管理方法、模型；

5：與新系統(tǒng)相配套的管理制度和運行體制的建立；四：下階段工程進度計劃系統(tǒng)分析報告格式一：引言部分（名稱，開發(fā)目標，主要功能，軟件需求說明書(SRS)

(SoftwareRequirementSpecification)

需求分析階段要完成的文檔。

SRS的作用：開發(fā)者與用戶間事實上的技術(shù)合同書開發(fā)者下一步設計和編碼的基礎測試驗收目標系統(tǒng)的依據(jù)軟件需求說明書(SRS)(SoftwareReS

R

S

大

綱

1引言1.1編寫目的1.2背景1.3定義1.4參考資料2任務概述2.1目標2.2用戶的特點2.3假定盒約束3需求規(guī)定3.1對功能的規(guī)定3.2對性能的規(guī)定3.3輸入輸出要求3.4數(shù)據(jù)管理能力要求3.5故障處理要求3.6其他專門要求（GB9385-88）4運行環(huán)境規(guī)定4.1設備4.2支持軟件4.3接口4.4控制S

R

S

大

綱

1引言（GB9385-88）4運行環(huán)境規(guī)軟件需求分析與總體設計講座教師：殷鋒博士西南民族大學圖書館副館長西南民族大學計算機科學與技術(shù)學院教授（原副院長）軟件需求分析與總體設計講座教師：殷鋒博士1需求工程概述2需求分析及其任務3獲取需求的方法4需求分析與軟件設計的關(guān)系5規(guī)格說明的工具（實體－聯(lián)系圖、數(shù)據(jù)規(guī)范化、狀態(tài)轉(zhuǎn)換圖、其它圖形工具）6驗證軟件需求軟件需求分析1需求工程概述軟件需求分析

1需求工程概述

需求工程是指應用已證實有效的技術(shù)、方法進行需求分析，確定客戶需求，幫助分析人員理解問題并定義目標系統(tǒng)的所有外部特征的一門學科。需求工程的活動：需求獲取需求建模形成需求規(guī)格（規(guī)約）需求驗證需求管理1需求工程概述需求工程是指應用已證實有效的技需求工程的層次分解示意圖

需求工程

需求活動

需求管理

問題獲取分析編寫規(guī)格說明

驗證需求工程的層次分解示意圖需求工程需求活動需求管理2需求分析及其任務

準確地定義未來系統(tǒng)的目標，確定為了滿足用戶的需求，系統(tǒng)必須要做的工作和應完成的功能。然后以《需求規(guī)格說明書》的形式準確、規(guī)范地表達用戶的需求。2需求分析及其任務需求分析的步驟需求獲取需求提煉：分析建模(通過數(shù)學建模、有窮狀態(tài)機、Z語言、Petri網(wǎng)等形式或半形式化方法導出軟件的邏輯模型)需求描述：編寫《需求規(guī)格說明書》需求驗證需求分析的步驟需求獲取軟件需求分析的幾個階段問題分析問題評估和方案綜合建模規(guī)約復審注意：軟件“系統(tǒng)分析員”的主要工作焦點是“做什么(what)”，不是“怎樣做(how)”。軟件需求分析的幾個階段問題分析（1）確定對系統(tǒng)的綜合要求功能需求性能需求可靠性和可用性需求出錯處理需求接口需求約束逆向需求將來可能的需求（2）

分析系統(tǒng)的數(shù)據(jù)要求（3）

導出系統(tǒng)的邏輯模型（4）修正系統(tǒng)開發(fā)計劃軟件需求分析的重要內(nèi)容（1）確定對系統(tǒng)的綜合要求軟件需求分析的重要內(nèi)容3需求獲取需求獲取的目的

清楚地理解所要解決的問題完整地獲取用戶需求3需求獲取需求獲取的目的需求獲取面臨的挑戰(zhàn)：(1)問題空間理解；(2)人與人之間的通信與交流困難；(3)需求隨著時間的不斷變化。需求獲取面臨的挑戰(zhàn)：(1)問題空間理解；需求獲取的方法訪談面向數(shù)據(jù)流自頂向下求精簡易的應用規(guī)格說明書快速建立軟件原型需求獲取的方法訪談某出版社系統(tǒng)調(diào)查表編號提出問題1您在哪個部門工作？2出版業(yè)務流程是什么？3您每日都處理那些文件、數(shù)據(jù)、報表？4工作中手工處理特別麻煩的事情是什么？5工作中手工處理什么問題解決不了？影響效率的問題有哪些？6您認為提高工作效率，節(jié)省工作時間，減輕工作強度可采取哪些辦法？某出版社系統(tǒng)調(diào)查表編號提出問題1您在哪個部門工作？2出版業(yè)務某出版社系統(tǒng)調(diào)查表編號提出問題7您的部門需要成本核算和統(tǒng)計的內(nèi)容有哪些？8您的部門采用計算機管理工作情況如何？9如何改進業(yè)務流程使之更合理？10哪些問題是目前傳統(tǒng)手工方法根本無法解決的？11出版社計算機管理信息系統(tǒng)需要解決什么問題？某出版社系統(tǒng)調(diào)查表編號提出問題7您的部門需要成本核算和統(tǒng)計的需求所要獲取的內(nèi)容

（1）用戶需求分類

1)功能性需求:

定義系統(tǒng)需要做什么（描述系統(tǒng)必須支持的功能和過程）；

2)非功能性需求（技術(shù)需求）:

定義系統(tǒng)工作時的特性（描述操作環(huán)境和性能目標）。需求所要獲取的內(nèi)容（1）用戶需求分類兩類需求應包括的具體內(nèi)容1)功能2)性能3)環(huán)境4)界面5)用戶或人的因素6)文檔7)數(shù)據(jù)8)資源9)安全保密10)軟件成本消耗與開發(fā)進度11)質(zhì)量保證兩類需求應包括的具體內(nèi)容1)功能1)功能需求

系統(tǒng)做什么？系統(tǒng)何時做什么？系統(tǒng)何時及如何修改或升級？1)功能需求系統(tǒng)做什么？2)性能需求

軟件開發(fā)的技術(shù)性指標例如：存儲容量限制執(zhí)行速度、相應時間吞吐量2)性能需求軟件開發(fā)的技術(shù)性指標3)環(huán)境需求

硬件設備：機型、外設、接口、地點、分布、溫度、濕度、磁場干擾等軟件：操作系統(tǒng)網(wǎng)絡數(shù)據(jù)庫3)環(huán)境需求硬件設備：機型、外設、接口、4)界面需求

有來自其它系統(tǒng)的輸入嗎？到自其它系統(tǒng)的輸出嗎？對數(shù)據(jù)格式有規(guī)定嗎？對數(shù)據(jù)存儲介質(zhì)有規(guī)定嗎？4)界面需求有來自其它系統(tǒng)的輸入嗎？5)用戶或人的因素

用戶類型？各種用戶熟練程度？需受何種訓練？用戶理解、使用系統(tǒng)的難度？用戶錯誤操作系統(tǒng)的可能性？5)用戶或人的因素用戶類型？6)文檔需求

需哪些文檔？文檔針對哪些讀者？6)文檔需求需哪些文檔？7)數(shù)據(jù)需求

輸入、輸出數(shù)據(jù)的格式？接收、發(fā)送數(shù)據(jù)的頻率？數(shù)據(jù)的準確性和精度？數(shù)據(jù)流量？數(shù)據(jù)需保持的時間？7)數(shù)據(jù)需求輸入、輸出數(shù)據(jù)的格式？8)資源需求

軟件運行時所需的數(shù)據(jù)、軟件。內(nèi)存空間等資源。軟件開發(fā)、維護所需的人力、支撐軟件、開發(fā)設備等。8)資源需求軟件運行時所需的數(shù)據(jù)、軟件。9)安全保密要求

需對訪問系統(tǒng)或系統(tǒng)信息加以控制嗎？如何隔離用戶之間的數(shù)據(jù)？用戶程序如何與其它程序和操作系統(tǒng)隔離？系統(tǒng)備份要求？9)安全保密要求需對訪問系統(tǒng)或系統(tǒng)信息加以控10)軟件成本消耗與開發(fā)進度需求開發(fā)有規(guī)定的時間表嗎？軟硬件投資有無限制？10)軟件成本消耗與開發(fā)進度需求開發(fā)有規(guī)定的時間表嗎？11)質(zhì)量保證

系統(tǒng)的可靠性要求？系統(tǒng)必須監(jiān)測和隔離錯誤嗎？規(guī)定系統(tǒng)平均出錯時間？出錯后，重啟系統(tǒng)允許的時間？系統(tǒng)變化如何反映到設計中？維護是否包括對系統(tǒng)的改進？系統(tǒng)的可移植性？11)質(zhì)量保證系統(tǒng)的可靠性要求？分析方法與方案綜合分析員從數(shù)據(jù)流向數(shù)據(jù)結(jié)構(gòu)出發(fā)，逐步細化所有的軟件功能，找出系統(tǒng)各元素之間的聯(lián)系、接口特性和設計上的限制，分析它們是否滿足功能要求，是否合理。依據(jù)功能需求、性能需求運行環(huán)境需求等，剔除其不合理的部分，增加其需要部分。最終合成系統(tǒng)的解決方案，給出目標系統(tǒng)的詳細邏輯模型。常用的分析方法有SA、JSD、OOA分析方法與方案綜合分析員從數(shù)據(jù)流向數(shù)據(jù)結(jié)構(gòu)出發(fā)，逐步細化所有4需求分析與軟件設計的關(guān)系需求分析：系統(tǒng)需要做什么

(對問題的調(diào)查與描述)軟件設計：系統(tǒng)如何做

(邏輯解決方案)當前的需求使我們考慮選擇某種設計選項選擇設計選項可能引發(fā)新的需求需求分析與軟件設計的界限：存在、模糊、迭代4需求分析與軟件設計的關(guān)系需求分析：系統(tǒng)需要做什么軟件設計需求的類型需求類型軟件需求設計約束功能性需求非功能性需求父需求子需求1子需求2子需求3例：父需求：系統(tǒng)安全性使用行業(yè)標準子需求1：數(shù)據(jù)安全性采用事務日志鏡象方法。子需求2：數(shù)據(jù)保密性根據(jù)身份等級分配相應數(shù)據(jù)庫存取權(quán)限子需求3：……需求的類型需求類型軟件需求設計約束功能性需求非功能性需求父需需求分析的過程(1)通過對現(xiàn)實環(huán)境的調(diào)查，

獲得當前系統(tǒng)的物理模型

學生學生購書申請購書單發(fā)票領書單書信北107張教務科信北206王會計室信北206李出納員(二實南)趙教材科學生購買教材的實際處理流程—當前系統(tǒng)物理模型需求分析的過程(1)通過對現(xiàn)實環(huán)境的調(diào)查，學學購購書(2)

去掉具體模型中的非本質(zhì)因素，

抽取現(xiàn)實系統(tǒng)的實質(zhì)，抽象出當前系統(tǒng)的邏輯模型。

學生購買教材的邏輯模型學生學生購書申請購書單發(fā)票領書單書審查有效性開發(fā)票開領書單發(fā)書需求分析的過程(2)去掉具體模型中的非本質(zhì)因素，學生購買教材的邏輯模型學需求分析的過程(3)分析當前系統(tǒng)與目標系統(tǒng)的差別，

建立目標系統(tǒng)的邏輯模型

計算機教材管理系統(tǒng)的邏輯模型學生購書單發(fā)票領書單審查并開發(fā)票開領書單無效書單學生需求分析的過程(3)分析當前系統(tǒng)與目標系統(tǒng)的差別，計算機教需求分析過程示意(4)對目標系統(tǒng)的邏輯模型進行改進與優(yōu)化(5)需求分析的驗證

需求分析過程示意(4)對目標系統(tǒng)的邏輯模型進行改進與優(yōu)化需求分析的步驟當前系統(tǒng)目標系統(tǒng)物理模型邏輯模型邏輯模型物理模型模型化抽象化具體化實例化怎么做做什么當前系統(tǒng)目標系統(tǒng)需求定義需求分析的步驟當前目標物理邏輯邏輯物理模型化抽象化具體化實例

邏輯模型和物理模型

模型是對對象系統(tǒng)的形式化的特征抽象，概括性或近似地表示；

構(gòu)造模型的過程是一個抽象、分析的過程。對象系統(tǒng)模型系統(tǒng)抽象（映射）模型應用模型構(gòu)造的過程邏輯模型和物理模型對象模型抽象（映射）模型應用模型

邏輯模型物理模型

(本質(zhì)模型、概念模型)

(實施模型、技術(shù)模型)現(xiàn)行系統(tǒng)目標系統(tǒng)描述重要的業(yè)務功能，無論系統(tǒng)是如何實施的。描述現(xiàn)實系統(tǒng)是如何在物理上實現(xiàn)的。描述新系統(tǒng)的主要業(yè)務功能和用戶新的需求，無論系統(tǒng)應如何實施。描述新系統(tǒng)是如何實施的（包括技術(shù)）。邏輯模型物理模型現(xiàn)目描述重要的業(yè)務3.1需求分析的任務3.2與用戶溝通獲取需求的方法3.3分析建模與規(guī)格說明3.4實體－聯(lián)系圖3.5數(shù)據(jù)規(guī)范化3.6狀態(tài)轉(zhuǎn)換圖3.7其它圖形工具3.8驗證軟件需求3.1需求分析的任務（1）實體－聯(lián)系圖數(shù)據(jù)模型工具數(shù)據(jù)對象屬性聯(lián)系實體－聯(lián)系圖的符號5規(guī)格說明工具（1）實體－聯(lián)系圖數(shù)據(jù)模型工具5規(guī)格說明工具圖3.2某校教學管理ER圖軟件需求分析與總體設計課件為減少數(shù)據(jù)冗余，避免出現(xiàn)插入異?；騽h除異常，簡化修改數(shù)據(jù)的過程，通常需要把數(shù)據(jù)結(jié)構(gòu)規(guī)范化。通常用“范式(normalforms)”定義消除數(shù)據(jù)冗余的程度。第一范式(1NF)數(shù)據(jù)冗余程度最大，第五范式(5NF)數(shù)據(jù)冗余程度最小。(1)第一范式每個屬性值都必須是原子值，即僅僅是一個簡單值而不含內(nèi)部結(jié)構(gòu)。(2)第二范式滿足第一范式條件，而且每個非關(guān)鍵字屬性都由整個關(guān)鍵字決定(而不是由關(guān)鍵字的一部分來決定)。(3)第三范式符合第二范式的條件，每個非關(guān)鍵字屬性都僅由關(guān)鍵字決定，而且一個非關(guān)鍵字屬性不能僅僅是對另一個非關(guān)鍵字屬性的進一步描述(即一個非關(guān)鍵字屬性值不依賴于另一個非關(guān)鍵字屬性值)。（2）

數(shù)據(jù)規(guī)范化為減少數(shù)據(jù)冗余，避免出現(xiàn)插入異?；騽h除異常，簡化修改數(shù)據(jù)的過（3）狀態(tài)轉(zhuǎn)換圖1狀態(tài)：可被觀察到的系統(tǒng)的行為模式2事件：引起系統(tǒng)動作或（和）狀態(tài)轉(zhuǎn)換的控制信息3符號：4例子：下頁（3）狀態(tài)轉(zhuǎn)換圖1狀態(tài)：可被觀察到的系統(tǒng)的行為模式圖

狀態(tài)圖中使用的主要符號軟件需求分析與總體設計課件1）UML面向?qū)ο蟮姆治雠c設計(OOA&D)方法的發(fā)展在80年代末至90年代中出現(xiàn)了一個高潮,UML是這個高潮的產(chǎn)物。它不僅統(tǒng)一了Booch、Rumbaugh和Jacobson的表示方法,而且對其作了進一步的發(fā)展,并最終統(tǒng)一為大眾所接受的標準建模語言。

其它圖形工具1）UML面向?qū)ο蟮姆治雠c設計(OOA&D)方法的發(fā)展在8面向?qū)ο蠹夹g(shù)和UML的發(fā)展過程可用下圖來表示,標準建模語言的出現(xiàn)是其重要成果。在美國,截止1996年10月,UML獲得了工業(yè)界、科技界和應用界的廣泛支持,已有700多個公司表示支持采用UML作為建模語言。1996年底,UML已穩(wěn)占面向?qū)ο蠹夹g(shù)市場的85%,成為可視化建模語言事實上的工業(yè)標準。1997年11月17日,OMG采納UML1.1作為基于面向?qū)ο蠹夹g(shù)的標準建模語言。UML代表了面向?qū)ο蠓椒ǖ能浖_發(fā)技術(shù)的發(fā)展方向,具有巨大的市場前景,也具有重大的經(jīng)濟價值和國防價值。面向?qū)ο蠹夹g(shù)和UML的發(fā)展過程可用下圖來表示,標準建模語言的軟件需求分析與總體設計課件作為一種建模語言,UML的定義包括UML語義和UML表示法兩個部分。

(1)UML語義描述基于UML的精確元模型定義。元模型為UML的所有元素在語法和語義上提供了簡單、一致、通用的定義性說明,使開發(fā)者能在語義上取得一致,消除了因人而異的最佳表達方法所造成的影響。此外UML還支持對元模型的擴展定義。

(2)UML表示法定義UML符號的表示法,為開發(fā)者或開發(fā)工具使用這些圖形符號和文本語法為系統(tǒng)建模提供了標準。這些圖形符號和文字所表達的是應用級的模型,在語義上它是UML元模型的實例。作為一種建模語言,UML的定義包括UML語義和UML表示法兩標準建模語言UML的重要內(nèi)容可以由下列五類圖(共9種圖形)來定義:

·第一類是用例圖,從用戶角度描述系統(tǒng)功能,并指出各功能的操作者。

·第二類是靜態(tài)圖(Staticdiagram),包括類圖、對象圖和包圖。其中類圖描述系統(tǒng)中類的靜態(tài)結(jié)構(gòu)。不僅定義系統(tǒng)中的類,表示類之間的聯(lián)系如關(guān)聯(lián)、依賴、聚合等,也包括類的內(nèi)部結(jié)構(gòu)(類的屬性和操作)。類圖描述的是一種靜態(tài)關(guān)系,在系統(tǒng)的整個生命周期都是有效的。對象圖是類圖的實例,幾乎使用與類圖完全相同的標識。他們的不同點在于對象圖顯示類的多個對象實例,而不是實際的類。一個對象圖是類圖的一個實例。由于對象存在生命周期,因此對象圖只能在系統(tǒng)某一時間段存在。包由包或類組成,表示包與包之間的關(guān)系。包圖用于描述系統(tǒng)的分層結(jié)構(gòu)。標準建模語言UML的重要內(nèi)容可以由下列五類圖(共9種圖形)來

·第三類是行為圖(Behaviordiagram),描述系統(tǒng)的動態(tài)模型和組成對象間的交互關(guān)系。其中狀態(tài)圖描述類的對象所有可能的狀態(tài)以及事件發(fā)生時狀態(tài)的轉(zhuǎn)移條件。通常,狀態(tài)圖是對類圖的補充。在實用上并不需要為所有的類畫狀態(tài)圖,僅為那些有多個狀態(tài)其行為受外界環(huán)境的影響并且發(fā)生改變的類畫狀態(tài)圖。而活動圖描述滿足用例要求所要進行的活動以及活動間的約束關(guān)系,有利于識別并行活動。

·第四類是交互圖(Interactivediagram),描述對象間的交互關(guān)系。其中順序圖顯示對象之間的動態(tài)合作關(guān)系,它強調(diào)對象之間消息發(fā)送的順序,同時顯示對象之間的交互;合作圖描述對象間的協(xié)作關(guān)系,合作圖跟順序圖相似,顯示對象間的動態(tài)合作關(guān)系。除顯示信息交換外,合作圖還顯示對象以及它們之間的關(guān)系。如果強調(diào)時間和順序,則使用順序圖;如果強調(diào)上下級關(guān)系,則選擇合作圖。這兩種圖合稱為交互圖。

·第五類是實現(xiàn)圖(Implementationdiagram)。其中構(gòu)件圖描述代碼部件的物理結(jié)構(gòu)及各部件之間的依賴關(guān)系。一個部件可能是一個資源代碼部件、一個二進制部件或一個可執(zhí)行部件。它包含邏輯類或?qū)崿F(xiàn)類的有關(guān)信息。部件圖有助于分析和理解部件之間的相互影響程度?！さ谌愂切袨閳D(Behaviordiagra需求建模實例：某金融貿(mào)易系統(tǒng)用例圖(UML)風險分析交易估計進行交易進行交易接待員酒店系統(tǒng)財務系統(tǒng)需求建模實例：某金融貿(mào)易系統(tǒng)用例圖(UML)風險分析交易估計需求建模實例：用例圖舉例（UML）簽定一份保險單