第三章軟件需求分析基礎(chǔ)

第三章軟件需求分析基礎(chǔ)第一頁，共一百一十頁，編輯于2023年，星期一主要內(nèi)容需求分析的概念和原則

傳統(tǒng)的軟件需求分析基礎(chǔ)

第二頁，共一百一十頁，編輯于2023年，星期一3.1需求分析的概念和原則

需求分析的基本任務(wù)是準(zhǔn)確地回答“系統(tǒng)必須做什么？”這一核心問題。

需求分析是發(fā)現(xiàn)、求精、建模和規(guī)約的過程。這一過程包括：詳細(xì)精化最初由系統(tǒng)分析員建立在軟件項(xiàng)目計(jì)劃中確定的軟件范圍，創(chuàng)建所需數(shù)據(jù)流、控制流以及操作行為的模型，在此基礎(chǔ)上選擇解決方案。

第三頁，共一百一十頁，編輯于2023年，星期一問題定義階段在需求分析之前，需要描述和定義問題。問題定義階段必須回答的關(guān)鍵問題是“要解決的問題是什么”。系統(tǒng)分析員扼要地寫出對問題的理解，提出關(guān)于問題性質(zhì)、工程目標(biāo)和規(guī)模的書面報(bào)告，最后得出使用戶和使用部門負(fù)責(zé)人都滿意的文檔。問題定義階段是軟件生存周期中最簡短的階段，一般只需要一天甚至更少的時(shí)間。

第四頁，共一百一十頁，編輯于2023年，星期一可行性研究階段

這個(gè)階段要回答的關(guān)鍵問題是“對于上一個(gè)階段所確定的問題有行得通的解決辦法嗎？”

系統(tǒng)分析員需要進(jìn)行一次大大壓縮和簡化了的系統(tǒng)分析和設(shè)計(jì)的過程。只有當(dāng)投資取得較大效益時(shí)，該工程項(xiàng)目才值得繼續(xù)進(jìn)行下去。系統(tǒng)分析員得出該工程項(xiàng)目不值得做的結(jié)論，應(yīng)該及時(shí)中止投資該工程項(xiàng)目，避免更大的浪費(fèi)。

第五頁，共一百一十頁，編輯于2023年，星期一可行性研究問題識別市場調(diào)查分析準(zhǔn)備環(huán)境分析物理分析功能分析信息分析動(dòng)態(tài)分析確立系統(tǒng)方案，作出各種估算模型評審第六頁，共一百一十頁，編輯于2023年，星期一問題的初步認(rèn)識了解系統(tǒng)應(yīng)解決的問題，這些問題是如何提出的設(shè)想這些問題如何解決才能滿足要求了解問題的結(jié)構(gòu)第七頁，共一百一十頁，編輯于2023年，星期一市場調(diào)查了解市場對待開發(fā)軟件的需求情況調(diào)查市場上已有的類似軟件系統(tǒng)的功能、性能、價(jià)格情況第八頁，共一百一十頁，編輯于2023年，星期一分析準(zhǔn)備確立分析計(jì)劃規(guī)定由誰參加分析作業(yè)，任務(wù)分配對參加分析的人員進(jìn)行必要的培訓(xùn)第九頁，共一百一十頁，編輯于2023年，星期一環(huán)境分析明確系統(tǒng)的目的和限制條件使用單位的狀況、經(jīng)營方針和組織機(jī)構(gòu)使用單位的計(jì)算機(jī)利用情況相關(guān)的硬件、軟件及其它接口部分用戶的操作環(huán)境及操作要求習(xí)慣、法律、制度上對軟件的制約開發(fā)能具備的技術(shù)條件和設(shè)備條件第十頁，共一百一十頁，編輯于2023年，星期一物理分析了解實(shí)際業(yè)務(wù)活動(dòng)狀況，特別對一些活動(dòng)要點(diǎn)進(jìn)行分析明確在這些要點(diǎn)之間什么東西在流動(dòng)，如何進(jìn)行流動(dòng)對物理流量進(jìn)行分析對其模型化，得到實(shí)際業(yè)務(wù)系統(tǒng)（當(dāng)前系統(tǒng)）的物理模型第十一頁，共一百一十頁，編輯于2023年，星期一功能分析決定系統(tǒng)應(yīng)具備的功能(工作域)分析功能的結(jié)構(gòu)：功能展開和功能分配分析各功能之間的關(guān)系，整理它們之間傳遞的信息利用數(shù)據(jù)流圖，描述信息在系統(tǒng)流動(dòng)與處理的情況第十二頁，共一百一十頁，編輯于2023年，星期一信息分析調(diào)查系統(tǒng)的輸入、輸出、保存信息明確信息的結(jié)構(gòu)及各信息之間的關(guān)系調(diào)查各信息的信息量調(diào)查各種報(bào)表和文件的格式建立粗略的數(shù)據(jù)詞典，定義系統(tǒng)中使用的數(shù)據(jù)第十三頁，共一百一十頁，編輯于2023年，星期一動(dòng)態(tài)分析系統(tǒng)內(nèi)每一部分有幾種狀態(tài)各種狀態(tài)轉(zhuǎn)換的條件同步產(chǎn)生的條件與同步后狀態(tài)的變化第十四頁，共一百一十頁，編輯于2023年，星期一確立系統(tǒng)方案，進(jìn)行各種估算粗略地估算成本估算可能取得的效益提出可能需要的資源，包括人員、硬件、軟件等提出大概的進(jìn)度安排第十五頁，共一百一十頁，編輯于2023年，星期一模型評審將目標(biāo)系統(tǒng)的邏輯模型提出管理部分與用戶進(jìn)行評審復(fù)查問題定義、工程規(guī)模和系統(tǒng)目標(biāo)第十六頁，共一百一十頁，編輯于2023年，星期一系統(tǒng)建模為了開發(fā)系統(tǒng)模型，可通過構(gòu)造模型進(jìn)一步分析系統(tǒng)?？梢杂孟到y(tǒng)流程圖，數(shù)據(jù)流圖和數(shù)據(jù)字典。第十七頁，共一百一十頁，編輯于2023年，星期一3.1.1需求分析

需求分析是一種軟件工程活動(dòng)，使得系統(tǒng)分析員能夠刻劃出軟件的功能和性能、指明軟件和其他系統(tǒng)元素的接口、并建立軟件必須滿足的約束。需求分析是軟件設(shè)計(jì)師進(jìn)行軟件分解的基礎(chǔ)，需求分析建造了軟件處理的數(shù)據(jù)模型、功能模型和行為模型。需求規(guī)約為軟件設(shè)計(jì)師和客戶提供了軟件建造完后，進(jìn)行質(zhì)量評估的依據(jù)。

第十八頁，共一百一十頁，編輯于2023年，星期一1.軟件需求的概念和分類

比較權(quán)威的需求的定義來自于IEEE軟件工程標(biāo)準(zhǔn)詞匯表中的定義：l

用戶解決問題或達(dá)到目標(biāo)所需要的條件。l

系統(tǒng)或系統(tǒng)部件要滿足合同、標(biāo)準(zhǔn)、規(guī)范或其他正式規(guī)定的文檔所要具有的條件。l

反映上面兩條的文檔說明。需求一方面反映了系統(tǒng)的外部行為，另一方面反映了系統(tǒng)的內(nèi)部特性，反映的方式是需求文檔。比較通俗的需求定義如下：需求是指明系統(tǒng)必須實(shí)現(xiàn)什么的規(guī)格說明，它描述了系統(tǒng)的行為、特性或?qū)傩?，是在開發(fā)過程中對系統(tǒng)的約束。

第十九頁，共一百一十頁，編輯于2023年，星期一需求的類別

功能需求：指定系統(tǒng)必須提供的服務(wù)，通過需求分析應(yīng)該劃分出系統(tǒng)必須完成的所有功能；性能需求：指定系統(tǒng)必須滿足的定時(shí)約束或容量約束，通常包括速度（響應(yīng)時(shí)間）、信息量速率、主存容量、磁盤容量、安全性等方面的需求；可靠性和可用性需求：定量地指定系統(tǒng)的可靠性與可用性；第二十頁，共一百一十頁，編輯于2023年，星期一出錯(cuò)處理需求：說明系統(tǒng)對環(huán)境錯(cuò)誤應(yīng)該怎樣響應(yīng)；接口需求：描述應(yīng)用系統(tǒng)與其環(huán)境通信的格式，常見的接口需求有用戶接口需求、硬件接口需求、軟件接口需求和通信接口需求；約束：描述了應(yīng)用系統(tǒng)應(yīng)遵守的限制條件，常見的約束有：精度約束、工具和語言約束、設(shè)計(jì)約束、應(yīng)該使用的標(biāo)準(zhǔn)、應(yīng)該使用的硬件平臺(tái)等；

第二十一頁，共一百一十頁，編輯于2023年，星期一逆向需求：說明軟件系統(tǒng)不應(yīng)該做什么。理論上有無限多個(gè)逆向需求，我們應(yīng)該僅選取能澄清真實(shí)需求且可消除發(fā)生誤解的那些逆向需求；將來可能提出的要求：應(yīng)該明確地列出那些雖然不屬于當(dāng)前系統(tǒng)開發(fā)范疇，但是據(jù)分析將來很可能會(huì)提出來的要求。第二十二頁，共一百一十頁，編輯于2023年，星期一另一種分類功能性需求產(chǎn)品的范圍功能與數(shù)據(jù)需求非功能性需求觀感需求易用性性能限制條件

操作需求可維護(hù)性和可移植性需求安全性需求文化與政策法律需求第二十三頁，共一百一十頁，編輯于2023年，星期一需求的質(zhì)量完整性正確性可行性必要性劃分優(yōu)先級無二義性可驗(yàn)證性設(shè)計(jì)無關(guān)性第二十四頁，共一百一十頁，編輯于2023年，星期一2.需求分析的任務(wù)

需求分析的任務(wù)是借助于當(dāng)前系統(tǒng)的物理模型導(dǎo)出目標(biāo)系統(tǒng)的邏輯模型，解決目標(biāo)系統(tǒng)“做什么”的問題。所要做的工作是深入描述軟件的功能和性能，確定軟件設(shè)計(jì)的限制和軟件同其他系統(tǒng)元素的接口細(xì)節(jié)，定義軟件的其他有效性需求。必須全面理解用戶的各項(xiàng)要求，但只能接受合理的要求。要將軟件的需求準(zhǔn)確地表達(dá)出來，形成軟件需求說明書。

第二十五頁，共一百一十頁，編輯于2023年，星期一目標(biāo)系統(tǒng)當(dāng)前系統(tǒng)物理模型邏輯模型模型化抽象化物理模型邏輯模型具體化實(shí)例化理解需求表達(dá)需求導(dǎo)出怎么做做什么第二十六頁，共一百一十頁，編輯于2023年，星期一需求分析的任務(wù)

獲得當(dāng)前系統(tǒng)的物理模型：首先，分析、理解當(dāng)前系統(tǒng)是如何運(yùn)行的，并用一個(gè)具體的模型來反映自己對當(dāng)前系統(tǒng)的理解。

抽象出當(dāng)前系統(tǒng)的邏輯模型：在理解當(dāng)前系統(tǒng)“怎樣做”的基礎(chǔ)上，取出非本質(zhì)因素，抽取出“做什么”的本質(zhì)。

第二十七頁，共一百一十頁，編輯于2023年，星期一

建立目標(biāo)系統(tǒng)的邏輯模型：分析目標(biāo)系統(tǒng)與當(dāng)前系統(tǒng)邏輯上的差別，明確目標(biāo)系統(tǒng)要“做什么”，從而從當(dāng)前系統(tǒng)的邏輯模型中，導(dǎo)出目標(biāo)系統(tǒng)的邏輯模型。

對目標(biāo)系統(tǒng)邏輯模型進(jìn)行補(bǔ)充：具體內(nèi)容如用戶界面、啟動(dòng)和結(jié)束、出錯(cuò)處理、系統(tǒng)輸入輸出、系統(tǒng)性能、其他限制等等。

第二十八頁，共一百一十頁，編輯于2023年，星期一3．需求分析的主要工作

軟件需求分析可被劃分成5個(gè)工作階段：問題分析；問題評估和方案綜合；建模；規(guī)約；復(fù)審。

例1.

汽車零件的主要供應(yīng)商需要一個(gè)庫存控制系統(tǒng)，系統(tǒng)分析員發(fā)現(xiàn)與當(dāng)前的手工系統(tǒng)相關(guān)的問題包括：（1）不能快速地獲得部件的狀況；（2）更新卡片文件需要2至或3天的工作量；（3）由于沒有辦法查找相關(guān)廠商的部件信息，而使得對同一廠商同一貨品多次再訂貨，等等。一旦問題被標(biāo)識出來，系統(tǒng)分析員將確定新系統(tǒng)該產(chǎn)生什么信息，以及將提供什么信息。

第二十九頁，共一百一十頁，編輯于2023年，星期一例2.

客戶希望得到指明什么零件從庫存中取出、以及還剩余多少相似零件的日報(bào)表?？蛻糁该饕坏┊?dāng)該零件離開倉庫時(shí)庫存管理員就該記載每個(gè)零件的標(biāo)號。通過對當(dāng)前問題和希望的信息（輸入和輸出）進(jìn)行的評估，系統(tǒng)分析員開始綜合一個(gè)或多個(gè)解決方案。為了便于開始，必須詳細(xì)地定義系統(tǒng)的數(shù)據(jù)、處理功能和行為。

第三十頁，共一百一十頁，編輯于2023年，星期一例3.

在例1與例2的基礎(chǔ)上，一些可以進(jìn)一步思考內(nèi)容是，一旦已經(jīng)建立這些信息，就該考慮針對實(shí)現(xiàn)的基本體系結(jié)構(gòu)，那么客戶/服務(wù)器方法似乎是合適的，但是它確實(shí)屬于軟件計(jì)劃的范圍嗎？似乎需要一個(gè)數(shù)據(jù)庫管理系統(tǒng)，但是，該數(shù)據(jù)庫系統(tǒng)真的是用戶需要的嗎？繼續(xù)這種評估和綜合的過程，直至分析員和客戶均確信針對后面的開發(fā)步驟軟件確實(shí)已被適當(dāng)?shù)乜虅澚恕?/p>

第三十一頁，共一百一十頁，編輯于2023年，星期一在整個(gè)評估和綜合過程中，分析員的主要焦點(diǎn)是“做什么”，而不是“怎么做”，即應(yīng)該思考的是：系統(tǒng)會(huì)產(chǎn)生和使用什么數(shù)據(jù)？系統(tǒng)必須完成什么功能？將定義什么界面？會(huì)應(yīng)用什么約束？在問題評估和綜合解決方案的活動(dòng)中，系統(tǒng)分析員創(chuàng)建系統(tǒng)模型，以便可以更好地理解數(shù)據(jù)流和控制流、處理功能和操作行為以及信息內(nèi)容。

第三十二頁，共一百一十頁，編輯于2023年，星期一4.系統(tǒng)分析員的主要能力

在整個(gè)系統(tǒng)分析活動(dòng)中，系統(tǒng)分析員起著關(guān)鍵的作用，其本人應(yīng)該具備突出的能力，如：能掌握抽象概念，能對其進(jìn)行分類，能從中綜合出解的能力；能從沖突或者混淆中吸取恰當(dāng)事實(shí)的能力；能弄清用戶環(huán)境的能力；能為用戶系統(tǒng)恰當(dāng)配置軟硬件的能力能較好地用書面和口頭形式進(jìn)行溝通的能力有“從樹木見森林”的能力。

第三十三頁，共一百一十頁，編輯于2023年，星期一3.1.2需求獲取

軟件需求分析中需要很好的的相互溝通，溝通總是要在兩方或多方間進(jìn)行。

客戶和系統(tǒng)分析員之間最常用的交流方式，是通過預(yù)備會(huì)議或訪談進(jìn)行的。獲取用戶需求的主要方法是調(diào)查研究。做好準(zhǔn)備制定調(diào)研計(jì)劃準(zhǔn)備調(diào)研資料訪談?dòng)脩魧懻{(diào)研報(bào)告評審第三十四頁，共一百一十頁，編輯于2023年，星期一系統(tǒng)分析員所問的第一組問題可以關(guān)注客戶、整體目標(biāo)和收益，例如：誰是本工作的最初請求者？誰將使用該解決方案？成功的解決方案的經(jīng)濟(jì)收益是什么？接下來的下一組問題使得系統(tǒng)分析員能夠?qū)栴}做更好的理解，使得客戶能夠表達(dá)其關(guān)于解決方案的感覺，最后一組問題關(guān)注于會(huì)議的效果。例如：你是回答這些問題的合適人員嗎？你的回答是“正式的”嗎？其他人員可以提供附加信息嗎？有其他我應(yīng)該問你的問題嗎？

第三十五頁，共一百一十頁，編輯于2023年，星期一3.1.3分析原則

在過去20年，研究者已經(jīng)開發(fā)出一些實(shí)用分析方法及相應(yīng)的建模符號，每種分析方法有獨(dú)特的觀點(diǎn)，然而，所有分析方法都遵循以下操作原則：必須表示可理解的問題信息域。必須定義軟件將完成的功能。必須表示軟件的行為（作為外部事件的結(jié)果）。必須劃分描述信息、功能和行為的模型，從而能以層次的方式揭示細(xì)節(jié)。分析過程應(yīng)該從要素信息移向細(xì)節(jié)實(shí)現(xiàn)。

第三十六頁，共一百一十頁，編輯于2023年，星期一除了上面提到的操作性分析原則，Davis提出了一組針對需求工程的指導(dǎo)性原則：

在開始建立分析模型前，先充分理解問題。開發(fā)原型，使得用戶能夠了解如何進(jìn)行人機(jī)交互。記錄每個(gè)需求的起源及原因。使用多個(gè)需求視圖。建立數(shù)據(jù)、功能和行為模型，為軟件工程師提供三種不同的視圖。給需求賦予優(yōu)先級。努力刪除歧義性。第三十七頁，共一百一十頁，編輯于2023年，星期一1.信息域

所有的應(yīng)用軟件均可稱為數(shù)據(jù)處理系統(tǒng)。信息流表示了數(shù)據(jù)和控制在系統(tǒng)中流動(dòng)時(shí)的變化方式，輸入對象被變換為中間信息（數(shù)據(jù)和/或控制），這些信息被進(jìn)一步變換為輸出數(shù)據(jù)的變換是程序必須完成的功能或子功能，在兩個(gè)變換（功能）間流動(dòng)的數(shù)據(jù)和控制定義了每個(gè)功能的接口。信息結(jié)構(gòu)表示了各種數(shù)據(jù)和控制項(xiàng)的內(nèi)部組織，

第三十八頁，共一百一十頁，編輯于2023年，星期一2.建模

我們創(chuàng)建模型，以獲得對將要建造的實(shí)際實(shí)體有更好的理解。要對軟件變換的信息進(jìn)行建模、對變換發(fā)生的功能（和子功能）進(jìn)行建模、以及對變換發(fā)生時(shí)的系統(tǒng)行為進(jìn)行建模。在軟件需求分析階段，我們創(chuàng)建系統(tǒng)模型，這些模型著重于描述系統(tǒng)必須做什么而不是如何去做。我們常使用圖形符號創(chuàng)建模型。

第三十九頁，共一百一十頁，編輯于2023年，星期一功能模型：記錄軟件的變換信息，為了達(dá)到此目標(biāo)必須至少完成三個(gè)常見功能：輸入、處理和輸出。行為模型：大多數(shù)軟件對來自外界的事件做出反應(yīng)，這種刺激-反應(yīng)特征構(gòu)成了行為模型的基礎(chǔ)。行為模型創(chuàng)建了軟件狀態(tài)的表示，以及導(dǎo)致軟件狀態(tài)變化的事件表示。

第四十頁，共一百一十頁，編輯于2023年，星期一需求分析階段創(chuàng)建模型的作用模型幫助分析員理解系統(tǒng)的信息、功能和行為，因此，使得需求分析任務(wù)更容易實(shí)現(xiàn)。

模型變成了復(fù)審的焦點(diǎn)，因此，也成為確定規(guī)約的完整性、一致性和精確性的重要依據(jù)。模型變成了設(shè)計(jì)的基礎(chǔ)，為設(shè)計(jì)者提供了軟件要素的表示視圖，該表示可被轉(zhuǎn)化到實(shí)現(xiàn)中去。

第四十一頁，共一百一十頁，編輯于2023年，星期一3.劃分

實(shí)際的問題經(jīng)常太大而且復(fù)雜難于進(jìn)行整體理解，我們往往將這樣的問題劃分為易于理解的子問題，并建立各子問題間的接口，以便完成整個(gè)功能。第四條操作性分析原則建議劃分軟件的信息、功能和行為域。第四十二頁，共一百一十頁，編輯于2023年，星期一需求分析階段的文檔軟件需求說明書初步的用戶手冊修改、完善與確定軟件開發(fā)實(shí)施計(jì)劃第四十三頁，共一百一十頁，編輯于2023年，星期一3.1.4需求規(guī)格說明

軟件需求規(guī)格說明是分析任務(wù)的最終產(chǎn)物，美國國家標(biāo)準(zhǔn)局、IEEE（標(biāo)準(zhǔn)號830－1984）以及美國防部門均已提出了軟件需求規(guī)約（以及其他軟件工程文檔）的候選格式。

軟件需求規(guī)格說明必須正確地定義所有的軟件需求；除了設(shè)計(jì)上的特殊限制之外，軟件需求規(guī)格說明中一般不描述任何設(shè)計(jì)、驗(yàn)證或項(xiàng)目管理的細(xì)節(jié)。

第四十四頁，共一百一十頁，編輯于2023年，星期一需求必須描述的基本問題功能——所設(shè)計(jì)的軟件要做什么；

性能——軟件功能在執(zhí)行過程中的速度、可使用性、響應(yīng)時(shí)間、各種軟件功能的恢復(fù)時(shí)間、吞吐能力、精度、頻率等等；

強(qiáng)加給實(shí)現(xiàn)的設(shè)計(jì)限制——在效果、實(shí)現(xiàn)的語言、數(shù)據(jù)庫完整性、資源限制、操作環(huán)境等等方面所要求的標(biāo)準(zhǔn)；

屬性——可移植性、正確性、可維護(hù)性及安全性等方面的考慮因素；

外部接口——與人、硬件、其他軟件和其他硬件的相互關(guān)系。

第四十五頁，共一百一十頁，編輯于2023年，星期一軟件需求規(guī)格說明的大綱

1前言

1.1目的

1.2范圍

1.3定義、縮寫詞、略語

1.4參考資料2項(xiàng)目概述

2.1產(chǎn)品描述

2.2產(chǎn)品功能2.3用戶特點(diǎn)

2.4一般約束2.5假設(shè)和依據(jù)

3具體需求

3.1功能需求

3.1.1功能需求13.1.1.1引言3.1.1.2輸入3.1.1.3加工3.1.1.4輸出

3.1.2功能需求2……

3.1.n功能需求n

第四十六頁，共一百一十頁，編輯于2023年，星期一3.2外部接口需求

3.2.1用戶接口

3.2.2硬件接口3.2.3軟件接口3.2.4通信接口3.3性能需求

3.4設(shè)計(jì)約束

3.4.1其他標(biāo)準(zhǔn)的約束

3.4.2硬件的限制

…………

3.5屬性3.5.1安全性3.5.2可維護(hù)性

…………

3.6其他需求

3.6.1數(shù)據(jù)庫

3.6.2操作

3.6.3場合適應(yīng)性

…………

附錄索引

第四十七頁，共一百一十頁，編輯于2023年，星期一3.1.5評審

需求審查是需求分析階段工作的最后一步，是由軟件軟件工程師和客戶一起進(jìn)行并完成的。目的是發(fā)現(xiàn)軟件需求規(guī)格說明中的錯(cuò)誤、二義性和遺漏的需求。復(fù)審首先在宏觀的級別上進(jìn)行，復(fù)審者試圖保證軟件需求規(guī)格說明是完整的、一致的、精確的。例如提出以下問題：敘述的軟件目標(biāo)與系統(tǒng)的目標(biāo)是否保持一致？圖是否清楚？每個(gè)圖可以沒有文字補(bǔ)充而單獨(dú)存在嗎？是否考慮過開發(fā)的技術(shù)風(fēng)險(xiǎn)？是否存在不一致性、是否信息被忽略或存在冗余？和客戶全面接觸過嗎？

第四十八頁，共一百一十頁，編輯于2023年，星期一然后復(fù)審會(huì)更詳細(xì)，關(guān)注軟件需求規(guī)格說明中的措詞。例如：著重于說服性的連接詞（例如，當(dāng)然、因此、明確地、顯然地、緊隨的），并問“為什么”。

觀察含糊的術(shù)語（例如，一些、有時(shí)、經(jīng)常、通常、一般地、大多數(shù)、大多數(shù)的），并進(jìn)行澄清。

當(dāng)給出了不完整的列表時(shí)，確定已理解了所有的項(xiàng)。關(guān)鍵是查找“等等、如此這樣”。

小心含糊的動(dòng)詞如“處理、拒絕、處制、跳過、限制”等，它們可以以很多方式來解釋。小心含糊的代詞（例如，I/O模塊與數(shù)據(jù)校驗(yàn)?zāi)K通信，且設(shè)置它的控制標(biāo)志，那么標(biāo)志是誰的？）等等。

第四十九頁，共一百一十頁，編輯于2023年，星期一3.2傳統(tǒng)的軟件需求分析基礎(chǔ)

結(jié)構(gòu)化的分析方法是最經(jīng)典的需求分析方法。適用于數(shù)據(jù)處理類型軟件的需求分析。它提供的工具包括：數(shù)據(jù)流圖、數(shù)據(jù)字典、結(jié)構(gòu)化英語、判定表和判定樹。

系統(tǒng)的分析模型必須達(dá)到三個(gè)主要目標(biāo)：（1）描述客戶的需要；（2）建立創(chuàng)建軟件設(shè)計(jì)的基礎(chǔ)；（3）定義在軟件完成后可以被確認(rèn)的一組需求。第五十頁，共一百一十頁，編輯于2023年，星期一實(shí)體—關(guān)系圖狀態(tài)—遷移圖數(shù)據(jù)流圖數(shù)據(jù)對象描述加工規(guī)格說明數(shù)據(jù)字典控制規(guī)格說明第五十一頁，共一百一十頁，編輯于2023年，星期一模型的核心是數(shù)據(jù)字典——一個(gè)包含了軟件使用或生產(chǎn)的所有數(shù)據(jù)對象描述的中心庫。實(shí)體-關(guān)系圖描述數(shù)據(jù)對象間的關(guān)系，實(shí)體-關(guān)系圖是用來進(jìn)行數(shù)據(jù)建?；顒?dòng)的。數(shù)據(jù)流圖有兩個(gè)目的：指明數(shù)據(jù)在系統(tǒng)中移動(dòng)時(shí)如何被變換；描述對數(shù)據(jù)流進(jìn)行變換的功能（和子功能）。它可以用于信息域的分析，作為功能建模的基礎(chǔ)。狀態(tài)轉(zhuǎn)換圖指明系統(tǒng)將如何動(dòng)作。為此，狀態(tài)轉(zhuǎn)換圖表示了系統(tǒng)的各種行為模式（稱為“狀態(tài)”），以及在狀態(tài)間進(jìn)行變遷的方式，狀態(tài)轉(zhuǎn)換圖是行為建模的基礎(chǔ)。第五十二頁，共一百一十頁，編輯于2023年，星期一3.2.1數(shù)據(jù)流圖

任何軟件系統(tǒng)（或計(jì)算機(jī)系統(tǒng)）從根本上來說，都是對數(shù)據(jù)進(jìn)行加工或變換的工具。

第五十三頁，共一百一十頁，編輯于2023年，星期一1.組成符號

第五十四頁，共一百一十頁，編輯于2023年，星期一例4.下面以教材購銷系統(tǒng)中的教材銷售為例，說明如何畫數(shù)據(jù)流圖。從用戶調(diào)查中了解到某高校向?qū)W生銷售教材的手續(xù)是：先由系辦公室的張秘書開購書證明，學(xué)生憑證明找教材科的王會(huì)計(jì)開購書發(fā)票，向李出納員交付書款，然后到書庫找趙保管員領(lǐng)書?，F(xiàn)欲將上述手工操作改為計(jì)算機(jī)處理，試畫出教材銷售過程的數(shù)據(jù)流圖。

第五十五頁，共一百一十頁，編輯于2023年，星期一首先找出數(shù)據(jù)的源點(diǎn)和終點(diǎn)，即找出數(shù)據(jù)源與數(shù)據(jù)匯，由此確定系統(tǒng)的邊界。由于是由學(xué)生開始購書，最后由學(xué)生領(lǐng)書，因此數(shù)據(jù)的源點(diǎn)和終點(diǎn)都是“學(xué)生”。第二步找出加工，需要從描述中抽象出系統(tǒng)要完成的工作。學(xué)生須憑購書證明得到購書發(fā)票，然后交付書款，得到領(lǐng)書憑證，最后領(lǐng)書。其間能由計(jì)算機(jī)完成的工作是審查學(xué)生的購書憑證并開出發(fā)票，按發(fā)票開出領(lǐng)書單，由此我們得到2個(gè)加工（審查并開發(fā)票，并領(lǐng)書單）。第五十六頁，共一百一十頁，編輯于2023年，星期一第三步要找出數(shù)據(jù)流。

學(xué)生向系統(tǒng)提交購書單，學(xué)生從系統(tǒng)得到領(lǐng)書單，在加工之間要傳輸發(fā)票信息，這樣我們得到3個(gè)數(shù)據(jù)流。同時(shí)還要注意在“審查并開發(fā)票”加工中排除了無效的書單，它也因作為一個(gè)數(shù)據(jù)流，因此最后得到4個(gè)數(shù)據(jù)流：購書單，發(fā)票，領(lǐng)書單，無效書單。

第五十七頁，共一百一十頁，編輯于2023年，星期一第五十八頁，共一百一十頁，編輯于2023年，星期一我們還要補(bǔ)充數(shù)據(jù)存儲(chǔ)。數(shù)據(jù)存儲(chǔ)一般不能通過系統(tǒng)描述確定，而要在設(shè)計(jì)數(shù)據(jù)流圖時(shí)按照需要添加。

實(shí)際上在審查購書單和開出發(fā)票之前，至少要查閱兩個(gè)文件：①各班學(xué)生用書表，該表用以核對學(xué)生是否需用這些教材；②教材存量表，了解有沒有該生要買的教材。

把這兩個(gè)文件加進(jìn)上圖中，并給加工添上編號，就得到計(jì)算機(jī)售書系統(tǒng)的完整的數(shù)據(jù)流圖。第五十九頁，共一百一十頁，編輯于2023年，星期一第六十頁，共一百一十頁，編輯于2023年，星期一例子在學(xué)生管理系統(tǒng)的一部分功能中，學(xué)術(shù)部安排好課程，學(xué)生通過系統(tǒng)注冊想上的課程，得到課表，系統(tǒng)根據(jù)課程注冊情況產(chǎn)生班級列表給相應(yīng)教師。第六十一頁，共一百一十頁，編輯于2023年，星期一第六十二頁，共一百一十頁，編輯于2023年，星期一2.命名

數(shù)據(jù)流圖中每個(gè)成分的命名是否恰當(dāng)，直接影響數(shù)據(jù)流圖的可理解性。給這些成分起名字時(shí)應(yīng)該仔細(xì)推敲。下面講述在命名時(shí)應(yīng)注意的問題：

為數(shù)據(jù)流（或數(shù)據(jù)存儲(chǔ)）命名

名字應(yīng)代表整個(gè)數(shù)據(jù)流（或數(shù)據(jù)存儲(chǔ)）的內(nèi)容，而不是僅僅反映它的某些成分?？忌彰诸惡蟮男彰浫》诸惖诹?，共一百一十頁，編輯于2023年，星期一注意合適的命名，盡量用現(xiàn)實(shí)存在的表格、單據(jù)。不要使用空洞的、缺乏具體含義的名字（如“數(shù)據(jù)”、“信息”、“輸入”之類）。不要把控制流作為數(shù)據(jù)流。匯款單格式錯(cuò)誤合格的匯款單核準(zhǔn)的匯款單格式檢查計(jì)算匯費(fèi)取下一個(gè)考生成績錄取分類第六十四頁，共一百一十頁，編輯于2023年，星期一為處理命名通常先為數(shù)據(jù)流命名，再為與之相關(guān)聯(lián)的處理命名

名字應(yīng)該反映整個(gè)處理的功能，而不是它的一部分功能。名字最好有一個(gè)具體的及物動(dòng)詞加上一個(gè)具體的賓語組成。應(yīng)該盡量避免使用“加工”、“處理”等空洞籠統(tǒng)的動(dòng)詞作名字。通常名字中僅包括一個(gè)動(dòng)詞，如果必須用兩個(gè)動(dòng)詞才能描述整個(gè)處理的功能，則把這個(gè)處理再分解成兩個(gè)處理可能跟恰當(dāng)些。如果在為某個(gè)處理命名時(shí)遇到了困難，則很可能是分解不恰當(dāng)造成的，應(yīng)該考慮重新分解。

第六十五頁，共一百一十頁，編輯于2023年，星期一數(shù)據(jù)的源點(diǎn)和終點(diǎn)并不需要在系統(tǒng)中實(shí)現(xiàn)，它們只是系統(tǒng)的外圍環(huán)境（可能是人員、計(jì)算機(jī)外部設(shè)備或傳感器等）。通常為數(shù)據(jù)的源點(diǎn)和終點(diǎn)命名是采用它們在問題中習(xí)慣使用的名字，如“學(xué)生”，“管理員”。

第六十六頁，共一百一十頁，編輯于2023年，星期一3.分層數(shù)據(jù)流圖

第六十七頁，共一百一十頁，編輯于2023年，星期一對于大型的系統(tǒng)，按照其層次結(jié)構(gòu)進(jìn)行逐步分解，并以分層的數(shù)據(jù)流圖反映這種結(jié)構(gòu)關(guān)系，能清楚地表達(dá)和容易理解整個(gè)系統(tǒng)。

對任何一層數(shù)據(jù)流圖來說，我們稱它的上層圖為父圖，在它下一層的圖則稱為子圖。

在多層數(shù)據(jù)流圖中，頂層流圖僅包含一個(gè)加工，它代表將被開發(fā)系統(tǒng)。它的輸入流是該系統(tǒng)的輸入數(shù)據(jù)，輸出流是系統(tǒng)所輸出數(shù)據(jù)。底層流圖是指其加工不需再做分解的數(shù)據(jù)流圖，它處在最底層。中間層流圖則表示對其上層父圖的細(xì)化。它的每一加工可能繼續(xù)細(xì)化，形成子圖。

第六十八頁，共一百一十頁，編輯于2023年，星期一4．?dāng)?shù)據(jù)流圖實(shí)例

建立數(shù)據(jù)流模型的基本步驟概括地說，就是自外向內(nèi)、自頂向下、逐層細(xì)化、完善求精。

例5.

建立一個(gè)簡化的商業(yè)自動(dòng)化系統(tǒng)。其中：售貨員負(fù)責(zé)錄入銷售的商品（商品名，編號，單價(jià)，數(shù)量），有時(shí)要根據(jù)特定情況對銷售的商品進(jìn)行修改或刪除。收款員負(fù)責(zé)收取現(xiàn)金，并將多交的付款退還用戶。銷售經(jīng)理需要隨時(shí)查詢整個(gè)部門的銷售情況（時(shí)間，商品編號，銷售金額），并在每日結(jié)束時(shí)，統(tǒng)計(jì)各類商品的銷售金額。

第六十九頁，共一百一十頁，編輯于2023年，星期一首先：建立系統(tǒng)環(huán)境，確定系統(tǒng)邊界，畫出頂層DFD。

其中：1數(shù)據(jù)流為：銷售的商品，日銷售額等

2數(shù)據(jù)源點(diǎn)為：營業(yè)員，經(jīng)理，收款員

3數(shù)據(jù)終點(diǎn)為：經(jīng)理，收款員

4加工名為：要建立的系統(tǒng)名字第七十頁，共一百一十頁，編輯于2023年，星期一然后自頂向下，逐層分解。

A、按人或部門的功能要求，將加工“打碎”，形成：錄入、修改或刪除商品信息錄入、修改現(xiàn)金額,并計(jì)算余額查詢商品銷售情況計(jì)算日銷售額123注：需給每一加工編號第七十一頁，共一百一十頁，編輯于2023年，星期一B、”分派”數(shù)據(jù)流，形成：錄入、修改或刪除商品信息

2錄入、修改現(xiàn)金額,并計(jì)算余額查詢商品銷售情況計(jì)算日銷售額銷售的商品現(xiàn)金額現(xiàn)金余額查詢要求銷售情況日銷售額13其中：要根據(jù)特定的加工要求進(jìn)行分派；保持與頂層數(shù)據(jù)流的一致；可以不引入數(shù)據(jù)源和數(shù)據(jù)終點(diǎn)。第七十二頁，共一百一十頁，編輯于2023年，星期一C、引入文件，使之形成一個(gè)有機(jī)整體—系統(tǒng)錄入、修改或刪除商品信息錄入、修改現(xiàn)金額,并計(jì)算余額查詢商品銷售情況計(jì)算日銷售額銷售的商品現(xiàn)金額現(xiàn)金余額查詢要求銷售情況日銷售額銷售文件123注：到一個(gè)文件，既有輸入流，又有輸出流，則可簡化為，并可不給出標(biāo)識。至此，體現(xiàn)精化，形成0層數(shù)據(jù)流圖。

第七十三頁，共一百一十頁，編輯于2023年，星期一繼續(xù)A、B、C：自頂向下，逐層分解。例如：加工3查詢商品銷售情況計(jì)算日銷售額查詢要求銷售情況日銷售額銷售文件3可分解為：3.1判定要求查詢要求

3.2統(tǒng)計(jì)銷售情況

3.3計(jì)算日銷售額銷售文件查詢要求2查詢要求1銷售情況日銷售額第七十四頁，共一百一十頁，編輯于2023年，星期一5.注意事項(xiàng)

畫數(shù)據(jù)流圖不是畫流程圖。數(shù)據(jù)流圖只描述“做什么”，不描述“怎么做”和做的順序，而流程圖表述對數(shù)據(jù)進(jìn)行加工的次序和細(xì)節(jié)。

父圖和子圖的平衡。正常情況下，父圖和子圖的輸入數(shù)據(jù)和輸出數(shù)據(jù)應(yīng)分別保持一致，稱為父子平衡。

局部文件。隨著數(shù)據(jù)流圖的分解，在下層數(shù)據(jù)流圖中允許出現(xiàn)父圖中沒有的文件。

要遵守加工編號規(guī)則。頂層加工不編號；第0層的加工編為1，2，…，n號；第1層編為1.1，1.2，…，1.n等號，依此類推。

第七十五頁，共一百一十頁，編輯于2023年，星期一分解的深度與層次。逐層分解時(shí)，要求加工分解到足夠簡單，易于理解為止，這一加工也就是我們常說的基本加工。

分解的層次多少是合適的，這應(yīng)當(dāng)根據(jù)問題的復(fù)雜程度來確定?？梢詤⒖家韵乱恍┙?jīng)驗(yàn)性的原則。

一個(gè)加工的分解，最多不要超出7個(gè)子加工。分解在邏輯上應(yīng)合理、自然，不能硬性分割。

在保證數(shù)據(jù)流得以理解的前提下，盡量少分解層次。分解要均勻。即在一張數(shù)據(jù)流圖中，盡量少出現(xiàn)有些加工已是基本加工，有些還要分解好幾層的情況。

第七十六頁，共一百一十頁，編輯于2023年，星期一3.2.2數(shù)據(jù)字典

數(shù)據(jù)字典的作用，就是描述軟件中的每個(gè)數(shù)據(jù)和加工的具體含義，以保持?jǐn)?shù)據(jù)在系統(tǒng)中的一致性。

有了數(shù)據(jù)流圖和數(shù)據(jù)字典才算是較完整地描述了一個(gè)系統(tǒng)。數(shù)據(jù)流圖和數(shù)據(jù)字典是需求規(guī)格說明書的主要組成部分。

數(shù)據(jù)字典要對數(shù)據(jù)流圖中出現(xiàn)的所有名字（數(shù)據(jù)流、加工、數(shù)據(jù)存儲(chǔ)）進(jìn)行定義。

第七十七頁，共一百一十頁，編輯于2023年，星期一在數(shù)據(jù)字典中，描述數(shù)據(jù)元素之間的關(guān)系時(shí)，可以使用自然語言也可采用以下符號：

=等價(jià)于（或定義為）

+與

[|]或（從方括號內(nèi)由“|”號隔開的分量中選擇一個(gè)）

{}重復(fù)（）選擇

常常使用上限和下限符號，以進(jìn)一步注釋表示重復(fù)的括號。例如：和1{A}5都表示A重復(fù)5次。

第七十八頁，共一百一十頁，編輯于2023年，星期一數(shù)據(jù)流條目學(xué)生=學(xué)號+姓名+性別+系+年級+選修課程選修課程=課程號+課名+學(xué)時(shí)+學(xué)分+課表課表={星期幾+第幾節(jié)+教室}年級=[1|2|3|4]=[1..4]第七十九頁，共一百一十頁，編輯于2023年，星期一文件條目列出數(shù)據(jù)存儲(chǔ)的組成數(shù)據(jù)項(xiàng)及文件的組織方式航班目錄文件={航班號+起點(diǎn)+終點(diǎn)+時(shí)間}組織：按航班號次序排列第八十頁，共一百一十頁，編輯于2023年，星期一加工條目只列出基本加工的小說明描述加工邏輯，也包括與加工有關(guān)的其他信息用結(jié)構(gòu)化自然語言描述第八十一頁，共一百一十頁，編輯于2023年，星期一1、數(shù)據(jù)流:銷售的商品=商品名+商品編號+單價(jià)+數(shù)量+日期現(xiàn)金額=余額=非負(fù)實(shí)數(shù)查詢要求=[商品編號|日期]查詢要求1=商品編號查詢要求2=日期銷售情況=商品名+商品編號+金額日銷售額={類名+現(xiàn)金額}2、數(shù)據(jù)存貯:銷售文件={銷售的商品}第八十二頁，共一百一十頁，編輯于2023年，星期一3、數(shù)據(jù)項(xiàng)給出加工小說明可以使用判定表、判定樹判斷表Ⅰ條件類別Ⅱ條件組合

Ⅲ操作Ⅳ操作執(zhí)行例如：考試總分>=620>=620<620

單科成績有滿分有不及格有滿分發(fā)升級通知書yyn

發(fā)留級通知書nny

發(fā)重修通知書nyn第八十三頁，共一百一十頁，編輯于2023年，星期一某公司承擔(dān)空中和地面運(yùn)輸業(yè)務(wù)。計(jì)算貨物托運(yùn)費(fèi)的比率規(guī)定如下：

空運(yùn):如果貨物重量小于等于2kg．則一律收費(fèi)6元；如果貨物重量大于2kg而又小于等于20kg，則收費(fèi)3元/kg；如果貨物重量大于20kg，則收費(fèi)4元/kg。

地運(yùn):若為慢件每kg收費(fèi)為1元，若為快件，當(dāng)重量小于等于20kg時(shí)，收費(fèi)為2元/kg，當(dāng)貨物重量大于20kg時(shí)，則收費(fèi)為3元/kg。

第八十四頁，共一百一十頁，編輯于2023年，星期一方式空運(yùn)空運(yùn)空運(yùn)地運(yùn)地運(yùn)地運(yùn)貨物重量≤20Kg>2Kg、≤20Kg>20Kg慢件重量≤20Kg>20Kg收費(fèi)6元3元/Kg4元/Kg1元/Kg2元/Kg3元/Kg第八十五頁，共一百一十頁，編輯于2023年，星期一3.2.3實(shí)體－關(guān)系圖（E-R圖）

實(shí)體－關(guān)系圖中包含3種相互關(guān)聯(lián)的信息：數(shù)據(jù)對象、數(shù)據(jù)對象的屬性及數(shù)據(jù)對象彼此間相互連接的關(guān)系。

是一種面向問題的數(shù)據(jù)模型，是按照用戶的觀點(diǎn)對數(shù)據(jù)建立的模型。它描述了從用戶角度看到的數(shù)據(jù)，它反映了用戶的現(xiàn)實(shí)環(huán)境，而且與軟件系統(tǒng)中的實(shí)現(xiàn)方法無關(guān)。

第八十六頁，共一百一十頁，編輯于2023年，星期一1.數(shù)據(jù)對象、屬性與關(guān)系

數(shù)據(jù)對象是軟件必須理解的復(fù)合信息的抽象。

數(shù)據(jù)對象彼此間是有關(guān)聯(lián)的。屬性定義了數(shù)據(jù)對象的特征。它可用來：①

為數(shù)據(jù)對象的實(shí)例命名；②

描述這個(gè)實(shí)例；③

建立對另一個(gè)數(shù)據(jù)對象的另一個(gè)實(shí)例的引用。數(shù)據(jù)對象彼此之間相互連接的方式稱為聯(lián)系，也稱為關(guān)系。

第八十七頁，共一百一十頁，編輯于2023年，星期一聯(lián)系可分為以下3種類型

一對一聯(lián)系（1∶1）

一個(gè)部門有一個(gè)經(jīng)理，而每個(gè)經(jīng)理只在一個(gè)部門任職，則部門與經(jīng)理的聯(lián)系是一對一的。

一對多聯(lián)系（1∶N）

每位教師可以教多門課程，但是每門課程只能由一位教師來教，則某校教師與課程之間存在一對多的聯(lián)系。

多對多聯(lián)系（M∶N）一個(gè)學(xué)生可以學(xué)多門課程，而每門課程可以有多個(gè)學(xué)生來學(xué)，則學(xué)生與課程間的聯(lián)系是多對多的。

第八十八頁，共一百一十頁，編輯于2023年，星期一2.實(shí)體－關(guān)系圖實(shí)例

第八十九頁，共一百一十頁，編輯于2023年，星期一例12.

在教學(xué)管理中，一個(gè)教師可以教授零門、一門或多門課程，每位學(xué)生也需要學(xué)習(xí)幾門課程。用E-R圖描述。

第九十頁，共一百一十頁，編輯于2023年，星期一3.2.4狀態(tài)轉(zhuǎn)換圖

狀態(tài)轉(zhuǎn)換圖（簡稱為狀態(tài)圖）通過描繪系統(tǒng)的狀態(tài)及引起系統(tǒng)狀態(tài)轉(zhuǎn)換的事件，來表示系統(tǒng)的行為。此外，狀態(tài)圖還指明了作為特定事件的結(jié)果，系統(tǒng)將做哪些動(dòng)作（例如，處理數(shù)據(jù)）。

第九十一頁，共一百一十頁，編輯于2023年，星期一1.組成部分及其符號表示

第九十二頁，共一百一十頁，編輯于2023年，星期一狀態(tài)是任何可以被觀察到的系統(tǒng)行為模式，一個(gè)狀態(tài)代表系統(tǒng)的一種行為模式。狀態(tài)規(guī)定了系統(tǒng)對事件的響應(yīng)方式。

在狀態(tài)圖中定義的狀態(tài)主要有：初態(tài)（即初始狀態(tài)）、終態(tài)（即最終狀態(tài)）和中間狀態(tài)。在一張狀態(tài)圖中只能有一個(gè)初態(tài)，而終態(tài)則可以有0至多個(gè)。

狀態(tài)圖既可以表示系統(tǒng)循環(huán)運(yùn)行過程，也可以表示系統(tǒng)單程生命期。

事件是在某個(gè)特定時(shí)刻發(fā)生的事情，它是對引起系統(tǒng)做動(dòng)作或系統(tǒng)狀態(tài)轉(zhuǎn)變的外界事件的抽象。狀態(tài)圖中兩個(gè)狀態(tài)之間帶箭頭的連線稱為狀態(tài)轉(zhuǎn)換，箭頭指明了轉(zhuǎn)換方向。

第九十三頁，共一百一十頁，編輯于2023年，星期一當(dāng)有多個(gè)進(jìn)程申請占用CPU運(yùn)行的時(shí)，有關(guān)CPU分配的進(jìn)程的狀況，可以用以下狀態(tài)遷移圖表示。

第九十四頁，共一百一十頁，編輯于2023年，星期一CPU分配的狀態(tài)遷移表

第九十五頁，共一百一十頁，編輯于2023年，星期一2.狀態(tài)轉(zhuǎn)換圖實(shí)例

畫出電話系統(tǒng)的狀態(tài)圖。沒有人打電話時(shí)電話，電話處于閑置狀態(tài)；有人拿起聽筒，則進(jìn)入撥號音狀態(tài)，到達(dá)