...wd......wd......wd...2.2需求分析需求分析是通過開發人員的分析概括，抽象為完整的需求定義，再形成一系列文檔的過程。2.2.1需求分析的目的與意義需求分析是一個非常重要的過程，它完成的好壞直接影響后續軟件開發的質量。有效的需求分析通常都具有一定的難度。需求分析不僅僅是屬于軟件開發生命周期早期的一項工作，而且還應該貫穿于整個生命周期中，它應該隨著工程的深入而不斷地變化。此外，為了方便后續的評審和測試等工作，需求的描述應該盡量做到：具體、詳細、可以測量和可以實現，并且基于時間。

2.2.2需求分析的步驟遵循科學的需求分析步驟可以使需求分析工作更高效。需求分析的一般步驟如圖2-3所示。

圖2-3需求分析的步驟需求涉及的方面：在功能方面，需求包括系統要做什么，相對于原系統目標系統需要進展哪些修改，目標用戶有哪些，以及不同用戶需要通過系統完成何種操作等。在性能方面，需求包括用戶對于系統執行速度、響應時間、吞吐量和并發度等指標的要求。在運行環境方面，需求包括目標系統對于網絡設置、硬件設備、溫度和濕度等周圍環境的要求，以及對操作系統、數據庫和瀏覽器等軟件配置的要求。在界面方面，需求涉及數據的輸入/輸出格式的限制及方式、數據的存儲介質和顯示器的分辨率要求等問題。1.獲取需求，識別問題開發人員從功能、性能、界面和運行環境等多個方面識別目標系統要解決哪些問題，要滿足哪些限制條件，這個過程就是對需求的獲取。開發人員通過調查研究，要理解當前系統的工作模型和用戶對新系統的設想與要求。遺漏需求是最難修訂的需求錯誤。獲取需求是需求分析的根基。為了能有效地獲取需求，開發人員應該采取科學的需求獲取方法。在實踐中，獲取需求的方法有很多種，比方，問卷調查、訪談、實地操作、建設原型和研究資料等。問卷調查法是采用調查問卷的形式來進展需求分析的一種方法。通過對用戶填寫的調查問卷進展匯總、統計和分析，開發人員便可以得到一些有用的信息。采用這種方法時，調查問卷的設計很重要。一般在設計調查問卷時，要合理地控制開放式問題和封閉式問題的比例。開放式問題的答復不受限制，自由靈活，能夠激發用戶的思維，使他們能盡可能地闡述自己的真實想法。但是，對開放式問題進展匯總和分析的工作會比擬復雜。封閉式問題的答案是預先設定的，用戶從假設干答案中進展選擇。封閉式問題便于對問卷信息進展歸納與整理，但是會限制用戶的思維。訪談通過開發人員與特定的用戶代表進展座談，進而了解到用戶的意見，是最直接的需求獲取方法。為了使訪談有效，在進展訪談之前，開發人員要首先確定訪談的目的，進而準備一個問題列表，預先準備好希望通過訪談解決的問題。在訪談的過程中，開發人員要注意態度誠懇，并保持虛心求教的姿態，同時還要對重點問題進展深入的討論。由于被訪談的用戶身份可能多種多樣，開發人員要根據用戶的身份特點，進展提問，給予啟發。當然，進展詳細的記錄也是訪談過程中必不可少的工作。訪談完成后，開發人員要對訪談的收獲進展總結，澄清已解決的和有待進一步解決的問題。關注用戶的行為而不是他們的言語。為了深入地了解用戶需求，有時候開發人員還會以用戶的身份直接參與到現有系統的使用過程中，在親身實踐的根基上，更直接地體會現有系統的弊端以及新系統應該解決的問題，這種需求獲取方法就是實地操作。通過實地操作得到的信息會更加準確和真實，但是這種方法會比擬費時間。當用戶本身對需求的了解不太清晰的時候，開發人員通常采用建設原型系統的方法對用戶需求進展挖掘。原型系統就是目標系統的一個可操作的模型。在初步獲取需求后，開發人員會快速地開發一個原型系統。通過對原型系統進展模擬操作，開發人員能及時獲得用戶的意見，從而對需求進展明確。利用原型系統獲取需求的方法的示意圖如圖2-4所示。

〔點擊查看大圖〕圖2-4利用原型系統獲取需求2.分析需求，建設目標系統的邏輯模型在獲得需求后，開發人員應該對問題進展分析抽象，并在此根基上從高層建設目標系統的邏輯模型。模型是對事物高層次的抽象，通常由一組符號和組織這些符號的規則組成。常用的模型圖有數據流圖、E-R圖、用例圖和狀態轉換圖等，不同的模型從不同的角度或不同的側重點描述目標系統。繪制模型圖的過程，既是開發人員進展邏輯思考的過程，也是開發人員更進一步認識目標系統的過程。3.將需求文檔化獲得需求后要將其描述出來，即將需求文檔化。對于大型的軟件系統，需求階段一般會輸出三個文檔：系統定義文檔〔用戶需求報告〕；系統需求文檔〔系統需求規格說明書〕；軟件需求文檔〔軟件需求規格說明書〕。對于簡單的軟件系統而言，需求階段只需要輸出軟件需求文檔〔即軟件需求規格說明書〕就可以了。軟件需求規格說明書主要描述軟件的需求，從開發人員的角度對目標系統的業務模型、功能模型和數據模型等內容進展描述。作為后續的軟件設計和測試的重要依據，需求階段的輸出文檔應該具有清晰性、無二義性和準確性，并且能夠全面和確切地描述用戶需求。4.需求驗證需求驗證是對需求分析的成果進展評估和驗證的過程。為了確保需求分析的正確性、一致性、完整性和有效性，提高軟件開發的效率，為后續的軟件開發做好準備，需求驗證的工作非常必要。在需求驗證的過程中，可以對需求階段的輸出文檔進展多種檢查，比方，一致性檢查、完整性檢查和有效性檢查等。同時，需求評審也是在這個階段進展的。

2.3構造化需求分析的方法構造化需求分析是20世紀70年代由Yourdon、Constaintine及DeMarco提出的一種面向數據流的需求分析方法。它基于"分解"和"抽象"的根本思想，逐步建設目標系統的邏輯模型，進而描繪出滿足用戶要求的軟件系統。"分解"是指對于一個復雜的系統，為了將復雜性降低到可以掌握的程度，可以把大問題分解為假設干個小問題，然后再分別解決。圖2-5演示了對目標系統X進展自頂向下逐層分解的示意圖。

〔點擊查看大圖〕圖2-5自頂向下逐層分解最頂層描述了整個目標系統，中間層將目標系統劃分為假設干個模塊，每個模塊完成一定的功能，而最底層是對每個模塊實現方法的細節性描述?？梢?，在逐層分解的過程中，起初并不考慮細節性的問題，而是先關注問題最本質的屬性，隨著分解自頂向下進展，才逐漸考慮越來越具體的細節。這種用最本質的屬性表示一個軟件系統的方法就是"抽象"。抽象是一種人類處理復雜問題的根本方法。分解和抽象是構造化需求分析的根本指導思想。在構造化需求分析的過程中，通常還需要借助數據流程圖、數據字典、E-R圖、構造化語言、判定表、判定樹等工具。接下來我們介紹數據流圖、數據字典和E-R圖的相關知識。

2.4構造化需求分析的工具2.4.1數據流圖數據流圖〔DataFlowDiagram，DFD〕是描述系統中數據流的圖形工具，是一種用來表示信息流和信息變換過程的圖解方法，可以標識一個系統的邏輯輸入和邏輯輸出，以及把邏輯輸入轉換為邏輯輸出所需的加工處理。數據流圖把軟件系統看成是由數據流聯系的各種功能的組合，在需求分析的過程中，可以用來建設目標系統的邏輯模型。構造化需求分析采用的是"自頂向下，由外到內，逐層分解"的思想，開發人員要先畫出系統頂層的數據流圖，然后再逐層畫出低層的數據流圖。頂層的數據流圖要定義系統范圍，并描述系統與外界的數據聯系，它是對系統架構的高度概括和抽象。底層的數據流圖是對系統某個局部的精細描述。數據流圖的目的是在用戶和系統開發人員之間提供語義的橋梁。--KennethKozar按照Gane-Sarson法，在繪制數據流圖的過程中，主要用到了4個根本符號，如表2-1所示。表2-1數據流圖的根本符號

1SA法概述SA法也是一種建模的活動，主要是根據軟件內部的數據傳遞、變換關系，自頂向下逐層分解，描繪出滿足功能要求的軟件模型。1．SA法的根本思想構造化分析〔StructuredAnalysis，簡稱SA法〕是面向數據流的需求分析方法，是70年代由Yourdon,Constaintine及DeMarco等人提出和開展，并得到廣泛的應用。構造化分析方法的根本思想是“分解〞和“抽象〞。分解：是指對于一個復雜的系統，為了將復雜性降低到可以掌握的程度，可以把大問題分解成假設干小問題，然后分別解決。圖4是自頂向下逐層分解的示意圖。頂層抽象地描述了整個系統，底層具體地畫出了系統的每一個細節，而中間層是從抽象到具體的逐層過渡。抽象：分解可以分層進展，即先考慮問題最本質的屬性，暫把細節略去，以后再逐層添加細節，直至涉及到最詳細的內容，這種用最本質的屬性表示一個自系統的方法就是“抽象〞。2．SA法的步驟⑴建設當前系統的“具體模型〞；系統的“具體模型〞就是現實環境的忠實寫照，即將當前系統用DFD圖描述出來。這樣的表達與當前系統完全對應，因此用戶容易理解。⑵抽象出當前系統的邏輯模型；分析系統的“具體模型〞，抽象出其本質的因素，排除次要因素，獲得用DFD圖描述的當前系統的“邏輯模型〞。⑶建設目標系統的邏輯模型；分析目標系統與當前系統邏輯上的差異，從而進一步明確目標系統“做什么〞，建設目標系統的“邏輯模型〞〔修改后的DFD圖〕。⑷為了對目標系統作完整的描述，還需要考慮人機界面和其它一些問題。3．SA法的描述工具⑴分層的數據流圖⑵數據詞典⑶描述加工邏輯的構造化語言、判定表或判定樹。2數據流圖數據流圖〔DataFlowDiagram，簡稱DFD〕是描述系統中數據流程的圖形工具，它標識了一個系統的邏輯輸入和邏輯輸出，以及把邏輯輸入轉換邏輯輸出所需的加工處理。1．數據流圖的圖符數據流圖有以下4種根本圖形符號：箭頭表示數據流，圓或橢圓表示加工。雙杠或者單杠表示數據存儲，矩形框表示數據的源點或終點，即外部實體。⑴數據流是數據在系統內傳播的路徑，由一組成固定的數據項組成。除了與數據存儲〔文件〕之間的數據流不用命名外，其余數據流都應該用名詞或名詞短語命名。數據流可以從加工流向加工，也可以從加工流向文件或從文件流向加工，也可以從源點流向加工或從加工流向終點。⑵加工也稱為數據處理，它對數據流進展某些操作或變換。每個加工也要有名字，通常是動詞短語，簡明地描述完成什么加工。在分層的數據流圖中，加工還應有編號。⑶數據存儲指暫時保存的數據，它可以是數據庫文件或任何形式的數據組織。流向數據存儲的數據流可理解為寫入文件，或查詢文件，從數據存儲流出的數據可理解為從文件讀數據或得到查詢結果。⑷數據源點和終點是軟件系統外部環境中的實體〔包括人員、組織或其他軟件系統〕，統稱為外部實體。一般只出現在數據流圖的頂層圖中。還有一些輔助的圖例:例1：畫出圖書預定系統的DFD圖?，F有一圖書預定系統，接收由顧客發來的訂單，并對訂單進展驗證，驗證過程是根據圖書目錄檢查訂單的正確性，同時根據顧客檔案確定是新顧客還是老顧客，是否有信譽。經過驗證的正確訂單，暫存放在待處理的訂單文件中。對訂單進展成批處理，根據出版社檔案，將訂單按照出版社進展分類匯總，并保存訂單存根，然后將匯總訂單發往各出版社。畫圖步驟是：⑴首先確定外部實體〔顧客、出版社〕及輸入、輸出數據流〔訂單、出版社訂單〕。⑵再分解頂層的加工〔驗證訂單、匯總訂單〕。⑶確定所使用的文件〔圖書目錄文件、顧客檔案等5個文件〕。⑷用數據流將各局部連接起來，形成數據封閉。特別要注意的是：數據流圖不是傳統的流程圖或框圖，數據流也不是控制流。數據流圖是從數據的角度來描述一個系統，而框圖則是從對數據進展加工的工作人員的角度來描述系統。數據流圖中的箭頭是數據流，而框圖中的箭頭則是控制流，控制流表達的是程序執行的次序。以下列圖是培訓中心管理系統的數據流圖，由于只有一層，因此分解的加工較多不易理解，而且如果其中某個加工較復雜，例如編號為3的加工“付款〞和編號為7的加工“復審〞仍很復雜，一時難以理解，如果不繼續分解下去，直到每個加工都足夠簡單易于理解為止，則會影響需求分析結果的可讀性。1．畫分層DFD圖的方法如圖2.8所示，如果系統規模較大，僅用一個DFD圖難以描述，會使得系統變得復雜，且難以理解。為了降低系統的復雜性，采取“逐層分解〞的技術，畫分層的DFD圖。畫分層DFD圖的一般原則是：“先全局后局部,先整體后細節,先抽象后具體〞。通常將這種分層的DFD圖,分為頂層、中間層、底層。頂層圖說明了系統的邊界,即系統的輸入和輸出數據流，頂層圖只有一張。底層圖由一些不能再分解的加工組成，這些加工都已足夠簡單，稱為根本加工。在頂層和底層之間的是中間層。中間層的數據流圖描述了某個加工的分解，而它的組成局部又要進一步分解。畫各層DFD圖時，應“由外向內〞。畫分層DFD圖的具體步驟：⑴先確定系統范圍，畫出頂層的DFD圖。⑵逐層分解頂層DFD圖，獲得假設干中間層DFD圖。⑶畫出底層的DFD圖。在畫分層數據流圖時，首先遇到的問題就是應該如何分解不能夠一下子把一個加工分解成它所有的根本加工，一張圖中畫出過多的加工是使人難以理解的，但是如果每次只是將一個加工分解成兩個或三個加工，又可能需要分解過多的層次，也會影響系統的可理解性。一個加工每次分解成多少個子加工才適宜呢?根據經歷“最多不要超過7個〞。統計結果證明，人們能有效地同時處理7個或7個以下的問題，但當問題多于7個時，處理效果就會下降。當然也不能機械地應用，關鍵是要使數據流圖易于理解。同時還有幾條原則可供參考：分解應自然，概念上要合理、清晰。只要不影響數據流圖的“易理解性〞，可以適當地多分解成幾局部，這樣分層圖的層數就可少些。一般來說，在上層可以分解得快些，而在中、下層則應分解得慢些，因為上層是一些綜合性的描述，“易理解性〞相對地說不太重要。下節我們以一個實例來說明畫分層DFD圖的方法。2分層DFD圖的改良分層數據流圖是一種比擬嚴格又易于理解的描述方式，它的頂層描繪了系統的總貌，底層畫出了系統所有的細部，而中間層則給出了從抽象到具體的逐步過渡。1．畫分層DFD圖的根本原則⑴．數據守恒與數據封閉原則所謂數據守恒是指加工的輸入輸出數據流是否匹配，即每一個加工既有輸入數據流又有輸出數據流。或者說一個加工至少有一個輸入數據流，一個輸出數據流。⑵加工分解的原則自然性：概念上合理、清晰；均勻性：理想的分解是將一個問題分解成大小均勻的幾個局部；分解度：一般每一個加工每次分解最多不要超過７個子加工,應分解到根本加工為止。⑶子圖與父圖的“平衡〞父圖中某個加工的輸入輸出數據流應該同相應的子圖的輸入輸出一樣(相對應)，分層數據流圖的這種特點稱為子圖與父圖“平衡〞。例1考察以下列圖中子父圖的平衡顯然，圖2.13中子圖與父圖不平衡。子圖是父圖中加工2的分解，加工2有輸入數據流R和M，輸出數據流T，而子圖則只有一個輸入數據流N，卻有兩個輸出數據流T與S。圖2.14中，子圖是父圖中加工4的分解，雖然外表上加工4只有一個輸入數據流“訂貨單〞，而子圖卻有三個輸入數據流，但是如果“訂貨單〞是由“客戶〞、“帳號〞和“數量〞三局部組成，即有如下數據條目：訂貨單=客戶+帳號+數量〔2.2.5數據詞典〕，則子、父圖平衡。⑷合理使用文件當文件作為某些加工之間的交界面時，文件必須畫出來，一旦文件作為數據流圖中的一個獨立成份畫出來了為了對數據流圖有更直觀的認識，我們以一個考試成績管理系統為例，介紹它的數據流圖。某單位進展招聘考試，應聘者報名后，單位的招聘委員會將每位應聘者的根本情況輸入系統。招聘考試完畢后，招聘委員會需要將應聘者的成績輸入系統，并按照成績對應聘者進展排序，將成績單發放給每位應聘者，并發放錄用通知書。該考試成績管理系統頂層和底層的數據流圖分別如圖2-6和圖2-7所示。

〔點擊查看大圖〕圖2-6考試成績管理系統頂層數據流圖

〔點擊查看大圖〕圖2-7考試成績管理系統底層數據流圖在繪制數據流圖的過程中，要注意以下幾點。(1)數據的處理不一定是一個程序或一個模塊，也可以是一個連貫的處理過程。(2)數據存儲是指輸入或輸出文件，但它不僅僅可以是文件，還可以是數據項或用來組織數據的中間數據。(3)數據流和數據存儲是不同狀態的數據。數據流是流動狀態的數據，而數據存儲是指處于靜止狀態的數據。(4)當目標系統的規模較大時，為了描述的清晰和易于理解，通常采用逐層分解的方法，畫出分層的數據流圖。在分解時，要考慮到自然性、均勻性和分解度幾個概念。自然性是指概念上要合理和清晰。均勻性是指盡量將一個大問題分解為規模均勻的假設干局部。分解度是指分解的維度，一般每一個加工每次分解最多不宜超過7個子加工，應分解到根本的加工為止。(5)數據流圖分層細化時必須保持信息的連續性，即細化前后對應功能的輸入和輸出數據必須一樣。關于數據流圖的詳細繪制方法，本章的實踐局部會詳細介紹。2.4.2數據字典用數據流圖來表示系統的邏輯模型直觀且形象，但是缺乏細節描述，也就是說它沒有準確和完整地定義各個圖元。可以用數據字典〔datadictionary，DD〕來對數據流圖做出補充和完善。數據字典用于定義數據流圖中各個圖元的具體內容，為數據流圖中出現的圖形元素做出確切的解釋。數據字典包含4類條目：數據流、數據存儲、數據項和數據加工。這些條目按照一定的規則組織起來便構成了數據字典。定義規則時，常用的符號如表2-2所示。表2-2數據字典符號符號含義例如=被定義為+與X=a+b表示X由a和b組成[…|…]或X=[a|b]表示X由a或b組成m{…}n或重復X=2{a}6或表示重復2～6次a{…}重復X={a}表示X由0個或多個a組成(…)可選X=(a)表示a在X中可能出現，也可能不出現“…〞根本數據元素X=“a〞表示X是取值為字符a的數據元素..連接符X=1..9表示X可取1到9中的任意一個值

例如，數據流"應聘者名單"由假設干應聘者姓名、性別、年齡、專業和聯系等信息組成，那么"應聘者名單"可以表示為：應聘者名單={應聘者姓名+性別+年齡+專業+聯系}。數據項考試成績可以表示為：考試成績=0..100。再如，某教務系統的學生成績庫文件的數據字典描述可以表示為以下形式。文件名：學生成績庫記錄定義：學生成績=學號+姓名+{課程代碼+成績+[必修|選修]}學號：由6位數字組成姓名：2～4個漢字課程代碼：8位字符串成績：1～3位十進制整數文件組織：以學號為關鍵字遞增排列

2.4.3E-R圖E-R圖用于描述應用系統的概念構造數據模型，它是進展需求分析，并歸納、整理、表達和優化現實世界中數據及其聯系的重要工具。在建模的過程中，E-R圖以實體、聯系和屬性三個根本概念概括數據的根本構造。實體就是現實世界中的事物，多用矩形框來表示，框內含有相應的實體名稱。比方，在一個教務系統中，"學生"就是一個實體，如圖2-8所示。

圖2-8學生實體屬性多用橢圓形表示，并用無向邊與相應的實體聯系起來，表示該屬性歸某實體所有。可以說，實體是由假設干個屬性組成的，每個屬性都代表了實體的某些特征。學生實體的屬性如圖2-9所示。

〔點擊查看大圖〕圖2-9學生實體的屬性聯系用菱形表示，并用無向邊分別與有關實體連接起來，以此描述實體之間的關系。實體之間存在著三種聯系類型，分別是一對一、一對多、多對多，它們反映到E-R圖中就為相應的聯系類型，即1:1、1:n和m:n。(1)一對一聯系是指甲實體的任何一個實例只能對應到乙實體的一個實例，并且乙實體的任何一個實例只能對應到甲實體的一個實例。比方，在一個座位分配系統中，"學生"實體和"座位"實體之間的關系就是一對一的，如圖2-10所示。(2)一對多聯系是指甲實體的任何一個實例能夠對應到乙實體的多個實例，而乙實體的任何一個實例只能對應到甲實體的一個實例。比方，在一個住宿管理系統中，一個"學生"只能分配到一間"宿舍"，而一間"宿舍"可以容納多個"學生"，如圖2-11所示。

〔點擊查看大圖〕圖2-10一對一聯系

〔點擊查看大圖〕圖2-11一對多聯系(3)多對多聯系是指甲實體的任何一個實例能夠對應到乙實體的假設干個實例，而乙實體的任何一個實例也可以對應到甲實體的假設干個實例。比方，在一個選課系統中，一個"學生"可以選修假設干門"課程"，同時一門"課程"也可以被假設干個"學生"選修，如圖2-12所示。

〔點擊查看大圖〕圖2-12多對多聯系

需要指出的是，同一個系統的E-R圖不具有唯一性，即不同的軟件開發人員所設計出來的E-R圖可能不同。

2.5利用Visio繪制網上書店系統的數據流圖〔1〕網上書店是一種新型的書店模式，它不僅是傳統銷售渠道的開展和補充，也是未來圖書銷售的開展方向。目前，我國運作和銷售較好的大型網上書店有很多，如當當、卓越亞馬遜等，其中當當網上書店在價格和品種方面的優勢眾所周知；卓越亞馬遜網上書店創造流行的能力比擬強。國外影響較大的網上書店有美國的亞馬遜、德國的貝塔斯曼等，其中亞馬遜網上書店在1998年擁有450萬名顧客，而到2002年就有將近32億人網上購書，銷售額到達了78億美元。網上售書將成為圖書銷售的主要渠道。下面我們將以一個小型的"網上書店系統"為例，對軟件工程開發實踐方法和相關工具的使用進展介紹。該網上書店系統旨在實現圖書銷售的電子商務模式并滿足經銷商和用戶進展電子交易的需求，從而充分發揮網上交易的優勢。它的目標是保證經銷商和用戶之間快速的信息交流。本節主要是實踐利用Visio2007來繪制網上書店系統的數據流圖。利用Visio2007創立Gane-Sarson數據流圖，可以選擇"軟件和數據庫"模板，然后再選擇"數據流模型圖"，創立之后可以看到Gane-Sarson有4種根本符號，如表2-1所示。在繪制系統數據流圖的過程中，構造化需求分析方法通常強調"自頂向下，逐層分析"的思想。對于大規模的軟件系統而言，需要采用多層的數據