軟件需求分析

第三章軟件需求工程

§3.1軟件需求分析

準(zhǔn)確地定義未來(lái)系統(tǒng)的目標(biāo)，確定為了滿足用戶的需求系統(tǒng)必須做什么。用<需求規(guī)格說(shuō)明書>規(guī)范的形式準(zhǔn)確地表達(dá)用戶的需求。在進(jìn)行可行性研究和項(xiàng)目開發(fā)計(jì)劃以后，如果確認(rèn)開發(fā)一個(gè)新的軟件系統(tǒng)是必要的而且是可能的，那么就可進(jìn)入需求分析階段。

需求分析是指開發(fā)人員要準(zhǔn)確理解用戶的要求，進(jìn)行細(xì)致的調(diào)查分析，將用戶非形式的需求陳述轉(zhuǎn)化為完整的需求定義，再由需求定義轉(zhuǎn)換到相應(yīng)的形式功能規(guī)約(需求規(guī)格說(shuō)明)的過(guò)程。需求分析概述

軟件需求是指用戶對(duì)目標(biāo)系統(tǒng)在功能、行為、性能等方面的期望。需求分析是發(fā)現(xiàn)、求精、建模和產(chǎn)生規(guī)格說(shuō)明的過(guò)程，軟件開發(fā)人員需對(duì)應(yīng)用問(wèn)題及環(huán)境的理解、分析，為問(wèn)題涉及的信息、功能及行為建立模型。需求分析實(shí)際上是對(duì)系統(tǒng)的理解與表達(dá)的過(guò)程，是一種軟件工程的活動(dòng)。理解的含義就是開發(fā)人員充分理解用戶的需求，對(duì)問(wèn)題及環(huán)境的理解、分析與綜合，逐步建立目標(biāo)系統(tǒng)的模型。通常軟件人員和用戶一起完全了解系統(tǒng)的確切的要求，即系統(tǒng)要做什么。表達(dá)的含義是產(chǎn)生規(guī)格說(shuō)明書等有關(guān)的文檔。規(guī)格說(shuō)明就是把分析的結(jié)果完全地、精確地表達(dá)出來(lái)。系統(tǒng)分析員經(jīng)過(guò)調(diào)查分析后建立好模型，在這個(gè)基礎(chǔ)上，逐步形成規(guī)格說(shuō)明書，需求規(guī)格說(shuō)明書是一個(gè)非常重要的文檔。經(jīng)過(guò)軟件的需求分析建立起來(lái)的模型可以稱它為分析模型或者需求模型，注意到分析模型實(shí)際上是一組模型，它是一種目標(biāo)系統(tǒng)邏輯表示技術(shù)，它可以用圖形描述工具來(lái)建模，選定一些圖形符號(hào)分別表示信息流、加工處理、以及系統(tǒng)的行為等，還可以用自然語(yǔ)言給出加工說(shuō)明。軟件需求分析的困難性

(1)問(wèn)題的復(fù)雜性。這是由用戶需求所涉及的因素繁多引起的，如運(yùn)行環(huán)境和系統(tǒng)功能等。(2)交流障礙。需求分析涉及人員較多，如軟件系統(tǒng)用戶、問(wèn)題領(lǐng)域?qū)＜?、需求工程師和?xiàng)目管理員等，這些人具備不同的背景知識(shí)，處于不同的角度，扮演不同角色，造成了相互之間交流的困難。(3)不完備性和不一致性：由于各種原因，用戶對(duì)問(wèn)題的陳述往往是不完備的，其各方面的需求還可能存在著予盾，需求分析要消除其矛盾，形成完備及一致的定義(4)需求易變性。用戶需求的變動(dòng)是—個(gè)極為普便的問(wèn)題，即使是部分變動(dòng)，也往往會(huì)影響到需求分析的全部，導(dǎo)致不一致性和不完備性。軟件需求

（1）用戶解決問(wèn)題或達(dá)到目標(biāo)所需的條件或權(quán)能（Capability）。（2）系統(tǒng)或系統(tǒng)部件要滿足合同、標(biāo)準(zhǔn)、規(guī)范或其他正式規(guī)定文件所需具有的條件或權(quán)能。（3）一種反映上面（1）或（2）所描述的條件或權(quán)能的文檔說(shuō)明。

軟件需求的層次

·業(yè)務(wù)需求:業(yè)務(wù)需求反映了組織機(jī)構(gòu)或者客戶對(duì)系統(tǒng)、產(chǎn)品高層的目標(biāo)要求，它們?cè)陧?xiàng)目視圖與范圍文檔中給予說(shuō)明?！び脩粜枨?用戶需求描述了用戶使用產(chǎn)品必須要完成的任務(wù)，這可以在使用實(shí)例文檔給予說(shuō)明。用戶需求應(yīng)該只描述系統(tǒng)的外部行為，盡量避免對(duì)系統(tǒng)設(shè)計(jì)特性描述。用戶需求通常用自然語(yǔ)言、圖表以及直觀的圖形來(lái)描述。在用戶需求描述時(shí)，可能會(huì)出現(xiàn)描述不夠清楚、需求混亂、需求混合等問(wèn)題。系統(tǒng)需求又可以分成功能需求、非功能需求性和領(lǐng)域需求。

功能需求定義了開發(fā)人員必須實(shí)現(xiàn)的軟件功能，使得用戶能完成他們的任務(wù)，從而滿足業(yè)務(wù)需求。在需求規(guī)格說(shuō)明中，功能需求充分描述了軟件系統(tǒng)所具有的外部行為（服務(wù)）。

非功能性需求是不直接與系統(tǒng)具體功能相關(guān)的一類需求，例如，可靠性、響應(yīng)時(shí)間、存儲(chǔ)空間等。非功能需求可以分類：（1）產(chǎn)品需求。（2）機(jī)構(gòu)需求。（3）外部需求。領(lǐng)域需求來(lái)自系統(tǒng)的應(yīng)用領(lǐng)域的需求，反映了該領(lǐng)域的特點(diǎn)。它們可能是一個(gè)新的特有的功能需求、或者是對(duì)已存在的功能需求的約束，也可能是一種非功能需求。需求工程

軟件需求工程領(lǐng)域的層次分解:需求分析原則

必須理解和表示問(wèn)題的信息域，可用數(shù)據(jù)模型描述；·必須定義軟件將完成的功能，可用功能模型描述；·必須表示軟件的行為（服務(wù)、操作），可用行為模型描述；·對(duì)描述的信息、功能和行為模型必須被劃分，使得分析模型可以用層次的方法展示細(xì)節(jié)?！し治鲞^(guò)程應(yīng)該從要素信息移到實(shí)現(xiàn)細(xì)節(jié)?？梢圆捎弥鸩角缶募夹g(shù)。需求分析的步驟當(dāng)前系統(tǒng)目標(biāo)系統(tǒng)物理模型邏輯模型邏輯模型物理模型模型化抽象化具體化實(shí)例化怎么做做什么當(dāng)前系統(tǒng)目標(biāo)系統(tǒng)需求定義邏輯模型和物理模型

模型是對(duì)對(duì)象系統(tǒng)的形式化的特征抽象，概括性或近似地表示；

構(gòu)造模型的過(guò)程是一個(gè)抽象、分析的過(guò)程。對(duì)象系統(tǒng)模型系統(tǒng)抽象（映射）模型應(yīng)用模型構(gòu)造的過(guò)程

邏輯模型物理模型

(本質(zhì)模型、概念模型)

(實(shí)施模型、技術(shù)模型)現(xiàn)行系統(tǒng)目標(biāo)系統(tǒng)描述重要的業(yè)務(wù)功能，無(wú)論系統(tǒng)是如何實(shí)施的。描述現(xiàn)實(shí)系統(tǒng)是如何在物理上實(shí)現(xiàn)的。描述新系統(tǒng)的主要業(yè)務(wù)功能和用戶新的需求，無(wú)論系統(tǒng)應(yīng)如何實(shí)施。描述新系統(tǒng)是如何實(shí)施的（包括技術(shù)）。獲得當(dāng)前系統(tǒng)的物理模型

了解當(dāng)前系統(tǒng)的組織機(jī)構(gòu)、輸入輸出、資源利用情況和日常數(shù)據(jù)處理過(guò)程，并用一個(gè)具體模型來(lái)反映對(duì)當(dāng)前系統(tǒng)的理解。需求分析過(guò)程示意學(xué)生(1)通過(guò)對(duì)現(xiàn)實(shí)環(huán)境的調(diào)查，

獲得當(dāng)前系統(tǒng)的物理模型

學(xué)生購(gòu)書申請(qǐng)購(gòu)書單發(fā)票領(lǐng)書單書107張教務(wù)科206王會(huì)計(jì)室206李出納員303趙教材科學(xué)生購(gòu)買教材的物理模型抽象出當(dāng)前系統(tǒng)的邏輯模型

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

需求分析過(guò)程示意(2)去掉具體模型中的非本質(zhì)因素，

抽象出當(dāng)前系統(tǒng)的邏輯模型

學(xué)生購(gòu)買教材的邏輯模型學(xué)生學(xué)生購(gòu)書申請(qǐng)購(gòu)書單發(fā)票領(lǐng)書單書審查有效性開發(fā)票開領(lǐng)書單發(fā)書建立目標(biāo)系統(tǒng)的邏輯模型

（1）決定變化的范圍，即決定目標(biāo)系統(tǒng)與當(dāng)前系統(tǒng)在邏輯上的差別；（2）對(duì)功能圖（數(shù)據(jù)流圖）及對(duì)象圖等進(jìn)行調(diào)整，將變化的部分看成是新的處理步驟；（3）由外向里對(duì)變化的部分進(jìn)行分析，推斷其結(jié)構(gòu)，獲得目標(biāo)系統(tǒng)的邏輯模型。需求分析過(guò)程示意(3)分析當(dāng)前系統(tǒng)與目標(biāo)系統(tǒng)的差別，

建立目標(biāo)系統(tǒng)的邏輯模型

計(jì)算機(jī)售書系統(tǒng)的邏輯模型學(xué)生學(xué)生購(gòu)書單發(fā)票領(lǐng)書單審查并開發(fā)票開領(lǐng)書單無(wú)效書單對(duì)得到的邏輯模型做一些補(bǔ)充：

（1）說(shuō)明目標(biāo)系統(tǒng)的用戶界面。根據(jù)目標(biāo)系統(tǒng)所處的應(yīng)用環(huán)境及它與外界環(huán)境的相互關(guān)系，研究所有可能與它發(fā)生聯(lián)系和作用的部分，從而決定人機(jī)界面。（2）說(shuō)明至今尚未詳細(xì)考慮的細(xì)節(jié)。這些細(xì)節(jié)包括系統(tǒng)的啟動(dòng)和結(jié)束、出錯(cuò)處理、系統(tǒng)的輸入／輸出、系統(tǒng)性能等。（3）系統(tǒng)必須滿足的其他性能。具體任務(wù)：

·繪制系統(tǒng)關(guān)聯(lián)圖；·創(chuàng)建用戶接口原型；·分析需求可行性；·確定需求的優(yōu)先級(jí)；·為需求建立模型；·創(chuàng)建數(shù)據(jù)字典。需求開發(fā)過(guò)程

需求獲取

·功能需求·性能需求·環(huán)境需求·安全保密要求·用戶界面需求

·資源使用需求

軟件成本消耗與開發(fā)進(jìn)度需求

軟件質(zhì)量屬性

·有效性（availability）有效性=系統(tǒng)的平均故障時(shí)間/（平均故障時(shí)間＋故障修復(fù)時(shí)間）·高效性（efficiency）·靈活性（flexibility）·完整性（integrity）·互操作性（interoperability）·可靠性（reliability）·健壯性（robustness）·可用性（usability）·可維護(hù)性（maintainability）·可移植性（Portability）·可重用性（reusability）·可測(cè)試性（testability）需求分析

需求分析包括提煉、分析、和審查已收集的需求，以確保所有的風(fēng)險(xiǎn)承擔(dān)者都明白它們的含義，并且找出其中的錯(cuò)誤、遺漏或者不足的地方。

需求規(guī)格說(shuō)明描述需求的文檔叫做軟件需求規(guī)格說(shuō)明，分析模型是需求規(guī)格說(shuō)明中的其中一部分。分析員應(yīng)以調(diào)查分析及分析模型為基礎(chǔ)，逐步形成規(guī)格說(shuō)明書。

制定數(shù)據(jù)要求說(shuō)明書及編寫初步的用戶手冊(cè)。

修改、完善并確定軟件開發(fā)實(shí)施計(jì)劃。

需求評(píng)審

對(duì)功能的正確性、完整性和清晰性，以及其他需求給予評(píng)價(jià)。評(píng)審應(yīng)指定專人負(fù)責(zé)，并嚴(yán)格按規(guī)程進(jìn)行。評(píng)審結(jié)束后應(yīng)由評(píng)審負(fù)責(zé)人簽署評(píng)審意見。通常，在評(píng)審意見中包括了一些修改意見，須按這些修改意見對(duì)軟件進(jìn)行修改，待修改完成后還要再評(píng)審，直至通過(guò)才可進(jìn)行軟件設(shè)計(jì)。軟件需求建模

所謂模型，就是為了理解事物而對(duì)事物做出的一種抽象，是對(duì)事物的一種無(wú)歧義的書面描述。簡(jiǎn)單地說(shuō)，模型就是某一事物的抽象表示方式。通常，軟件工程中的模型可以由一組圖形符號(hào)和組織這些符號(hào)的規(guī)則組成。

最終確立的分析模型是生成需求規(guī)格說(shuō)明的基礎(chǔ)，也是軟件設(shè)計(jì)和實(shí)現(xiàn)的基礎(chǔ)。模型的作用建模的原因：在建模過(guò)程中了解系統(tǒng)通過(guò)抽象降低復(fù)雜性有助于回憶所有的細(xì)節(jié)有助于開發(fā)小組間的交流有助于與用戶的交流為系統(tǒng)的維護(hù)提供文檔

模型化或模型方法是通過(guò)抽象、概括和一般化，把研究的對(duì)象或問(wèn)題轉(zhuǎn)化為本質(zhì)（關(guān)系或結(jié)構(gòu)）相同的另一對(duì)象或問(wèn)題，從而加以解決的方法。模型化方法要求所建立的模型能真實(shí)反映所研究對(duì)象的整體結(jié)構(gòu)、關(guān)系或某一過(guò)程、某一局部、某一側(cè)面的本質(zhì)特征和變化規(guī)律。模型的類型數(shù)學(xué)模型描述模型圖形模型軟件分析模型

的基本要求·描述用戶對(duì)軟件系統(tǒng)的需求；·為軟件設(shè)計(jì)奠定一個(gè)良好的基礎(chǔ)；·定義一組需求，并且可以作為軟件產(chǎn)品驗(yàn)收的標(biāo)準(zhǔn)。數(shù)據(jù)模型

數(shù)據(jù)模型用于描述數(shù)據(jù)對(duì)象之間的關(guān)系，數(shù)據(jù)模型應(yīng)包含有三種相關(guān)的信息，即數(shù)據(jù)對(duì)象、屬性和關(guān)系。

·數(shù)據(jù)對(duì)象數(shù)據(jù)對(duì)象是幾乎所有必須被軟件理解的復(fù)合信息的表示。復(fù)合信息是指具有若干不同特性或者屬性的事物。所以，僅有單個(gè)值的事物不是對(duì)象，例如，寬度、長(zhǎng)度等等。數(shù)據(jù)對(duì)象可以是一個(gè)外部實(shí)體、事物、行為、事件、角色、單位、地點(diǎn)、結(jié)構(gòu)等等。

屬性定義了數(shù)據(jù)對(duì)象的性質(zhì)，它具有三種不同的特性之一。（1）為數(shù)據(jù)對(duì)象實(shí)例命名；（2）描述該實(shí)例；（3）引用另一個(gè)實(shí)例。

·關(guān)系數(shù)據(jù)對(duì)象彼此之間是有關(guān)聯(lián)的，也稱為關(guān)系。例如，數(shù)據(jù)對(duì)象“教師”和“課程”的連接關(guān)系是“教”；數(shù)據(jù)對(duì)象“學(xué)生”和“課程”的連接關(guān)系是“學(xué)”等等。這種關(guān)聯(lián)的形態(tài)有三種。（1）一對(duì)一關(guān)聯(lián)（1：1）。例如，一個(gè)間學(xué)校只有一位校長(zhǎng)，所以，學(xué)校與校長(zhǎng)的關(guān)聯(lián)是一對(duì)一的。（2）一對(duì)多關(guān)聯(lián)（1：N）。例如，一位教師可以“教”多門課程，所以，教師和課程的關(guān)聯(lián)是一對(duì)多的。（3）多對(duì)多關(guān)聯(lián)（M：N）。例如，一名學(xué)生可以學(xué)多門課程，一門課程有多名學(xué)生學(xué)習(xí)，所以，學(xué)生和課程的關(guān)聯(lián)是多對(duì)多的。實(shí)體—關(guān)系圖

ERD包含三種基本元素，即實(shí)體、屬性、關(guān)系。通常用矩形表示實(shí)體即數(shù)據(jù)對(duì)象；用圓角矩形或者橢圓形表示實(shí)體的屬性；用菱形連接相關(guān)實(shí)體表示關(guān)系。功能模型

數(shù)據(jù)流圖中的基本元素有：

·數(shù)據(jù)流·加工處理·文件·源點(diǎn)和終點(diǎn)分解的程度

系統(tǒng)自頂向下逐層分解時(shí)，可以把一個(gè)加工分解成幾個(gè)加工，當(dāng)每一個(gè)加工都已分解到足夠簡(jiǎn)單時(shí)，分解工作就可以結(jié)束了。足夠簡(jiǎn)單的不再分解的加工稱為基本加工。如果某一層分解不合理、不恰當(dāng)就要重新分解。加工說(shuō)明

加工說(shuō)明或者說(shuō)加工處理（ProcessSpecification）過(guò)程，它用于描述系統(tǒng)的每一個(gè)基本加工處理的邏輯，說(shuō)明輸入數(shù)據(jù)轉(zhuǎn)換為輸出數(shù)據(jù)的加工規(guī)則。加工邏輯僅說(shuō)明“做什么”就可以了，而不是實(shí)現(xiàn)加工的是細(xì)節(jié)。加工說(shuō)明的描述方式可以用結(jié)構(gòu)化語(yǔ)言、判定表、判定樹、IPO（輸入/處理/輸出）圖等等。行為模型

狀態(tài)機(jī)模型通過(guò)描述系統(tǒng)的狀態(tài)以及引起系統(tǒng)狀態(tài)轉(zhuǎn)換的事件，來(lái)表示系統(tǒng)的行為。狀態(tài)圖中的基本元素有事件、狀態(tài)和行為等。數(shù)據(jù)字典

數(shù)據(jù)字典（DataDictionary）用于描述軟件系統(tǒng)中使用或者產(chǎn)生的每一個(gè)數(shù)據(jù)元素，是系統(tǒng)數(shù)據(jù)信息定義的集合。數(shù)據(jù)字典方便于人們對(duì)不了解的條目進(jìn)行查閱，人們可以借助于數(shù)據(jù)字典查出每一個(gè)名字（包括數(shù)據(jù)流、加工名、文件名等）的定義和組成，以免產(chǎn)生誤解。面向?qū)ο竽Ｐ?/p>

分析模型有3個(gè)子模型—對(duì)象模型、動(dòng)態(tài)模型和功能模型。其中，對(duì)象模型描述軟件系統(tǒng)的靜態(tài)結(jié)構(gòu)；動(dòng)態(tài)模型描述軟件系統(tǒng)的控制結(jié)構(gòu)；功能模型描述軟件系統(tǒng)必須要完成的功能。

需求規(guī)格說(shuō)明書(SRS)

(SoftwareRequirementSpecification)需求分析階段要完成的文檔。SRS的作用：開發(fā)者與用戶間事實(shí)上的技術(shù)合同書開發(fā)者下一步設(shè)計(jì)和編碼的基礎(chǔ)測(cè)試驗(yàn)收目標(biāo)系統(tǒng)的依據(jù)軟件需求規(guī)格與評(píng)審

SRS也是客戶和開發(fā)小組對(duì)將要開發(fā)的產(chǎn)品達(dá)成一致的協(xié)議，這個(gè)協(xié)議應(yīng)該綜合業(yè)務(wù)需求、用戶需求和一個(gè)詳細(xì)系統(tǒng)需求描述；它能精確地反映和描述一個(gè)軟件系統(tǒng)必須提供的功能（應(yīng)該做什么）以及實(shí)現(xiàn)和運(yùn)行的約束條件。軟件需求規(guī)格不應(yīng)該包括設(shè)計(jì)、構(gòu)造、測(cè)試或者工程管理的細(xì)節(jié)。·用結(jié)構(gòu)化和自然語(yǔ)言編寫文本型文檔；·建立圖形化模型，這些模型可以描繪數(shù)據(jù)變換過(guò)程、系統(tǒng)狀態(tài)和它們之間的變化、數(shù)據(jù)關(guān)系、邏輯流、對(duì)象類以及它們的關(guān)系；·用形式化語(yǔ)言編寫，通過(guò)使用數(shù)學(xué)上精確的形式化邏輯語(yǔ)言來(lái)定義需求。

軟件需求規(guī)格目標(biāo)

·便于用戶、分析員和軟件設(shè)計(jì)人員進(jìn)行理解及交流；·支持目標(biāo)系統(tǒng)的確認(rèn)，反映問(wèn)題的結(jié)構(gòu)，可作為設(shè)計(jì)和編程的基礎(chǔ)；·控制系統(tǒng)的實(shí)施過(guò)程；·作為軟件測(cè)試和驗(yàn)收以及維護(hù)的依據(jù)。

需求規(guī)格說(shuō)明的內(nèi)容

見文檔。軟件需求規(guī)格的評(píng)審

需求評(píng)審是一個(gè)手工過(guò)程，需要用戶和開發(fā)者共同參與，檢查文檔中是否存在不規(guī)范和遺漏的地方，如果在評(píng)審過(guò)程中發(fā)現(xiàn)存在錯(cuò)誤或者缺陷，應(yīng)該及時(shí)進(jìn)行更改和補(bǔ)充，重新進(jìn)行相應(yīng)部分的需求分析、需求建模等，然后再進(jìn)行評(píng)審。

評(píng)審指標(biāo)

正確性。無(wú)歧義性。完全性。需求規(guī)格說(shuō)明不能遺漏任何用戶需求。可驗(yàn)證性。對(duì)于規(guī)格說(shuō)明中的任意需求，均存在技術(shù)和經(jīng)濟(jì)可行的手段進(jìn)行驗(yàn)證和確認(rèn)。一致性。需求規(guī)格說(shuō)明的各部分之間不能相互矛盾?？衫斫庑??？尚薷男?。可追蹤性。需求規(guī)格說(shuō)明必須將分析后獲得的每一項(xiàng)需求與用戶的原始需求聯(lián)系起來(lái)。

·系統(tǒng)定義的目標(biāo)是否與用戶的要求一致；·系統(tǒng)需求分析提供的文檔資料是否齊全；·文檔中的所有描述是否完整、清晰、準(zhǔn)確；·與所有其他系統(tǒng)成分的重要接口是否都已經(jīng)描述；·所開發(fā)項(xiàng)目的數(shù)據(jù)流與數(shù)據(jù)結(jié)構(gòu)是否足夠，是否確定；·所有圖表是否清楚，是否易于理解；·主要功能是否已包括在規(guī)定的軟件范圍之內(nèi)；·設(shè)計(jì)的約束條件或限制條件是否符合實(shí)際；·開發(fā)的技術(shù)風(fēng)險(xiǎn)是什么；·是否考慮過(guò)軟件需求的其他方案；·是否考慮過(guò)將來(lái)可能會(huì)提出的軟件需求；·是否詳細(xì)制定了檢驗(yàn)標(biāo)準(zhǔn)；·有沒(méi)有遺漏、重復(fù)或不一致的地方；·用戶是否審查了初步的用戶手冊(cè)；·軟件開發(fā)計(jì)劃中的估算是否受到了影響。需求管理

需求管理是一個(gè)對(duì)系統(tǒng)需求變更了解和控制的過(guò)程。需求管理過(guò)程與需求開發(fā)過(guò)程相互關(guān)聯(lián)，當(dāng)初始需求導(dǎo)出的同時(shí)就啟動(dòng)了需求管理規(guī)劃，一旦形成了需求文檔的初稿，需求管理活動(dòng)就開始了需求管理強(qiáng)調(diào)：·控制對(duì)需求基線的變動(dòng)；·保持項(xiàng)目計(jì)劃與需求一致；·控制單個(gè)需求和需求文檔的版本情況；·管理需求和聯(lián)系鏈，或者管理單個(gè)需求和其他項(xiàng)目可交付產(chǎn)品之間的依賴關(guān)系；

需求管理原則

·需求管理的關(guān)鍵過(guò)程領(lǐng)域不涉及收集和分析項(xiàng)目需求。

·開發(fā)人員在向客戶以及有關(guān)部門承諾（commitment）某些需求之前，應(yīng)該確認(rèn)需求和約束條件、風(fēng)險(xiǎn)、偶然因素、假定條件等等。

·關(guān)鍵處理領(lǐng)域同樣建議通過(guò)版本控制和變更控制來(lái)管理需求文檔。

需求規(guī)格說(shuō)明的版本控制

每一個(gè)新版本的需求文檔，應(yīng)該公布的包括一個(gè)修正版本的歷史情況，例如，變更的內(nèi)容、變更日期、變更人員的姓名以及變更的原因等等。

需求屬性

·創(chuàng)建需求的時(shí)間；·需求的版本號(hào)；·創(chuàng)建需求的作者；·負(fù)責(zé)認(rèn)可該軟件需求的人員；·需求狀態(tài)；·需求的原因和根據(jù)；·需求涉及的子系統(tǒng)；·需求涉及的產(chǎn)品版本號(hào)；·使用的驗(yàn)證方法或者接受的測(cè)試標(biāo)準(zhǔn)；·產(chǎn)品的優(yōu)先級(jí)或者重要程度；·需求的穩(wěn)定性。

需求變更

毫無(wú)控制的變更是項(xiàng)目陷入混亂、不能按進(jìn)度完成，或者軟件質(zhì)量無(wú)法保證的主要原因之一。

·仔細(xì)評(píng)估已建議的變更；·挑選合適的人選對(duì)變更做出決定；·變更應(yīng)及時(shí)通知所有涉及的人員；·項(xiàng)目要按一定的程序來(lái)采納需求變更；變更控制過(guò)程

·問(wèn)題分析和變更描述。

這是識(shí)別和分析需求問(wèn)題或者一份明確的變更提議，以檢查它的有效性，從而產(chǎn)生一個(gè)更明確的需求變更提議?！ぷ兏治龊统杀居?jì)算。

使用可追溯性信息和系統(tǒng)需求的一般知識(shí)，對(duì)需求變更提議進(jìn)行影響分析和評(píng)估。變更成本計(jì)算應(yīng)該包括對(duì)需求文檔的修改、系統(tǒng)修改的設(shè)計(jì)和實(shí)現(xiàn)的成本。一旦分析完成并且被確認(rèn)，應(yīng)該制定是否執(zhí)行這一變更的決策?！ぷ兏鼘?shí)現(xiàn)。

這要求需求文檔以及系統(tǒng)設(shè)計(jì)和實(shí)現(xiàn)都要同時(shí)修改。如果先對(duì)系統(tǒng)的程序做變更，然后再修改需求文檔，這幾乎不可避免地出現(xiàn)需求文檔和程序的不一致。需求變更策略

·所有需求變更必須遵循變更控制過(guò)程；·對(duì)于未獲得批準(zhǔn)的變更，不應(yīng)該做設(shè)計(jì)和實(shí)現(xiàn)工作；·變更應(yīng)該由項(xiàng)目變更控制委員會(huì)決定實(shí)現(xiàn)哪些變更；·項(xiàng)目風(fēng)險(xiǎn)承擔(dān)者應(yīng)該能夠了解變更數(shù)據(jù)庫(kù)的內(nèi)容；·決不能從數(shù)據(jù)庫(kù)中刪除或者修改變更請(qǐng)求的原始文檔；·每一個(gè)集成的需求變更必須能跟蹤到一個(gè)經(jīng)核準(zhǔn)的變更請(qǐng)求。需求變更工具·可以定義變更請(qǐng)求的數(shù)據(jù)項(xiàng)；·可以定義變更請(qǐng)求生存期的狀態(tài)轉(zhuǎn)換圖；·可以加強(qiáng)狀態(tài)轉(zhuǎn)換圖使經(jīng)授權(quán)的用戶僅能做出所允許的狀態(tài)變更；·記錄每一種狀態(tài)變更的數(shù)據(jù)，確認(rèn)做出變更的人員；·可以定義在提交新請(qǐng)求或請(qǐng)求狀態(tài)被更新后應(yīng)該自動(dòng)通知的設(shè)計(jì)人員；·可以根據(jù)需要生成標(biāo)準(zhǔn)的或定制的報(bào)告和圖表。變更控制委員會(huì)

變更控制委員會(huì)負(fù)責(zé)決定哪一些已建議需求變更或者新產(chǎn)品特性付諸應(yīng)用，決定在哪一些版本中糾正哪一些錯(cuò)誤。廣義上，變更控制委員會(huì)對(duì)項(xiàng)目中任何基線工作產(chǎn)品的變更都可以做出決定，需求變更文檔僅是其中之一。

A．制定決策制定決策過(guò)程（程式）的描述應(yīng)確認(rèn)：·變更控制委員會(huì)必須到會(huì)的人數(shù)或做出有效決定必須出席的人員數(shù)；·決策的方法（例如投票，一致通過(guò)或其它機(jī)制）；·變更控制委員會(huì)主席是否可以否決該集體的決定。變更控制委員會(huì)應(yīng)該對(duì)每個(gè)變更權(quán)衡利弊后做出決定。“利”包括節(jié)省的資金或額外的收入、增強(qiáng)的客戶滿意度、競(jìng)爭(zhēng)優(yōu)勢(shì)、減少上市時(shí)間?！氨住笔侵附邮茏兏螽a(chǎn)生的負(fù)面影響，包括增加的開發(fā)費(fèi)用、推遲的交付日期、產(chǎn)品質(zhì)量的下降、減少的功能、用戶不滿意。如果估計(jì)的費(fèi)用超過(guò)了本級(jí)變更控制委員會(huì)的管理范圍，上報(bào)到高一級(jí)的委員會(huì)，否則用制訂的決策程式來(lái)對(duì)變更做出決定。B．交流情況一旦變更控制委員會(huì)做出決策時(shí)，指派的人員應(yīng)及時(shí)更新數(shù)據(jù)庫(kù)中請(qǐng)求的狀態(tài)。有的工具可以自動(dòng)通過(guò)電子郵件來(lái)通知相關(guān)人員。若沒(méi)有這樣的工具，就應(yīng)該人工通知，以保證他們能充分處理變更。C．重新協(xié)商約定變更總是有代價(jià)的。即使拒絕的變更也因?yàn)闆Q策行為（提交、評(píng)估、決策）而耗費(fèi)了資源。變更對(duì)新的產(chǎn)品特性會(huì)有很大的影響。如果向一個(gè)工程項(xiàng)目中增加很多新功能，又要求在原先確定的進(jìn)度計(jì)劃、人員安排、資金預(yù)算和質(zhì)量要求限制內(nèi)完成整個(gè)項(xiàng)目是不現(xiàn)實(shí)的。當(dāng)工程項(xiàng)目接受了重要的需求變更時(shí)，為了適應(yīng)變更情況要與管理部門和客戶重新協(xié)商約定。協(xié)商的內(nèi)容可能包括推遲“交貨”時(shí)間、要求增加入手、推遲實(shí)現(xiàn)尚未實(shí)現(xiàn)的較低優(yōu)先級(jí)的需求，或者質(zhì)量上進(jìn)行折衷。要是不能獲得一些約定的調(diào)整，應(yīng)該把面臨的威脅寫進(jìn)風(fēng)險(xiǎn)管理計(jì)劃中，這樣當(dāng)項(xiàng)目沒(méi)有達(dá)到期望的結(jié)果時(shí)就不會(huì)有人驚奇了。需求跟蹤

需求跟蹤包括編制每個(gè)需求同系統(tǒng)元素之間的聯(lián)系文檔，這些元素包括別的需求、體系結(jié)構(gòu)、其他設(shè)計(jì)部件、源代碼模塊、測(cè)試、幫助文件、文檔等。跟蹤能力信息使變更影響分析十分便利，有利于確認(rèn)和評(píng)估實(shí)現(xiàn)某個(gè)建議的需求變更所必須的工作。需求可跟蹤能力

·客戶需求向前追溯到軟件需求。這樣就能區(qū)分出開發(fā)過(guò)程中或者開發(fā)結(jié)束后，由于需求變更受到影響的需求。這也就可以確保需求規(guī)格說(shuō)明包括所有客戶需求?！能浖枨蠡厮菹鄳?yīng)的客戶需求。這也就是確認(rèn)每個(gè)軟件需求的源頭，如果用使用實(shí)例的形式來(lái)描述客戶需求，那么客戶需求與軟件需求之間的跟蹤情況就是使用實(shí)例和功能性需求。·從軟件需求向前追溯到下一級(jí)工作產(chǎn)品。由于開發(fā)過(guò)程中系統(tǒng)需求轉(zhuǎn)變?yōu)檐浖枨蟆⒃O(shè)計(jì)、編碼等，所以通過(guò)定義單個(gè)需求和特定的產(chǎn)品元素之間的（聯(lián)系）鏈，可以從需求向前追溯到下一級(jí)工作產(chǎn)品。這種聯(lián)系鏈告訴我們每個(gè)需求對(duì)應(yīng)的產(chǎn)品部件（構(gòu)件），從而確保產(chǎn)品部件滿足每個(gè)需求?！漠a(chǎn)品部件回溯到軟件需求。使你知道每個(gè)部件存在的原因，如果不能把設(shè)計(jì)元素、代碼段或測(cè)試回溯到一個(gè)需求，可能有一個(gè)“畫蛇添足”的程序。然而，如果這些孤立的元素表明了一個(gè)正當(dāng)?shù)墓δ?，則說(shuō)明需求規(guī)格說(shuō)明書漏掉了一項(xiàng)需求。

需求變更的代價(jià)和風(fēng)險(xiǎn)

影響分析是需求管理的一個(gè)重要組成部分。影響分析可以提供對(duì)建議的變更的準(zhǔn)確理解，幫助做出信息量充分的變更批準(zhǔn)決策。通過(guò)對(duì)變更內(nèi)容的檢驗(yàn)，確定對(duì)現(xiàn)有的系統(tǒng)做出是修改或者拋棄的決定；或者創(chuàng)建新系統(tǒng)以及評(píng)估每個(gè)任務(wù)的工作量。進(jìn)行影響分析的能力依賴于跟蹤能力數(shù)據(jù)的質(zhì)量和完整性。軟件需求分析工具

需求分析的自動(dòng)工具按不同的方式可以歸為兩類。一類工具是為自動(dòng)生成和維護(hù)系統(tǒng)的規(guī)格說(shuō)明（以前是以手工方法制作的）而設(shè)計(jì)的。這類工具主要利用圖形記號(hào)進(jìn)行分析，它們產(chǎn)生一些圖示，輔助問(wèn)題分解，維護(hù)系統(tǒng)的信息層次，并使用試探法來(lái)發(fā)現(xiàn)規(guī)格說(shuō)明中的問(wèn)題。

另一類需求分析工具要用到一種特殊的以自動(dòng)方式處理的表示法（多數(shù)情況是需求規(guī)格說(shuō)明語(yǔ)言）。用需求規(guī)格說(shuō)明語(yǔ)言來(lái)描述需求，它是由關(guān)鍵字指示符號(hào)與自然語(yǔ)言（例如英語(yǔ)）敘述組合而成。

需求管理的工具

以數(shù)據(jù)庫(kù)為核心的產(chǎn)品把所有的需求、屬性和跟蹤能力信息存儲(chǔ)在數(shù)據(jù)庫(kù)中。依賴于這樣的產(chǎn)品，數(shù)據(jù)庫(kù)可以是商業(yè)（通用）的或者是專有的，關(guān)系型或者面向?qū)ο蟮?。可以從不同的源文檔中產(chǎn)生需求，但結(jié)果都存在數(shù)據(jù)庫(kù)中。在大多數(shù)情況下，需求的文本描述被簡(jiǎn)單地處理為必須的屬性。

分析建模方法結(jié)構(gòu)化分析(傳統(tǒng)建模方法)面向?qū)ο蠓治龅?章作業(yè)1、什么是需求分析？需求分析有哪些原則？2、簡(jiǎn)述建立目標(biāo)系統(tǒng)邏輯模型的一般步驟。3、軟件的質(zhì)量屬性有哪些？各自含義是什么？4、需求規(guī)格說(shuō)明評(píng)審指標(biāo)有哪些？各自含義是什么？5、簡(jiǎn)述需求管理的主要活動(dòng)。結(jié)構(gòu)化方法包含：SA-SD-SP原理：自頂向下、逐步求精基本原則：抽象與分解結(jié)構(gòu)化分析方法(StructuredAnalysis,SA)基本原則：P153

抽象:先把分析對(duì)象抽象成為一個(gè)系統(tǒng)。

分解：由頂向下，層層分解，使復(fù)雜的系統(tǒng)分解成足夠簡(jiǎn)單，能被清楚地理解和表達(dá)的若干子系統(tǒng)。結(jié)構(gòu)化分析方法SA結(jié)構(gòu)化分析（StructuredAnalysis，SA）是由DouglasRoss提出的，由DeMarco進(jìn)行推廣的。采用自頂向下、逐層進(jìn)行功能分解的系統(tǒng)分析方法來(lái)定義系統(tǒng)的需求。適用于分析大型的數(shù)據(jù)處理系統(tǒng)。方法的特點(diǎn)：利用數(shù)據(jù)流圖（DataFlowDiagram，DFD）來(lái)幫助理解問(wèn)題，對(duì)問(wèn)題進(jìn)行分析。一般工具：DFD、數(shù)據(jù)字典、結(jié)構(gòu)化英語(yǔ)、判定表、判定樹等。SA分析模型的主要目標(biāo)描述用戶需要建立創(chuàng)建軟件設(shè)計(jì)的基礎(chǔ)定義軟件完成后可被確認(rèn)的一組需求SA分析模型的結(jié)構(gòu)數(shù)據(jù)字典數(shù)據(jù)流圖E-R圖狀態(tài)變遷圖加工規(guī)約控制規(guī)約數(shù)據(jù)對(duì)象描述結(jié)構(gòu)化分析方法功能分析工具：DFD、DD、結(jié)構(gòu)化英語(yǔ)、判定表和判定樹。行為分析工具：狀態(tài)遷移圖、Petri網(wǎng)等。數(shù)據(jù)分析工具：ER圖或者EER（擴(kuò)展ER）圖。SA主要針對(duì)數(shù)據(jù)處理領(lǐng)域，因此，系統(tǒng)分析的側(cè)重點(diǎn)在于功能分析和數(shù)據(jù)分析，而行為分析使用得較少。分析模型的構(gòu)成元素?cái)?shù)據(jù)字典(DD)

模型核心，包含了所有數(shù)據(jù)對(duì)象的描述的中心庫(kù)。E-R圖(ERD)表示數(shù)據(jù)對(duì)象以及相互的關(guān)系，用于數(shù)據(jù)建模。數(shù)據(jù)流圖(DFD)指明數(shù)據(jù)在系統(tǒng)中移動(dòng)時(shí)如何被變換;描述對(duì)數(shù)據(jù)流進(jìn)行變換的功能;DFD中每個(gè)功能的描述包含在加工規(guī)約(小說(shuō)明)。用于功能建模。狀態(tài)變遷圖(STD)指明作為外部事件的結(jié)果,系統(tǒng)將如何動(dòng)作。用于行為建模。數(shù)據(jù)建模最常用的表示概念性數(shù)據(jù)模型的方法，是實(shí)體聯(lián)系方法（Entity-RelationshipApproach）ER圖描述現(xiàn)實(shí)世界中的實(shí)體，而不涉及這些實(shí)體在系統(tǒng)中的實(shí)現(xiàn)方法。E-R圖元素⑴Entities例：,

,StudentInstructorClass實(shí)體是客觀世界中存在的且可相互區(qū)分的事務(wù)。實(shí)體可以是人也可以是物，可以是具體的事物也可以是抽象概念。例如，職工、學(xué)生、課程、教師等都是實(shí)體。E-R圖元素客觀世界中的事物彼此間往往是有聯(lián)系的，例如，教師與課程間存在“教”這種聯(lián)系。⑵Relations例：EnrolledinTeach111NMNE-R圖元素屬性是實(shí)體或聯(lián)系所具有的性質(zhì)。通常一個(gè)實(shí)體由若干個(gè)屬性來(lái)刻畫。例如，“學(xué)生”實(shí)體有學(xué)號(hào)、姓名、性別、系、年級(jí)⑶Attributes例：,NameID#E-R圖…………InstructorStudentEnrolledinTeachClassID#ID#NameNameSexSexTitleInstructorIDClassIDGradeStudentIDClassIDCreditID#Subject例：變換輸入信息信息流模型輸出信息外部實(shí)體外部實(shí)體外部實(shí)體輸入信息外部實(shí)體外部實(shí)體輸出信息輸出信息功能建模和信息流數(shù)據(jù)存儲(chǔ)1數(shù)據(jù)流圖數(shù)據(jù)流圖說(shuō)明(Yourdon表示)：表示外部實(shí)體，代表數(shù)據(jù)源和數(shù)據(jù)池。表示加工，代表接收輸入，經(jīng)過(guò)變換，繼而產(chǎn)生輸出的處理過(guò)程。表示數(shù)據(jù)流，代表數(shù)據(jù)的流向和路徑。表示數(shù)據(jù)存儲(chǔ)，代表系統(tǒng)加工的數(shù)據(jù)所存儲(chǔ)的地方。外部實(shí)體變換數(shù)據(jù)存儲(chǔ)圖7.3數(shù)據(jù)流圖的符號(hào)1數(shù)據(jù)流圖數(shù)據(jù)流圖(DFD，DataFlowDiagram)描述邏輯模型的圖形工具，表示數(shù)據(jù)在系統(tǒng)內(nèi)的變化。DFD可以分層表示信息流和功能的細(xì)節(jié)，既提供了功能建模的機(jī)制，又提供了信息流建模的機(jī)制。第0層的DFD也被稱為基本系統(tǒng)模型或語(yǔ)境模型。DFD沒(méi)有提供顯式的處理順序，過(guò)程或順序式隱含在DFD中的，顯式的推遲到系統(tǒng)設(shè)計(jì)時(shí)。不要混淆DFD和程序流程圖！例1

下面通過(guò)一個(gè)簡(jiǎn)單例子具體說(shuō)明怎樣畫數(shù)據(jù)流圖。假設(shè)一家工廠的采購(gòu)部每天需要一張定貨報(bào)表，報(bào)表按零件編號(hào)排序，表中列出所有需要再次定貨的零件。對(duì)于每個(gè)需要再次定貨的零件應(yīng)該列出下述數(shù)據(jù)；零件編號(hào)、零件名稱、定貨數(shù)量、目前價(jià)格、主要供應(yīng)者和次要供應(yīng)者。零件入庫(kù)或出庫(kù)稱為事務(wù)，通過(guò)放在倉(cāng)庫(kù)中的CRT終端把事務(wù)報(bào)告給定貨系統(tǒng)。當(dāng)某種零件的庫(kù)存數(shù)量少于庫(kù)存量臨界值時(shí)就應(yīng)該再次定貨。數(shù)據(jù)流圖有四種成分：源點(diǎn)或終點(diǎn)、處理、數(shù)據(jù)存儲(chǔ)和數(shù)據(jù)流。因此，畫出上述定貨系統(tǒng)的數(shù)據(jù)流圖可采用以下步驟。從問(wèn)題描述中提取數(shù)據(jù)流圖的四種成分。表1總結(jié)了上面分析的結(jié)果，其中加星號(hào)標(biāo)記的是在問(wèn)題描述中隱含的成分。一旦把數(shù)據(jù)流圖的四種成分都分離出來(lái)以后，就可以著手畫數(shù)據(jù)流圖了。任何系統(tǒng)的基本模型都由若干個(gè)數(shù)據(jù)源點(diǎn)/終點(diǎn)以及一個(gè)處理組成，這個(gè)處理就代表了系統(tǒng)對(duì)數(shù)據(jù)加工變換的基本功能。從基本系統(tǒng)模型這樣非常高的抽象層次開始畫數(shù)據(jù)流圖是一個(gè)好辦法。在這個(gè)高層次的數(shù)據(jù)流圖上是否列出了所有給定的數(shù)據(jù)源點(diǎn)/終點(diǎn)是一目了然的，因此它是很有價(jià)值的通信工具。

下一步應(yīng)該把基本系統(tǒng)模型細(xì)化，描繪系統(tǒng)的主要功能。給處理和數(shù)據(jù)存儲(chǔ)都加了編號(hào)，這樣做的目的是便于引用和追蹤。接下來(lái)應(yīng)該對(duì)功能級(jí)數(shù)據(jù)流圖中描繪的系統(tǒng)主要功能進(jìn)一步細(xì)化。當(dāng)對(duì)數(shù)據(jù)流圖分層細(xì)化時(shí)必須保持信息連續(xù)性，也就是說(shuō)，當(dāng)把一個(gè)處理分解為一系列處理時(shí)，分解前和分解后的輸入/輸出數(shù)據(jù)流必須相同。定貨系統(tǒng)的基本系統(tǒng)模型(突出表明了數(shù)據(jù)的源點(diǎn)和終點(diǎn))定貨系統(tǒng)的功能級(jí)數(shù)據(jù)流圖把處理事務(wù)的功能進(jìn)一步分解后的數(shù)據(jù)流圖人事部門人事工資管理系統(tǒng)會(huì)計(jì)部門職工出缺勤報(bào)表職工出缺勤信息職工工資信息職工工資報(bào)表職工職工基本信息職工工資單例2：人事工資管理系統(tǒng)的頂層DFD(概圖)范例職工基本信息管理子系統(tǒng)1.02.0人事工資管理系統(tǒng)0層DFD范例職工出缺勤信息職工工資管理子系統(tǒng)3.0職工出缺勤管理子系統(tǒng)職工基本信息職工工資信息人事部門會(huì)計(jì)部門職工職工出缺勤報(bào)表職工出缺勤信息職工工資信息職工工資報(bào)表職工基本信息職工工資單建立職工出缺勤信息3.1人事工資管理系統(tǒng)1層DFD：加工3.0的分解圖職工出缺勤信息3.2制作職工出缺勤信息統(tǒng)計(jì)表職工基本信息職工出缺勤報(bào)表職工出缺勤信息例3：分層DFD實(shí)例一個(gè)簡(jiǎn)單的考務(wù)處理系統(tǒng)功能描述：(1)對(duì)考生送來(lái)的報(bào)名單進(jìn)行檢查;(2)對(duì)合格的報(bào)名單編好準(zhǔn)考證號(hào)后將準(zhǔn)考證送給考生，并將匯總后的考生名單送給閱卷站;(3)對(duì)閱卷站送來(lái)的成績(jī)單進(jìn)行檢查，并根據(jù)考試中心制定的合格標(biāo)準(zhǔn)審定合格者;(4)制作考生通知單(含成績(jī)及合格/不合格標(biāo)志)送給考生;(5)按地區(qū)進(jìn)行成績(jī)分類統(tǒng)計(jì)和試題難度分析，產(chǎn)生統(tǒng)計(jì)分析表?？忌紕?wù)處理系統(tǒng)考試中心閱卷站不合格報(bào)名單報(bào)名單準(zhǔn)考證考生通知單成績(jī)清單合格標(biāo)準(zhǔn)錯(cuò)誤成績(jī)清單考生名單統(tǒng)計(jì)分析表頂層數(shù)據(jù)流圖登記報(bào)名單報(bào)名單準(zhǔn)考證1統(tǒng)計(jì)成績(jī)2不合格報(bào)名單考生通知單成統(tǒng)計(jì)分析表考生名冊(cè)績(jī)清單合格標(biāo)準(zhǔn)考生名單成績(jī)清單錯(cuò)誤0層數(shù)據(jù)流圖1層數(shù)據(jù)流圖(a)檢查報(bào)名單報(bào)名單準(zhǔn)考證1.1編準(zhǔn)考證號(hào)1.2不合格報(bào)名單考生名冊(cè)考生名單合格報(bào)名單登記考生1.3一層數(shù)據(jù)流圖(b)檢查成績(jī)清單2.1審定合格者2.2考生名冊(cè)正確成績(jī)清單制作通知單2.3分析統(tǒng)計(jì)成績(jī)2.4分析試題難度2.5試題得分清單考生通知單難度分析表合格標(biāo)準(zhǔn)分類統(tǒng)計(jì)表成績(jī)清單錯(cuò)誤成績(jī)清單經(jīng)審定的成績(jī)清單數(shù)據(jù)流圖分解原則DFD可以用來(lái)表示一個(gè)系統(tǒng)或軟件在任何層次上的抽象。較大型軟件系統(tǒng)DFD分成多層(子圖、父圖概念),可以表示數(shù)據(jù)流和功能的進(jìn)一步的細(xì)節(jié)。頂層數(shù)據(jù)流圖應(yīng)當(dāng)把系統(tǒng)或軟件作為一個(gè)單一的功能來(lái)描述。應(yīng)當(dāng)注意原始的輸入和輸出。每個(gè)過(guò)程的每次細(xì)化一般控制在3－4個(gè)分過(guò)程。所有圓圈和箭頭應(yīng)用有意義的名稱標(biāo)注。一個(gè)名稱標(biāo)注在同一個(gè)DFD中只能出現(xiàn)一次。每次細(xì)化時(shí)，細(xì)化部分的輸入和輸出必須保持一致，即保持信息流連續(xù)性，有時(shí)稱為平衡。一次最好只對(duì)一個(gè)圓圈細(xì)化。S2132.22.12.33.13.2頂層（不編號(hào)）0層1層數(shù)據(jù)流圖的畫法P156注意事項(xiàng)P1578條數(shù)據(jù)流圖與其他流程圖的區(qū)別P159行為建模采用動(dòng)態(tài)分析方法，直觀地分析系統(tǒng)的動(dòng)作。最常用的動(dòng)態(tài)分析方法：

狀態(tài)轉(zhuǎn)換圖STDSTD通過(guò)描述狀態(tài)以及導(dǎo)致系統(tǒng)改變狀態(tài)的事件來(lái)表示系統(tǒng)的行為。狀態(tài)是任意可觀察的行為模式，一個(gè)狀態(tài)代表系統(tǒng)的一種行為模式。STD指明了系統(tǒng)如何在狀態(tài)間移動(dòng)。時(shí)序圖Petri網(wǎng)就緒t1t4t2t3等待運(yùn)行狀態(tài)事件運(yùn)行就緒等待t1t2t3t4運(yùn)行就緒就緒等待進(jìn)程的狀態(tài)遷移圖和狀態(tài)遷移表狀態(tài)轉(zhuǎn)換圖數(shù)據(jù)字典DD是對(duì)所有與系統(tǒng)相關(guān)的數(shù)據(jù)元素的一個(gè)有組織的列表，以及精確的、嚴(yán)格的定義，使得用戶和系統(tǒng)分析員對(duì)于輸入、輸出、存儲(chǔ)成分和中間計(jì)算有共同的理解。數(shù)據(jù)字典4種條目：數(shù)據(jù)流數(shù)據(jù)文件數(shù)據(jù)項(xiàng)加工

操作符含義描述

＝定義為＋與(順序結(jié)構(gòu))｛...}n重復(fù)n次(循環(huán)結(jié)構(gòu))〔..｜..〕或(選擇結(jié)構(gòu))〔..,..〕(...)任選m..n界域＊...,＊注釋符DD內(nèi)容描述符號(hào)表示數(shù)據(jù)流條目給出DFD中某個(gè)數(shù)據(jù)流的定義，通常包括：

數(shù)據(jù)流標(biāo)識(shí)數(shù)據(jù)流來(lái)源數(shù)據(jù)流去向數(shù)據(jù)流的數(shù)據(jù)組成流動(dòng)屬性描述：頻率、數(shù)據(jù)量購(gòu)書單發(fā)票領(lǐng)書單審查并開發(fā)票開領(lǐng)書單無(wú)效書單學(xué)生12各班學(xué)生用書表舉例：學(xué)生教材存量表數(shù)據(jù)流條目說(shuō)明舉例數(shù)據(jù)流名:購(gòu)書單別名:

無(wú)簡(jiǎn)述:

學(xué)生購(gòu)書時(shí)填寫的項(xiàng)目來(lái)源:

學(xué)生去向:

加工1“審查并開發(fā)票”組成:(學(xué)號(hào))＋姓名＋｛書號(hào)＋數(shù)量｝數(shù)據(jù)流量:1000次/周

高峰值：開學(xué)期間1000次/天

數(shù)據(jù)存儲(chǔ)條目(數(shù)據(jù)文件條目)對(duì)某個(gè)文件的定義，包括：

文件名描述數(shù)據(jù)結(jié)構(gòu)數(shù)據(jù)存儲(chǔ)方式關(guān)鍵碼存取頻率和數(shù)據(jù)量安全性要求數(shù)據(jù)存儲(chǔ)條目說(shuō)明舉例文件名:庫(kù)存記錄別名:無(wú)簡(jiǎn)述:存放庫(kù)存所有可供貨物的信息組成：貨物名稱＋編號(hào)＋生產(chǎn)廠家＋單價(jià)＋庫(kù)存量組織方式：索引文件，以貨物編號(hào)為關(guān)鍵字查詢要求:要求能夠立即查詢F1:航班信息文件＝{航空公司名稱＋航班號(hào)＋起點(diǎn)＋終點(diǎn)＋日期＋起飛時(shí)間＋降落時(shí)間}航空公司名稱＝2{字母}4航班號(hào)＝3{十進(jìn)制數(shù)字}3字母＝“A”…“Z”十進(jìn)制數(shù)字＝“0”…“9”起點(diǎn)＝終點(diǎn)＝1{漢字}10起飛時(shí)間＝降落時(shí)間＝時(shí)＋分時(shí)＝“00”…“23”分＝“00”…“59”日期＝年＋月＋日年＝[2000｜2001｜2002｜2004]月＝“01”…“12”日＝“01”…“31”數(shù)據(jù)項(xiàng)條目說(shuō)明舉例數(shù)據(jù)項(xiàng)名:貨物編號(hào)別名:G-No,G-num簡(jiǎn)述:本公司的所有貨物的編號(hào)類型:字符串長(zhǎng)度：11取值范圍及含義:第1位：[J｜G](進(jìn)口/國(guó)產(chǎn))第2-5位：LB01..LB29(類別)第6-8位：“A00”..“A99”(規(guī)格)第9-11位：“001”..“999”(品名編號(hào))加工條目(加工邏輯說(shuō)明)