軟件需求工程課件

需求工程軟件工程（SoftwareEngineering）1需求工程軟件工程1 通過對問題及其環(huán)境的理解與分析，為問題涉及的信息、功能及系統(tǒng)行為建立模型，將用戶需求精確化、完全化，最終形成需求規(guī)格說明，這一系列的活動即構(gòu)成軟件開發(fā)生命周期的需求分析階段。 軟件需求作為軟件生命周期的一個階段，其重要性越來越突出，到20世紀80年代中期，逐步形成了軟件工程的子領(lǐng)域——需求工程。

90年代后，需求工程成為軟件界研究的重點之一。從1993年起，每兩年舉辦一次需求工程國際研討會（ISRE），1994年起，每兩年舉辦一次需求工程國際會議（ICRE）。一些關(guān)于需求工程的工作小組相繼成立，使需求工程的研究得到了迅速進展。2 通過對問題及其環(huán)境的理解與分析，為問題涉及的信息、功能及系內(nèi)容摘要1.什么是需求工程？2.什么是軟件需求工程？3.軟件需求的重要性4.軟件需求的困難5.軟件需求內(nèi)容6.需求工程的活動3內(nèi)容摘要1.什么是需求工程？31)需求的基本概念

寬泛地講，需求來源于用戶的一些“需要”，這些“需要”被分析、確認后形成完整的文檔，該文檔詳細地說明了產(chǎn)品“必須或應(yīng)當”做什么。軟件需求——是指用戶對目標軟件系統(tǒng)在功能、行為、性能、設(shè)計約束等方面的期望。

2)需求工程(RE)的概念

是指應(yīng)用已證實有效的技術(shù)、方法進行需求分析，確定客戶需求，幫助分析人員理解問題并定義目標系統(tǒng)的所有外部特征的一門學科。需求分析專家AlanDavis把需求工程定義為“直到（但不包括）把軟件分解為實際架構(gòu)構(gòu)件之前的所有活動”RE通過合適的工具和記號系統(tǒng)地描述待開發(fā)系統(tǒng)及其行為特征和相關(guān)約束，形成需求文檔，并對用戶不斷變化的需求演進給予支持。1什么是需求工程41)需求的基本概念1什么是需求工程42.什么是軟件需求工程？需求工程RE可分為系統(tǒng)需求工程（如果是針對由軟硬件共同組成的整個系統(tǒng)）和軟件需求工程（如果僅是專門針對純軟件部分）。軟件需求工程——是一門分析并記錄軟件需求的學科，它把系統(tǒng)需求分解成一些主要的子系統(tǒng)和任務(wù)，把這些子系統(tǒng)或任務(wù)分配給軟件，并通過一系列重復(fù)的分析、設(shè)計、比較研究、原型開發(fā)過程把這些系統(tǒng)需求轉(zhuǎn)換成軟件的需求描述和一些性能參數(shù)。52.什么是軟件需求工程？需求工程RE可分為系統(tǒng)需求工程（如果 軟件需求無疑是當前軟件工程中的關(guān)鍵問題，沒有需求就沒有軟件。需求的重要性FrederickBrooks在他1987年經(jīng)典文章“NoSilverBullet”中闡述了需求的重要性：開發(fā)軟件系統(tǒng)最困難的部分就是準確說明開發(fā)什么。最困難的概念性工作是編寫出詳細的需求，包括所有面向用戶、面向機器和其它軟件系統(tǒng)的接口。此工作一旦做錯，將會給系統(tǒng)帶來極大的損害，并且以后對它修改也極為困難。

需求是產(chǎn)品的根源，需求工作的優(yōu)劣對產(chǎn)品影響最大。就像一條河流，如果源頭被污染了，那么整條河流也就被污染了。

國內(nèi)軟件業(yè)的痼疾：人們并不清楚究竟該做什么，但卻一直忙碌不停地開發(fā)。3.軟件需求的重要性6 軟件需求無疑是當前軟件工程中的關(guān)鍵問題，沒有需求就沒有軟件3.軟件需求的重要性美國于1995年開始對全國范圍內(nèi)的8000個軟件項目進行跟蹤調(diào)查。分析失敗的原因發(fā)現(xiàn)，與需求過程相關(guān)的原因占了45%，而其中缺乏最終用戶的參與以及不完整的需求又是兩大首要原因，各占13%和12%。未完成完成未實施完成73.軟件需求的重要性美國于1995年開始對4.軟件需求的困難軟件需求是軟件工程中最復(fù)雜的過程之一：應(yīng)用領(lǐng)域的廣泛性，它的實施無疑與各個應(yīng)用行業(yè)的特征密切相關(guān)。非功能性需求建模技術(shù)的缺乏及其與功能性需求有著錯綜復(fù)雜的聯(lián)系，大大增加了需求工程的復(fù)雜性。溝通上的困難，由于系統(tǒng)需求分析各方面人員有不同的著眼點和不同的知識背景，給需求工程的實施增加了人為的難度?？蛻粽f不清楚需求；需求自身經(jīng)常變動；分析人員或客戶理解有誤。

84.軟件需求的困難軟件需求是軟件工程中最復(fù)雜的過程之一：8真正的軟件需求獲取如此困難（漫畫）

9真正的軟件需求獲取如此困難（漫畫）9

需求工程是系統(tǒng)工程和軟件工程的一個交叉分支，涉及到軟件系統(tǒng)的目標、軟件系統(tǒng)提供的服務(wù)、軟件系統(tǒng)的約束和軟件系統(tǒng)運行的環(huán)境。它還涉及這些因素和系統(tǒng)的精確規(guī)格說明以及系統(tǒng)進化之間的關(guān)系。它也提供現(xiàn)實需求和軟件能力之間的橋梁。需求工程系統(tǒng)目標系統(tǒng)服務(wù)軟件約束運行環(huán)境5.軟件需求內(nèi)容10需求工程是系統(tǒng)工程和軟件工程的一個交叉軟件需求用戶需求系統(tǒng)需求功能需求非功能需求領(lǐng)域需求由客戶管理員、用戶等提出軟件需求的內(nèi)容5.軟件需求內(nèi)容11軟件需求用戶需求系統(tǒng)需求功能需求非功能需求領(lǐng)域需功能需求它是對系統(tǒng)應(yīng)該提供的服務(wù)、功能以及系統(tǒng)在特定條件下的行為的描述。它與軟件系統(tǒng)的類型、使用系統(tǒng)的用戶等相關(guān)，有時需要詳細描述系統(tǒng)的功能、輸入/輸出、異常等，有時還需要申明系統(tǒng)不應(yīng)該做什么。領(lǐng)域需求是由軟件系統(tǒng)的應(yīng)用領(lǐng)域所決定的特有的功能需求，或是對功能的約束。12功能需求領(lǐng)域需求12非功能需求產(chǎn)品需求機構(gòu)需求外部需求互操作需求道德需求立法需求性能需求空間需求交付需求實現(xiàn)需求標準需求隱私需求安全性需求可用性需求效率需求可靠性需求可移植性需求非功能需求13非功能需求產(chǎn)品需求機構(gòu)需求外部需求互操作道德立法性能空間交付因此系統(tǒng)應(yīng)該具備以下功能：⑴基本數(shù)據(jù)維護功能⑵基本業(yè)務(wù)功能⑶數(shù)據(jù)庫管理功能⑷信息查詢功能例1：有一個大學圖書管理系統(tǒng)，該系統(tǒng)除了一般的圖書管理功能外，還能夠為學生和教工從其他圖書館借閱圖書和文獻資料提供服務(wù)。14因此系統(tǒng)應(yīng)該具備以下功能：例1：有一個大學圖書管理系統(tǒng)，該系1.功能需求⑴基本數(shù)據(jù)維護功能：提供使用者錄入，修改并進行維護基本數(shù)據(jù)的途徑?；緮?shù)據(jù)包括讀者的信息、圖書資料的相關(guān)信息，可以對這些信息進行修改，更新。⑵基本業(yè)務(wù)功能：讀者借、還書籍的登記管理功能，隨時根據(jù)讀者借、還書籍的情況更新數(shù)據(jù)庫系統(tǒng)，可以進行書籍的編目、入庫、更新等操作。151.功能需求15⑶數(shù)據(jù)庫管理功能：對所有圖書信息及讀者信息進行統(tǒng)一管理維護的功能，對書籍的借還也要進行詳細的登記，以便協(xié)調(diào)整個圖書館的運作。⑷信息查詢功能：提供對各類信息的查詢功能，如對本圖書館的用戶借書信息，還書的信息，書籍源信息等進行查詢，對其他圖書館的書籍、資料源信息的查詢功能。16⑶數(shù)據(jù)庫管理功能：162.非功能需求①系統(tǒng)安全性需求：為保證系統(tǒng)安全性，對本圖書館的各項功能進行分級、分權(quán)限操作，對各類用戶進行確認。對其它圖書館借閱圖書和文獻資料服務(wù)控制訪問范圍：如限IP、限用戶等。②對系統(tǒng)可用性的需求：為了方便使用者，要求對所有交互操作提供在線幫助功能。③對系統(tǒng)查詢速度的需求：要求系統(tǒng)在20S之內(nèi)響應(yīng)查詢服務(wù)請求。④對系統(tǒng)可靠性的需求：要求系統(tǒng)失敗發(fā)生率小于1%。172.非功能需求173.領(lǐng)域需求例如：對“大學圖書管理系統(tǒng)”，提出一些與圖書管理的業(yè)務(wù)相關(guān)的需求：⑴圖書編目要求按照《中國圖書館分類法》進行；⑵由于版權(quán)限制，某些文獻資料只能在圖書館規(guī)定的閱覽室閱讀，并限制復(fù)制和打印。第一條需求是對遵循我國圖書管理的規(guī)定，執(zhí)行對圖書的分類管理的標準。而第二條需求則是版權(quán)法對圖書館文獻資料的保護的需要，描述了對一類文獻資料有限制的使用和服務(wù)。183.領(lǐng)域需求18

HerbKrasner定義了需求工程的五階段生命周期：需求定義和分析、需求決策、形成需求規(guī)格、需求實現(xiàn)與驗證、需求演進管理 MatthiasJarke和KlausPohl提出了三階段周期的說法：獲取、表示和驗證 本書將軟件需求工程細分為：需求獲取、需求分析與協(xié)商、系統(tǒng)建模、需求規(guī)約、需求驗證和需求管理六個階段?！?.需求工程的活動19HerbKrasner定義了需求工程需求工程中的活動可分為兩大類:一、需求開發(fā)二、需求管理6.需求工程的活動20需求工程中的活動可分為兩大類:6.需求工程的活動20一、需求開發(fā)需求開發(fā)的任務(wù)是準確地定義未來系統(tǒng)的目標，確定為了滿足用戶的需求系統(tǒng)必須做什么。用《需求規(guī)格說明書》規(guī)范的形式準確地表達用戶的需求。需求開發(fā)的目的是通過調(diào)查與分析，獲取用戶需求并定義產(chǎn)品需求。（1）需求獲取的目的是深入實際，通過各種途徑,在充分理解用戶需求的基礎(chǔ)上，獲取用戶的需求信息。（2）需求分析、協(xié)商與建模的目的是對各種需求信息進行分析，消除錯誤，刻畫細節(jié)等。（3）需求規(guī)格說明目的是根據(jù)需求獲取和需求分析的結(jié)果，進一步定義準確無誤的產(chǎn)品需求，產(chǎn)生《需求規(guī)格說明書》。系統(tǒng)設(shè)計人員將依據(jù)《需求規(guī)格說明書》開展系統(tǒng)設(shè)計工作。（4）需求驗證是指開發(fā)方和客戶共同對需求文檔進行評審，雙方對需求達成共識后作出書面承諾，使需求文檔具有商業(yè)合同效果。確保需求說明準確、完整地表達系統(tǒng)的主要特性。21一、需求開發(fā)需求開發(fā)的任務(wù)是準確地定義未來系統(tǒng)的目標，確需求獲取是需求工程的主體,非常困難，主要原因有：●缺乏領(lǐng)域知識,應(yīng)用領(lǐng)域的問題常常是模糊的、不精確的；●存在默認的知識,如難以描述的常識問題；●存在多個知識源,且多知識源之間可能有沖突；●客戶可能的偏見，如不能提供或不想告知你所需要了解的事情。(一)、需求獲取(requirementelicitation)22需求獲取是需求工程的主體,非常困難，主要原因有：(一)、需求需求獲取技術(shù)1.面談法重要而直接，簡單的需求獲取技術(shù)。2.問卷法調(diào)查法是對面談法的補充。

3.需求專題討論會最有力的需求獲取技術(shù)。有利于培養(yǎng)高效團隊。4.觀察用戶的工作流程適用于用戶無法準確表達需求的情況。5.原型化方法6.基于用例的方法還有知識工程方法等如：場記分析法、卡片分類法、分類表格技術(shù)和基于模型的知識獲取等。面談的對象主要有用戶和領(lǐng)域?qū)＜遥?）面談前的準備要充分；2）面談后注意認真分析總結(jié)；3）注意掌握面談的人際交流技能。

23需求獲取技術(shù)還有知識工程方法等如：場記分析法需求獲取技術(shù)1.面談法重要而直接，簡單的需求獲取技術(shù)。2.問卷法調(diào)查法是對面談法的補充。

3.需求專題討論會最有力的需求獲取技術(shù)。有利于培養(yǎng)高效團隊。4.觀察用戶的工作流程適用于用戶無法準確表達需求的情況。5.原型化方法6.基于用例的方法是從多個用戶中收集需求信息的有效方式，一般問卷設(shè)計形式：1）多項選擇問題；2）評分問題；3）排序問題。24需求獲取技術(shù)1.面談法重要而直接，簡單的需求獲取技術(shù)。是從需求獲取技術(shù)

1.面談法重要而直接，簡單的需求獲取技術(shù)。2.問卷法調(diào)查法是對面談法的補充。

3.需求專題討論會最有力的需求獲取技術(shù)。有利于培養(yǎng)高效團隊。4.觀察用戶的工作流程適用于用戶無法準確表達需求的情況。5.原型化方法6.基于用例的方法由開發(fā)方和用戶方共同召開,操作步驟：①開發(fā)方根據(jù)雙方制定的《需求調(diào)研計劃》召開相關(guān)需求主題溝通會；②會后開發(fā)方整理出《需求調(diào)研記錄》提交給用戶方確認；③如果此主題還有未明確的問題則再次溝通,否則開始下一主題；④所有需求都溝通清楚后，開發(fā)方根據(jù)歷次《需求調(diào)研記錄》整理出《用戶需求說明書》，提交給用戶方確認簽字。25需求獲取技術(shù)由開發(fā)方和用戶方共同召開,操作步驟：25

需求分析階段主要對收集到的需求進行提煉、分析和認真審查，進行需求建模、對模型或原型進行分析。確保所有參加人員取得一致共識。找出錯誤、遺漏和不足，建立完整的分析模型。(二)、需求分析、協(xié)商與建模26(二)、需求分析、協(xié)商與建模261、確定系統(tǒng)的綜合要求

系統(tǒng)功能要求—這是最主要的需求，確定系統(tǒng)必須完成的所有功能。

系統(tǒng)性能要求—應(yīng)就具體系統(tǒng)而定，例如可靠性、聯(lián)機系統(tǒng)的響應(yīng)時間、存儲容量、安全性能等。

系統(tǒng)運行要求—主要是對系統(tǒng)運行時的環(huán)境要求，如系統(tǒng)軟件、數(shù)據(jù)庫管理系統(tǒng)、外存和數(shù)據(jù)通信接口等。

將來可能提出的要求—對將來可能提出的擴充及修改作預(yù)準備。2、分析系統(tǒng)的數(shù)據(jù)要求軟件系統(tǒng)本質(zhì)上是信息處理系統(tǒng)，因此，必須考慮：

數(shù)據(jù)（需要哪些數(shù)據(jù)、數(shù)據(jù)間聯(lián)系、數(shù)據(jù)性質(zhì)、結(jié)構(gòu)）數(shù)據(jù)處理（處理的類型、處理的邏輯功能）3、導(dǎo)出系統(tǒng)的邏輯模型。4、修正系統(tǒng)的開發(fā)計劃—通過需求對系統(tǒng)的成本及進度有了更精確的估算，可進一步修改開發(fā)計劃。需求分析、協(xié)商與建模的具體任務(wù)271、確定系統(tǒng)的綜合要求需求分析、協(xié)商與建模的具體任務(wù)27當前系統(tǒng)目標系統(tǒng)物理模型邏輯模型邏輯模型物理模型模型化抽象化具體化實例化怎么做做什么當前系統(tǒng)目標系統(tǒng)需求定義需求分析的一般步驟28當前目標物理邏輯邏輯物理模型化抽象化具體化實例化怎做當前目標1．必須能夠表示和理解問題的信息域2．必須能夠定義軟件將完成的功能3．必須能夠表示軟件的行為(作為外部事件的結(jié)果)4．必須劃分描述數(shù)據(jù)、功能和行為的模型，從而可以分層次地揭示細節(jié)5．分析過程應(yīng)該從要素信息移向細節(jié)信息需求分析操作原則291．必須能夠表示和理解問題的信息域需求分析操作原則29信息域信息域：包括信息內(nèi)容、信息流、以及信息結(jié)構(gòu)。信息內(nèi)容表示了單個數(shù)據(jù)和控制對象，目標軟件所有處理的信息集合由它們構(gòu)成。例如，數(shù)據(jù)對象“工資”是一組重要數(shù)據(jù)體的組合：領(lǐng)款人的姓名、凈付款數(shù)、付款總額、扣除額等等信息流表示了數(shù)據(jù)和控制在系統(tǒng)中流動時的變化方式，輸入對象被變換為中間信息(數(shù)據(jù)和/或控制)，然后進一步被變換為輸出信息結(jié)構(gòu)表示了各種數(shù)據(jù)和控制項的內(nèi)部組織數(shù)據(jù)或控制項將被組織為n維表還是樹形結(jié)構(gòu)？在結(jié)構(gòu)的語境內(nèi)，什么信息是和其他信息相關(guān)的？信息包含在單個結(jié)構(gòu)中，還是使用不同的結(jié)構(gòu)？在某信息結(jié)構(gòu)中的信息如何和在另一個結(jié)構(gòu)中的信息相關(guān)？30信息域信息域：包括信息內(nèi)容、信息流、以及信息結(jié)構(gòu)。30需求工程的指導(dǎo)性原則除了上面提到的操作性分析原則，Davis提出了一組針對需求工程的指導(dǎo)性原則：

在開始建立分析模型前，先充分理解問題。開發(fā)原型，使得用戶能夠了解如何進行人機交互。記錄每個需求的起源及原因。使用多個需求視圖。建立數(shù)據(jù)、功能和行為模型，為軟件工程師提供三種不同的視圖。給需求賦予優(yōu)先級。努力刪除歧義性。31需求工程的指導(dǎo)性原則除了上面提到的操作性分析原則，Davis常用的需求分析方法：功能分解方法面向數(shù)據(jù)流的結(jié)構(gòu)化分析方法(SA)面向數(shù)據(jù)結(jié)構(gòu)的分析方法信息建模法面向?qū)ο蟮姆治龇椒?OOA)32常用的需求分析方法：功能分解方法32功能分解方法

將系統(tǒng)看作若干功能模塊的集合，每個功能又可以分解為子功能,子功能還可繼續(xù)分解,分解的結(jié)果即是系統(tǒng)的雛形。存在問題1.需要人工完成2.無法對描述的準確度進行驗證。3.難以適應(yīng)需求的變化。問題空間功能子功能映射33功能分解方法存在問題問題空間功能映射331．客房預(yù)定系統(tǒng)2．前臺接待系統(tǒng)3．前臺收銀系統(tǒng)4．帳務(wù)系統(tǒng)

5．管家系統(tǒng)6．電話系統(tǒng)

7．客歷系統(tǒng)8．合約系統(tǒng)

9．經(jīng)理系統(tǒng)10．總經(jīng)理系統(tǒng)

11．密碼管理系統(tǒng)12．報表系統(tǒng)

13．帳務(wù)報表酒店管理系統(tǒng)例：按照功能分解為以下子系統(tǒng)：341．客房預(yù)定系統(tǒng)2．前臺接待系統(tǒng)酒店管理盤存/銷售系統(tǒng)1.0.0銷售處理1.1.0盤存處理1.2.0例：盤存/銷售系統(tǒng)，用戶提出,系統(tǒng)應(yīng)具有以下功能:①計算買主訂單②準備銷售報表③建立買主文件和應(yīng)收帳發(fā)票④運行更新的盤存文件

⑤產(chǎn)生托運單和包裝單⑥保證庫存及時訂貨計算銷售記錄1.1.1產(chǎn)生銷售報表1.1.2核對買主貸方金額1.1.3驗證庫存量級1.2.1產(chǎn)生貨運訂單1.2.2執(zhí)行買主匯票1.2.3產(chǎn)生盤存報表1.2.435盤存/銷售系統(tǒng)銷售處理盤存處理例：盤存/銷售系統(tǒng)，用戶提出,結(jié)構(gòu)化分析方法結(jié)構(gòu)化分析方法是面向數(shù)據(jù)流的需求分析方法，是20世紀70年代末由Yourdon,Constaintine及DeMarco等人提出和發(fā)展，并得到廣泛的應(yīng)用。它適合于分析大型的數(shù)據(jù)處理系統(tǒng)，特別是企事業(yè)管理系統(tǒng)。SA法也是一種建模的活動，主要是根據(jù)軟件內(nèi)部的數(shù)據(jù)傳遞、變換關(guān)系，自頂向下逐層分解，描繪出滿足功能要求的軟件模型。36結(jié)構(gòu)化分析方法36面向?qū)ο蟮姆治龇椒?/p>

面向?qū)ο蟮姆治龇椒?OOA)的關(guān)鍵是識別問題域內(nèi)的對象,分析它們之間的關(guān)系,并建立起三類模型。信息建模法

是從數(shù)據(jù)的角度對現(xiàn)實世界建立系統(tǒng)的信息模型,基本工具是ER圖。是由實體、屬性和關(guān)系組成的網(wǎng)絡(luò)圖。E-實體，是一個或一組對象；R-關(guān)系，實體之間聯(lián)系或交互作用。37面向?qū)ο蟮姆治龇椒ㄐ畔⒔７?7需求協(xié)商協(xié)商的過程就是討論需求沖突，找出每個人都滿意的折衷方案協(xié)商不是簡單的邏輯或技術(shù)上的爭論要注意組織和行政方面的因素①不一致的目標②責任的喪失或轉(zhuǎn)移③組織文化④組織管理態(tài)度和士氣⑤部門差異38需求協(xié)商協(xié)商的過程就是討論需求沖突，找出每個人都滿意的折衷通常會議是解決沖突最快的方式參加者應(yīng)該包括發(fā)現(xiàn)沖突、遺漏或重疊的分析員，以及可以解決發(fā)現(xiàn)的問題的項目相關(guān)人員會議應(yīng)該討論那些非正式討論不能解決的問題通常會議分為三個階段：敘述階段討論階段決策階段39通常會議是解決沖突最快的方式39需求建模在軟件需求分析階段，所創(chuàng)建的模型，要著重于描述系統(tǒng)要做什么，而不是如何去做目標軟件的模型不應(yīng)涉及軟件實現(xiàn)細節(jié)典型分析建模方法結(jié)構(gòu)化分析(傳統(tǒng)建模方法)面向?qū)ο蠓治?0需求建模在軟件需求分析階段，所創(chuàng)建的模型，要著重于描述系統(tǒng)計算機世界現(xiàn)實世界結(jié)構(gòu)化開發(fā)方法結(jié)構(gòu)化分析結(jié)構(gòu)化設(shè)計結(jié)構(gòu)化編程OOAOODOOP面向?qū)ο箝_發(fā)方法模型的作用41計算機世界現(xiàn)實世界結(jié)結(jié)構(gòu)化結(jié)構(gòu)化結(jié)構(gòu)化OOAOODOOP面模面向?qū)ο蠓治瞿Ｐ偷慕M成結(jié)構(gòu)對象-關(guān)系模型類/對象模型對象-行為模型使用實例(UseCase)操作、屬性、協(xié)作者42面向?qū)ο蠓治瞿Ｐ偷慕M成結(jié)構(gòu)對象-關(guān)類/對象對象-行為模型使用數(shù)據(jù)流圖(DFD)E-R圖狀態(tài)變遷圖(STD圖)加工說明控制說明數(shù)據(jù)對象說明數(shù)據(jù)字典（DD）結(jié)構(gòu)化分析模型的組成結(jié)構(gòu)43數(shù)據(jù)流圖E-R圖狀態(tài)變遷圖加工說明控制說明數(shù)據(jù)對說數(shù)據(jù)字典結(jié)結(jié)構(gòu)化分析模型的元素數(shù)據(jù)字典(DD)：模型核心(中心庫)數(shù)據(jù)流圖(DFD)

指明數(shù)據(jù)在系統(tǒng)中移動時如何被變換;描述對數(shù)據(jù)流進行變換的功能;DFD中每個功能的描述包含在加工規(guī)約(小說明)。E-R圖(ERD)狀態(tài)變遷圖(STD)指明作為外部事件的結(jié)果,系統(tǒng)將如何動作。44結(jié)構(gòu)化分析模型的元素數(shù)據(jù)字典(DD)：模型核心(中心庫)44(三)需求規(guī)格說明(需求規(guī)約)采用原始模板，在你的組織中要為編寫軟件需求文檔定義一種標準模板指明需求的來源為每項需求注上標號制定一種慣例來為每項需求提供一個獨立的可識別的標號或記號記錄業(yè)務(wù)規(guī)范45(三)需求規(guī)格說明(需求規(guī)約)采用原始模板，在你的組織中要為需求規(guī)約的原則1．從現(xiàn)實中分離功能，即描述要“做什么”而不是“怎樣實現(xiàn)”。2．要求使用面向處理的規(guī)約語言（或稱系統(tǒng)定義語言），討論來自環(huán)境的各種刺激可能導(dǎo)致系統(tǒng)做出什么樣的功能性反應(yīng)，來定義一個行為模型，從而得到“做什么”的規(guī)約。3．如果被開發(fā)軟件只是一個基于計算機的系統(tǒng)中的一個元素，那么整個大系統(tǒng)也包括在規(guī)格說明的描述之中。4．規(guī)約必須包括系統(tǒng)運行環(huán)境。46需求規(guī)約的原則1．從現(xiàn)實中分離功能，即描述要“做什么”而不需求規(guī)約的原則(續(xù))5．規(guī)約必須是一個認識模型，而不是設(shè)計或?qū)崿F(xiàn)的模型。6．規(guī)約必須是可操作的，以便能夠利用它決定對于任意給定的測試用例，已提出的解決方案是否都能滿足規(guī)約。7．規(guī)約必須允許不完備性并允許擴充。8．規(guī)約必須局部化和松散耦合。它所包括的信息必須局部化，這樣當信息被修改時，只要修改某個單個的段落（理想情況）。同時，規(guī)約應(yīng)被松散地構(gòu)造（即松耦合），以便能夠很容易地加入和刪去一些段落。47需求規(guī)約的原則(續(xù))5．規(guī)約必須是一個認識模型，而不是設(shè)計需求規(guī)約IEEE/ANSI830-1993簡化大綱Ⅰ.引言A.系統(tǒng)參考文獻B.整體描述C.軟件項目約束Ⅱ.信息描述A.信息內(nèi)容表示B.信息流表示：ⅰ數(shù)據(jù)流ⅱ控制流Ⅲ.功能描述A.功能劃分B.功能描述：ⅰ處理說明ⅱ限制∕局限ⅲ性能需求ⅳ設(shè)計約束ⅴ支撐圖C.控制描述ⅰ控制規(guī)約ⅱ設(shè)計約束Ⅳ.行為描述A.系統(tǒng)狀態(tài)B.事件和響應(yīng)Ⅴ.檢驗標準A.性能范圍B.測試種類C.期望的軟件響應(yīng)D.特殊的考慮Ⅵ.參考書目Ⅶ.附錄48需求規(guī)約IEEE/ANSI830-1993簡化大綱Ⅰ.引引言：陳述軟件目標，在基于計算機的系統(tǒng)語境內(nèi)進行描述。信息描述：給出軟件必須解決問題的詳細描述，記錄信息內(nèi)容和關(guān)系、流和結(jié)構(gòu)。功能描述：描述解決問題所需的每個功能。其中包括，為每個功能說明一個處理過程；敘述設(shè)計約束；敘述性能特征；用一個或多個圖形來形象地表示軟件的整體結(jié)構(gòu)和軟件功能與其他系統(tǒng)元素間的相互影響。行為描述：描述作為外部事件和內(nèi)部產(chǎn)生的控制特征的軟件操作。檢驗標準：描述檢驗系統(tǒng)成功的標志。即對系統(tǒng)進行什么樣的測試，得到什么樣的結(jié)果，就表示系統(tǒng)已經(jīng)成功實現(xiàn)了。它是“確認測試”的基礎(chǔ)。參考書目：包含了對所有和該軟件相關(guān)的文檔的引用，其中包括其他的軟件工程文檔、技術(shù)參考文獻、廠商文獻以及標準。附錄：包含了規(guī)約的補充信息，表格數(shù)據(jù)、算法的詳細描述、圖表以及其他材料。49引言：陳述軟件目標，在基于計算機的系統(tǒng)語境內(nèi)進行描述。49(四)、需求的有效性驗證需求驗證目的是要檢驗需求是否能夠反映用戶的意愿一)需求驗證的重要性

１.由于需求分析是軟件開發(fā)的第一階段，直接影響后面各階段的開發(fā)。２.需求的可變性必須進行驗證。二)需求驗證的內(nèi)容1.有效性檢查—指功能需求是否符合用戶所提出的需求。2.一致性檢查—系統(tǒng)功能描述及約束是否一致。3.完備性檢查—是否包含所有系統(tǒng)用戶的需求和約束。4.可檢驗性檢查—是否能設(shè)計出一組驗證方法。50(四)、需求的有效性驗證需求驗證目的是要檢驗需求是否能夠反映需求開發(fā)過程

可行性研究需求獲取和分析需求描述需求有效性驗證可行性報告系統(tǒng)模型用戶需求和系統(tǒng)需求需求文擋51需求開發(fā)過程可行性研究需求獲取需求描述需求有效性可行性報告二、需求管理需求管理是一組用于幫助項目組在項目進展中的任何時候去標識、控制和跟蹤需求的活動需求管理的目的是在客戶與開發(fā)方之間建立對需求的共同理解，維護需求與其它工作成果的一致性，并控制需求的變更。需求管理貫穿需求分析全過程，包括:需求管理變更控制建議變更分析影響交流合并測量需求的穩(wěn)定性版本控制定義需求文檔版本確定單個需求文檔版本需求跟蹤建立與維護“需求跟蹤矩陣”，確保產(chǎn)品依據(jù)需求文檔進行開發(fā)。需求狀態(tài)跟蹤定義需求狀態(tài)跟蹤所有需求狀態(tài)52二、需求管理需求管理是一組用于幫助項目組在項目進展中的任何時需求管理的所有活動中，最重要的是需求變更管理，包括:問題分析和變更描述變更分析和成本計算變更實現(xiàn)修正后的需求識別出的問題需求管理過程需要CASE(ComputerAidedSoftwareEngineering)工具支持。二、需求管理53需求管理的所有活動中，最重要的是需求變更管理，包括:系統(tǒng)分析員的主要能力在整個系統(tǒng)分析活動中，系統(tǒng)分析員起著關(guān)鍵的作用，其本人應(yīng)該具備以下能力：熟悉計算機技術(shù)；了解用戶業(yè)務(wù)領(lǐng)域的相關(guān)知識；能在用戶和開發(fā)人員之間借助于數(shù)據(jù)概念進行交流。同時從個人素質(zhì)上，分析師應(yīng)善于從原始材料中抽象出邏輯概念，將其重新整理之后成為各種邏輯成分，并根據(jù)各種邏輯成分綜合出問題的解決辦法，并善于用模型說話；能從沖突或者混淆中吸取恰當事實的能力；能弄清用戶環(huán)境的能力；能為用戶系統(tǒng)恰當配置軟硬件的能力能較好地用書面和口頭形式進行溝通的能力有“從樹木見森林”的能力。54系統(tǒng)分析員的主要能力在整個系統(tǒng)分析活動中，系統(tǒng)分析員起著關(guān)需求工程小結(jié)軟件需求工程,是軟件開發(fā)人員與用戶密切配合，充分交換意見，獲得對需求一致意見的過程。在開發(fā)者一方，參與工作的主要角色是系統(tǒng)分析員和系統(tǒng)工程師等，負責溝通用戶和開發(fā)人員的認識和見解，起著橋梁作用。需求工程階段的最終任務(wù)是要完成目標系統(tǒng)的需求規(guī)格說明，確定系統(tǒng)的功能、非功能需求和性能，為后階段的開發(fā)打下基礎(chǔ)。本階段常用的有SA法，OOA法等。55需求工程小結(jié)軟件需求工程,是軟件開發(fā)人員與用戶密切配合，充分需求工程軟件工程（SoftwareEngineering）56需求工程軟件工程1 通過對問題及其環(huán)境的理解與分析，為問題涉及的信息、功能及系統(tǒng)行為建立模型，將用戶需求精確化、完全化，最終形成需求規(guī)格說明，這一系列的活動即構(gòu)成軟件開發(fā)生命周期的需求分析階段。 軟件需求作為軟件生命周期的一個階段，其重要性越來越突出，到20世紀80年代中期，逐步形成了軟件工程的子領(lǐng)域——需求工程。

90年代后，需求工程成為軟件界研究的重點之一。從1993年起，每兩年舉辦一次需求工程國際研討會（ISRE），1994年起，每兩年舉辦一次需求工程國際會議（ICRE）。一些關(guān)于需求工程的工作小組相繼成立，使需求工程的研究得到了迅速進展。57 通過對問題及其環(huán)境的理解與分析，為問題涉及的信息、功能及系內(nèi)容摘要1.什么是需求工程？2.什么是軟件需求工程？3.軟件需求的重要性4.軟件需求的困難5.軟件需求內(nèi)容6.需求工程的活動58內(nèi)容摘要1.什么是需求工程？31)需求的基本概念

寬泛地講，需求來源于用戶的一些“需要”，這些“需要”被分析、確認后形成完整的文檔，該文檔詳細地說明了產(chǎn)品“必須或應(yīng)當”做什么。軟件需求——是指用戶對目標軟件系統(tǒng)在功能、行為、性能、設(shè)計約束等方面的期望。

2)需求工程(RE)的概念

是指應(yīng)用已證實有效的技術(shù)、方法進行需求分析，確定客戶需求，幫助分析人員理解問題并定義目標系統(tǒng)的所有外部特征的一門學科。需求分析專家AlanDavis把需求工程定義為“直到（但不包括）把軟件分解為實際架構(gòu)構(gòu)件之前的所有活動”RE通過合適的工具和記號系統(tǒng)地描述待開發(fā)系統(tǒng)及其行為特征和相關(guān)約束，形成需求文檔，并對用戶不斷變化的需求演進給予支持。1什么是需求工程591)需求的基本概念1什么是需求工程42.什么是軟件需求工程？需求工程RE可分為系統(tǒng)需求工程（如果是針對由軟硬件共同組成的整個系統(tǒng)）和軟件需求工程（如果僅是專門針對純軟件部分）。軟件需求工程——是一門分析并記錄軟件需求的學科，它把系統(tǒng)需求分解成一些主要的子系統(tǒng)和任務(wù)，把這些子系統(tǒng)或任務(wù)分配給軟件，并通過一系列重復(fù)的分析、設(shè)計、比較研究、原型開發(fā)過程把這些系統(tǒng)需求轉(zhuǎn)換成軟件的需求描述和一些性能參數(shù)。602.什么是軟件需求工程？需求工程RE可分為系統(tǒng)需求工程（如果 軟件需求無疑是當前軟件工程中的關(guān)鍵問題，沒有需求就沒有軟件。需求的重要性FrederickBrooks在他1987年經(jīng)典文章“NoSilverBullet”中闡述了需求的重要性：開發(fā)軟件系統(tǒng)最困難的部分就是準確說明開發(fā)什么。最困難的概念性工作是編寫出詳細的需求，包括所有面向用戶、面向機器和其它軟件系統(tǒng)的接口。此工作一旦做錯，將會給系統(tǒng)帶來極大的損害，并且以后對它修改也極為困難。

需求是產(chǎn)品的根源，需求工作的優(yōu)劣對產(chǎn)品影響最大。就像一條河流，如果源頭被污染了，那么整條河流也就被污染了。

國內(nèi)軟件業(yè)的痼疾：人們并不清楚究竟該做什么，但卻一直忙碌不停地開發(fā)。3.軟件需求的重要性61 軟件需求無疑是當前軟件工程中的關(guān)鍵問題，沒有需求就沒有軟件3.軟件需求的重要性美國于1995年開始對全國范圍內(nèi)的8000個軟件項目進行跟蹤調(diào)查。分析失敗的原因發(fā)現(xiàn)，與需求過程相關(guān)的原因占了45%，而其中缺乏最終用戶的參與以及不完整的需求又是兩大首要原因，各占13%和12%。未完成完成未實施完成623.軟件需求的重要性美國于1995年開始對4.軟件需求的困難軟件需求是軟件工程中最復(fù)雜的過程之一：應(yīng)用領(lǐng)域的廣泛性，它的實施無疑與各個應(yīng)用行業(yè)的特征密切相關(guān)。非功能性需求建模技術(shù)的缺乏及其與功能性需求有著錯綜復(fù)雜的聯(lián)系，大大增加了需求工程的復(fù)雜性。溝通上的困難，由于系統(tǒng)需求分析各方面人員有不同的著眼點和不同的知識背景，給需求工程的實施增加了人為的難度?？蛻粽f不清楚需求；需求自身經(jīng)常變動；分析人員或客戶理解有誤。

634.軟件需求的困難軟件需求是軟件工程中最復(fù)雜的過程之一：8真正的軟件需求獲取如此困難（漫畫）

64真正的軟件需求獲取如此困難（漫畫）9

需求工程是系統(tǒng)工程和軟件工程的一個交叉分支，涉及到軟件系統(tǒng)的目標、軟件系統(tǒng)提供的服務(wù)、軟件系統(tǒng)的約束和軟件系統(tǒng)運行的環(huán)境。它還涉及這些因素和系統(tǒng)的精確規(guī)格說明以及系統(tǒng)進化之間的關(guān)系。它也提供現(xiàn)實需求和軟件能力之間的橋梁。需求工程系統(tǒng)目標系統(tǒng)服務(wù)軟件約束運行環(huán)境5.軟件需求內(nèi)容65需求工程是系統(tǒng)工程和軟件工程的一個交叉軟件需求用戶需求系統(tǒng)需求功能需求非功能需求領(lǐng)域需求由客戶管理員、用戶等提出軟件需求的內(nèi)容5.軟件需求內(nèi)容66軟件需求用戶需求系統(tǒng)需求功能需求非功能需求領(lǐng)域需功能需求它是對系統(tǒng)應(yīng)該提供的服務(wù)、功能以及系統(tǒng)在特定條件下的行為的描述。它與軟件系統(tǒng)的類型、使用系統(tǒng)的用戶等相關(guān)，有時需要詳細描述系統(tǒng)的功能、輸入/輸出、異常等，有時還需要申明系統(tǒng)不應(yīng)該做什么。領(lǐng)域需求是由軟件系統(tǒng)的應(yīng)用領(lǐng)域所決定的特有的功能需求，或是對功能的約束。67功能需求領(lǐng)域需求12非功能需求產(chǎn)品需求機構(gòu)需求外部需求互操作需求道德需求立法需求性能需求空間需求交付需求實現(xiàn)需求標準需求隱私需求安全性需求可用性需求效率需求可靠性需求可移植性需求非功能需求68非功能需求產(chǎn)品需求機構(gòu)需求外部需求互操作道德立法性能空間交付因此系統(tǒng)應(yīng)該具備以下功能：⑴基本數(shù)據(jù)維護功能⑵基本業(yè)務(wù)功能⑶數(shù)據(jù)庫管理功能⑷信息查詢功能例1：有一個大學圖書管理系統(tǒng)，該系統(tǒng)除了一般的圖書管理功能外，還能夠為學生和教工從其他圖書館借閱圖書和文獻資料提供服務(wù)。69因此系統(tǒng)應(yīng)該具備以下功能：例1：有一個大學圖書管理系統(tǒng)，該系1.功能需求⑴基本數(shù)據(jù)維護功能：提供使用者錄入，修改并進行維護基本數(shù)據(jù)的途徑?；緮?shù)據(jù)包括讀者的信息、圖書資料的相關(guān)信息，可以對這些信息進行修改，更新。⑵基本業(yè)務(wù)功能：讀者借、還書籍的登記管理功能，隨時根據(jù)讀者借、還書籍的情況更新數(shù)據(jù)庫系統(tǒng)，可以進行書籍的編目、入庫、更新等操作。701.功能需求15⑶數(shù)據(jù)庫管理功能：對所有圖書信息及讀者信息進行統(tǒng)一管理維護的功能，對書籍的借還也要進行詳細的登記，以便協(xié)調(diào)整個圖書館的運作。⑷信息查詢功能：提供對各類信息的查詢功能，如對本圖書館的用戶借書信息，還書的信息，書籍源信息等進行查詢，對其他圖書館的書籍、資料源信息的查詢功能。71⑶數(shù)據(jù)庫管理功能：162.非功能需求①系統(tǒng)安全性需求：為保證系統(tǒng)安全性，對本圖書館的各項功能進行分級、分權(quán)限操作，對各類用戶進行確認。對其它圖書館借閱圖書和文獻資料服務(wù)控制訪問范圍：如限IP、限用戶等。②對系統(tǒng)可用性的需求：為了方便使用者，要求對所有交互操作提供在線幫助功能。③對系統(tǒng)查詢速度的需求：要求系統(tǒng)在20S之內(nèi)響應(yīng)查詢服務(wù)請求。④對系統(tǒng)可靠性的需求：要求系統(tǒng)失敗發(fā)生率小于1%。722.非功能需求173.領(lǐng)域需求例如：對“大學圖書管理系統(tǒng)”，提出一些與圖書管理的業(yè)務(wù)相關(guān)的需求：⑴圖書編目要求按照《中國圖書館分類法》進行；⑵由于版權(quán)限制，某些文獻資料只能在圖書館規(guī)定的閱覽室閱讀，并限制復(fù)制和打印。第一條需求是對遵循我國圖書管理的規(guī)定，執(zhí)行對圖書的分類管理的標準。而第二條需求則是版權(quán)法對圖書館文獻資料的保護的需要，描述了對一類文獻資料有限制的使用和服務(wù)。733.領(lǐng)域需求18

HerbKrasner定義了需求工程的五階段生命周期：需求定義和分析、需求決策、形成需求規(guī)格、需求實現(xiàn)與驗證、需求演進管理 MatthiasJarke和KlausPohl提出了三階段周期的說法：獲取、表示和驗證 本書將軟件需求工程細分為：需求獲取、需求分析與協(xié)商、系統(tǒng)建模、需求規(guī)約、需求驗證和需求管理六個階段。……6.需求工程的活動74HerbKrasner定義了需求工程需求工程中的活動可分為兩大類:一、需求開發(fā)二、需求管理6.需求工程的活動75需求工程中的活動可分為兩大類:6.需求工程的活動20一、需求開發(fā)需求開發(fā)的任務(wù)是準確地定義未來系統(tǒng)的目標，確定為了滿足用戶的需求系統(tǒng)必須做什么。用《需求規(guī)格說明書》規(guī)范的形式準確地表達用戶的需求。需求開發(fā)的目的是通過調(diào)查與分析，獲取用戶需求并定義產(chǎn)品需求。（1）需求獲取的目的是深入實際，通過各種途徑,在充分理解用戶需求的基礎(chǔ)上，獲取用戶的需求信息。（2）需求分析、協(xié)商與建模的目的是對各種需求信息進行分析，消除錯誤，刻畫細節(jié)等。（3）需求規(guī)格說明目的是根據(jù)需求獲取和需求分析的結(jié)果，進一步定義準確無誤的產(chǎn)品需求，產(chǎn)生《需求規(guī)格說明書》。系統(tǒng)設(shè)計人員將依據(jù)《需求規(guī)格說明書》開展系統(tǒng)設(shè)計工作。（4）需求驗證是指開發(fā)方和客戶共同對需求文檔進行評審，雙方對需求達成共識后作出書面承諾，使需求文檔具有商業(yè)合同效果。確保需求說明準確、完整地表達系統(tǒng)的主要特性。76一、需求開發(fā)需求開發(fā)的任務(wù)是準確地定義未來系統(tǒng)的目標，確需求獲取是需求工程的主體,非常困難，主要原因有：●缺乏領(lǐng)域知識,應(yīng)用領(lǐng)域的問題常常是模糊的、不精確的；●存在默認的知識,如難以描述的常識問題；●存在多個知識源,且多知識源之間可能有沖突；●客戶可能的偏見，如不能提供或不想告知你所需要了解的事情。(一)、需求獲取(requirementelicitation)77需求獲取是需求工程的主體,非常困難，主要原因有：(一)、需求需求獲取技術(shù)1.面談法重要而直接，簡單的需求獲取技術(shù)。2.問卷法調(diào)查法是對面談法的補充。

3.需求專題討論會最有力的需求獲取技術(shù)。有利于培養(yǎng)高效團隊。4.觀察用戶的工作流程適用于用戶無法準確表達需求的情況。5.原型化方法6.基于用例的方法還有知識工程方法等如：場記分析法、卡片分類法、分類表格技術(shù)和基于模型的知識獲取等。面談的對象主要有用戶和領(lǐng)域?qū)＜遥?）面談前的準備要充分；2）面談后注意認真分析總結(jié)；3）注意掌握面談的人際交流技能。

78需求獲取技術(shù)還有知識工程方法等如：場記分析法需求獲取技術(shù)1.面談法重要而直接，簡單的需求獲取技術(shù)。2.問卷法調(diào)查法是對面談法的補充。

3.需求專題討論會最有力的需求獲取技術(shù)。有利于培養(yǎng)高效團隊。4.觀察用戶的工作流程適用于用戶無法準確表達需求的情況。5.原型化方法6.基于用例的方法是從多個用戶中收集需求信息的有效方式，一般問卷設(shè)計形式：1）多項選擇問題；2）評分問題；3）排序問題。79需求獲取技術(shù)1.面談法重要而直接，簡單的需求獲取技術(shù)。是從需求獲取技術(shù)

1.面談法重要而直接，簡單的需求獲取技術(shù)。2.問卷法調(diào)查法是對面談法的補充。

3.需求專題討論會最有力的需求獲取技術(shù)。有利于培養(yǎng)高效團隊。4.觀察用戶的工作流程適用于用戶無法準確表達需求的情況。5.原型化方法6.基于用例的方法由開發(fā)方和用戶方共同召開,操作步驟：①開發(fā)方根據(jù)雙方制定的《需求調(diào)研計劃》召開相關(guān)需求主題溝通會；②會后開發(fā)方整理出《需求調(diào)研記錄》提交給用戶方確認；③如果此主題還有未明確的問題則再次溝通,否則開始下一主題；④所有需求都溝通清楚后，開發(fā)方根據(jù)歷次《需求調(diào)研記錄》整理出《用戶需求說明書》，提交給用戶方確認簽字。80需求獲取技術(shù)由開發(fā)方和用戶方共同召開,操作步驟：25

需求分析階段主要對收集到的需求進行提煉、分析和認真審查，進行需求建模、對模型或原型進行分析。確保所有參加人員取得一致共識。找出錯誤、遺漏和不足，建立完整的分析模型。(二)、需求分析、協(xié)商與建模81(二)、需求分析、協(xié)商與建模261、確定系統(tǒng)的綜合要求

系統(tǒng)功能要求—這是最主要的需求，確定系統(tǒng)必須完成的所有功能。

系統(tǒng)性能要求—應(yīng)就具體系統(tǒng)而定，例如可靠性、聯(lián)機系統(tǒng)的響應(yīng)時間、存儲容量、安全性能等。

系統(tǒng)運行要求—主要是對系統(tǒng)運行時的環(huán)境要求，如系統(tǒng)軟件、數(shù)據(jù)庫管理系統(tǒng)、外存和數(shù)據(jù)通信接口等。

將來可能提出的要求—對將來可能提出的擴充及修改作預(yù)準備。2、分析系統(tǒng)的數(shù)據(jù)要求軟件系統(tǒng)本質(zhì)上是信息處理系統(tǒng)，因此，必須考慮：

數(shù)據(jù)（需要哪些數(shù)據(jù)、數(shù)據(jù)間聯(lián)系、數(shù)據(jù)性質(zhì)、結(jié)構(gòu)）數(shù)據(jù)處理（處理的類型、處理的邏輯功能）3、導(dǎo)出系統(tǒng)的邏輯模型。4、修正系統(tǒng)的開發(fā)計劃—通過需求對系統(tǒng)的成本及進度有了更精確的估算，可進一步修改開發(fā)計劃。需求分析、協(xié)商與建模的具體任務(wù)821、確定系統(tǒng)的綜合要求需求分析、協(xié)商與建模的具體任務(wù)27當前系統(tǒng)目標系統(tǒng)物理模型邏輯模型邏輯模型物理模型模型化抽象化具體化實例化怎么做做什么當前系統(tǒng)目標系統(tǒng)需求定義需求分析的一般步驟83當前目標物理邏輯邏輯物理模型化抽象化具體化實例化怎做當前目標1．必須能夠表示和理解問題的信息域2．必須能夠定義軟件將完成的功能3．必須能夠表示軟件的行為(作為外部事件的結(jié)果)4．必須劃分描述數(shù)據(jù)、功能和行為的模型，從而可以分層次地揭示細節(jié)5．分析過程應(yīng)該從要素信息移向細節(jié)信息需求分析操作原則841．必須能夠表示和理解問題的信息域需求分析操作原則29信息域信息域：包括信息內(nèi)容、信息流、以及信息結(jié)構(gòu)。信息內(nèi)容表示了單個數(shù)據(jù)和控制對象，目標軟件所有處理的信息集合由它們構(gòu)成。例如，數(shù)據(jù)對象“工資”是一組重要數(shù)據(jù)體的組合：領(lǐng)款人的姓名、凈付款數(shù)、付款總額、扣除額等等信息流表示了數(shù)據(jù)和控制在系統(tǒng)中流動時的變化方式，輸入對象被變換為中間信息(數(shù)據(jù)和/或控制)，然后進一步被變換為輸出信息結(jié)構(gòu)表示了各種數(shù)據(jù)和控制項的內(nèi)部組織數(shù)據(jù)或控制項將被組織為n維表還是樹形結(jié)構(gòu)？在結(jié)構(gòu)的語境內(nèi)，什么信息是和其他信息相關(guān)的？信息包含在單個結(jié)構(gòu)中，還是使用不同的結(jié)構(gòu)？在某信息結(jié)構(gòu)中的信息如何和在另一個結(jié)構(gòu)中的信息相關(guān)？85信息域信息域：包括信息內(nèi)容、信息流、以及信息結(jié)構(gòu)。30需求工程的指導(dǎo)性原則除了上面提到的操作性分析原則，Davis提出了一組針對需求工程的指導(dǎo)性原則：

在開始建立分析模型前，先充分理解問題。開發(fā)原型，使得用戶能夠了解如何進行人機交互。記錄每個需求的起源及原因。使用多個需求視圖。建立數(shù)據(jù)、功能和行為模型，為軟件工程師提供三種不同的視圖。給需求賦予優(yōu)先級。努力刪除歧義性。86需求工程的指導(dǎo)性原則除了上面提到的操作性分析原則，Davis常用的需求分析方法：功能分解方法面向數(shù)據(jù)流的結(jié)構(gòu)化分析方法(SA)面向數(shù)據(jù)結(jié)構(gòu)的分析方法信息建模法面向?qū)ο蟮姆治龇椒?OOA)87常用的需求分析方法：功能分解方法32功能分解方法

將系統(tǒng)看作若干功能模塊的集合，每個功能又可以分解為子功能,子功能還可繼續(xù)分解,分解的結(jié)果即是系統(tǒng)的雛形。存在問題1.需要人工完成2.無法對描述的準確度進行驗證。3.難以適應(yīng)需求的變化。問題空間功能子功能映射88功能分解方法存在問題問題空間功能映射331．客房預(yù)定系統(tǒng)2．前臺接待系統(tǒng)3．前臺收銀系統(tǒng)4．帳務(wù)系統(tǒng)

5．管家系統(tǒng)6．電話系統(tǒng)

7．客歷系統(tǒng)8．合約系統(tǒng)

9．經(jīng)理系統(tǒng)10．總經(jīng)理系統(tǒng)

11．密碼管理系統(tǒng)12．報表系統(tǒng)

13．帳務(wù)報表酒店管理系統(tǒng)例：按照功能分解為以下子系統(tǒng)：891．客房預(yù)定系統(tǒng)2．前臺接待系統(tǒng)酒店管理盤存/銷售系統(tǒng)1.0.0銷售處理1.1.0盤存處理1.2.0例：盤存/銷售系統(tǒng)，用戶提出,系統(tǒng)應(yīng)具有以下功能:①計算買主訂單②準備銷售報表③建立買主文件和應(yīng)收帳發(fā)票④運行更新的盤存文件

⑤產(chǎn)生托運單和包裝單⑥保證庫存及時訂貨計算銷售記錄1.1.1產(chǎn)生銷售報表1.1.2核對買主貸方金額1.1.3驗證庫存量級1.2.1產(chǎn)生貨運訂單1.2.2執(zhí)行買主匯票1.2.3產(chǎn)生盤存報表1.2.490盤存/銷售系統(tǒng)銷售處理盤存處理例：盤存/銷售系統(tǒng)，用戶提出,結(jié)構(gòu)化分析方法結(jié)構(gòu)化分析方法是面向數(shù)據(jù)流的需求分析方法，是20世紀70年代末由Yourdon,Constaintine及DeMarco等人提出和發(fā)展，并得到廣泛的應(yīng)用。它適合于分析大型的數(shù)據(jù)處理系統(tǒng)，特別是企事業(yè)管理系統(tǒng)。SA法也是一種建模的活動，主要是根據(jù)軟件內(nèi)部的數(shù)據(jù)傳遞、變換關(guān)系，自頂向下逐層分解，描繪出滿足功能要求的軟件模型。91結(jié)構(gòu)化分析方法36面向?qū)ο蟮姆治龇椒?/p>

面向?qū)ο蟮姆治龇椒?OOA)的關(guān)鍵是識別問題域內(nèi)的對象,分析它們之間的關(guān)系,并建立起三類模型。信息建模法

是從數(shù)據(jù)的角度對現(xiàn)實世界建立系統(tǒng)的信息模型,基本工具是ER圖。是由實體、屬性和關(guān)系組成的網(wǎng)絡(luò)圖。E-實體，是一個或一組對象；R-關(guān)系，實體之間聯(lián)系或交互作用。92面向?qū)ο蟮姆治龇椒ㄐ畔⒔７?7需求協(xié)商協(xié)商的過程就是討論需求沖突，找出每個人都滿意的折衷方案協(xié)商不是簡單的邏輯或技術(shù)上的爭論要注意組織和行政方面的因素①不一致的目標②責任的喪失或轉(zhuǎn)移③組織文化④組織管理態(tài)度和士氣⑤部門差異93需求協(xié)商協(xié)商的過程就是討論需求沖突，找出每個人都滿意的折衷通常會議是解決沖突最快的方式參加者應(yīng)該包括發(fā)現(xiàn)沖突、遺漏或重疊的分析員，以及可以解決發(fā)現(xiàn)的問題的項目相關(guān)人員會議應(yīng)該討論那些非正式討論不能解決的問題通常會議分為三個階段：敘述階段討論階段決策階段94通常會議是解決沖突最快的方式39需求建模在軟件需求分析階段，所創(chuàng)建的模型，要著重于描述系統(tǒng)要做什么，而不是如何去做目標軟件的模型不應(yīng)涉及軟件實現(xiàn)細節(jié)典型分析建模方法結(jié)構(gòu)化分析(傳統(tǒng)建模方法)面向?qū)ο蠓治?5需求建模在軟件需求分析階段，所創(chuàng)建的模型，要著重于描述系統(tǒng)計算機世界現(xiàn)實世界結(jié)構(gòu)化開發(fā)方法結(jié)構(gòu)化分析結(jié)構(gòu)化設(shè)計結(jié)構(gòu)化編程OOAOODOOP面向?qū)ο箝_發(fā)方法模型的作用96計算機世界現(xiàn)實世界結(jié)結(jié)構(gòu)化結(jié)構(gòu)化結(jié)構(gòu)化OOAOODOOP面模面向?qū)ο蠓治瞿Ｐ偷慕M成結(jié)構(gòu)對象-關(guān)系模型類/對象模型對象-行為模型使用實例(UseCase)操作、屬性、協(xié)作者97面向?qū)ο蠓治瞿Ｐ偷慕M成結(jié)構(gòu)對象-關(guān)類/對象對象-行為模型使用數(shù)據(jù)流圖(DFD)E-R圖狀態(tài)變遷圖(STD圖)加工說明控制說明數(shù)據(jù)對象說明數(shù)據(jù)字典（DD）結(jié)構(gòu)化分析模型的組成結(jié)構(gòu)98數(shù)據(jù)流圖E-R圖狀態(tài)變遷圖加工說明控制說明數(shù)據(jù)對說數(shù)據(jù)字典結(jié)結(jié)構(gòu)化分析模型的元素數(shù)據(jù)字典(DD)：模型核心(中心庫)數(shù)據(jù)流圖(DFD)

指明數(shù)據(jù)在系統(tǒng)中移動時如何被變換;描述對數(shù)據(jù)流進行變換的功能;DFD中每個功能的描述包含在加工規(guī)約(小說明)。E-R圖(ERD)狀態(tài)變遷圖(STD)指明作為外部事件的結(jié)果,系統(tǒng)將如何動作。99結(jié)構(gòu)化分析模型的元素數(shù)據(jù)字典(DD)：模型核心(中心庫)44(三)需求規(guī)格說明(需求規(guī)約)采用原始模板，在你的組織中要為編寫軟件需求文檔定義一種標準模板指明需求的來源為每項需求注上標號制定一種慣例來為每項需求提供一個獨立的可識別的標號或記號記錄業(yè)務(wù)規(guī)范100(三)需求規(guī)格說明(需求規(guī)約)采用原始模板，在你的組織中要為需求規(guī)約的原則1．從現(xiàn)實中分離功能，即描述要“做什么”而不是“怎樣實現(xiàn)”。2．要求使用面向處理的規(guī)約語言（或稱系統(tǒng)定義語言），討論來自環(huán)境的各種刺激可能導(dǎo)致系統(tǒng)做出什么樣的功能性反應(yīng)，來定義一個行為模型，從而得到“做什么”的規(guī)約。3．如果被開發(fā)軟件只是一個基于計算機的系統(tǒng)中的一個元素，那么整個大系統(tǒng)也包括在規(guī)格說明的描述之中。4．規(guī)約必須包括系統(tǒng)運行環(huán)境。10