軟件需求分析

第三章軟件需求工程

§3.1軟件需求分析

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

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

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

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

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

軟件需求的層次

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

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

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

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

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

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

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

邏輯模型物理模型

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

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

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

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

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

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

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

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

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

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

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

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

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

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

需求獲取

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

·資源使用需求

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

軟件質(zhì)量屬性

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

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

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

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

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

需求評審

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

評審指標(biāo)

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

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

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

需求管理原則

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

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

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

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

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

需求屬性

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

需求變更

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

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

·問題分析和變更描述。

這是識別和分析需求問題或者一份明確的變更提議，以檢查它的有效性，從而產(chǎn)生一個更明確的需求變更提議?！ぷ兏治龊统杀居嬎恪?/p>

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

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

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

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

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

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

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

需求變更的代價和風(fēng)險

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

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

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

需求管理的工具

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

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

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

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

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

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

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

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

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

操作符含義描述

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

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

無簡述:

學(xué)生購書時填寫的項目來源:

學(xué)生去向:

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

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

數(shù)據(jù)存儲條目(數(shù)據(jù)文件條目)對某個文件的定義，包括：

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