軟件工程第3章_需求_第1頁
軟件工程第3章_需求_第2頁
軟件工程第3章_需求_第3頁
軟件工程第3章_需求_第4頁
軟件工程第3章_需求_第5頁
已閱讀5頁,還剩47頁未讀 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領(lǐng)

文檔簡介

1、 需求分析是軟件定義時期的最后一個階段,它的需求分析是軟件定義時期的最后一個階段,它的基本任務(wù)基本任務(wù)不是確定系統(tǒng)怎樣完成不是確定系統(tǒng)怎樣完成它的工作,它的工作,而是而是確定系統(tǒng)必須完成確定系統(tǒng)必須完成哪些工作,也就是對目標系統(tǒng)哪些工作,也就是對目標系統(tǒng)提出完整、準確、清晰、具體的要求。并在需求提出完整、準確、清晰、具體的要求。并在需求分析階段結(jié)束之前,由系統(tǒng)分析員寫出軟件需求分析階段結(jié)束之前,由系統(tǒng)分析員寫出軟件需求規(guī)格說明書,以書面形式準確地描述軟件需求。規(guī)格說明書,以書面形式準確地描述軟件需求。即:即: - - 準確地回答準確地回答“系統(tǒng)必須做什么系統(tǒng)必須做什么?”?” 在分析軟件需求和

2、書寫軟件需求規(guī)格在分析軟件需求和書寫軟件需求規(guī)格說明書的過程中,分析員和用戶都起說明書的過程中,分析員和用戶都起著關(guān)鍵的、必不可少的作用。著關(guān)鍵的、必不可少的作用。 1.1.什么是軟件需求分析?什么是軟件需求分析? 2.2.軟件需求分析的任務(wù)是什么?軟件需求分析的任務(wù)是什么? 3.3.需求分析過程需求分析過程/ /步驟步驟 4.4.軟件需求分析方法軟件需求分析方法 對系統(tǒng)應(yīng)該提供的服務(wù)和所受到的約束進行理解、對系統(tǒng)應(yīng)該提供的服務(wù)和所受到的約束進行理解、分析、建立文檔、檢驗的過程;分析、建立文檔、檢驗的過程; 是系統(tǒng)分析人員和用戶共同協(xié)商,明確系統(tǒng)的全是系統(tǒng)分析人員和用戶共同協(xié)商,明確系統(tǒng)的全部

3、功能、性能以及運行規(guī)格,并且使用軟件開發(fā)部功能、性能以及運行規(guī)格,并且使用軟件開發(fā)人員和用戶都能理解的語言準確表達出來。人員和用戶都能理解的語言準確表達出來。 軟件需求無疑是當(dāng)前軟件工程中的關(guān)鍵問題,軟件需求無疑是當(dāng)前軟件工程中的關(guān)鍵問題,。因而,需求分析是軟件開發(fā)的基礎(chǔ),所因而,需求分析是軟件開發(fā)的基礎(chǔ),所產(chǎn)生的需求規(guī)格說明書是以后各階段開發(fā)工作的依據(jù)。產(chǎn)生的需求規(guī)格說明書是以后各階段開發(fā)工作的依據(jù)。 美國于美國于19951995年開始對全國范圍內(nèi)的年開始對全國范圍內(nèi)的80008000個軟件項目進個軟件項目進行跟蹤調(diào)查。行跟蹤調(diào)查。 分析失敗的原因發(fā)現(xiàn),分析失敗的原因發(fā)現(xiàn),與需求過程相關(guān)的原

4、因占了與需求過程相關(guān)的原因占了45%45%,而其中,而其中各占各占13%13%和和12%12%。 未完成未完成完成未實施完成未實施 需求分析的重要性 軟件開發(fā)的基礎(chǔ)和前提 最終目標軟件系統(tǒng)驗收的標準 避免或者盡早剔除早期的錯誤軟件需求是軟件工程中最復(fù)雜的過程之一:應(yīng)用領(lǐng)域的廣泛性,它的實施無疑與各個應(yīng)用行業(yè)的特征密切相關(guān)。非功能性需求建模技術(shù)的缺乏,及其與功能性需求有著錯綜復(fù)雜的聯(lián)系,大大增加了需求工程的復(fù)雜性。溝通上的困難,由于系統(tǒng)分析員、需求分析員等各方面人員有不同的著眼點和不同的知識背景,給需求工程的實施增加了人為的難度。 需求分析的復(fù)雜性和面臨的困難片面, 不完全模糊, 不準確不一致,

5、 歧義需求復(fù)雜和龐大 因此必須使用系統(tǒng)的方法、借助于一系列行之有效的技術(shù)和工具進行軟件需求分析 需求內(nèi)容一般包括:軟軟 件需件需 求求用用 戶需戶需 求求系系 統(tǒng)需統(tǒng)需 求求功能功能需求需求非功能非功能需求需求領(lǐng)域領(lǐng)域需求需求由客戶管理員、由客戶管理員、用戶等提出用戶等提出軟件需求的內(nèi)容軟件需求的內(nèi)容軟件需求內(nèi)容軟件需求內(nèi)容非功能需求非功能需求產(chǎn)品需求產(chǎn)品需求機構(gòu)需求機構(gòu)需求外部需求外部需求互操作互操作需求需求道德道德需求需求立法立法需求需求性能性能需求需求空間空間需求需求交付交付需求需求實現(xiàn)實現(xiàn)需求需求標準標準需求需求隱私隱私需求需求安全安全性需求性需求可用性可用性需求需求效率效率需求需求可

6、靠性可靠性需求需求可移植可移植性需求性需求 需求分析的任務(wù)通過對應(yīng)用問題及其環(huán)境的理解和分析,準確、一致和完全地刻劃用戶需求,形成軟件需求規(guī)格說明書( SRS: Software Requirement Specification )。借助于當(dāng)前系統(tǒng)的邏輯模型導(dǎo)出目標系統(tǒng)的邏輯模型,解決目標系統(tǒng)的 “做什么” 的問題。 需求分析階段(需求分析過程)的基本活動獲取和理解用戶需求。深入實際,在充分理解用戶需求的基礎(chǔ)上,獲取系統(tǒng)需求。描述和分析用戶需求。進行需求建模、對模型或原型進行分析。對用戶需求進行評審。確認需求,進化需求。確保需求說明準確、完整地表達系統(tǒng)的主要特性,且客戶的需要總是不斷(連續(xù))

7、增長的 ,進化需求是必要的。 獲取和理解需求獲取和理解需求描述和分析需求描述和分析需求評審用戶需求評審用戶需求需求獲取需求獲取技術(shù)技術(shù)建模、抽象、建模、抽象、多視點、問題多視點、問題分解、原型分解、原型需求評需求評審原則審原則 任務(wù)獲取并理解用戶需求, 清除用戶需求的不一致性,模糊性和歧義性,幫助用戶發(fā)現(xiàn)潛在的需求 原則和用戶進行交流和合作將對原始問題理解與軟件開發(fā)經(jīng)驗結(jié)合 任務(wù)對用戶需求進行建模,生成SRS和初步用戶手冊 SRS:用戶需求(功能, 行為, 性能等)用戶手冊:如何操作和使用目標軟件,界面描述和使用初步構(gòu)想 原則確保SRS的完整性、一致性和準確性鼓勵用戶參與SRS以及用戶手冊的制

8、定盡可能做到SRS結(jié)構(gòu)清晰,措辭準確和簡潔 任務(wù)多方人員一起對SRS進行復(fù)核和評審,以確保用戶手冊和SRS全面、準確、一致地反映用戶需求 原則支持各方(用戶,需求分析人員、設(shè)計人員)共同參與評審工作l 缺乏領(lǐng)域知識缺乏領(lǐng)域知識, ,應(yīng)用領(lǐng)域的問題常常是模糊的、應(yīng)用領(lǐng)域的問題常常是模糊的、不精確的;不精確的;l 存在默認的知識存在默認的知識, ,如難以描述的常識問題;如難以描述的常識問題;l 存在多個知識源存在多個知識源, ,且多知識源之間可能有沖突;且多知識源之間可能有沖突;l 客戶可能的偏見客戶可能的偏見,如不能提供或不想告知你所需,如不能提供或不想告知你所需要了解的事情。要了解的事情。非常

9、困難,主要原因有:非常困難,主要原因有: 訪談訪談 面向數(shù)據(jù)流自頂向下面向數(shù)據(jù)流自頂向下求精求精 簡易的應(yīng)用規(guī)格說明簡易的應(yīng)用規(guī)格說明技術(shù)技術(shù) 快速建立軟件原型快速建立軟件原型 問題域問題域 用戶用戶 需求分析員需求分析員 交流交流 正式的訪談?wù)降脑L談 - 系統(tǒng)分析員將提出一些事先準備好的具體問題。系統(tǒng)分析員將提出一些事先準備好的具體問題。 非正式的訪談非正式的訪談 - 分析員將提出一些用戶可以自由回答的開放性問題,以鼓勵被訪分析員將提出一些用戶可以自由回答的開放性問題,以鼓勵被訪問人員說出自己的想法。問人員說出自己的想法。 當(dāng)需要調(diào)查大量人員的意見時,向被調(diào)查人分發(fā)調(diào)查表是當(dāng)需要調(diào)查大量人

10、員的意見時,向被調(diào)查人分發(fā)調(diào)查表是一個十分有效的做法。一個十分有效的做法。 在訪問用戶的過程中使用情景分析技術(shù)往往非常有效。在訪問用戶的過程中使用情景分析技術(shù)往往非常有效。情景分析技術(shù)的用處主要體現(xiàn)在下述兩個方面:情景分析技術(shù)的用處主要體現(xiàn)在下述兩個方面:(1) (1) 它能在某種程度上演示目標系統(tǒng)的行為,從而便于它能在某種程度上演示目標系統(tǒng)的行為,從而便于用戶理解,而且還可能進一步揭示出一些分析員目前用戶理解,而且還可能進一步揭示出一些分析員目前還不知道的需求。還不知道的需求。(2) (2) 由于情景分析較易為用戶所理解,使用這種技術(shù)能由于情景分析較易為用戶所理解,使用這種技術(shù)能保證用戶在需

11、求分析過程中始終扮演一個積極主動的保證用戶在需求分析過程中始終扮演一個積極主動的角色。需求分析的目標是獲知用戶的真實需求,而這角色。需求分析的目標是獲知用戶的真實需求,而這一信息的唯一來源是用戶,因此,一信息的唯一來源是用戶,因此,讓用戶起積極主動讓用戶起積極主動的作用對需求分析工作獲得成功是至關(guān)重要的。的作用對需求分析工作獲得成功是至關(guān)重要的。 數(shù)據(jù)決定了需要的處理和算法,它是需求分析的出發(fā)點。數(shù)據(jù)決定了需要的處理和算法,它是需求分析的出發(fā)點。 可行性研究階段產(chǎn)生的是高層數(shù)據(jù)流圖,許多具體的細節(jié)可行性研究階段產(chǎn)生的是高層數(shù)據(jù)流圖,許多具體的細節(jié)沒有包括,許多實際的數(shù)據(jù)元素被忽略,當(dāng)時分析員還

12、不沒有包括,許多實際的數(shù)據(jù)元素被忽略,當(dāng)時分析員還不需要考慮這些細節(jié),現(xiàn)在是定義這些數(shù)據(jù)元素的時候了。需要考慮這些細節(jié),現(xiàn)在是定義這些數(shù)據(jù)元素的時候了。自頂向下求精過程自頂向下求精過程 使用傳統(tǒng)的訪談或面向數(shù)據(jù)流自頂向下求精方法定義需求時,用戶處于被動地位而且往往有意無意地與開發(fā)者區(qū)分“彼此”。由于不能像同一個團隊的人那樣齊心協(xié)力地識別和精化需求,這兩種方法的效果有時并不理想。 這種方法提倡用戶與開發(fā)者密切這種方法提倡用戶與開發(fā)者密切合作,共同標識問題,提出解決方案合作,共同標識問題,提出解決方案要素,商討不同方案并指定基本需求。要素,商討不同方案并指定基本需求。1. 1. 初步的訪談,通過用

13、戶對基本問題的回答,初步確定待解決的問題的初步的訪談,通過用戶對基本問題的回答,初步確定待解決的問題的范圍和解決方案。范圍和解決方案。2. 2. 開發(fā)者和用戶分別寫出開發(fā)者和用戶分別寫出“產(chǎn)品需求產(chǎn)品需求”。3. 3. 開發(fā)者和用戶開會討論,共同創(chuàng)建一張意見一致的組合列表。開發(fā)者和用戶開會討論,共同創(chuàng)建一張意見一致的組合列表。4. 4. 把與會者分成更小的小組,每個小組的工作目標是為每張列表中的項把與會者分成更小的小組,每個小組的工作目標是為每張列表中的項目制定小型規(guī)格說明。小型規(guī)格說明是對列表中包含的單詞或短語的目制定小型規(guī)格說明。小型規(guī)格說明是對列表中包含的單詞或短語的準確說明。準確說明。

14、5. 5. 每個小組向全體與會者展示他們制定的小型規(guī)格說明,討論,以創(chuàng)建每個小組向全體與會者展示他們制定的小型規(guī)格說明,討論,以創(chuàng)建出意見一致的確認標準。出意見一致的確認標準。6. 6. 由一名或多名與會者根據(jù)會議成果起草完整的軟件需求規(guī)格說明書。由一名或多名與會者根據(jù)會議成果起草完整的軟件需求規(guī)格說明書。 正如第正如第1 1章已經(jīng)講過的,快速原型就是快速章已經(jīng)講過的,快速原型就是快速建立起來的旨在演示目標系統(tǒng)主要功能的建立起來的旨在演示目標系統(tǒng)主要功能的可運行的程序??蛇\行的程序。 快速建立軟件原型是最準確、最有效、最快速建立軟件原型是最準確、最有效、最強大的需求分析技術(shù)。強大的需求分析技術(shù)

15、。 快速原型應(yīng)具備的特性是快速原型應(yīng)具備的特性是“快速快速”、“容容易修改易修改”。結(jié)構(gòu)化分析方法中的抽象與分解2.42.32.22.121431.31.21.1X結(jié)構(gòu)化分析模型的描述工具數(shù)據(jù)字典是模型的核心,包含軟件使用和產(chǎn)生所有數(shù)據(jù)的描述。數(shù)據(jù)流圖:用于功能建模,描述系統(tǒng)的輸入數(shù)據(jù)流如何經(jīng)過一系列的加工變換逐步變換成系統(tǒng)的輸出數(shù)據(jù)流。ER圖:用于數(shù)據(jù)建模,描述數(shù)據(jù)字典中數(shù)據(jù)之間的關(guān)系。實 體實 體 - 關(guān) 系關(guān) 系圖圖數(shù)據(jù)流圖數(shù)據(jù)流圖狀態(tài)轉(zhuǎn)換圖狀態(tài)轉(zhuǎn)換圖數(shù)數(shù)據(jù)據(jù)字字典典 狀態(tài)轉(zhuǎn)換圖:用于行為建模,描述系統(tǒng)接收哪些外部事件,以及在外部事件的作用下的狀態(tài)遷移情況。 數(shù)據(jù)流圖(Data Flow

16、 Diagram,簡稱DFD)是結(jié)構(gòu)化系統(tǒng)分析的主要工具,它能圖形化地顯示出系統(tǒng)中數(shù)據(jù)的使用,表達數(shù)據(jù)在系統(tǒng)內(nèi)部的邏輯流向以及系統(tǒng)的邏輯功能和數(shù)據(jù)的邏輯變換 數(shù)據(jù)流圖有四種基本符號:數(shù)據(jù)源、數(shù)據(jù)流、加工和數(shù)據(jù)存儲數(shù)據(jù)流圖數(shù)據(jù)流圖數(shù)據(jù)流的畫法示例數(shù)據(jù)流的畫法示例數(shù)據(jù)流圖的建立數(shù)據(jù)流圖的建立自頂向下擴展自頂向下擴展數(shù)據(jù)流圖的建立數(shù)據(jù)流圖的建立自頂向下擴展自頂向下擴展 分層數(shù)據(jù)流圖的審查分層數(shù)據(jù)流圖的審查 檢查圖中是否存在錯誤或不合理檢查圖中是否存在錯誤或不合理( (不理想不理想) )的部分的部分一致性:分層一致性:分層DFDDFD中不存在矛盾和沖突中不存在矛盾和沖突完整性:分層完整性:分層DFDD

17、FD本身的完整性,即是否有遺漏的數(shù)本身的完整性,即是否有遺漏的數(shù)據(jù)流、加工等元素據(jù)流、加工等元素 可從分層可從分層DFDDFD的一致性和完整性、構(gòu)造分層的一致性和完整性、構(gòu)造分層DFDDFD時時需注意的問題以及分解程度等幾個方面來說明如需注意的問題以及分解程度等幾個方面來說明如何審查分層何審查分層DFDDFD的合理性的合理性分層數(shù)據(jù)流圖的一致性父圖與子圖平衡父圖與子圖平衡 任何一張任何一張DFDDFD子圖邊界上的輸入子圖邊界上的輸入/ /輸出數(shù)據(jù)流必須與其父圖輸出數(shù)據(jù)流必須與其父圖中對應(yīng)的加工的輸入中對應(yīng)的加工的輸入/ /輸出數(shù)據(jù)流保持一致輸出數(shù)據(jù)流保持一致數(shù)據(jù)守恒數(shù)據(jù)守恒一個加工所有輸出數(shù)據(jù)流中的數(shù)據(jù),必須能從該加工的輸一個加工所有輸出數(shù)據(jù)流中的數(shù)據(jù),必須能從該加工的輸入數(shù)據(jù)流中直接獲得,或者能通過該加工的處理而產(chǎn)生入數(shù)據(jù)流中直接獲得,或者能通過該加工的處理而產(chǎn)生多余的數(shù)據(jù)流:加工未使用其輸入數(shù)據(jù)流中的某些數(shù)據(jù)項多余的數(shù)據(jù)流:加工未使用其輸入數(shù)據(jù)流中的某些數(shù)據(jù)項 局部文件局部文件 一個加工的輸出數(shù)據(jù)流不能與該加工的輸入數(shù)據(jù)一個加工的輸出數(shù)據(jù)流不能與該加工的輸入數(shù)據(jù)流同名流同名分層數(shù)據(jù)流圖的完整性 每個加工至少有一個輸

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論