軟件工程需求分析

1、軟件工程(Software Engineering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院 魏東 Slide 1第四章第四章需求分析需求分析 軟件工程(Software Engineering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院 魏東 Slide 24.1 需求分析概述l 需求分析的目標(biāo)與任務(wù)l 目標(biāo)：l弄清用戶對系統(tǒng)的細(xì)節(jié)要求，完整、準(zhǔn)確、清晰、具體地回答目標(biāo)系統(tǒng)“做什么”。l 任務(wù)： l是對用戶提出的軟件功能、性能等應(yīng)用問題及其環(huán)境進行分析與理解，采用一系列的分析方法和技術(shù)，把系統(tǒng)分析階段產(chǎn)生的系統(tǒng)規(guī)格說明和項目規(guī)劃逐步精確化、完全化、一

2、致化，借助于當(dāng)前系統(tǒng)的邏輯模型導(dǎo)出目標(biāo)系統(tǒng)邏輯模型，最終形成需求規(guī)格說明文檔的過程。l 具體過程：l需求的獲取、建模、文檔、驗證；軟件工程(Software Engineering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院 魏東 Slide 34.1 需求分析概述l需求開發(fā)是技術(shù)范疇，需求管理是管理范疇。l在軟件工程課里通常講述需求分析是指需求工程當(dāng)中的需求開發(fā)部分l需求分析=需求開發(fā)軟件工程(Software Engineering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院 魏東 Slide 44.1 需求分析概述l 需求分析的必要性l軟件開發(fā)是用

3、戶與開發(fā)者共同參與的過程，項目涉眾人員之間必須經(jīng)過充分交流；l用戶與開發(fā)者的知識領(lǐng)域不同，缺乏共同語言，存在對問題理解的歧義；l軟件開發(fā)失敗的原因大約超過50%是需求不合理而急于編程引起的；l在需求分析階段的錯誤會引起錯誤的放大，后期發(fā)現(xiàn)錯誤時要花費更大的精力修改；軟件工程(Software Engineering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院 魏東 Slide 54.1 需求分析概述需求分析是RUP生命周期的“細(xì)化”階段產(chǎn)產(chǎn)品品目目標(biāo)標(biāo)業(yè)務(wù)建模業(yè)務(wù)建模初始階段初始階段細(xì)化階段細(xì)化階段層面：面向決策層（商務(wù)層面）活動：問題定義；可行性研究人員：領(lǐng)域決策人+領(lǐng)域

4、專家 IT決策人+IT專家層面：面向終端用戶層（應(yīng)用層面） 面向設(shè)計層面（技術(shù)層面）活動：獲取；建模；描述；驗證人員：領(lǐng)域?qū)＜?終端用戶 IT專家（分析師、架構(gòu)師、設(shè)計師）需求建模需求建模軟軟件件結(jié)結(jié)構(gòu)構(gòu)軟件工程(Software Engineering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院 魏東 Slide 64.1 需求分析概述l從問題定義到需求分析是個逐步細(xì)化的過程，到需求分析階段把需求的細(xì)節(jié)搞清楚問題定義可行性研究需求分析軟 件 規(guī) 模、 性 質(zhì) 、約束在 約 束 條件 下 客 戶提 出 的 軟件 的 功 能能否實現(xiàn)軟 件 功 能的 細(xì) 節(jié) 要求對軟件的要實現(xiàn)

5、的功能逐步細(xì)化的過程，前者是后者的子集軟件工程(Software Engineering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院 魏東 Slide 74.1 需求分析概述l 需求分析的參與者 開開 發(fā)發(fā) 方方用用 戶戶 方方分析師分析師需求分析需求分析設(shè)計師設(shè)計師架構(gòu)師架構(gòu)師部門負(fù)責(zé)部門負(fù)責(zé)領(lǐng)域?qū)＜翌I(lǐng)域?qū)＜医K端用戶終端用戶軟件工程(Software Engineering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院 魏東 Slide 84.1 需求分析概述l 需求工程：也稱需求過程或需求階段。l包括了需求開發(fā)和需求管理，所涉及到的具體工作如下圖所示軟

6、件工程(Software Engineering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院 魏東 Slide 94.1 需求分析概述l 任務(wù)講究目標(biāo)，過程要講究方法：l需求獲取（需求提出）l Gathering detailed requirements is the first part of the project lifecycle l問題分析（分析建模）l The analysis phase: Understanding what the customer wants l需求說明（需求文檔）l Capture the right user requirement

7、s with these best practices for writing software specifications l需求驗證（需求評審）l Determine user requirements now to avoid problems later軟件工程(Software Engineering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院 魏東 Slide 104.1 需求分析概述l需求獲取：l 調(diào)查軟件需求，弄清用戶對目標(biāo)軟件系統(tǒng)在功能、性能、行為、設(shè)計約束等方面的期望。l 手段：通過現(xiàn)場調(diào)查、核實、歸納，用自然語言描述。l需求建模：l 是對現(xiàn)實世界進行

8、抽象的過程。通過符號和文字說明描述系統(tǒng)模型使用戶和開發(fā)者間建立共同語言基礎(chǔ)，消除理解上的歧義；l 從原始模型分析找尋目標(biāo)模型，從物理模型過渡到邏輯模型，作為設(shè)計階段的依據(jù)；l 手段：采用建模語言和工具 軟件工程(Software Engineering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院 魏東 Slide 114.1 需求分析概述l 需求說明：l需求說明書是需求分析階段的最終成果，也是需求分析階段復(fù)審的依據(jù)；是用戶領(lǐng)域?qū)＜摇④浖治鰩?、軟件設(shè)計師共同交流的途徑和媒介；是交付給用戶文檔的一部份；l手段：編寫文檔l 需求評審：l根據(jù)需求說明書，對需求的正確性、一致性、

9、l完整性、無二義行進行評審、確認(rèn)。l手段：分析師、設(shè)計師、客戶會審文檔軟件工程(Software Engineering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院 魏東 Slide 124.1 需求分析概述l 需求分析的步驟l需求分析過程：是一個從模糊概念出發(fā)，經(jīng)過分析、綜合評價，到概念逐步清晰的過程。l需求分析過程就是四項任務(wù)的工作流程，一般分四個步驟。l需求分析四個步驟并不遵循線性的順序，這些活動是相互隔開、增量和反復(fù)的。需求獲取需求獲取分析建模分析建模需求描述需求描述需求驗證需求驗證軟件工程(Software Engineering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院

10、沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院 魏東 Slide 134.2 需求獲取l 需求獲取的內(nèi)容分為： l功能性需求:搞清系統(tǒng)做什么；l非功能性需求:定義了系統(tǒng)工作時的特性(環(huán)境、性能、可靠性、安全保密性、成本消耗、資源利用、用戶接口等)；l 需求獲取的特性l需求獲取不是一次完成，不僅僅在分析階段，在問題定義、可行性研究階段都需要，是逐步深化的結(jié)果。l需求獲取是有層次的，不同層面的需求內(nèi)容取自不同的對象，不同層面的需求寫在不同的文檔及章節(jié)里。l需求獲取的內(nèi)容經(jīng)過整理要寫進“需求規(guī)格說明書”的“用戶里，軟件工程(Software Engineering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)信息科

11、學(xué)與工程學(xué)院 魏東 Slide 144.2 需求獲取l 軟件需求的層次軟件工程(Software Engineering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院 魏東 Slide 154.2 需求獲取l軟件需求包括三個不同的層次：業(yè)務(wù)需求；用戶需求；功能需求-也包括非功能需求。l業(yè)務(wù)需求（business requirement）l 反映了組織機構(gòu)或客戶對系統(tǒng)、產(chǎn)品高層次的目標(biāo)要求，它們在項目視圖與范圍文檔中予以說明，通常就是“問題定義”或在SRS中的項目背景、系統(tǒng)目標(biāo)所指（調(diào)查誰？）。l用戶需求(user requirement)l 描述了用戶使用產(chǎn)品必須要完成的任務(wù)

12、，采用業(yè)務(wù)領(lǐng)域的術(shù)語，使用用戶與開發(fā)者都能理解的語言和圖形表達。如結(jié)構(gòu)化的DFD圖+加工說明，面向?qū)ο蟮挠美╱se case）圖+用例腳本（scenario）。它是經(jīng)過調(diào)查、歸納后雙方認(rèn)同的結(jié)果（調(diào)查誰？ ）。l功能需求(functional requirement)l 定義了開發(fā)人員必須實現(xiàn)的軟件功能，用軟件行業(yè)術(shù)語，通常是需求建模的結(jié)果即目標(biāo)系統(tǒng)的邏輯模型，如結(jié)構(gòu)化的功能模型、數(shù)據(jù)模型、行為模型，面向?qū)ο蟮念惸Ｐ偷龋▽懺谀模浚?。l特性(feature)l 是指邏輯上相關(guān)的功能需求的集合，給用戶提供處理能力并滿足業(yè)務(wù)需求（非功能需求）。l例子（P76）軟件工程(Software Engin

13、eering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院 魏東 Slide 164.2 需求獲取l需求獲取方法l需求獲取是調(diào)查研究的結(jié)果，獲取方法以采訪、觀察、座談、對先前的系統(tǒng)版本的測試等。必要時采用快速原型法。l先集中在使用者對系統(tǒng)的觀點上，以收集用戶原始資料，數(shù)據(jù)、工作方式、工作流程、使用要求等為工作起點，深入到部門、車間、班組，做好原始紀(jì)錄；l然后根據(jù)對問題及其環(huán)境的理解與軟件開發(fā)經(jīng)驗，改正用戶需求的模糊性、歧義性和不一致性，排除由于用戶的片面性和短期行為所導(dǎo)致的不合理要求、挖掘用戶尚未提出但具有價值的潛在需求，并在用戶的幫助下對相互沖突的要求進行折衷，使用戶需求逐

14、步精確化、一致化和完全化；l需求獲取不是一次完成，不僅僅在分析階段，在問題定義、可行性研究階段都需要，是往復(fù)進行、逐步深化的結(jié)果。l需求獲取的內(nèi)容經(jīng)過整理形成“用戶需求”最終要寫進“需求規(guī)格說明書”， 結(jié)果由客戶確認(rèn)。l三步法（P77）軟件工程(Software Engineering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院 魏東 Slide 174.3 需求建模l 需求建模的意義l建模就是把客觀世界的領(lǐng)域問題模型化領(lǐng)域問題模型化，通過逐步細(xì)化逐步細(xì)化模型最終映射到計算機世界里。需求建模是模型化的開始。需求模型就是根據(jù)用戶需求建立的目標(biāo)軟件的邏輯模型。需求模型起到承上啟

15、下的作用。l承上：面向用戶，指與領(lǐng)域?qū)＜业臏贤?，反映用戶的需求。通過建立需求模型進一步清除用戶需求的模糊性、歧義性和不一致性，也就是對需求獲取的校驗。如果需求獲取不完整、不清楚，建立模型就會有所反應(yīng)，甚至無法進行。這就要重新調(diào)研，完善需求獲取。l啟下：面向設(shè)計，指需求模型作為設(shè)計階段的輸入，反映系統(tǒng)要實現(xiàn)的功能。模型細(xì)化的下一步就是設(shè)計，設(shè)計的依據(jù)就是這里的需求模型。軟件工程(Software Engineering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院 魏東 Slide 184.3 需求建模l 建模的過程l建模的一般過程l 獲得當(dāng)前系統(tǒng)的物理模型 l 抽象出當(dāng)前系統(tǒng)

16、的邏輯模型。 l 建立目標(biāo)系統(tǒng)的邏輯模型。問題定義、可行性問題定義、可行性( (系統(tǒng)規(guī)格說明系統(tǒng)規(guī)格說明) )需求分析需求分析( (需求規(guī)格說明需求規(guī)格說明) )軟件設(shè)計軟件設(shè)計( (設(shè)計說明設(shè)計說明) )實現(xiàn)實現(xiàn)( (程序代碼程序代碼) )軟件工程(Software Engineering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院 魏東 Slide 194.3 需求建模l 建模的方法l形式化的方法，l 采用嚴(yán)格的數(shù)學(xué)模型，這種方法目前常見的是Z語言和petri網(wǎng)。l非形式化的方法，l 如用自然語言、半形式化語言、圖形符號、表格等方式對需求規(guī)格進行描述。l形式化方法得到的

17、需求模型更加嚴(yán)密和精確，容易過渡到編碼，但往往難以掌握，特別是不易與用戶溝通。l非形式化方法的需求模型更加直觀和易于理解，要通過逐步細(xì)化（映射）到編碼。目前普遍應(yīng)用以非形式化為主。l無論采用形式化還是非形式化的、是傳統(tǒng)的還是現(xiàn)代的分析方法，所遵循的原則是一樣的。軟件工程(Software Engineering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院 魏東 Slide 204.3 需求建模l 非形式化的兩種建模技術(shù)l結(jié)構(gòu)化分析建模 SA （Structured Analysis），又分面向數(shù)據(jù)建模和面向數(shù)據(jù)流建模。l主要應(yīng)用技術(shù)：l數(shù)據(jù)流圖（DFD）；l數(shù)據(jù)字典（DD）

18、；l加工說明（PESPEC）；l實體關(guān)系圖（E-R）；l狀態(tài)變遷圖（STD）等。軟件工程(Software Engineering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院 魏東 Slide 214.3 需求建模l 結(jié)構(gòu)化分析模型的組織結(jié)構(gòu)軟件工程(Software Engineering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院 魏東 Slide 224.3 需求建模l 非形式化的兩種建模技術(shù)l面型對象分析建模OOA（Object-Oriented Analysis）l主要應(yīng)用視圖：l用例圖（Use Case）；l時序圖（Sequence）；l狀態(tài)

19、圖（Statechart）；l類圖（Class）；l構(gòu)件圖（Component）；l部署圖（Deployment）等。軟件工程(Software Engineering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院 魏東 Slide 234.3 需求建模l 面向?qū)ο蠓治瞿Ｐ偷慕M織結(jié)構(gòu)軟件工程(Software Engineering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院 魏東 Slide 244.3 需求建模l 建模過程舉例l通過對現(xiàn)實環(huán)境的調(diào)查，獲得當(dāng)前系統(tǒng)的物理模型教務(wù)科審批2#樓D座304王老師領(lǐng)書申請領(lǐng)書單財務(wù)科交款辦公樓201李老師教材科領(lǐng)

20、書圖書館126楊老師領(lǐng)書單學(xué)生學(xué)生軟件工程(Software Engineering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院 魏東 Slide 254.3 需求建模l去掉具體模型中的非本質(zhì)因素，抽取現(xiàn)實系統(tǒng)的實質(zhì)，抽象出當(dāng)前系統(tǒng)的邏輯模型。學(xué)學(xué)生生學(xué)學(xué)生生購購書書申申請請購購書書單單發(fā)發(fā)票票領(lǐng)領(lǐng)書書單單書書審查審查有效性有效性開發(fā)票開發(fā)票開領(lǐng)開領(lǐng)書單書單發(fā)書發(fā)書軟件工程(Software Engineering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院 魏東 Slide 264.3 需求建模l分析當(dāng)前系統(tǒng)與目標(biāo)系統(tǒng)的差別，建立目標(biāo)系統(tǒng)的邏輯模型（結(jié)

21、構(gòu)化的DFD）學(xué)學(xué)生生購書單購書單發(fā)票發(fā)票領(lǐng)書單領(lǐng)書單審查并審查并開發(fā)票開發(fā)票開領(lǐng)開領(lǐng)書單書單無效書單無效書單學(xué)學(xué)生生軟件工程(Software Engineering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院 魏東 Slide 27審核發(fā)書教師（收款）學(xué)生教師（發(fā)書）收款財務(wù)系統(tǒng)教師（審核）軟件工程(Software Engineering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院 魏東 Slide 28教師（審核）(from Use Case View)領(lǐng)書申請單教師（收款）(from Use Case View)發(fā)票學(xué)生(from Use Ca

22、se View)領(lǐng)書單教師（發(fā)書）(from Use Case View)書籍軟件工程(Software Engineering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院 魏東 Slide 29學(xué)生(from Use Case View)教師教師（審核收款）審核，發(fā)票教師發(fā)書登記發(fā)書軟件工程(Software Engineering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院 魏東 Slide 30填寫領(lǐng)書申請從新填寫審核申請合格？收款開封票形成領(lǐng)書單領(lǐng)取書籍教師（審核收款）學(xué)生 : 學(xué)生提交領(lǐng)書單領(lǐng)取圖書登記圖書發(fā)書教師發(fā)書學(xué)生軟件工程(Softwa

23、re Engineering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院 魏東 Slide 314.3 需求建模l面向?qū)ο蟮哪繕?biāo)系統(tǒng)的邏輯模面向?qū)ο蟮哪繕?biāo)系統(tǒng)的邏輯模型（型（UMLUML用例圖）用例圖）軟件工程(Software Engineering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院 魏東 Slide 324.3 需求建模l 建模原則l必須能夠表達和理解問題的數(shù)據(jù)域和功能域l按自頂向下、逐層分解問題 l要給出系統(tǒng)的邏輯視圖軟件工程(Software Engineering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院 魏東

24、Slide 334.4 需求說明l需求說明的作用lSRS(Software Rrquirement Specification)是需求分析的最終結(jié)果。SRS是軟件項目的一個關(guān)鍵性文檔，主要用來描述待開發(fā)系統(tǒng)所要實現(xiàn)的功能和目標(biāo)，清楚地闡述一個軟件系統(tǒng)必須提供的功能性需求和非功能性需求以及所要考慮的限制條件。 lSRS是用戶、分析人員和設(shè)計人員之間進行理解和交流的手段；lSRS是開發(fā)者與用戶間事實上的技術(shù)合同書，是制定目標(biāo)系統(tǒng)測試和項目驗收計劃的依據(jù)； lSRS是下一步設(shè)計和編碼的基礎(chǔ)，指導(dǎo)著整個系統(tǒng)的開發(fā)過程，如果對評審過的SRS進行任何改動就需要進行變更控制；lSRS是制定初步測試計劃的基礎(chǔ)

25、。lSRS是編寫初步用戶手冊的基礎(chǔ)。軟件工程(Software Engineering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院 魏東 Slide 344.4 需求說明l 需求說明的質(zhì)量要求lSRS要達到質(zhì)量要求，也是需求分析要達到明確(Clear)、 完整(Complete)、 一致(Consistent)、 可測試 (Testable)、可跟蹤（Traceability）、可修改（modifiability）等標(biāo)準(zhǔn)。l 正確性；l 無歧義性；l 完整性；l 一致性；l 重要性/穩(wěn)定性分級；l 可驗證性；l 可修改性；l 可追蹤性；軟件工程(Software Engin

26、eering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院 魏東 Slide 354.4 需求說明l SRS的編寫l在軟件項目中，開發(fā)組織應(yīng)該采用一種標(biāo)準(zhǔn)的軟件需求規(guī)格說明的模板?，F(xiàn)在有許多推薦的軟件需求規(guī)格說明模板可以使用，這里介紹一種由IEEE標(biāo)準(zhǔn)830-1998改寫并擴充的模板。國家標(biāo)準(zhǔn)委員會于2008年在第6號公告中又發(fā)布了GB/T 9385-2008計算機軟件需求規(guī)格說明規(guī)范，是最新的SRS文檔編制指南，見本書的電子資料附錄。l 引言l 綜合描述（任務(wù)概述、項目概述)l 功能需求(需求模型)l 外部接口l 非功能需求（性能需求）l 其它需求軟件工程(Software

27、 Engineering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院 魏東 Slide 364.4 需求說明l引言引言l 1.1 1.1 編寫目的編寫目的: : 說明編寫需求規(guī)格說明書的目的說明編寫需求規(guī)格說明書的目的. .l 1.2 1.2 背景說明背景說明: : 軟件產(chǎn)品的名稱軟件產(chǎn)品的名稱, ,項目的提出者、開發(fā)者及用戶，軟件產(chǎn)項目的提出者、開發(fā)者及用戶，軟件產(chǎn)品能做什么。品能做什么。l 1.3 1.3 預(yù)期讀者：列舉本說明所針對的不同讀者，例如開發(fā)人員、項目經(jīng)預(yù)期讀者：列舉本說明所針對的不同讀者，例如開發(fā)人員、項目經(jīng)理、營銷人員、用戶、測試人員或文檔的編寫人員。描述

28、了文檔中剩余理、營銷人員、用戶、測試人員或文檔的編寫人員。描述了文檔中剩余部分的內(nèi)容及其組織結(jié)構(gòu)，建議每一類型讀者最適合的閱讀文檔章節(jié)。部分的內(nèi)容及其組織結(jié)構(gòu)，建議每一類型讀者最適合的閱讀文檔章節(jié)。l 1.4 1.4 術(shù)語定義術(shù)語定義: :列出文檔中所用的專門術(shù)語的定義、縮寫、略語等列出文檔中所用的專門術(shù)語的定義、縮寫、略語等. .l 1.5 1.5 參考資料參考資料: :列出文檔所引用的全部資料列出文檔所引用的全部資料. .軟件工程(Software Engineering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院 魏東 Slide 374.4 需求說明l綜合描述l 這

29、一部分概述了正在定義的產(chǎn)品以及它所運行的環(huán)境、使用產(chǎn)品的用戶和已知的限制、假設(shè)和依賴。l 2.1產(chǎn)品描述：l描述了軟件需求規(guī)格說明中所定義的產(chǎn)品的背景和起源?？紤]的問題有：系列產(chǎn)品；改進產(chǎn)品；替代品；新型的；子系統(tǒng)。l 2.2 產(chǎn)品功能：l概述了產(chǎn)品所具有的主要功能。其詳細(xì)內(nèi)容將在3中描述，所以在此只需要概略地總結(jié)，例如用列表的方法給出。很好地組織產(chǎn)品的功能，使每個讀者都易于理解。用圖形表示主要的需求分組以及它們之間的聯(lián)系，例如總體框圖、頂層數(shù)據(jù)流圖或類關(guān)系圖。軟件工程(Software Engineering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院 魏東 Slide

30、384.4 需求說明l 2.3 用戶特征：l對用戶的受教育程度、行業(yè)工作經(jīng)驗、計算機知識水平等因素對用戶進行分類，即什么樣的操作需要什么樣的水平。以免用戶對產(chǎn)品感到失望。l 2.4 運行環(huán)境：l描述了軟件的運行環(huán)境，包括硬件平臺、操作系統(tǒng)和版本，還有其它的軟件組件或與其共存的應(yīng)用程序。l 2.5 限制說明：l敘述對系統(tǒng)設(shè)計產(chǎn)生影響的限制條件或特殊需求的理由,如管理模式、硬件限制、與其它應(yīng)用系統(tǒng)的接口、安全保密等。l 2.6 假設(shè)和依賴：l列舉出在對軟件需求規(guī)格說明中影響需求陳述的假設(shè)因素，以及項目對外部因素存在的依賴。軟件工程(Software Engineering) 沈陽工業(yè)大學(xué)信息科學(xué)與

31、工程學(xué)院沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院 魏東 Slide 394.4 需求說明l功能需求l 該部分是SRS的靈魂。需求分析核心工作由此體現(xiàn)l 3.1 功能描述（功能模型）：詳列出系統(tǒng)的詳細(xì)功能需求。這也是必須提交給用戶的軟件功能。l 注意：與2.2 （產(chǎn)品功能）的區(qū)別，2.2是羅列而展示全貌，這里是具體詳實的操作功能。l 3.2 數(shù)據(jù)描述(數(shù)據(jù)模型)：實體關(guān)系圖（ER），數(shù)據(jù)的邏輯模型。l 3.3 狀態(tài)描述（行為模型、動態(tài)模型）：對于實時系統(tǒng)是必須的。軟件工程(Software Engineering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院 魏東 Slide 404.4

32、 需求說明l外部接口l 4.1 用戶接口:l （用戶界面）描述屏幕格式、報表或菜單的頁面格式及內(nèi)容、功能鍵等；對于用戶界面的細(xì)節(jié)，例如特定對話框的布局，應(yīng)該寫入一個獨立的用戶界面規(guī)格說明中，而不能寫入軟件需求規(guī)格說明中。l 4.2 硬件接口:l 描述系統(tǒng)中軟件和硬件每一接口的特征。這種描述可能包括支持的硬件類型、軟硬件之間交流的數(shù)據(jù)和控制信息的性質(zhì)以及所使用的通信協(xié)議。l 4.3軟件接口:l 該軟件與其它軟件之間的接口。描述該產(chǎn)品與其它外部組件（由名字和版本識別）的連接，包括數(shù)據(jù)庫、操作系統(tǒng)、工具、庫和集成的商業(yè)組件。明確并描述在軟件組件之間交換數(shù)據(jù)或消息的目的。描述所需要的服務(wù)以及內(nèi)部組件通

33、信的性質(zhì)，確定將在組件之間共享的數(shù)據(jù)。 l 4.4 通信接口：l 描述與產(chǎn)品所使用的通信功能相關(guān)的需求，包括電子郵件、Web瀏覽器、網(wǎng)絡(luò)通信標(biāo)準(zhǔn)或協(xié)議及電子表格等等。定義了相關(guān)的消息格式，規(guī)定通信安全或加密問題、數(shù)據(jù)傳輸速率和同步通信機制。軟件工程(Software Engineering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院 魏東 Slide 414.4 需求說明l非功能需求l 5.1 性能需求l 闡述了不同的應(yīng)用領(lǐng)域?qū)Ξa(chǎn)品性能的需求，并解釋它們的原理以幫助開發(fā)人員作出合理的設(shè)計選擇。確定相互合作的用戶數(shù)或者所支持的操作、響應(yīng)時間以及與實時系統(tǒng)的時間關(guān)系。l 5.2

34、 安全設(shè)施需求l 詳盡陳述與產(chǎn)品使用過程中可能發(fā)生的損失、破壞或危害相關(guān)的需求。定義必須采取的安全保護或動作，還有那些預(yù)防的潛在的危險動作。明確產(chǎn)品必須遵從的安全標(biāo)準(zhǔn)、策略或規(guī)則。l 5.3 安全性需求l 詳盡陳述與系統(tǒng)安全性、完整性或與私人問題相關(guān)的需求，這些問題將會影響到產(chǎn)品的使用和產(chǎn)品所創(chuàng)建或使用的數(shù)據(jù)的保護。定義用戶身份確認(rèn)或授權(quán)需求，明確產(chǎn)品必須滿足的安全性或保密性策略。l 5.4 軟件質(zhì)量屬性l 詳盡陳述與客戶或開發(fā)人員至關(guān)重要的產(chǎn)品質(zhì)量其它特性，這些特性必須是確定、定量的并在可能時是可驗證的。如產(chǎn)品的易用程度、執(zhí)行速度、可靠性、當(dāng)發(fā)生異常情況時，系統(tǒng)如何處理。這些被稱為軟件質(zhì)量屬

35、性(或質(zhì)量因素)的特性，是系統(tǒng)非功能（也叫非行為）部分的需求。l 5.5 業(yè)務(wù)規(guī)則l 列舉出有關(guān)產(chǎn)品的所有操作規(guī)則，例如什么人在特定環(huán)境下可以進行何種操作。這些本身不是功能需求，但它們可以暗示某些功能需求執(zhí)行這些規(guī)則。l 5.6 用戶文檔l 列舉出將與軟件一同發(fā)行的用戶文檔部分，例如用戶手冊、在線幫助和教程，明確所有已知的用戶文檔的交付格式或標(biāo)準(zhǔn)。軟件工程(Software Engineering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院 魏東 Slide 424.4 需求說明lSRS是說明由軟件獲得的結(jié)果，而不是獲得這些結(jié)果的手段。l避免將需求與項目、與設(shè)計的界限混淆。

36、l表述具體需求功能可以用若干種方法來表達l可參考的模板有多種，不管使用哪個模板， SRS文檔結(jié)構(gòu)中要反映出業(yè)務(wù)需求、用戶需求、功能需求的三個層次。軟件工程(Software Engineering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院 魏東 Slide 434.4 需求說明lSRS與需求層次需求模型的細(xì)化非功能能需求非功能能需求綜合描述（任務(wù)概述項目概述綜合描述（任務(wù)概述項目概述項目背景系統(tǒng)目標(biāo)）項目背景系統(tǒng)目標(biāo)） SRS主要章節(jié)： 綜合描述 功能需求 非功能需求 其它需求軟件工程(Software Engineering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)

37、信息科學(xué)與工程學(xué)院 魏東 Slide 444.4 需求說明l一個字處理程序為例說明需求層次一個字處理程序為例說明需求層次l 業(yè)務(wù)需求：“能有效地糾正文檔中的拼寫錯誤”；l 用戶需求： “用戶檢查拼寫錯誤時，提示文檔中拼寫錯誤的單詞并通過一個提供的替換項列表來供選擇替換拼錯的詞”。l 功能需求：l找出拼寫錯誤單詞；l定位并高亮提示錯詞；l顯示提供替換詞的對話框以及實現(xiàn)整個文檔范圍的替換。l 所有的用戶需求必須與業(yè)務(wù)需求一致，功能需求必須滿足用戶需求，而開發(fā)人員則根據(jù)功能需求來設(shè)計軟件以實現(xiàn)必須的功能。軟件工程(Software Engineering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)

38、信息科學(xué)與工程學(xué)院 魏東 Slide 454.4 需求說明l 書寫規(guī)格說明的困惑書寫規(guī)格說明的困惑l先進行開發(fā)然后再寫需求規(guī)格說明；l規(guī)格說明往往寫的過于簡單；l不知道如何反映需求的三個層次，寫在規(guī)格說明書什么章節(jié)。l對逐步求精理解不夠，認(rèn)為許多內(nèi)容是重復(fù)。l軟件需求規(guī)格說明的模板不統(tǒng)一，不知采用哪個為好。如需求分析的核心內(nèi)容是建立需求模型，也是教材和教學(xué)的重點內(nèi)容，但建模的結(jié)果寫在SRS哪個章節(jié)里？不同的SRS模板說法不同，有的模板甚至無處表述。l很難找到公開的、可以參照的范文。 IT企業(yè)有自己的模板但不公開，也未必規(guī)范，但內(nèi)部使用沒有問題。軟件工程(Software Engineering

39、) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院 魏東 Slide 464.5 需求評審l 需求評審的作用l需求說明書描述幾乎都是自然語言，這種非形式化的語言容易出現(xiàn)不準(zhǔn)確、冗余、遺漏和理解不一致等問題。對規(guī)格說明書的審查是必須的，確保需求說明準(zhǔn)確、完整地、清晰、無二義地表達產(chǎn)品的功能和質(zhì)量要求。l需求評審是為了及早消除隱藏的錯誤，經(jīng)驗和研究表明，在需求開發(fā)階段糾正這個錯誤會節(jié)省相當(dāng)多的時間和金錢。l評審是需求分析的最后一步，通過評審后的需求文檔才可以生效。軟件工程(Software Engineering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院 魏東

40、Slide 474.5 需求評審l 評審標(biāo)準(zhǔn)l 需求規(guī)格說明的質(zhì)量特性作為評審的標(biāo)準(zhǔn)l 正確性l 完整性l 一致性l 無二義性l 可修改性l 可跟蹤性l 可驗證性軟件工程(Software Engineering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院 魏東 Slide 484.5 需求評審l正確性：對系統(tǒng)功能、行為、性能等的描述必須與用戶的期望相吻合，代表了用戶的真正需求。l完整性：需求規(guī)格說明應(yīng)該包括軟件要完成的全部任務(wù)，不能遺漏任何必要的需求信息，注重用戶的任務(wù)而不是系統(tǒng)的功能將有助于你避免不完整性l 一致性：需求規(guī)格說明對各種需求的描述不能存在矛盾，如術(shù)語使用沖

41、突、功能和行為特性方面的矛盾以及時序上的不一致等l可修改性：格式和組織方式應(yīng)保證后續(xù)的修改能夠比較容易和協(xié)調(diào)一致。我們可以使用軟件工具，或者使用目錄表、索引和相互參照列表等方法使軟件需求規(guī)格說明更容易修改。l 可跟蹤性：可跟蹤性意味著每項需求都能與其對應(yīng)的來源、設(shè)計、源代碼和測試用例聯(lián)系起來。l可驗證性：描述的需求都可以運用一些可行的手段對其進行驗證和確認(rèn)。軟件工程(Software Engineering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院 魏東 Slide 494.5 需求評審l需求評審方法l規(guī)格說明書評審：l 分析人員要在用戶和軟件設(shè)計人員的配合下對自己生成的

42、需求規(guī)格說明和初步的用戶手冊進行復(fù)核。可以有：l用戶評審和同行評審：l 用戶驗收的標(biāo)準(zhǔn)則是依據(jù)需求規(guī)格說明書中的內(nèi)容來制訂，所以用戶評審是第一位的；而同行評審是在軟件項目初期發(fā)現(xiàn)那些潛在的缺陷或錯誤，避免這些錯誤和缺陷遺漏到項目的后續(xù)階段。l正式與非正式：l 非正式評審多少有些同行切磋的性質(zhì)，根據(jù)個人愛好的方式，不拘時間，不拘形式；正式評審除軟件開發(fā)人員外，還邀請用戶代表和領(lǐng)域?qū)＜覅⒓樱ǔ２捎么疝q形式，與會者有備而來(即提前審閱了文檔)，分析人員在做詳細(xì)說明后，答復(fù)與會者的問題并記下各種重要的評審意見。這種評審方式應(yīng)對事不對人，防止把評審變?yōu)橘|(zhì)詢或辯論。l 評審規(guī)格說明時配合演示原型是個重要

43、的輔助方式，通過對模型的運行，評審人員可以了解系統(tǒng)是否滿足需求，模型的運行也可揭示出需求文檔中的錯誤和遺漏。軟件工程(Software Engineering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院 魏東 Slide 504.5 需求評審l編寫輔助文檔也屬需求驗證l 初始測試用例：根據(jù)用戶需求所要求的產(chǎn)品特性寫出黑盒功能測試用例。通過使用測試用例以確認(rèn)是否達到了期望的要求，從測試用例追溯回功能需求以確保沒有需求被疏忽，并且確保所有測試結(jié)果與測試用例相一致。l 初始用戶手冊：在需求開發(fā)早期即可起草一份用戶手冊，用它作為需求規(guī)格說明的參考并輔助需求分析。軟件工程(Softw

44、are Engineering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院 魏東 Slide 514.5 需求評審l評審規(guī)格說明需要考慮的問題l是否所有的分配需求都在SRS中體現(xiàn)?l在SRS中定義需求時,是否避免使用那些引起歧義的術(shù)語,諸如也許,可能,每條需求都清晰無歧義?l是否在SRS中清楚地描述了軟件要做什么及不做什么?l是否在SRS中描述了軟件使用的目標(biāo)環(huán)境,指明并簡短描述了目標(biāo)環(huán)境中其他相關(guān)軟件產(chǎn)品/子系統(tǒng)/模塊?l是否每個需求有唯一的編號?l每個需求是否切實可行,可測試,前后一致,彼此不沖突?l是否在SRS中說明了對每個輸入的驗證措施,并描述了每個輸入的屬性如:度

45、量單位,邊界值,時序要求等等?l是否在SRS中說明了對每個輸入的處理?l是否在SRS中說明了每個輸入項是如何輸出的,并描述每個輸出的屬性如:度量單位,邊界值,時序要求?軟件工程(Software Engineering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院 魏東 Slide 524.5 需求評審l是否在SRS中描述了軟件的所有的性能要求?l是否性能需求的描述能通過測試來驗證?l是否在SRS中說明了所有對系統(tǒng)的可能的約束?l質(zhì)量屬性是否以可測量或可驗證的術(shù)語進行描述?l是否在SRS中描述了系統(tǒng)中與子系統(tǒng),模塊或硬件設(shè)備的相關(guān)的接口?l是否對每個接口的描述足夠清楚,實現(xiàn)時

46、不需要多于的解釋?l是否在SRS中描述了與操作系統(tǒng)的接口?l是否在SRS的附錄中記錄了分配需求可行性的分析結(jié)果?l是否項目SOW文檔所對應(yīng)的分配需求都在RTM中體現(xiàn)?l Requirements Traceability Matrix （需求跟蹤矩陣）l Statement of Work (工作說明)軟件工程(Software Engineering) 沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院沈陽工業(yè)大學(xué)信息科學(xué)與工程學(xué)院 魏東 Slide 534.5 需求評審l需求舉例l需求文檔陳述與改進舉例-1產(chǎn)品必須在固定的產(chǎn)品必須在固定的時間間隔內(nèi)提供狀時間間隔內(nèi)提供狀態(tài)消息，態(tài)消息，并且每次時間間隔并且每次時間間隔不得小于不得小于6060秒。秒。 后臺任務(wù)管理器后臺任務(wù)管理器( (BTM) )應(yīng)該應(yīng)該在用戶界面的指定區(qū)域顯示在用戶界面的指定區(qū)域顯示狀態(tài)消息。狀態(tài)消息。 a. 在后臺任務(wù)進程啟動之后后臺任務(wù)進程啟動之后，消息必須每隔，消息必須每隔60(60( 1010) )秒秒更新一次，并且保持連續(xù)的更新一次，并且保持連續(xù)的可見性?？梢娦浴?b. 如果正在正常處理后臺任務(wù)如果正在正常處理后臺任務(wù)進程，那么后臺任務(wù)管理器進程，那么后臺任務(wù)管理器( (BTM) )必須顯示后臺任務(wù)進必須顯示后臺任務(wù)進程已完成的百