軟體需要解決的是使用者所面臨的現實問題，但是，這些現實問題需要由軟體技術人員來解 決。情況往往是，開發軟體的技術人員精通計算機技術，但并不熟悉使用者的業務領域；而使用者 清楚自己的業務，卻又不太懂計算機技術。是以，對于同一個問題，技術人員和使用者之間可能 存在認識上的差異。也是以，在軟體技術人員着手設計軟體之前，需要由既精通計算機技術又 熟悉使用者應用領域的軟體系統分析人員，對軟體問題進行細緻的需求分析。 需求分析是軟體工程過程中一個重要的裡程碑。在需求分析過程中，軟體系統分析人員通 過研究使用者在軟體問題上的需求意願，分析出軟體系統在功能、性能、資料等諸多方面應該達 到的目标，進而獲得有關軟體的需求規格定義，其資訊流如圖 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. 需求規格定義
需求規格說明書是需求分析階段需要傳遞的基本文檔，将成為開發者進行軟體設計和使用者 進行軟體驗證的基本依據，涉及引言、術語定義、使用者需求、系統體系結構、系統需求等有關 軟體需求及其規格的諸多描述與定義。