1問題分析的主要步驟(五步)?

(1)在問題定義上達成共識；

(2)理解根本原因，分析問題背后的問題；

(3)確定相關人員和用戶；

(4)定義解決方案的界限；

(5)確定加在解決方案上的約束。

2魚骨圖主要用于定性分析，帕累托圖主要用于定量分析。

3魚膏圖、帕累托圖構愛的主要步驟？

魚骨圖

A選擇問題

首先選擇一個具體的問題或者結果。在選擇問題時，要保

證問題是專門的、定義嚴謹的、范圍相對較小的(對于大范圍

的問題往往需要考慮將其分解成相對較小的問題)，并且保證

參與人員切實理解要分析的內容。對問題定義產生出來的問題

一般都應該進行一次獨立的魚骨圖分析。

B頭腦風暴

就導致問題的可能原因進行頭腦風暴。將大家提出的意

見記錄下來，確認后貼到魚骨圖上。

需要注意的是不要將原因和解決方案混為一談。在確定

原因的分類前先進行頭腦風暴(一個人提，大家批)，不然

思考問題的范圍就會受到限制。支持者需要引導和鼓勵參與

者參與其中。

C確定問題類型

對頭腦風暴的結果進行整理，確定出主要的原因類型。

一般來說，劃分出來的問題不要少于2類，不要超過6類

(經驗數值，僅供參考)。經常使用的類型有：人、設備、

材料、環境、方法、過程等.將這些類型補充到魚骨圖上。

D分配原因

將頭腦風暴中得出的潛在原因放在魚骨圖上，并且確保每

一項原因都歸于適當的類別中。如果原因看起來可以放在多個

類別中，就表示是多重原因造成的問題。但如果多次出現多重

原因，可能就以為著分類存在問題。該階段將形成最終的魚骨圖

E分析根本原因

對魚骨圖中羅列出來的所有潛在原因進行分析。分析出

造成某一結果的最根本原因是什么？找出核心所在。

方法如下：

通過參與者之間的公開討論來分享看法和經驗；

尋找重復的原因，或者與特定類有關的原因的數量；

使用檢查表收集資料、制造流程圖或者進行用戶調查，

通過帕累托分析法測就各種原因的相對強度；

投票(真理多數情況下掌握在多數人手里)

帕累托圖

在通過使用魚骨圖完成問題原因的定性描述后。仍然存在一個

問題，就是根本原因的辨識需要有經驗的決策者確定，或者根

據人類固有經驗（少數服從多數）確定。更好地方法是能夠開

展定量分析。帕累托分析可以幫助我們做出這樣的定量分析。

帕累托分析應用就是根據魚骨圖分析的結果，通過收集相關統計

資料，通過直方圖的方式顯示問題的相對頻度或者大小高低等定

量結果。

A確定問題和相關原因

利用魚骨圖的結果。

B收集數據

有針對性第收集數據。例如上例中，我們可以抽取一些

廢品，分析這些廢品產生的原因

C繪制直方圖

4上下文圖畫法步驟？

在繪制上下文關系圖時應該采用以下步驟：

1、首先用一個矩形表示系統，寫上系統的名稱，將整個系統看做一個黑盒子；

2、然后找到該系統的所有Customer（客戶），考慮這些Customer會發起什么事件，這些事件會引

發Worker（內部工作人員）的什么工作，將這些序列逐一表示出來；

3、最后在看看系統的每個Worker還有沒有一些主動發起的事件。

（Customer：也就是該主題域的客戶，它處于該主題域的外部.如，對于體檢業務子系統而言，體檢者顯然就是

一類客戶，除此之外，客服中心、物資部門、財務部門的工作人員也是這個主題域的Customer。

Worker：也就是該主題域的工作人員，它處于該主題域的內部。如，服務中心，體檢科室，綜合科的工作人員

都是其Worker。關鍵要點在于“針對本主題域”而言。）

5需求獲取的主要活動

研究應用背景，建立初始的知識框架；

根據獲取的需要，采用必要的獲取方法和技巧；

先行確定獲取的內容和主題，設定場景；

分析用戶的高（深）層目標，理解用戶的意圖；

進行涉眾分析，針對涉眾的特點開展工作。

6需求協商的幾條法則的應用？

差異問題協調法則：

不同的業務層面（有時即使是相同業務層面）的用戶對同樣的概念或者流程

有不同的認識和理解，會出現一些差異，在需求整理時應該將這些差異明確

標識出來，并展示給用戶高層管理人員，由他們來確定如何消除這些差異，

并將這些情況記錄。

消除變更問題協調法則：

上面法則提到的問題，從消除變更的角度考慮仍然存在問題。僅僅將差異標

識并展示給高層并不能消除變更的可能，應該考慮這些差異形成背后的問題，

應該從開發角度考慮如何消除這些差異，并提供給高層管理人員。要有主動性

需求協商時機法則：

不要在需求凍結前開展需求辦商工作。需求協商應該在

需求獲取過程中不斷開展，出現就考慮消除。如果都等到凍結前，將所有矛

盾集中體現對工作是非常不利的。

實例：

W公司開發的信息系統到了需求凍結前夕，A建立拿出厚厚一本需求

協商底稿，分為重點差異協調部分，一般差異協調部分，已協調差異列表。

結果用戶高層非常不滿，認為這些工作需要大量時間難以短期完成。

7需求獲取的主要方法

用戶訪談

用戶調查

文檔分析

原型法（情節串聯板）

模型驅動的方法

8開放式話題與封閉式話題運用

開放式話題

優點：

-讓被會見者感到自在；

-會見者可以收集被會見者使用的詞匯，這能反應他的教育、價值標準、杰度和信

念；

-提供豐富的細節；

-對沒采用的進一步的提問有啟迪作用；

-讓被會見者更感興趣；

-容許更多的自發性；

-會見者可以在沒有太多準備的情況下進行面談。

缺點：

-提此類問題可能會產生太多不相干的細節；

-面談可能失控；

-開放式的回答會花費大量的時間才能獲得有用的信息量；

-可能會使會見者看上去沒有準備

封閉式話題

?：?優點：

-節省時間；

-切中要點；

-保持對面談的控制；

-快速探討大范圍問題；

-得到貼切的數據

?：?缺點：

-使得被會見者厭煩；

-得不到豐富的細節；

-出于上述原因，失去主要思想；

-不能建立和面談者的友好關系。

9用戶訪淡時問題組織的三種方式及特點？

金字塔結構

?：?如果會見者認為被會見者需要對話題進行預熱，可以采用金字塔結構，通過逐步的引導

來使得被會見者打開話匣子。

如果會見者發現自己事先對事實的確認存在較大偏差或者被會見者看上去不情愿討論這

個話題，也可以采用金字塔結構。

當想結束討論這個話題的時候，使用金字塔結構的提問順序也是有用的。

漏斗結構

。漏斗結構為開始一場面談提供了一種容易而輕松的途徑。

當被會見者對這個話題有情緒，并且需要自由表達這些情緒的時候，需要采用漏斗型提

問順序。

或者在會見者事先對事實了解不多時，也應該采用漏斗結構的問題組織方式。

用這種方式組織面談能得出很多的詳細信息，以至于沒有必要使用長序列的受限制問題

和調查問題。

菱形結構

使用菱形結構的主要優點是通過各種各樣的問題保持被會見者的興趣和注意力。一旦掌

握了如何在正確的時間問正確的問題，就可以多樣地選擇問題的順序。

10市場調查和需求獲取在訪夜與調查順序上有何不同？原因何在？

一般來說，在開展市場調查時，由于很難深入接觸到潛在的用戶。所以

總是先調查，后訪談。而在需求獲取時，通常采用的策略是先訪談，后調查。

其實原因在于市場調查與需求獲取有不同的應用背景C一般市場調查通常

用于驗證潛在客戶對產品的接受程度。而需求獲取的目標是要理解客戶需要解

決的問題。

也就是說需求獲取時你往往還沒有產品，信息不夠充分，所以很難設計出

有效的調查問卷。

11采用原型方法的三個目的？

明確并完善需求

原型作為一種需求工具，它是對部分系統的初步實現，因為我們尚沒有很好地了解該系統。

研究設計選擇方案

原型作為一種設計工具，涉眾可以用它研究不同的用戶交互技術，優化系統易用性，并評估

可能的技術方案。

發展為最終產品

原型作為一種構造工具，是產品一個最初子集的完整功能實現。

12用例描述方法

13需求關系的根本任務是什么？

需求分析是軟件需求中最核心的工作，需求建模是需求分析

的主要手段。

需求分析是軟件定義時期的最后一個階段，它的基本任務是

準確地回答“系統必須做什么?”這個問題。

需求分析的任務還不是確定系統怎樣完成它的工作，而僅僅是確定系統必須完成哪些

工作，也就是對目標系統提出完整、準確、清晰、具體的要求。

需求分析根本任務：建立分析模型，創建解決方案。

14需求分析任務中分解策略主要包含那幾種？每種策略分別迨合應用于

砰些系統的開發

1）業務流程為主線的分解策略；

業務流程為主線的分解策略是目前比較流行的方法，主要按照

“業務”的角度考慮分解方法。此方法特別適合聯機事務處理系

統、管理信息系統（MIS）。

目標系統一》主題域的分解依據是“目標決定范圍”；

主題域-》業務事件所做的是理清業務脈絡；

業務事件-》業務活動所做的是填充細節；

業務活動-》處務步驟所做的是細化和確認工作。

2）程序結構為主線的分解策略；

方法是需求分析最常用的分解方法。當由于其過早進入程序結

構，割裂了與問題域之恒的聯系，從而容易導致對問題域研究的

不足，降低了需求的質量。目前認為此種方法僅適合于問題域比

較清晰，問題不算復雜的情況,例如工具軟件、嵌入式系統等。

3）基于場景的分解策略；

對于決策支持系統、面向用戶的嵌入式系統等來說,決策場景、

使用場景是主要的線索。向上可以總結成一類相似的集合，再

總結成一系列的關注點或者功能域，向下可以分解成具體的步驟

或者操作任務。

4）基于數據的分解策略等。

上述分解策略都是從“業務”角度來組織。但對于類似數據倉庫

之類的數據類項目,業務線索并不是十分明顯，或者并不重要

這是就需要以數據為主的分解策略。其中主題域仍然與“業務

流程為主的分解策略”類似。而主題類是企業中的高層實體，

主要由一組企業的邏輯數據類來表示，而企業的邏輯數據類在

實現時又會對應于多個物理數據類。

15需求分析中分解與提煉的比較？

分解是一種自頂向下的方法，當按照任何一種線索進行分解時。就會破壞其它線索的完整性。例

如，如果以“業務”為線索，就會發現數據需求分解后會出現相互交疊的情況，也就是在多個業

務事件中都涉及相同的類。

此種情況出現時，可能會影響需求分析人員建立全面的理解，因此需要采用自底向上

的方法進行提煉。例如將每個業務事件中的類進行提煉，抽取出共性的部分，建立針對整個系統

的全局領域模型。

16構建分析橫型的目的？

1將復雜的系統分解成為簡單的部分以及它們之間的聯系，確定本質特征

2和用戶達成對信息內容的共同理解

3分析的活動主要包括識別、定義和結構化，它的目的是獲取某個可以轉換為知識的事物的信

息

17分析模型的建模方決？

模型

“模型是對事物的抽象，幫助人們在創建一個事物之前可以有更好的理解”

-集中關注問題的計算特性(數據、功能、規則等等)

“它是對系統進行思考和推理的一種方式。建模的目標是建立系統的一個表示，

這個表示以精確一致的方式描述系統，使得系統的使用更加容易”

-建模方法

,抽象

?分解

?投影

?抽象(Abstraction)

-一方面要求人們只關注重要的信息，忽略次要的內容

?通過強調本質的特征，就減少了問題的復雜性(例如學生模型)

-另一方面也更求人們將認知保留在適當的層次，屏蔽更深層次的細節

?在問題的各元素之間推斷出更廣泛和更普遍的關系，幫助人們尋找解決方

案

?：?分解(Decomposition/Partitioning)

-“分而治之”

?將單個復雜和難以理解的問題分解成多個相對更容易的子問題，并掌握各

子問題之間的聯系

-分解的方案往往還能提供問題的解決思路

?投影(Projection)

-多視點方法

18實際的建模過程中要遵循的建模原則？

在建模時，要注意考慮到計劃之外的變化：設計要文檔化，只有這樣，才能使不熟悉的新手也可

以有效地利用設計的方案。用可視化的模型表達現實世界，有助于理解變化所代表的含義。

在實際的建模過程中要遵循以下建模原則：

-模型是用來溝通的；

?選擇創建什么模型對如何解決問題和如何形成解決方案具有深遠的影響。

?每種模型可以在不同的精度級別上表示；

?最好的模型是與現實相聯系的模型；

?單個模型往往不夠充分，對每個重要的系統最好用一組幾乎獨立的模型去處理。

19需求建模的流程？

先依據獲取的問題域信息建立初步的模型。

然后分析用戶需求，對模型進行調整，得到一個中間形式的模型形式。

最后，對調整后的模型進行邏輯推理和驗證，如果符合預期的期望，那么它就是最終的解決

方案模型。

20常見的需求分析技術?

結構化技術

-數據建模

實體關系圖EntityRelationshipDiagram

-過程建模

數據流圖DataFlowDiagram

上下文圖ContextDiagram

微規格說明Mini-Specification

?數據字典DataDictionary

-行為建模

?狀杰(轉換)圖/矩陣State(Transition)Diagram/Matrix

-過程/數據關系建模

?功能實體矩陣Functicn/Entit.yMatrix

-信息工程方法

功能分解圖FunctionDecompositionDiagram

過程依賴圖ProcessDependencyDiagram

?面向對象技術

-UML

,用例圖Use-CaseDiagram

?類圖ClassDiagram

?交互圖(順序圖/通信圖)Interaction(Sequence/Communication)

Diagram

,活動圖ActivityDiagram

?對象約束語言ObjectConstraintLanguage

,狀杰圖StateChartDiagram

21正確認識UML(2)(3)(4)

(2)UML的準確理解

UML是一種語言(Language)

實際上UML就是一種表示方法，它不是方法論。

UML是一種建模語言(ModelingLanguage)

它不是編程語言，而是建模語言。它不僅包含軟件建模，而且可用于業務建模、流程建模等

多種領域。

UML是統一愛模語言(UnifiedModelingLanguage)

它是一種標準化的、統一的建模語言，0MG認可的工業標準，也是如IBM、SUN等大型公司認

可的事實標準。

(3)為什么要使用UML

UML是一種統一的、標準化的建模語言，它為參與軟件設計和開發的各類人員提供統一的語言,

使開發人員能夠基于共的模型來理解業務、需求，理解軟件及其架構如何構造的。

(4)如何使用UML

UML2.0標準中，共定義了13種不同的圖，這些圖的功能以及與UMLL0之間的關系如下表

圖名功能備注

類圖描述類、類特性及類間關系UMLL0原有

對象圖描述一個時間點上系統各個對象的一個快照UMLL0非正式圖

復合結構圖描述類的運行時刻的分解UML2.0新增

構件圖描述構件的結構和連接UMLLO原有

部署圖描述在各個節點上的部署UMLLO原有

包圖描述編譯時的層次結構UMLLO非正式圖

用例圖描述用戶與系統如何交互UMLLO原有

活動圖描述過程行為與并行行為UMLLO原有

狀態圖描述事件如何改變對象生命周期UML1.0原有

順序圖描述對象之間的交互、重點在于強調順序UML1.0原有

通信圖描述對象之間的交互、重點在于連接UML1.0中的協作圖

定時圖描述對象之間的交互、重點在于定時UML2.0新增

交互概觀圖是一種順序圖與活動圖的混合UML2.0新增

如何使用UML-需求階段一般常采用的圖

使用頻率圖名功能

主體用例圖說明角色和使用場景之間的關系

活動圖說明業務流程，以及業務活動的步驟

順序圖描述對象之間的交互

類圖說明業務實體之間的關系，體現結構規則

輔助構件圖說明主題域劃分以及他們之間的服務接口

部署圖描述系統的部署環境，體現設計約束

22結構化分析遵循的三條原則？

結構化分析遵循的三條基本原則：

分解

抽象

映射

23結構化分析模型的構成元素？

?：?數據字典(DD)

-模型核心，包含了所有數據對象的描述的中心庫。

?：?E-R圖(ERD)

-表示數據對象以及相互的關系，用于數據建模。

?數據流圖(DFD)

指明數據在系統中移動時如何被變換；

-描述對數據流進行變換的功能；

DFD中每個功能的描述包含在加工規約(小說明)。

-用于功能建模。

?狀態變遷困(STD)

-指明作為外部事件的結果，系統將如何動作。用于行為建模。

24結構化京模示例-建立計算機售書東統的近韓模型

(1)通過對現實環境的調查，獲得當前系統的物理模型。

-9堡

(2)去掉具體模型中的非本質因素：

-抽取現實系統的實質，抽象出當前系統的邏輯模型。

.…，??-a3?XM??

(3)分析當前系統與目標系統的差別,建立目標系統的邏輯模型。

(4)對目標系統的邏輯模型進行細化、改進與優化

(5)需求分析的驗證

25數據流圖CDFDJ第9章PPT第20-69頁

?：?數據流圖（DFD：DataFlowDiagram）就是組織中信息運動的抽象，是信息邏輯系統模

型的主要形式。這個模型不涉及硬件、軟件、數據結構與文件組織，它與對系統的物理

描述無關，只是用一種圖形及與此相關的注釋來表示系統的邏輯功能，即所開發的系統

在信息處理方面要做什么。

由于圖形描述簡明、清晰，不涉及到技術細節，所描述的內容是面向用戶的，所以即使

完全不懂信息技術用用戶單位的人員也容易理解。因此數據流圖是系統分析人員與用戶

之間進行交流的有效手段，也是系統設計（即建立所開發的系統的物理模型）的主要依

據之一。

數據流圖脫離系統中的物理因素（如計算機等），表達出系統對信息的加工情況。DFD可以

描述原系統/新系統/子系統。

?DFD是SA的主要工具，它簡單、直觀，用圖形、文字描述系統。它便于使用、便于交流、

便于討論、便于形成共識，是計算機專業人員和用戶單位業務人員的共同語言。

DFD由四種基本符號組成。如下圖所示。

匚□□一

外部項（S）,也據加工（P）數娓存健（D）數據濠（F）

A?.

數據流圖的構成及基本元素

（1）外部項（外部實體）

源點和終點（又稱端點）是系統外的實體，稱作外部項。它們存在于環境之中，與系統

有信息交流，從源點到系統的信息叫系統的輸入；從系統到終點的信息稱系統的輸出。

同一個端點可以是人或其它系統。在DFD中引入源點和終點是為了便于理解系統，所

以不需要詳細描述它們。它們可有編號，以“S”開頭。

?：?外部實體

-外部實體是指處于待構建系統之外的人、組織、設備或者其他軟件系統，

它們不受系統的控制，開發者不能以任何方式操縱它們。

-需要進行建模的外部實體是那些和待構建的軟件系統之間存在著數據交

互的外部實體，它們是待構建系統的數據源或者數據目的地

-所有的外部實體聯合起來構成了軟件系統的外部上下文環境

引入外部項是為了劃定系統的邊界，不需嚴格定義。但也要統一編號，而且要

與數據字典中的編號相一致。源點和終點可以在多處出現，用特定符號表示重復的外

部項。

為了使DFD清楚易懂，我們對加工、數據流、文件的命名都力求簡單。至于加

工的加工邏輯、數據流的數據結構等，將在數據字典中定義。數據字典和DFD一起來

描述系統。

常見的外部項（外部實體）有：

a)從待構建系統中獲取數據或者為其提供數據的組織，如：供貨方，銷售方等。

b)需要和待構建系統交互的個人，如：顧客，辦事員。

c)需要和待構建系統交換數據的其他軟件系統。

(2)加工

?加工又稱處理亦稱變換，它表示對數據流的操作。

加工的符號分成上、下兩部分，從上到下分別是標識部分和功能描述部分。

?標識部分用于標注加工編號，加工編號應具有唯一性，以標識加工，以“P”開頭。

。功能描述部分月來寫加工名。為使DFD清晰易讀，加工名應簡單，能概括地說明對

數據的加工行為，其詳細描述在數據詞典中定義。

加工要逐層分解，以求得分解后的加工功能簡單、易于理解.

(3)數據流

數據流由一個或一組確定的數據項組成。

數據流名應能直觀地反映數據流的含義。如產量日報表、匯款單、錄取通知書、課程表

等。也可以用一組數據中的主要數據為數據流命名。例如“考生成績單''由考生姓名、成

績、通訊地址等數據組成，但成績是主要的，所以可用“考生成績”作為數據流的名字。

數據流應統一編號，編號要與數據字典一致。

數據流經過一個加工后其數據結構/數據含義/數據的順序一定要有所變化，否則這個加

工就沒有意義了。

(4)數據存儲(文件)

數據存儲是用來存貯數據的。在分層DFD中，數據存儲一般僅屬于某一層或某幾層，因

此又稱數據存儲為局部文件。現對數據存儲符號說明如下：

①數據存儲名寫在開口的長方框內，應概要地說明文件中的主要數據。

②數據存儲上一定要有數據流。

③為便于說明和管理，數據存儲亦應編號，編號寫在文件符號左端小方格中，以“D”開

頭。

?④為避免DFD中出現交叉線，同一數據存儲可在多處畫出。

數據流圖的繪制步驟

?<1)確定所開發的系統的外部項(外部實體)，即系統的數據來源和去找。

(2)確定整個系統的輸出數據流和輸入數據流，把系統作為一個加工環節，畫出關聯圖。

(3)確定系統的主要信息處理功能，按此將整個系統分解成幾個加工環節(子系統)確

定每個加工的輸出與輸入數據流以及與這些加工有關的數據存儲。

?(4)根據自頂向下，逐層分解的原則，對上層圖中全部或部分加工環節進行分解。

?(5)重復步驟(4),直到逐層分解結束。

(6)對圖進行檢查和合理布局，主要檢查分解是否恰當、徹底，DFD中各層是否有遺漏、

重復、沖突之處，各層DFD及同層DFD之間關系是否合理，及命名、編號是否確切、合

理等，對錯誤與不當之處進行修改。

(7)和用戶進行交流，在用戶完全理解數據圖的內容的基礎上征求用戶的意見。

數據流圖繪制規則

(1)過程是對數據的處理，必須有輸入，也必須有輸出，而且輸入數據集和輸出數據集應

該存在差異。

(2)數據流是必須和過程產生關聯的，它要么是過程的數據輸入，要么是過程的數據輸出。

陽獸勰暹瞇x

I—I~~<□HHZZI

O~~￡□LZF——-EK

?一、

II----TIII~~HI

口---dIII—

(3)DFD當中所有的對象都應該有一個可以唯一標識自己的名稱。

-過程使用動詞

-外部實體、數據流和數據存儲使用名詞

數據流圖繪制過程

繪制數據流圖的主要原則

?(1)明確系統邊界。

?：?(2)自頂向下逐層擴展。

?(3)合理布局。

?(4)數據流圖繪制過程，就是系統的邏輯模型的形成過程，必須始終與用戶

密切接觸，詳細討論，不斷修改，也要和其他系統建設者共同商討一求一致意

見。

數據流圖應用示例-銀行取款系統

簡單銀行取款應用描述

(1)儲戶將填好的取款單、存折交銀行，銀行做如下處理：

①審核并查對帳目，將不合格的存折、取款單退回儲戶，合格的存折、取款單送取款處理。

②處理取款修改帳目，將存折、利息單、結算清單及現金交儲戶，同時將取款單存檔。

畫出銀行取款處理數據流圖。

第一步，畫出關聯數據流圖.注意，現金是實物，不能作為數據流。

第二步，逐層分解加工，畫出下層DFD。

ra.i**we

電數?

,1不會格行苑J

數據流圖應用示例-圖書預定系統

圖書預訂系統：書店向顧客發放訂單，顧客將所填訂單交由系統處理，系統首先依據圖書目錄對

訂單進行檢查并對合格訂單進行處理，處理過程中根據顧客情況和訂單數目將訂單分為優先訂單

與正常訂單兩種，隨時處理優先訂單，定期處理正常訂單。最后系統根據歷處理的訂單匯總，并

按出版社要求發給出版社。

畫出圖書預定系統的各層數據流圖。

?：?第一步，畫出關聯數據流圖。

nGB書項訂羽統關BXflD

?第二步，逐層分解加工，畫出下層DFD。注意到根據題意，當繪出系統頂層圖后并不能將

所有加工分解成基本加工，還要進行二層圖分解。并在分解加工過程中逐步充實進數據

存儲。見圖。

*?nitmu?

數據流圖的作用

?：?前面說過，系統分析的主要任務是建立新系統的邏輯模型。具體地講主要是畫出新系統

的DFD,編寫定義DFD的數據詞典。

?建立新系統的DFD是一項十分重要的工作。因為建立的DFD是系統開發乃至系統維護的

依據，是系統的重要文檔之一。系統分析員要在詳細調查中，在與用戶的反復交流中修

改DFD,力求新建DFD是正確的、準確的。

DFD的層級結構

?：?依據所含過程的不同抽象程度，DFD可以在不同的抽象層次上進行系統的描述

一個比較抽象的過程可以被展開為一個子過程更加具體的DFD圖

DFD的層次結構

-上下文圖

-。層圖

-N層圖（N>0）

關于上下文圖

-將整個系統看做是一個過程，這個過程實現系統的所有功能，是系統功能的最高抽象

?上下文圖中存在且僅存在一個過程，表示整個系統。這個單一的過程通常編號為0

?上下文圖中需要表示出所有和系統交互的外部實體，并描述交互的數據流，包括系統

輸入和系統輸出

?上下文圖中不會出現數據存儲實例

-它非常適合于描述系統的應用環境、定義系統的邊界

關于0層圖

位于上下文圖下面一層，是上下文圖中單一過程的細節描述，是對該單一過程的第一次

功能分解

-是整個系統的功能概圖

0層圖應該被描述的簡潔、清晰，需求工程師要根據系統的復雜度掌握0層圖中過程的

抽象程度

關于N層圖

-對。層圖的過程分解產生的子圖稱為1層圖，對N層圖的過程分解后產生的子圖稱為N+1

層圖（N>0）,過程分解是可以持續進行的，直至最終產生的子圖都是原始DFD圖

-原始DFD圖可以進一步展開為

?微規格說明

?數據字典

-在低于0層圖的子圖上通常不顯示外部實體

層次結構的構建

建立步驟

1.創建上下文圖

2.發現并球立DFD片新

3.根據DFD片斷組合產生0層圖；

4.對0層圖的過程進行功能分解，產生N層圖

創建上下文圖

在需求獲取階段獲得的業務需求以及業務需求所決定的項目前景與范圍可以用來幫助建立系

統的上下文圖。

發現并建立DFD片段

DFD片斷是系統對某個事件的響應過程的DFD描述，它是為系統中發生的重要事件創建的。

它將系統對事件的處理看做是一個單一的過程，重點描述這個單一過程與事件外界（包

括系統內其他部分和系統外的外部實體）的數據流交互。

產生0層圖

往往需要多次調整DFD片段的整合結果才能得出

?對DFD圖（尤其是0層圖）質量的判定有下面幾個準則：

-1、沒有語法錯誤，遵守前述的各項規則。

-2、具有良好的語義，過程的功能設置要高內聚、低耦合。

-3、保持數據一致性，過程的輸入流要足以產生數據輸出。同時過程的輸出流是在

充分利用輸入數據的基礎上產生的，不存在輸入數據的浪費。

-4、控制復雜度，不要一次在圖中顯示太多的信息。一般情況下，一個圖中的過程

數量最好控制在5?9（人腦的最佳信息處理量）個。而且圖中的數據流數量越少

越好，越簡潔越好（接口最小化）。

功能分解產生N層圖

?功能分解是一個拆分功能的描述，將單個復雜的過程變為多個更加具體、更加精確和更

加細節的過程。

在功能分解過程當中，最重要的是要保證分解過程的平衡性（Balance）,它要求DFD

子圖的輸入流、輸出流必須和父過程的輸入流、輸出流保持一致。

在分解產生的子圖為下述情景之一時，可以判定其為原始DFD圖，此時應該停止持續的

功能分解活動：

-所有過程都已經被簡化為一個選擇、計算或者數據庫操作；

-所有數據存儲都僅僅表示了一個單獨的數據實體；

-用戶已經不關心比子圖更為細節的內容，或者子圖的描述已經詳細的足以支持后續

的開發活動；

-每一個數據流都已經不需要進行更詳細的切分，以展示對不同數據的不同處理方式；

-每一個業務表跑、事務、計算機的屏幕顯示(computeron-linedisplay)和業務

報表都巳經被表示為一個單獨的數據流；

-系統的每一個最低層菜單選項都能在子圖中找到獨立的過程。

層次結構的建立一示例

使用DFD描述常見的電梯控制系統。

-一個控制系統控制多個電梯。每個電梯被置于一個相應甬道之中，在卷揚電機的作

用下在甬道內做上下運動。甬道內安裝有多個傳感器，通常每個電梯?？奎c一個，

用來感應電梯的實時位置。電梯內部和建筑的每個電梯?？繉佣荚O置有指示器，用

來告知用戶的電梯實時位置和運動狀況。電梯內和建筑的每個電梯?？繉佣荚O有按

包.用戶可以通過這些按鈕提出服務申請并進出電梯?？刂葡到y調度用戶的申請.

讓電梯以最有效的方式滿足用戶的服務要求。

業芬需求實現業務需求需要的系統特桂局部解決方案的時外交互

SFI.1:能緲獲知電梯位置感應,并科交恰指外部輪入：感應)5那知信號

示修外部榆出：指示器箋求信號

SF1.2:能夠控制春揚電機，實現般務請求的內部輸入：詞度要求

BR1：讓電梯運轉起來

電樽運動外郁輸出：卷用電機控制信號

SFL3:閑戶可以利用按鈕發出服務請求外部輸入：按鈕信號

內部輸出：服務請求

BR2:實現電梯的療效詞SF2.1:系統從廈務請求隊列中建立高效率的內都輸入：服芬請求

尺.最大限度的服芬用戶內部輸出：詡度夏求

BR3:保證安全.尤其#?用SF3.1:系統國根據電梯的冰動軟況和期務申內部檢入：服務請求.電幡狀況

戶出入電樣的安全清控制電桶門的開關外部輸出：門控命令

門控信號

二4

012-25.電梯控制系統的上下文圖

層次結構的建立--建立DFD片斷

事件東統的響應

系統ft?先襄記錄請求，以備弼度.如果請求時電梯處于運動狀態，

閑戶利廂按鈕發出服芬請求

則系統需亶重新執行請求謂度,并在需要的情況下更改運動目標.

系統察科電梯狀態,如果處于靜止狀態且處于目前樓層.則發出門

閑戶利廂按鈕發出開關門請求

控命■令,否則不予處理.

呼應JS信號發生變化系統要根據新的信號更新電怫狀態，并通如指示器改變顯示.

電桶開始運動，印門已關閉，開始運系統要改變電棒狀態為運動狀態,然后根據等待的服務請求謂度確

動定電梯的運動目標，結合電棒目的位置，控制粗場電機開始工作.

系統更新電梯狀態為靜止狀態以停止對新增請求的處理，去除已先

電梯伸?止?印電樣已繪到處日標位置

成的請求，然后控制費抵電機停止運動，并在停止后.開啟業禪門

K12-8.電梯控制系統的外部事件及其響應

層次結構的建立-一

建立0層圖

012-27,電梯控制系統的初始。層圖

運動目標

圖12?28.電梯控制系統的最終。層圖

DFD驗證

?驗證DFD的語法

-確保DFD中不會發生語法錯誤

?瞼證DFD的結構

-驗證DFD層次結構之間的一致性

-驗證DFD層次結構說明的完備性

?：?驗證DFD的語義

-確保DFD所說明內容的正確性和準確性

26數據字典

數據字典的提出背景：

雖然數據流圖能夠形象、清晰地描述數據在系統中流動、加工、存儲的情況，但數據流圖中

的許多構成元素，如數據流、數據存儲、加工，僅依靠名稱并不能反映其本質含義，因此必須對

這些構成元素進行嚴格的定義。作為對數據流圖的補充，數據字典(DD,DataDictionary)能夠

準確地定義數據流圖中各組成成分的具體含義，二者共同構成了系統的邏輯模型。

?數據字典是一個儲存庫，包含軟件使用和產生的所有數據對象的描述，其中也包括DFD當

中數據流和數據存儲的定義。

有組織地列出DFD中的涉及的所有數據元素(數據流、數據存儲)，并定義每個數據元素的

-名稱

-別名

-使用地點

-使用方法

-使用范圍

-描述

單位/格式

名稱數據元素的原始名稱

別名數據元素的其他名稱

使用地點會使用該數據元素的過程

使用方法該數據元素扮演的角色（輸入流、輸出流或者數據存儲等）

使用范圍該數據元素存在的范圍

描述對數據元素內容的描述

單位/格式數據元素的數據類型，可能事先設置的取值

數據字典中的基本元素和含義

*X■5

■我示比又為?于時?金通的暴日遺行的定￡

■女與美?、-,mAXlhaWbMRMllft

111■帆.我水'前■或MRtft

1?1

(>?不可、ralt示?可以生、中出現.以不*現

II■用??大彩次

■H表不爆定次效力?現■復的次?依少?考?次

■■小v

-逢??！鯩M07.IZ我奉aMmf”中的保??

??K?為”?信?

符號含義示例

=包含，由…構成

Name=first_name+last_name

+指明序列結構

0內容可選Phone_No.=(Area_No.)+Local_No.

[]內容多選一

Number=[0|l|2|3|4|5|6|7|8|9]

1分割口內部的多個選項

n{}m循環,最少n次，最多m次Area_No=3{Number)4

@數據存儲的標識符(關鍵字)Student二@ID+Name+...

*?注釋Area_No=3{Number}4**區號為3到4位數字

數據字典中的條目及說明格式

數據字典是關于數據流圖中各種成分詳細定義的信息集合，可將其按照說明對象的類型劃分

為四類條目，分別為數據流條目、數據項條目、數據文件條目和數據加工條目。

數據字典的任務是：對于數據流圖中出現的所有被命名的圖形元素在字典中作為一個詞條

加以定義，使得每一個圖形元素的名字都有一個確切的解釋。

(1)數據流條目

數據流在數據流圖中主要用于說明數據結構在系統中的作用和流動方向，因此數據流也被稱

作“流動的數據結構“。數據字典中數據流條目應包括以下幾項主要內容：數據流名稱、數據流

別名、說明、數據流來源、數據流流向、數據流組成和數據流量等。

數據流詞條的描述示例1:

數據流名：發票

說明：用作學生已付書款的依據

數據流來源：來自加工“審查并開發票”

數據流去向：流向加工“開領書單”。

數據流組成：學號+姓名+書號+單價總價+書費合計

數據

工資系統中的出勤表數據流在數據字典中的條目描述為：

數據流名稱：出勤表

數據流別名：無

說明：由人事部門每月月底上報的職工考勤統計數字

數據流來源：人事部門

數據流流向：加工Li.i(統計出勤、請假及曠工時數)

數據流組成：出勤表=年份+月份+職工號+出勤時數+病假時數+事假時數+曠工時數

數據流量：1份/月

(2)數據項條目

數據流圖中每個數據結構都是由若干個數據項構成的，數據項是加工中的最小單位，不可再

分。數據字典的數據項條目中應包含的主要內容有：數據項名稱、數據項別名、說明、類型、長

度、取值范圍及含義等。

例如：出勤表中的職工號數據項在數據字典中的條目描述為

數據項名稱：職工號

數據項別名：employee_no

說明：本單位職工的惟一標識

類型：字符串

長度：6

取值范圍及含義：1?2位(00..99)為部門編號：3?6位(XX0001..XX9999)為人員編號

(3)數據文件條目

數據文件是數據流圖中數據結構的載體。數據字典的數據文件條目中應包含的主要內容有:

數據文件名稱、說明、數據文件組成、組織方式、存取方式、存取頻率等。

例如：工資系統中的職工工資檔案文件在數據字典中的條目描述為

數據文件名稱：工資檔案

說明：單位職工的基本工資、各項津貼及補貼信息

數據文件組成：職工號+國家工資+國家津貼+職務津貼+職齡津貼+交通補貼+部門補貼+

其他補貼

組織方式：按職工號從小到大排列

存取方式：順序

存取頻率：1次/月

⑷數據加工條目

在數據流圖中只簡單給出了每個加工的名稱，在數據字典中通過數據加工條目主要是要說

明每個加工是用來“做什么”的。數據字典的數據加工條目中應包含的主要內容有：

數據加工名稱、加工編號、說明、輸入數據流、輸出數據流、加工邏輯等。

〔例如「X資系統中的訐算應發工資這個加工在數據字典中的條目描述為|

數據加工名稱：計算應發工資

加工編號：1.2

27ERD也模示例

簡單情況下ERD建模

(1)從描述信息中辯識實體

-可以重點關注描述信息中的名詞，看系統是否需要收集其相關的特征

?(2)確定實體的標識符

(3)建立實體間關系

-判斷各個關系的建立是否會產生新的關聯實體或者影響已有的實體特性

(4)添加詳細的描述信息

-實體的詳細屬性和關系的基數

簡單情況下ERD建穆示例

研討班在每個學年開始的時候開設，然后持續一個學年。

-每個研討班針對一個或幾個研究方向。

-每個研討班由一位或幾位教師主持。

-在研討班開設之后，學生可以根據主持教師(的姓名)和研討班的方向來選擇和參加某

個研討班。

-所有的學生必須且只能參加一個研討班的學習。

-研討班時常會開展活動，由教師來決定活動的時間、地點、主題和做報告的學生(的姓

名）。

每次活動時，由一位或多位同學圍繞活動主題做學習報告，交流自己對新技術的學習心

得。

-每個學生一次活動最多只能作一個報告，但每個學生至少會在一次活動中做一個報告。

-教師對每份活動中的學生報告進行一次點評和指導，提出意議和意見。

復雜情況下ERD建液

1.發現系統的概念域

-指那些在系統業務口非常重要的概念，如果沒有這