軟件需要解決的是用戶所面臨的現實問題，但是，這些現實問題需要由軟件技術人員來解 決。情況往往是，開發軟件的技術人員精通計算機技術，但並不熟悉用戶的業務領域；而用戶 清楚自己的業務，卻又不太懂計算機技術。因此，對於同一個問題，技術人員和用戶之間可能 存在認識上的差異。也因此，在軟件技術人員着手設計軟件之前，需要由既精通計算機技術又 熟悉用戶應用領域的軟件系統分析人員，對軟件問題進行細致的需求分析。 需求分析是軟件工程過程中一個重要的里程碑。在需求分析過程中，軟件系統分析人員通 過研究用戶在軟件問題上的需求意願，分析出軟件系統在功能、性能、數據等諸多方面應該達 到的目標，從而獲得有關軟件的需求規格定義，其信息流如圖 4-1 所示。
需求分析是在軟件系統分析人員的操作下進行的，在這個過程中，用戶和開發者之間需要 達成的是對系統的一致性需求認識。實際上，可以把軟件系統分析人員看成是軟件用戶與軟件 開發技術人員之間的信息通道，其作用是使用戶對軟件問題的現實描述，能夠有效地轉變為開 發軟件的技術人員所需要的對軟件的技術描述，以方便技術人員對軟件的技術構建
需求分析是在軟件系統分析人員的操作下進行的，在這個過程中，用戶和開發者之間需要 達成的是對系統的一致性需求認識。實際上，可以把軟件系統分析人員看成是軟件用戶與軟件 開發技術人員之間的信息通道，其作用是使用戶對軟件問題的現實描述，能夠有效地轉變為開發軟件的技術人員所需要的對軟件的技術描述，以方便技術人員對軟件的技術構建。
一、需求分析任務
需求分析需要實現的是將軟件用戶對於軟件的一系列意圖、想法轉變為軟件開發人員所需要的有關軟件的技術規格，並由此實現用戶和開發人員之間的有效通信，它涉及面向用戶的用 戶需求和面向開發者的系統需求這兩個方面的工作內容。
1.用戶需求
用戶需求是用戶關於軟件的一系列意圖、想法的集中體現，涉及軟件的操作方式、界面風格、報表格式，用戶機構的業務范圍、工作流程，以及用戶對於軟件應用的發展期望等。因此， 用戶需求也就是用戶關於軟件的外界特征的規格表述。 實際上，用戶需求提出了一個有關軟件的基本需求框架，具有以下特點：
（1）用戶需求直接來源於用戶，可以由用戶主動提出，也可以通過與用戶交談，或對用戶 進行問卷調查等方式獲取。由於用戶對計算機系統認識上的不足，分析人員有義務幫助用戶挖掘需求，例如，可以使用啟發的方式激發用戶的需求想法。如何更有效地獲取用戶需求，既是 一門技術，也是一門思維溝通藝術。
（2）用戶需求需要以文檔的形式提供給用戶審查，因此需要使用流暢的自然語言或簡潔清 晰的直觀圖表來進行表述，以方便用戶的理解與確認。
（3）可以把用戶需求理解為用戶對軟件的合理請求，這意味着，用戶需求並不是開發者 用戶的盲目順從，而是建立在開發者和用戶共同討論、相互協商的基礎上。
（4）用戶需求主要是為用戶方管理層撰寫的，但用戶方的技術代表，軟件系統今后的操作 者，以及開發方的高層技術人員，也有必要認真閱讀用戶需求文檔。
2.系統需求
系統需求是比用戶需求更具有技術特性的需求陳述，是提供給開發者或用戶方技術人員閱 讀的，並將作為軟件開發人員設計系統的起點與基本依據。 系統需求需要對系統在功能、性能、數據等方面進行規格定義，由於自然語言隨意性較大， 在描述問題時容易發生歧義，因此系統需求往往要求用更加嚴格的形式化語言進行表述，例如 PDL 偽碼，以保證系統需求表述具有一致性。 系統需求涉及有關軟件的一系列技術規格，包括：功能、數據、性能、安全等諸多方面的 問題。
（1）功能需求
功能需求是有關軟件系統的最基本的需求表述，用於說明系統應該做什么，涉及軟件系統 的功能特征、功能邊界、輸入輸出接口、異常處理方法等方面的問題。也就是說，功能需求需 要對軟件系統的服務能力進行全面的詳細的描述。 在結構化方法中，往往通過數據流圖來說明系統對數據的加工過程，它能夠在一定程度上 表現出系統的功能動態特征。也就是說，可以使用數據流圖建立軟件系統的功能動態模型。
（2） 數據需求
數據需求用於對系統中的數據，包括：輸入數據、輸出數據、加工中的數據、保存在存儲 設備上的數據等，進行詳細的用途說明與規格定義。 在結構化方法中，往往使用數據字典對數據進行全面准確的定義，例如，數據的名稱、別 名、組成元素、出現的位置、出現的頻率等。當所要開發的軟件系統涉及到對數據庫的操作時， 還可以使用數據關系模型圖（ER圖）對數據庫中的數據實體、數據實體之 間的關系等進行描述。
（3） 其他需求
其他需求是指系統在性能、安全、界面等方面需要達到的要求。
二、需求分析過程
需求分析是對軟件系統的后期分析，需要進行一系列的活動，包括：分析用戶需求、建立 需求原型、分析系統需求和進行需求驗證等，其活動流程如圖 4-2 所示。
（1）需求分析可以可行性分析中軟件系統的高層模型為前提，首先需要進行的是分析用戶 需求，由此可以提出關於軟件的需求框架。 （2）由於用戶對計算機信息系統認識上的模糊性，以致直接來源於用戶的需求想法往往存 在着許多缺陷，例如：需求沖突、需求遺漏。為提高用戶需求的有效性，可以按照需求框架的 要求建立需求原型讓用戶確認，然后再通過需求原型去提取系統模型。
（3）系統需求是面向技術人員的。因此，它不僅需要從需求原型中提取系統模型，而且需 要對系統模型進行細節化處理，例如：數據流細化、數據字典分解、類模型的定義等，由此獲 得對系統的詳細的技術性需求說明。
（4）對需求框架、系統模型和需求細節等文檔進行有效性驗證，由此產生出用戶方、開發 方都能接受的關於軟件的需求規格說明書。
三、用戶需求獲取
優秀軟件總是能夠最大限度地滿足用戶需求。因此，有效獲取用戶需求，是實施軟件開發 時需要完成的第一項工作。
1.研究用戶
在建立軟件抽象模型過程中，用戶可以被當作為一個抽象概念，泛指諸多從系統獲得服務 的系統以外的對象，例如：軟件使用機構，軟件操作人員，以及從軟件獲得信息服務的其他系 統或設備。也就是說，可以把用戶看作為系統的外部應用接口。但從軟件的商業服務角度來看， 用戶則主要是指購置軟件的機構、使用軟件的部門、操作軟件的人。 軟件是為用戶開發的，為了使軟件能夠更好地為用戶服務，在軟件需求階段，軟件開發者 應該盡量充分地和用戶進行溝通，了解用戶的意圖。例如，用戶希望軟件為他提供哪些方面的 服務，用戶在操作軟件時有哪些工作習慣，喜歡什么樣的工作界面等。 軟件往往需要為各種不同的用戶服務，例如，用戶機構負責人、使用軟件的部門主管、軟 件操作人員，他們都是用戶，但由於所處位置不同，因此會有不同的需求。軟件操作人員大多需要較長時間地操作軟件，因此他們會特別關心軟件的工作方式、界面布局；使用軟件的部門 主管則一般不會直接操作軟件，但他需要從軟件中得到年度報表之類的打印數據，因此比較關 心軟件能夠提供哪些方面的報表，報表格式如何等。 用戶情況是復雜的，為了更好地研究用戶，有必要對軟件用戶做一些分類，例如：按軟 件需求層次不同，將用戶分為高層用戶、中層用戶和基層用戶；按使用軟件時間長短不同， 將用戶分為熟練用戶和非熟練用戶；按是否直接操作軟件系統，將用戶分為直接用戶和間接 用戶。
2. 從調查中獲取用戶需求
直到今天，用戶調查仍是最基本的用戶需求信息收集方法。應該說，用戶需求信息來源是 多方面的，為了保證用戶需求的完整性，在需求分析過程中，軟件系統分析人員往往需要調查 各類能夠代表用戶意願的相關人員，如圖 4-3 所示。
實際上，針對不同的應用項目通常會有不同的調查內容，需要采用不同的調查策略。例如， 開發一個信息管理系統，其用戶需求調查一般會涉及以下方面的內容：
（1）調查用戶的組織機構，包括：該組織的部門組成，各部門的職責等。由此得到的調查 結果將作為分析軟件系統領域邊界的基本依據。 （2）調查用戶各部門的業務活動，包括：各個部門輸入和使用什么數據，如何加工處理這 些數據，輸出什么數據，輸出到什么部門等。這是需求調查的重點內容，其結果將作為分析軟 件系統工作流程的基本依據。
（3）調查用戶對軟件系統的各項具體要求，包括：數據格式、操作方式、工作性能、安全 保密等方面的要求。
在調查過程中，可以根據不同的問題和條件，使用不同的調查方法。比較常用的調查方法 有以下幾種：
a. 訪談用戶
訪談用戶就是面對面地跟單個用戶進行對話。例如，請用戶機構高層人員介紹用戶的組織 結構、業務范圍、對軟件應用的期望。
b. 開座談會
當需要對用戶機構的諸多部門進行業務活動調查與商討時，可以考慮采用開一個座談會的 方式。這既有利於節約調查時間，又能使各部門之間就業務問題進行協商，以方便對與軟件有 關的業務進行合理分配與定位。
c. 問卷調查
問卷調查一般是通過精心設計的調查表去調查用戶對軟件的看法。當面對一個龐大的用戶 群體時，可能需要采用問卷調查形式進行用戶調查。例如在開發通用軟件時，為了獲得廣大用 戶對軟件的看法，就不得不采取問卷方式。如果調查表設計得合理，這種方法很有效，也易於 為用戶接受。
d. 跟班作業
跟班作業就是軟件分析人員親身參加用戶單位業務工作，由此可直接體驗用戶的業務活動 情況。這種方法可以更加准確地理解用戶的需求，但比較耗費時間。
e.收集用戶資料
盡管有待開發的軟件需要在較長時間以后才能交付用戶使用，但跟軟件有關的工作用戶卻 一直在以其他方式或通過其他系統進行着，並且也一直在產生結果。用戶資料主要就是指這些 結果，例如：年度匯總報表、提貨單、工資表等。軟件分析人員應該認真收集這些資料，由此 可以更加清楚地認識用戶的軟件需求。
3.通過原型完善用戶需求
需求原型可用來收集用戶需求，對用戶需求進行驗證，由此可幫助用戶克服對軟件需求的 模糊認識，並使用戶需求能夠更加完整地得以表達。例如，用戶對軟件應該提出哪些方面的服 務，操作界面應該如何等可能拿不定主意，為了使用戶能夠更加直觀地表述自己的需求意願， 可以先構造一個原型給用戶體驗。 原型需要根據用戶的評價而不斷修正，這也有利於挖掘用戶的一些潛在需求，使得用戶需求能夠更加完整地得以表達。一般情況下，開發人員將軟件系統中最能夠被用戶直接感受的那 一部分東西構造成為原型。例如，界面、報表或數據查詢結果。實際上，在諸多原型中，界面 原型是應用得最廣泛的原型。 如圖 4-4 所示，
需求原型可以建立在用戶所提出的需求框架基礎上。需求原型的作用是能 夠方便系統模型的創建。也就是說，需求原型可以方便由用戶需求到系統需求的過渡。
（1）倉庫管理系統將被計划部門、倉庫管理部門、采購部門、銷售部門的相關工作人員使 用。其中，計划部門制定商品計划，涉及：設置商品類別、登記商品、制定商品報損計划和進 行商品流通數據匯總；倉庫管理部門完成倉庫的日常管理，涉及：商品入庫、出庫、報損和查 詢等多項操作；采購部門可以查詢商品庫存情況、打印商品定貨報表；銷售部門可以查詢商品 庫存情況和提交商品定貨請求。
（2）由於不同部門有不同的任務，因此系統需要提供針對部門的權限管理機制和針對工作人員的登錄注冊機制。系統將通過一位系統管理員進行部門授權與工作人員注冊管理。
（3）進入倉庫管理系統的工作人員需要有惟一的個人身份標識，它既是工作人員登錄系統 時的身份驗證依據，也是工作人員在進行商品操作時的經手人標記。盡管工作人員的姓名也可 以用做其身份標識，但不同的工作人員有可能會出現姓名重復，因此有必要為工作人員設置一 個專門的身份標識碼。
（4）倉庫以商品品種為基本單位進行管理，所有商品都要由計划部門按品種進行登記，涉 及商品編碼、名稱、類別、庫存下限值等數據。其中，商品庫存量初始值為零。
（5）倉庫商品涉及入庫、出庫、報損這三種流通方式。憑采購部門填寫的入庫單進庫，憑 銷售部門填寫的出庫單出庫，憑計划部門制定的報損計划報損。商品的任何流通都需要以流水 方式記錄到商品流通表中，並對商品庫存量進行更新。當商品出庫、報損時，必須考慮到該商 品的當前庫存量是否能夠滿足操作需要。出庫、報損后，若商品庫存量低於庫存下限值，將自 動產生定貨請求。
（6）可以按商品類別或品種進行商品庫存情況和當月商品流通情況的查詢。另外，倉庫管 理系統需要自動在月底對商品流通數據進行盤查，包括：按月打印商品流通分類匯總報表，並 按月備份商品流通數據，然后將已備份的商品流通數據進行合計整理。
四、結構化分析建模
人在求解問題時，首要需要做的是理解問題，並且對問題理解得越透徹，則這個問題就越 容易解決。所謂模型，就是為了理解問題而對問題做的一種符號抽象。可以把模型看作為一種 思維工具，利用這種工具可以把問題規范地表示出來。 模型一般由一組圖示符號和組織這些符號的規則組成。因此，分析時期的建模，就是針對 用戶需求、系統需求等，采用圖示方式進行直觀描述。 軟件問題往往是復雜的，而建模可以使問題簡化。人的頭腦每次只能處理一定數量的信息， 模型通過把系統分解成人的頭腦一次能處理的若干個子部分，從而減少系統的復雜程度。分析 時期建立軟件模型的作用是多方面的，可以通過模型實現由用戶需求向系統需求的過渡，並可 通過模型獲得對系統需求的更具細節性的推論。實際上，分析時期產生的模型還可以被引用到 系統設計中去，作為設計前導。 為了開發復雜的軟件系統，往往需要從不同角度去構造系統模型。例如，用於描述系統功能組織結構的層次模型，用於描述系統中數據加工流程的數據流模型，用於描述數據實體及其 關系的數據關系模型，用於描述系統行為過程的系統狀態模型等。
1.功能層次模型
功能層次模型圖使用矩形來表示系統中的子系統或功能模塊，使用樹形連線結構來表達系 統所具有的功能層級關系。 實際上，不僅可以使用層次圖清晰地說明系統的功能組成關系，也可以使用功能層次圖對 系統的功能關系進行調整，從而使系統的諸多功能得到更加合理地分配。
2.數據流模型
（1）數據流圖特點
數據流模型由 DeMarco 於 1978 年提出，並隨着他的結構化分析思想一起被廣為流行。數據流圖用於描述系統對數據的加工過程，其圖形符號是一些具有抽象意義的邏輯符號。表 4-1 所列是數據流圖的基本符號。 在軟件定義時期，數據流圖被用來描述系統的邏輯加工步驟。由於數據流圖能夠為有待開發的系統提供一種簡潔的邏輯圖形說明，能夠方便用戶對系統分析的理解，因此，它也被用做 開發者和用戶之間的信息交流工具。
（2）數據流圖的用途
可以依靠數據流圖來實現從用戶需求到系統需求的過渡。例如，可以將用戶需求陳述中的 關鍵名詞、動詞提取出來，其中的名詞可以作為數據流圖中數據源、數據存儲，而動詞則可以 作為數據流圖中的數據加工進程。
數據流圖也能夠方便系統物理模型與邏輯模型之間的轉換，可以將 3.1.3 節中系統流程圖 經過符號轉換而獲得系統的數據流圖，例如圖 3-3 的系統流程圖，通過轉換符號可以得出圖 4-6 的數據流圖。數據流圖的這個特點表明，可以基於系統的基本物理框架而抽取它的邏輯模型。
軟件系統是復雜的，為了方便問題的解決，有必要將系統進行分解，由此將一個大的復雜 問題解剖為許多小的相對簡單的問題。例如，可以按照系統的功能構成，將系統分解為許多子 系統，各子系統又可以再分解為許多更小的功能模塊，由此可以不斷深入地了解軟件系統的功 能細節。由於數據流圖使用的是抽象的圖形符號，因此，它不僅能夠描述系統對數據的加工步 驟，而且能夠依靠對其圖形符號的邏輯細化而方便地實現對系統中數據加工步驟的有效分解。
（3） 數據流細化過程
數據流細化的過程即是從上至下對系統功能進行分層描述的過程，如圖 4-7 所示。其中， 高層數據流對功能的描述是抽象的，但通過邏輯細化能夠深入到系統內部的低層數據流，而使 對功能的描述逐步具體化。結構化分析就是基於數據流的細化實現的，它是結構化分析方法的 關鍵。 實際上，數據流圖對系統的描述可以從任何層面開始，只要那個層面的諸多軟件問題是清 晰的，則在該層面上獲得的數據流圖也就可以是清晰的。但是，進入系統的層面越深，則遇到的問題點越多，數據流越復雜。為了更加清楚地表現系統的功能，數據流圖往往從容易辨別的 高層開始，然后通過數據流的細化逐步深入。這個過程也就是從抽象到具體的解決問題方法在 軟件分析上的具體體現。
當面對一個有待開發的新系統進行數據流描述時，數據流圖往往需要從最頂層畫起，使用 一個數據處理框來表示整個系統，以反映系統與周圍環境的關系，然后通過數據流的細化而獲 得 0 層、1 層，以及更下層的數據流圖。 圖 4-8 是一個“工資管理系統”的頂層數據流圖，其中的處理框表示所要描述的系統，而 三個外部接口（人事處、財務處、員工所在工作部門）則可以表示系統的工作環境。系統與外 部接口之間的通信可以通過數據流，圖 4-8 中有四個數據流，即：職工清單、檔案工資、業績 工資、工資報表。
當需要對高層數據流細化以獲得對低層數據流的描述時，一種有效的方法是對高層數據流 圖中的數據加工進行合理分解。通過把一個數據加工分解為多個數據加工可以看到這個數據加 工的內部細節。 例如，圖 4-8 所描述的“工資管理系統”數據流圖。假如“工資管理系統”可以具有以下三項功能：
（1）輸入職工名冊清單；
（2）從員工的檔案工資和業績工資的計算中產生工資數 據；
（3）依據人事部門提供的職工清單按月打印出員工的工資報表。
那么，可以考慮將“工資 管理系統”分解為以下三項處理，即：
（1）提供職工清單；
（2）產生工資數據；
（3）打印工 資報表。
圖 4-9 即是依照上述功能分解而從頂層數據流圖細化出來的 0 層數據流圖。從 0 層數據流 圖可以看到數據流在細化時具有以下特點： （1）與上一層數據處理“工資管理系統”相關的數據流被繼承了下來。
（2）上一層數據處理“工資管理系統”中不可見的內部數據流變成了可見的外部數據流。
數據流細化被用來分析系統的內部功能構造。然而，面對一個具有一定規模的軟件系統， 0 層數據流圖往往只能對其功能進行一般性的高層描述。因此，為了使數據流對系統功能的描 述更加具體，數據流細化往往還需要繼續深入下去。 實際上，可以使用數據流進行軟件結構的映射（結構化設計）。一般情況下，假如希望將 數據流用於軟件設計，則對數據流細化更需要以設計中的模塊構件作為分解目標。 因此，可以考慮對“工資管理系統”進行更加深入的數據流細化。例如，“工資管理系統” 0 層數據流圖中的“產生工資數據”處理，假如其工資數據的產生涉及數據錄入、數據計算等 更加具體的數據操作，則“產生工資數據”處理可以進一步分解為：“錄入檔案工資”、“錄 入業績工資”、“計算工資”這三項處理。 圖 4-10 即是對“產生工資數據”處理框進一步細化后產生出來的 1 層數據流圖。其中的 數據加工流程是：
（1）來源於“人事處”和“員工所在工作部門”的“檔案工資”、“業績工資”數據流， 經“錄入檔案工資”、“錄入業績工資”的處理之后，被分別存入到“檔案工資表”、“業績 工資表”這兩個數據存儲之中。
（2）系統可以從“檔案工資表”和“業績工資表”這兩個數據存儲讀取數據，然后通過“計算工資”的處理產生出“工資數據”數據流。這個數據流將被存入到“工資數據表”中。
顯然，這又是一個既涉及細化又包含繼承的分析過程。與“工資管理系統”直接相關的數 據流成分被繼承了下來（人事處、員工所在工作部門、工資數據表），而圖 4-9 中不可見的內 部數據流則經過細化變成了可見的外部數據流。
（4） 數據流圖中符號的命名
數據流圖中的圖形符號一般都需要命名，並遵循以下命名規則：
a.數據接口：使用名詞或名詞短語命名。例如：人事處、財務處、工資數據錄入員、系 統管理員、讀卡設備、打印設備。
b.數據存儲：使用名詞或名詞短語命名。例如“工資數據表”。當數據存儲是存儲介質 上某個存儲單元的存儲片段時，其名稱還需要用到限定詞，例如“在職人員檔案工資”。
c.數據流：使用名詞或名詞短語命名。但為了提高數據流圖的清晰度，從數據存儲中流 出，或流入數據存儲的數據流，在不會發生名稱混淆的前提下，可以省略名稱。例如圖 4-9 中 從“檔案工資表”、“業績工資表”流出，或流向“檔案工資表”、“業績工資表”的數據流。
d.數據處理：數據處理涉及處理方式與處理對象兩方面的內容，一般使用“動詞+名詞 短語”的動賓結構來進行命名。例如，“錄入檔案工資”、“打印工資報表”。由於對數據流的細 化是通過對數據處理的分解實現的，考慮到對細化后的數據流圖進行分層檢索的便利，可以對 處理框進行合適的數字編碼。例如，“2. 產生工資數據”、“2.1 錄入檔案工資”、“2.2 錄入 業績工資” 、 “2.3 計算工資”。
（5）數據流圖中的數據字典
在需求分析中，數據字典是各類數據描述的集合，能夠提供對數據的詳細規格定義，並可 用於驗證數據，以發現系統在數據需求描述中是否出現遺漏。 數據流圖中的數據字典能夠提供對圖中的諸多數據元素的更加詳細的說明。其一般要求是：
（1）對數據的定義應該是嚴密、精確、一致的，不能有二義性；
（2）需要對數據流圖中的 每一個被命名的數據元素進行定義；
（3）需要分類定義各種不同種類的數據元素，或采用類別 代號加以區別。 數據流圖中的數據字典通常包括數據項、數據結構、數據流、數據存儲、數據接口和數據 處理過程這幾個部分的數據內容。其中，數據項是數據的最小組成單位，若干個數據項可以組 成一個數據結構。數據字典就是通過對數據項和數據結構的定義來描述數據流、數據存儲的邏 輯內容的。
（1）數據項 數據項是不可再分的數據單位。對數據項的描述通常包括以下內容： ｛數據項名，數據項含義說明，別名，數據類型，長度，取值范圍，取值含義，與其他數 據項的邏輯關系｝
（2）數據結構 數據結構反映了數據之間的組合關系。一個數據結構可以由若干個數據項組成，也可以由 若干個數據結構組成，或由若干個數據項和數據結構混合組成。對數據結構的描述通常包括以 下內容： ｛數據結構名，含義說明，組成：｛數據項或數據結構｝｝ 在定義數據結構時，可以采用以下符號說明數據的組成： = 被定義為，表示數據組成。 + 與，用於連接兩個數據分量。 [⋯|⋯] 或，從若干數據分量中選擇一個，方括號中的數據分量用“|”號隔開。 m{⋯}n 重復，重復花括號內的數據，最少重復 m 次，最多重復 n 次。 (⋯) 可選，圓括號內數據可有可無。
（3）數據流 數據流是數據結構在軟件系統內傳輸的路徑。對數據流的描述通常包括以下內容： ｛數據流名，說明，數據流來源，數據流去向，組成｛數據結構｝，平均流量，高峰期流量｝
其中，數據流來源是說明該數據流來自哪個過程。數據流去向是說明該數據流將到哪個過 程去。平均流量則是指在單位時間（每天、每周、每月等）里的傳輸次數。高峰期流量則是指 在高峰時期的數據流量。
（4）數據存儲 數據存儲是數據結構停留或保存的地方，也是數據流的來源和去向之一。對數據存儲的描 述通常包括以下內容： ｛數據存儲名，說明，編號，流入的數據流，流出的數據流，組成｛數據結構｝，數據量， 存取方式｝ 其中，數據量是指每次存取多少數據，每天（或每小時、每周等）存取幾次等信息。存取 方式則包括：是批處理還是聯機處理，是檢索還是更新，是順序檢索還是隨機檢索等。另外， 流入的數據流要指出其來源，流出的數據流要指出其去向。 可以使用表格將數據字典分類列出。例如前面介紹的“工資管理系統”數據流圖中的數據 字典，即可以通過表 4-2、表 4-3、表 4-4、表 4-5 列出。
3.數據關系模型(ER圖)
許多應用軟件系統往往需要通過數據庫來存儲數據。從結構上來看，數據庫系統是獨立於 軟件系統之外的專門系統，因此，在系統建模過程中，數據庫需要進行專門的分析與設計。其 中，需求分析時期建立的數據庫模型稱為概念模型。
數據關系模型圖也稱為 ER 圖，是應用最廣泛的數據庫分析建模工具。數據關系建模方法 最早由 Chen 於 20 世紀 70 年代中期提出，它以現實數據為建模依據，通過從現實數據中抽取數據實體、數據關系和數據屬性這三類圖形元素，建立數據庫的概念模型。
（1）數據實體
數據實體是對應用領域中現實對象的數據抽象。例如，課程教學中的教師、學生和課程這 三個現實對象，就可以作為數據實體對待。
（2）數據關系
數據關系是指不同數據實體之間存在的聯系，包括：一對一、一對多、多對多三種類型的 關系。數據關系類型及其描述如表 4-6 所列。
（3）數據屬性
數據屬性是指在數據實體與數據關系上所具有的一些特征值。例如，教師的編號、姓名、 性別、職稱、學歷，是教師實體的屬性；學生的學號、姓名、性別、專業、班級，是學生實體 的屬性；課程的課號、課名、學分、計划課時量，是課程實體的屬性。而學習的成績，則是學 習關系的屬性；講授的實際課時量，則是講授關系的屬性。 在數據關系圖中，數據實體用矩形表示，數據關系用菱形表示，數據屬性用橢圓形表示。 其中，能夠用來標記實體的關鍵屬性則通過在屬性名稱上加下划線來表示。 圖 4-11 是教師、學生、課程這三個實體之間存在的教學關系的數據關系圖的描述。
對於一些比較復雜的數據關系，為了方便分析，在畫數據關系圖時可以只畫出實體、關系和關鍵屬性，而其一般屬性則可以省略，例如圖 4-12。
4.系統狀態模型
（1）狀態圖特點
狀態圖於 1987 年由 Harel 首先提出，其使用狀態、事件等圖形符號來描述系統的行為活 動，用以反映系統因某個外部事件的干預而由一個可能的狀態轉換到另一個狀態。表 4-7 所列 為狀態模型圖中一些常用的圖形符號及其描述。
狀態模型圖是通過系統的內部狀態、外部事件為基本元素來描繪系統的工作流程的，這種 建模方式比較適合於描述一些依賴於外部事件驅動的實時系統。 另外，狀態模型也被 UML 建模語言采納。在面向對象建模之中，狀態模型可以用來對對象 的狀態及其變換進行細節描述。
（2）狀態圖應用舉例
下面是一台全自動洗衣機的大致活動過程：
（1）在洗衣機接通電源以后，洗衣機將進入待命狀態。
（2）在洗衣機進入待命狀態以后，操作者可以選擇“設置”或“工作”。若選擇“設置”， 洗衣機將進入設置狀態；若選擇“工作”，洗衣機將進入工作狀態。
（3）在洗衣機進入設置狀態以后，操作者可以設置洗衣水位，洗衣機工作流程，並可在完 成設置之后選擇“確定”返回待命狀態。
（4）在洗衣機進入工作狀態以后，洗衣機將按照設置的流程進行工作。若洗衣機在洗衣過 程中選擇暫停，洗衣機將進入暫停等待狀態；若洗衣機在洗衣過程中出現洗衣故障，洗衣機將 鳴報警音，並進入故障等待狀態。在洗衣機完成流程規定的工作以后，洗衣機進入結束等待狀態。
（5）在洗衣機進入暫停等待狀態以后，操作者可選擇“恢復”，使洗衣機返回工作狀態。
（6）在洗衣機進入故障等待狀態以后，操作者可在排除洗衣故障之后，選擇“恢復” ， 使洗衣機返回工作狀態。
（7）在洗衣機進入結束等待狀態以后，操作者可以切斷電源結束洗衣過程。 根據上述活動內容，可以畫出該洗衣機的狀態圖模型。其狀態圖模型如圖 4-13 所示。
需要注意的是，圖 4-13 中的工作狀態是一個復合狀態。也就是說該狀態中包含了子狀態。 假如洗衣機的常規工作流程是：累積洗滌 10 分鍾，然后進入漂洗狀態；累積漂洗 6 分鍾，然后 進入脫水狀態；累積脫水 1 分鍾，然后進入結束鳴音狀態。則工作狀態的下層子狀態圖如圖 4-14 所示。
五、需求有效性驗證
需求有效性驗證是指對已經產生的需求結論所要進行的檢查與評價，它是需求分析過程中 一個必不可少的環節。 需求分析是軟件開發過程中一個非常關鍵的階段。它是軟件設計、實現的基礎，同時也是用戶對軟件產品進行確認的基本依據。但是，需求分析過程中產生出來的結論難免存在問題。 例如，某項功能被遺漏了，某些功能之間發生了操作上的沖突，某些數據字節數不夠大等。更 加重要的是，這些問題看起來或許並不顯眼，但它所影響的是軟件系統的整體構造。 實際情況往往是：需求分析中的小問題，假如是在后續的開發過程中或是在系統開發出來 並投入使用以后才被發現，就會導致代價巨大的返工。因此，在需求分析結果出來以后，需要 對其進行嚴格的有效性驗證，由此盡早地發現需求文檔草稿中存在的問題。
1.需求驗證內容
在需求有效性驗證過程中，為了確保軟件需求的正確性，需要對需求文檔草稿從有效性、 一致性、完整性、現實性等幾個方面進行有效性驗證。
（1）有效性驗證
需求有效性驗證用於確認每一項需求定義都能符合用戶的實際需要。由於一個軟件系統在 其運行過程中一般需要面對許多不同的用戶，他們分別會有一些不同的個性需求意願，因此， 有效性驗證還包括對用戶需求個性差異的協商。
（2） 一致性驗證
一致性驗證用於檢查發現在需求文檔中可能存在的需求沖突，例如，同一個功能出現了不 同的描述或存在相互矛盾的規程約束。
（3）完整性驗證
完整性驗證用於檢查發現用戶確實需要的，但沒有寫入需求文檔中一些功能、約束等，以 使最終確定下來的需求文檔能夠更加完整的體現用戶的需求意願。
（4）現實性驗證
現實性驗證用於檢查需求文檔中所提出的功能、性能、安全等方面的需求，哪些還不能夠 利用現有技術加以實現，以確保用戶的一系列需求都能夠具有現實意義，都能夠最終實現。
（5）可檢驗性驗證
可檢驗性驗證用於判斷需求文檔中的各項需求是否有適合於用戶操作的檢測方法，可以使 得當系統開發完成並交付用戶使用時，開發人員能設計出一組合適的檢查方法來進行用戶需求 檢驗，由此最大限度地保證用戶的需求意願能夠得以實現。
2.需求驗證方法
在進行需求有效性驗證時，需要有一定的方法、工具提供支持。例如，需求評審、需求原 型評價和基於 CASE 工具的需求一致性分析等。
1. 需求評審
需求評審是傳統的需求檢查手段，采用專門評審小組的方式實施對需求文檔的有效性評 價。其評審工作的開展需要有開發人員、用戶的共同參與，他們一同檢查文檔中的不規范之處 和遺漏之處，一起討論需求中存在的問題，並需要對一些需求分歧進行協商。 需求評審可以是非正式的也可以是正式的。其中，非正式評審一般是在正式評審之前進行 的准備性工作。非正式評審往往由項目負責人召集，由盡可能多的項目相關人員一起參與討論， 然后就諸多需求結論是否正確給出一個基本判斷。 在非正式評審結果產生以后，接着需要進行正式的需求評審。這時，軟件開發機構需要拿 着經過非正式評審的需求文檔訪問用戶，逐條地向各個用戶解釋需求含義。 在正式評審過程中，軟件評審小組一般需要針對以下問題進行專門的檢查與評價：
（1）一致性：需求文檔對需求的描述是否有不一致的地方？
（2）完整性：是否還有需要的但沒有寫到需求文檔中的功能？
（3）可檢驗性：需求描述是否可實際測試？
（4）可讀性：需求描述能否被用戶讀懂？
（5）可跟蹤性：是否清晰地記錄了需求的出處？
（6）可調節性：需求是可調節的嗎？假如需求出現變更，能否不對系統帶來太大的影響？
2. 需求原型評價
本章 4.3.3 節主要說明了如何使用需求原型完善用戶的需求，但在這個過程中也包括對用 戶需求的有效性驗證。例如，可以根據需求文檔為用戶創建一個可以運行的系統模型，使用戶 通過模型進行更加接近實際的系統需求檢驗。 需求原型主要用來提供給用戶評價，以方便用戶進行需求確認。為了使需求原型評價更加 有效，分析人員有必要從不同方面對用戶評價作些引導。例如，為了啟發用戶的評價行為，可 以針對界面原型提出以下問題：
（1）界面所顯示的功能是你所期望的嗎？
（2）有遺漏的功能嗎？
（3）有多余的功能嗎？
（4）你感覺界面復雜嗎？
需求原型評價還有利於發現用戶的一些潛在需求。因此，在通過原型進行需求驗證的時候， 除了需要從用戶對原型的評價中確認用戶的想法之外，還有必要觀察用戶對原型的操作，以此 發現用戶所需要的而未能表達出來的需求。 用於需求評價的原型一般是拋棄型原型，當需求被確定之后，原型會被拋棄。這種原型能 夠快速創建，容易修改，可以加快需求工程速度，降低需求成本。 需求原型也可以是進化型原型，特別是當開發者在需求原型上花費時間太多的時候，就自 然會產生出要把原型進化為目標系統的想法。若要使需求原型能夠進化則一般需要滿足以下兩 個條件：
其一：原型創建工具和目標系統創建工具應該盡量一致，以方便從原型到目標系統的無縫 過渡。例如，使用 Microsoft Visual Basic、Inprise Delphi 等基於組件的可視化開發工具作 為原型創建工具。
其二：原型創建時必須考慮到軟件的健壯性、可靠性、可維護性，以及工作性能等技術性 要素，以保證原型質量標准和目標系統質量標准是一致的。 以上條件意味着，要使原型能夠進化，開發者就要在原型創建時投入更多的時間、精力。 顯然這就不得不增大原型創建費用。一般來講，項目越小則原型進化的價值也就越大。
3. 基於 CASE 工具的需求一致性分析
如果需求文檔中的需求元素是用結構化或形式化語言描述的，則可以使用需求 CASE 工具 來進行需求一致性分析。 需求 CASE 工具的工作流程如圖 4-15 所示。其中，需求處理器用於處理使用形式化語言描 述的需求，並將產生的需求結果存入需求數據庫中。以后，需求分析器可以使用方法規則或符 號規則對需求數據庫中的需求結果進行一致性檢查，並能夠根據檢查結論產生出關於需求一致性的分析報告。
六、需求規格定義
需求規格說明書是需求分析階段需要交付的基本文檔，涉及引言、術語定義、用戶需求、 系統體系結構、系統需求等有關軟件需求及其規格的諸多描述與定義。應該說，有關軟件系統 的一系列需求結論都需要以正式文檔的形式寫進這份文檔之中。 需求規格說明書將成為開發者進行軟件設計和用戶進行軟件驗證的基本依據，其作用是使 軟件用戶和軟件開發者雙方在軟件正式開發之前能夠對需要開發的軟件有一個共同認可的規格 定義。 需求規格說明書具有里程碑的意義，涉及比較廣泛的讀者群。幾乎所有與軟件項目有關的 人員，包括用戶、項目管理人員、系統開發人員、系統測試人員和系統維護人員等，都需要閱 讀這份文檔，並或多或少地受到它的一定范圍與程度的約束。
• 軟件用戶：提出需求，按照需求規格說明書對軟件系統進行驗收。
• 項目管理人員：根據需求規格說明書制定項目詳細開發計划，安排項目進程。
• 系統開發人員：以需求規格說明書為依據進行系統設計與實現。
• 系統測試人員：以需求規格說明書為依據進行系統有效性測試。
• 系統維護人員：通過需求規格說明書來幫助對系統功能與構造的認識。
小結:
1. 需求分析任務
（1）用戶需求 用戶需求是用戶關於軟件的一系列意圖、想法的集中體現，是用戶關於軟件的外界特征的 規格表述。
（2）系統需求 系統需求是比用戶需求更具有技術特性的需求陳述，是提供給開發者或用戶方技術人員閱 讀的，並將作為軟件開發人員設計系統的起點與基本依據。主要包括：功能、數據、性能、安 全等諸多方面的需求問題。
2. 需求分析過程
需求分析是對軟件系統的后期分析，需要進行的活動包括：分析用戶需求、建立需求原型、 分析系統需求和進行需求驗證等。
3. 用戶需求獲取
（1）用戶調查是最基本的用戶需求信息收集方法，比較常用的調查方法包括：訪談用戶、 開座談會、問卷調查、 跟班作業、收集用戶資料。
（2）需求原型可被用來解決用戶對軟件系統在需求認識上的不確定性。一般情況下，開發 人員將軟件系統中最能夠被用戶直接感受的那一部分東西構造成為原型。例如，界面、報表或 數據查詢結果。
4. 結構化分析建模
所謂模型，就是對問題所做的一種符號抽象。可以把模型看作為一種思維工具，利用這種 工具可以把問題規范地表示出來。主要的分析模型包括：
（1）功能層次模型。它使用矩形來表示系統中的子系統或功能模塊，使用樹形連線結構來 表達系統所具有的功能層級關系。
（2）數據流模型。用於描述系統對數據的加工過程，其圖形符號是一些具有抽象意義的邏 輯符號，主要的圖形符號包括：數據接口、數據流、數據存儲和數據處理。可以依靠數據流圖 來實現從用戶需求到系統需求的過渡。結構化分析就是基於數據流的細化實現的，它是結構化 分析方法的關鍵。
（3）數據關系模型。也稱為 ER 圖，是應用最廣泛的數據庫建模工具。需要通過數據實體、 數據關系和數據屬性這三類圖形元素建立數據關系模型。
（4） 系統狀態模型。通過系統的外部事件、內部狀態為基本元素來描繪系統的工作流程， 這種建模方式比較適合於描述一些依賴於外部事件驅動的實時系統。
5. 需求有效性驗證
需求有效性驗證是指對已經產生的需求結論所要進行的檢查與評價。 一般需要對需求文檔草稿從有效性、一致性、完整性、現實性等幾個方面進行有效性驗證。 比較常用的需求有效性驗證方法與工具包括：需求評審、需求原型評價和基於 CASE 工具的需求 一致性分析。
6. 需求規格定義
需求規格說明書是需求分析階段需要交付的基本文檔，將成為開發者進行軟件設計和用戶 進行軟件驗證的基本依據，涉及引言、術語定義、用戶需求、系統體系結構、系統需求等有關 軟件需求及其規格的諸多描述與定義。