需求工程與需求分析課件

第3章需求工程與需求分析1第3章需求工程與需求分析13.1基本的軟件需求22基本的軟件需求軟件項(xiàng)目中百分之四十至百分之六十的問題都是在需求分析階段埋下的“禍根”。可許多組織仍在那些基本的項(xiàng)目功能上采用一些不合規(guī)范的方法，這樣導(dǎo)致的后果便是一條鴻溝（期望差異）—開發(fā)者開發(fā)的與用戶所想得到的軟件存在著巨大期望差異。3基本的軟件需求軟件項(xiàng)目中百分之四十至百分之六十的問題基本的軟件需求在軟件工程中，所有的風(fēng)險(xiǎn)承擔(dān)者(stakeholder)都感興趣的就是需求分析階段。這些風(fēng)險(xiǎn)承擔(dān)者包括客戶、用戶、業(yè)務(wù)或需求分析員(負(fù)責(zé)收集客戶需求并編寫文檔，以及負(fù)責(zé)客戶與開發(fā)機(jī)構(gòu)之間聯(lián)系溝通的人)、開發(fā)人員、測試人員、用戶文檔編寫者、項(xiàng)目管理者和客戶管理者。這部分工作若處理好了，能開發(fā)出很出色的產(chǎn)品，同時(shí)會(huì)使客戶感到滿意，開發(fā)者也倍感滿足、充實(shí)。若處理不好，則會(huì)導(dǎo)致誤解、挫折、障礙以及潛在質(zhì)量和業(yè)務(wù)價(jià)值上的威脅。因?yàn)樾枨蠓治龅於塑浖こ毯晚?xiàng)目管理的基礎(chǔ)。4基本的軟件需求在軟件工程中，所有的風(fēng)險(xiǎn)承擔(dān)者(st3.1.1軟件需求的定義⑴用戶解決問題或達(dá)到目標(biāo)所需的條件或權(quán)能（Capability）。⑵系統(tǒng)或系統(tǒng)部件要滿足合同、標(biāo)準(zhǔn)、規(guī)范或其它正式規(guī)定文檔所需具有的條件或權(quán)能。⑶一種反映上面⑴或⑵所描述的條件或權(quán)能的文檔說明。53.1.1軟件需求的定義⑴用戶解決問題或達(dá)到目標(biāo)所3.1.1軟件需求的定義1.一些關(guān)于“需求”的解釋需求的關(guān)鍵的問題是一定要編寫需求文檔。如果只有一堆郵件、貼條、會(huì)談過幾次或一些零碎的對(duì)話，你就確信你已明白用戶的需求，那完全是自欺欺人。

許多的需求分析專家給出了不同形式的需求定義，但從這些不同形式的定義不難發(fā)現(xiàn)：并沒有一個(gè)清晰、毫無二義性的“需求”術(shù)語存在，真正的“需求”實(shí)際上在人們的腦海中。任何文檔形式的需求（例如：需求規(guī)格說明）僅是一個(gè)模型，一種敘述（Lawrence1998）。我們需要確保所有項(xiàng)目風(fēng)險(xiǎn)承擔(dān)者在描述需求的那些名詞的理解上務(wù)必達(dá)成共識(shí)。63.1.1軟件需求的定義1.一些關(guān)于“需求”的解釋63.1.1軟件需求的定義2．需求的層次

下面這些定義是需求工程領(lǐng)域中常見術(shù)語的定義說明。軟件需求包括三個(gè)不同的層次——業(yè)務(wù)需求、用戶需求和功能需求（包括非功能需求）。⑴業(yè)務(wù)需求（businessrequirement）反映了組織機(jī)構(gòu)或客戶對(duì)系統(tǒng)、產(chǎn)品高層次的目標(biāo)要求，它們?cè)陧?xiàng)目視圖與范圍文檔中予以說明。⑵用戶需求（userrequirement）文檔描述了用戶使用產(chǎn)品必須要完成的任務(wù)，這在使用實(shí)例（usecase）文檔或方案腳本（scenario）說明中予以說明。⑶功能需求(functionalrequirement)定義了開發(fā)人員必須實(shí)現(xiàn)的軟件功能，使得用戶能完成他們的任務(wù)，從而滿足了業(yè)務(wù)需求。所謂特性（feature）是指邏輯上相關(guān)的功能需求的集合，給用戶提供處理能力并滿足業(yè)務(wù)需求。73.1.1軟件需求的定義2．需求的層次73.1.1軟件需求的定義83.1.1軟件需求的定義83.1.2需求的開發(fā)和管理需求中名詞術(shù)語的混淆將導(dǎo)致對(duì)科目（規(guī)范，discipline）叫法的不一致。一些作者把整個(gè)需求范圍稱之為“需求工程”，另一些則稱之為“需求管理”。軟件專家認(rèn)為可把整個(gè)軟件需求工程研究領(lǐng)域劃分為需求開發(fā)和需求管理兩部分更合適：93.1.2需求的開發(fā)和管理需求中名詞術(shù)語的混淆將導(dǎo)3.1.2需求的開發(fā)和管理需求開發(fā)可進(jìn)一步分為：需求獲取(elicitation)、分析(analysis)、編寫規(guī)格說明(specification)和驗(yàn)證(verification)四個(gè)階段。需求開發(fā)活動(dòng)包括以下幾個(gè)方面：⑴確定產(chǎn)品所期望的用戶類。⑵獲取每個(gè)用戶類的需求。⑶了解實(shí)際用戶任務(wù)和目標(biāo)以及這些任務(wù)所支持的業(yè)務(wù)需求。⑷分析源于用戶的信息以區(qū)別用戶任務(wù)需求、功能需求、業(yè)務(wù)規(guī)則、質(zhì)量屬性、建議解決方法和附加信息。103.1.2需求的開發(fā)和管理需求開發(fā)可進(jìn)一步分為：需3.1.2需求的開發(fā)和管理⑸將系統(tǒng)級(jí)的需求分為幾個(gè)子系統(tǒng)，并將需求中的一部份分配給軟件組件。⑹了解相關(guān)質(zhì)量屬性的重要性。⑺商討實(shí)施優(yōu)先級(jí)的劃分。⑻將所收集的用戶需求編寫成規(guī)格說明和模型。⑼評(píng)審需求規(guī)格說明，確保對(duì)用戶需求達(dá)到共同的理解與認(rèn)識(shí)，并在整個(gè)開發(fā)小組接受說明之前將問題都弄清楚。113.1.2需求的開發(fā)和管理⑸將系統(tǒng)級(jí)的需求分為幾個(gè)3.1.2需求的開發(fā)和管理需求管理需要“建立并維護(hù)在軟件工程中同客戶達(dá)成的契約”(CMU/SEI1995)。這種契約都包含在編寫的需求規(guī)格說明與模型中。通常的需求管理活動(dòng)包括：⑴定義需求基線（迅速制定需求文檔的主體）。⑵評(píng)審提出的需求變更、評(píng)估每項(xiàng)變更的可能影響從而決定是否實(shí)施它。⑶以一種可控制的方式將需求變更融入到項(xiàng)目中。⑷使當(dāng)前的項(xiàng)目計(jì)劃與需求一致。⑸估計(jì)變更需求所產(chǎn)生影響并在此基礎(chǔ)上協(xié)商新的承諾(約定)。⑹讓每項(xiàng)需求都能與其對(duì)應(yīng)的設(shè)計(jì)、源代碼和測試用例聯(lián)系起來以實(shí)現(xiàn)跟蹤。⑺在整個(gè)項(xiàng)目過程中跟蹤需求狀態(tài)及其變更情況。123.1.2需求的開發(fā)和管理需求管理需要“建立并維3.1.2需求的開發(fā)和管理需求開發(fā)和需求管理之間的區(qū)別133.1.2需求的開發(fā)和管理需求開發(fā)和需求管理之間的區(qū)別133.1.3需求工程的作用1．支持項(xiàng)目的開發(fā)。

需求工程過程是軟件開發(fā)階段的前提和基礎(chǔ)。2．支持測試和驗(yàn)證

需求規(guī)格說明書將為項(xiàng)目測試和驗(yàn)證提供基準(zhǔn)，可以用來檢查設(shè)計(jì)和驗(yàn)證系統(tǒng)。3．支持維護(hù)

維護(hù)階段的工作同以下幾個(gè)方面緊密聯(lián)系：⑴修改在測試階段中尚未檢查出來的少量殘留編碼錯(cuò)誤。⑵軟件運(yùn)行一段時(shí)間后，因環(huán)境因素的改變而產(chǎn)生的軟件的適應(yīng)性維護(hù)。⑶用戶在軟件交付使用后又重新提出擴(kuò)充功能的需求時(shí)的軟件維護(hù)。4．支持項(xiàng)目承包商需求的證實(shí)過程為擬構(gòu)造系統(tǒng)的正確性提供了進(jìn)一步的根據(jù)。5．支持管理為了保證項(xiàng)目的順利進(jìn)行，項(xiàng)目管理者必須有一個(gè)完備的項(xiàng)目計(jì)劃，包括開銷、交付日期、可用資源、交付條件等等。143.1.3需求工程的作用1．支持項(xiàng)目的開發(fā)。143.2需求獲取15153.2.1需求獲取過程需求獲取時(shí)期的主要工作：⑴歸納和整理用戶提出的各種問題和要求；⑵弄清用戶企圖通過軟件達(dá)到的目的；⑶借助各種工具和方法，陳述用戶提出的實(shí)際需求，并標(biāo)定軟件的作用范圍。163.2.1需求獲取過程需求獲取時(shí)期的主要工作：163.2.2需求獲取方法需求獲取方法包括兩個(gè)方面：⑴指導(dǎo)開發(fā)小組獲取用戶需求的方法框架。⑵支持控制此項(xiàng)活動(dòng)進(jìn)展的過程控制機(jī)制。173.2.2需求獲取方法需求獲取方法包括兩個(gè)方面：173.2.3當(dāng)前狀況⑴誤解：由于分析員并非該應(yīng)用領(lǐng)域的專家，使得在需求獲取時(shí)，誤解了用戶潛在的隱含假設(shè)。⑵交流障礙：領(lǐng)域?qū)＜彝粋€(gè)新手交談時(shí)的用詞往往并不足以解決問題。⑶缺乏共同語言：由于需求分析員和系統(tǒng)用戶的經(jīng)歷和教育背景不同，他們之間通常缺乏足夠的溝通。⑷“完整性”問題：軟件工程師希望提出系統(tǒng)需求的用戶領(lǐng)域?qū)＜夷芮逦⒑喢骱屯陚涞孛枋龀龃_實(shí)可行的系統(tǒng)需求，然而，所要的需求知識(shí)在其最初階段可能是模糊、不完備甚至是不正確的。⑸需求永遠(yuǎn)不會(huì)穩(wěn)定：用戶對(duì)軟件的需求常常會(huì)發(fā)生變化，并且是不可預(yù)測的。⑹用戶意見不統(tǒng)一：大系統(tǒng)往往有各種不同的用戶，他們往往有互相沖突的需求和不同的需求優(yōu)先次序，尋求折衷是不容易的。⑺錯(cuò)誤的要求：系統(tǒng)的定購者（付錢的人）和系統(tǒng)的使用者經(jīng)常不是一個(gè)人，定購者由于受到組織或經(jīng)費(fèi)的限制，提出的需求會(huì)與最終用戶的需求相沖突。⑻認(rèn)識(shí)混淆：有時(shí)系統(tǒng)的目標(biāo)和系統(tǒng)的需求會(huì)發(fā)生混淆。目標(biāo)是系統(tǒng)應(yīng)達(dá)到的更為一般的特征，而需求應(yīng)是可測試的。183.2.3當(dāng)前狀況⑴誤解：由于分析員并非該應(yīng)用領(lǐng)域解決問題的建議1.了解系統(tǒng)需求2.市場調(diào)查3.訪問用戶和用戶領(lǐng)域?qū)＜?.考察現(xiàn)場19解決問題的建議1.了解系統(tǒng)需求19調(diào)查的方式1.調(diào)查提綱或調(diào)查表2.小型調(diào)查會(huì)議3.個(gè)別訪問4.現(xiàn)場調(diào)查5.資料6.調(diào)查工具20調(diào)查的方式1.調(diào)查提綱或調(diào)查表20調(diào)查中應(yīng)注意的事項(xiàng)1.不要用計(jì)算機(jī)專業(yè)術(shù)語與用戶或用戶領(lǐng)域?qū)＜医徽?.不要使用“你應(yīng)該…”這樣的字眼3.始終記住自己最近一段工作中要達(dá)到的目標(biāo)，引導(dǎo)用戶說出你需要的信息4.要善于把用戶中職位高的人和職位低的人的談話結(jié)合起來分析21調(diào)查中應(yīng)注意的事項(xiàng)1.不要用計(jì)算機(jī)專業(yè)術(shù)語與用戶或用戶3.3需求分析任務(wù)22223.3需求分析任務(wù)需求分析所要做的工作是深入描述軟件的功能和性能，確定軟件設(shè)計(jì)的限制和軟件同其它系統(tǒng)元素的接口細(xì)節(jié)，定義軟件的其它有效性需求。分析員通過需求分析，逐步細(xì)化對(duì)軟件的要求，描述軟件要處理的數(shù)據(jù)域，并給軟件開發(fā)提供一種可轉(zhuǎn)化為數(shù)據(jù)設(shè)計(jì)、結(jié)構(gòu)設(shè)計(jì)和過程設(shè)計(jì)的數(shù)據(jù)和功能表示。在軟件完成后，制定的軟件規(guī)格說明還要為評(píng)價(jià)軟件質(zhì)量提供依據(jù)。233.3需求分析任務(wù)需求分析所要做的工作是深入描述3.3需求分析任務(wù)⑴正確地確定對(duì)系統(tǒng)綜合要求，充分理解和表達(dá)用戶的需求。也就是詳細(xì)定義開發(fā)軟件的功能、性能、外部接口、設(shè)計(jì)限制、數(shù)據(jù)庫需求、確定硬件和軟件支持環(huán)境、輔助軟件以及將來可能提出的要求。⑵通過結(jié)構(gòu)分析的方法對(duì)系統(tǒng)進(jìn)行分解，以確定軟件系統(tǒng)的主要成分或軟件系統(tǒng)的構(gòu)成。243.3需求分析任務(wù)⑴正確地確定對(duì)系統(tǒng)綜合要求，充分3.3需求分析任務(wù)⑶是對(duì)以上已進(jìn)行的兩項(xiàng)工作進(jìn)行描述，以形成需求文檔，也就是編制“需求規(guī)格說明書”。它應(yīng)明確地定義要開發(fā)軟件的需求；系統(tǒng)的構(gòu)成及有關(guān)接口。

需求規(guī)格說明書的作用在于：①提供一個(gè)用戶和開發(fā)者對(duì)開發(fā)軟件的共同的理解；②相當(dāng)于用戶和開發(fā)單位之間的一份技術(shù)合同；③是今后各階段設(shè)計(jì)的基本依據(jù)；④是今后驗(yàn)收測試階段對(duì)軟件進(jìn)行確認(rèn)和驗(yàn)收的基準(zhǔn)。253.3需求分析任務(wù)⑶是對(duì)以上已進(jìn)行的兩項(xiàng)工作進(jìn)行描3.3需求分析任務(wù)⑷編寫用戶手冊(cè)概要，迫使分析員從用戶的角度看待軟件，及早考慮用戶界面工作，此時(shí)編寫的重點(diǎn)在系統(tǒng)輸入和輸出。把整個(gè)軟件系統(tǒng)分解為若干個(gè)子系統(tǒng)或軟件成分(如軟件包)，把整個(gè)軟件的外部功能分配給軟件系統(tǒng)的各功能成分，并詳細(xì)地定義每個(gè)軟件成分的外部功能以及它們間的接口。⑸編寫驗(yàn)收計(jì)劃，作為今后驗(yàn)收測試的依據(jù)。⑹修正可行性研究階段所制訂的軟件項(xiàng)目開發(fā)計(jì)劃。由于在需求分析過程中對(duì)將要開發(fā)的系統(tǒng)有了更深入的了解，所以可以更準(zhǔn)確地估計(jì)開發(fā)成本、進(jìn)度和資源需求。有必要對(duì)原計(jì)劃作出適當(dāng)修正。263.3需求分析任務(wù)⑷編寫用戶手冊(cè)概要，迫使分析員3.4需求分析過程27273.4.1功能性需求功能性需求包括：1．功能需求例舉出開發(fā)軟件在職能上應(yīng)做什么，這是最主要的需求。2．性能需求給出所開發(fā)軟件的技術(shù)性能指標(biāo)，包括存儲(chǔ)容量限制、運(yùn)行時(shí)間限制、安全保密性等。3．環(huán)境需求軟件系統(tǒng)運(yùn)行時(shí)多所處的環(huán)境要求。4．可靠性需求各種軟件在運(yùn)行時(shí)，失敗的影響各不相同，在需求分析時(shí)，應(yīng)對(duì)所開發(fā)的軟件在投入運(yùn)行后不發(fā)生故障的概率，按實(shí)際的運(yùn)行環(huán)境提出的要求。283.4.1功能性需求功能性需求包括：283.4.1功能性需求5．安全保密要求把軟件運(yùn)行的安全需求恰當(dāng)?shù)刈龀鲆?guī)定，以便對(duì)所開發(fā)的軟件給予特殊的設(shè)計(jì)，使其在運(yùn)行中其安全保密方面的性能得到必要的保證。6．用戶界面需求軟件與用戶界面的友好性是用戶能夠方便有效、愉快地使用該軟件的關(guān)鍵之一。7．資源使用需求開發(fā)軟件運(yùn)行時(shí)所需的數(shù)據(jù)、軟件、內(nèi)存空間等各項(xiàng)資源。8．軟件成本消耗與開發(fā)進(jìn)度需求軟件項(xiàng)目立項(xiàng)后，要根據(jù)合同規(guī)定，對(duì)軟件開發(fā)的進(jìn)度和各項(xiàng)步驟的費(fèi)用提出要求，作為開發(fā)管理的依據(jù)。9．預(yù)先估計(jì)系統(tǒng)可能達(dá)到的目標(biāo)在開發(fā)過程中可對(duì)系統(tǒng)將來可能的擴(kuò)充與修改做準(zhǔn)備。293.4.1功能性需求5．安全保密要求29【例1】假設(shè)需要制造一個(gè)帶有四個(gè)按鈕和兩個(gè)燈泡的盒子并具有以下功能：⑴有四個(gè)按鈕輸入，分別稱為B1，B2，B3和B4；⑵有兩個(gè)燈泡作為輸出，分別稱為L1和L2；⑶B1是打開電源的按鈕；⑷B4是關(guān)閉電源的按鈕；⑸B2和B3是操作按鈕；⑹在B1被按下后及B4被按下前，系統(tǒng)應(yīng)稱為電源打開狀態(tài)；⑺在B4被按下后及B1被按下前，系統(tǒng)應(yīng)稱為電源關(guān)閉狀態(tài)；⑻在電源關(guān)閉狀態(tài)下，B2和B3按鈕不起作用；⑼在電源關(guān)閉狀態(tài)下，燈應(yīng)不亮；⑽從最近一次電源打開狀態(tài)算起，如果B2被按下的次數(shù)比B3被按下的次數(shù)多，L1亮，否則L2亮。⑾任何時(shí)候都不能有一個(gè)以上的燈泡亮；⑿如果其中的一個(gè)燈泡出現(xiàn)故障，另一個(gè)燈泡應(yīng)以2秒鐘的間隔閃爍，而不管B2和B3的操作過程。當(dāng)B4按下時(shí)，閃爍停止；當(dāng)B1被按下時(shí)，閃爍重新開始。當(dāng)故障被排除后閃爍停止，系統(tǒng)恢復(fù)正常狀態(tài)。30【例1】假設(shè)需要制造一個(gè)帶有四個(gè)按鈕和兩個(gè)燈泡的盒子并具有以疑問？1.對(duì)于在燈泡出現(xiàn)故障時(shí)是否要記錄下B2和B3的操作過程2.系統(tǒng)記錄或不記錄B2和B3的操作，對(duì)于故障排除后系統(tǒng)的反應(yīng)如何31疑問？1.對(duì)于在燈泡出現(xiàn)故障時(shí)是否要記錄下B2和B3的3.4.2非功能性需求非功能性需求即為軟件的“約束”:非功能性需求過程需求產(chǎn)品需求外部需求交付需求實(shí)現(xiàn)方法需求標(biāo)準(zhǔn)需求可用性需求效用需求可靠性需求可移植性需求可重復(fù)需求安全保密性需求…性能需求應(yīng)用需求法規(guī)需求費(fèi)用需求互操作需求323.4.2非功能性需求非功能性需求即為軟件的“約束3.4.3需求分析文檔1．需求規(guī)格說明書的作用

⑴為用戶、分析人員和軟件設(shè)計(jì)人員之間的理解和交流提供了方便；⑵支持目標(biāo)軟件系統(tǒng)的確認(rèn)；⑶起到控制系統(tǒng)演進(jìn)的作用。

2．什么樣人閱讀需求規(guī)格說明書

必須閱讀需求規(guī)格說明書的是各種背景和技術(shù)能力都不同的人：客戶和使用者，分析人，設(shè)計(jì)師和工程師，項(xiàng)目管理者等。333.4.3需求分析文檔1．需求規(guī)格說明書的作用333.4.3需求分析文檔3．需求規(guī)格說明書編寫分類⑴按方法分類：形式化方法和非形式化方法非形式化的需求規(guī)格說明書是用自然語言寫的，可以用圖表和其他符號(hào)幫助理解，也可以用標(biāo)準(zhǔn)化的格式來編制。形式化的需求規(guī)格說明書是用完全精確的語法和語義來表達(dá)。半形式化的需求規(guī)格說明書也很有用。它采用了一些符號(hào)，但對(duì)這些符號(hào)并沒有給予精確的定義。⑵按文檔內(nèi)容的性質(zhì)分類：操作性和說明性操作性的需求規(guī)格說明書通過說明所要求的行為來描述要求哪種系統(tǒng)，通常提供一個(gè)系統(tǒng)模型作為模擬系統(tǒng)行為的抽象裝置。說明性的需求規(guī)格說明書用純粹的說明方式來描述系統(tǒng)的特性。343.4.3需求分析文檔3．需求規(guī)格說明書編寫分類343.4.3需求分析文檔4．需求規(guī)格說明書主要內(nèi)容：⑴概述。從系統(tǒng)的角度描述軟件的目標(biāo)和任務(wù)。⑵數(shù)據(jù)描述①數(shù)據(jù)流圖②數(shù)據(jù)字典③系統(tǒng)接口說明④內(nèi)部接口說明⑶功能描述①功能②處理③設(shè)計(jì)的限制353.4.3需求分析文檔4．需求規(guī)格說明書主要內(nèi)容：33.4.3需求分析文檔⑷性能描述①性能指標(biāo)②測試種類③預(yù)期的軟件響應(yīng)性能④其它⑸參考文獻(xiàn)目錄⑹附錄363.4.3需求分析文檔⑷性能描述363.5驗(yàn)證37373.5.1需求說明的特征1.完整性每一項(xiàng)需求都必須將所要實(shí)現(xiàn)的功能描述清楚，以使開發(fā)人員獲得設(shè)計(jì)和實(shí)現(xiàn)這些功能所需的所有必要信息。2.正確性每一項(xiàng)需求都必須準(zhǔn)確地陳述其要開發(fā)的功能。做出正確判斷的參考是需求的來源，如用戶或高層的系統(tǒng)需求規(guī)格說明。若軟件需求與對(duì)應(yīng)的系統(tǒng)需求相抵觸則是不正確的。只有用戶代表才能確定用戶需求的正確性，這就是一定要有用戶的積極參與的原因。沒有用戶參與的需求評(píng)審將導(dǎo)致此類說法：“那些毫無意義，這些才很可能是他們所要想的?！逼鋵?shí)這完全是評(píng)審者憑空猜測。383.5.1需求說明的特征1.完整性383.5.1需求說明的特征3.可行性每一項(xiàng)需求都必須是在已知系統(tǒng)和環(huán)境的權(quán)能和限制范圍內(nèi)可以實(shí)施的。為避免不可行的需求，最好在獲?。╡licitation）需求(收集需求)過程中始終有一位軟件工程小組的組員與需求分析人員或考慮市場的人員在一起工作，由他負(fù)責(zé)檢查技術(shù)可行性。4.必要性每一項(xiàng)需求都應(yīng)把客戶真正所需要的和最終系統(tǒng)所需遵從的標(biāo)準(zhǔn)記錄下來?！氨匾浴币部梢岳斫鉃槊宽?xiàng)需求都是用來授權(quán)你編寫文檔的“根源”。要使每項(xiàng)需求都能回溯至某項(xiàng)客戶的輸入，如使用實(shí)例或別的來源。393.5.1需求說明的特征3.可行性393.5.1需求說明的特征5.可修改性在必要時(shí)或?yàn)榫S護(hù)每一需求變更歷史記錄時(shí)，應(yīng)該修訂SRS。這就要求每項(xiàng)需求要獨(dú)立標(biāo)出，并與別的需求區(qū)別開來，從而無二義性。每項(xiàng)需求只應(yīng)在SRS中出現(xiàn)一次。這樣更改時(shí)易于保持一致性。另外，使用目錄表、索引和相互參照列表方法將使軟件需求規(guī)格說明更容易修改。6.可跟蹤性應(yīng)能在每項(xiàng)軟件需求與它的根源和設(shè)計(jì)元素、源代碼、測試用例之間建立起鏈接鏈，這種可跟蹤性要求每項(xiàng)需求以一種結(jié)構(gòu)化的，粒度好（fine-grained）的方式編寫并單獨(dú)標(biāo)明，而不是大段大段的敘述。403.5.1需求說明的特征5.可修改性403.5.1需求說明的特征7.劃分優(yōu)先級(jí)給每項(xiàng)需求、特性或使用實(shí)例分配一個(gè)實(shí)施優(yōu)先級(jí)以指明它在特定產(chǎn)品中所占的分量。如果把所有的需求都看作同樣重要，那么項(xiàng)目管理者在開發(fā)或節(jié)省預(yù)算或調(diào)度中就喪失控制自由度。8.無二義性對(duì)所有需求說明的讀者都只能有一個(gè)明確統(tǒng)一的解釋，由于自然語言極易導(dǎo)致二義性，所以盡量把每項(xiàng)需求用簡潔明了的用戶性的語言表達(dá)出來。避免二義性的有效方法包括對(duì)需求文檔的正規(guī)審查，編寫測試用例，開發(fā)原型以及設(shè)計(jì)特定的方案腳本。9.可驗(yàn)證性檢查一下每項(xiàng)需求是否能通過設(shè)計(jì)測試用例或其它的驗(yàn)證方法，如用演示、檢測等來確定產(chǎn)品是否確實(shí)按需求實(shí)現(xiàn)了。如果需求不可驗(yàn)證，則確定其實(shí)施是否正確就成為主觀臆斷，而非客觀分析了。一份前后矛盾，不可行或有二義性的需求也是不可驗(yàn)證的。413.5.1需求說明的特征7.劃分優(yōu)先級(jí)413.6軟件原型系統(tǒng)開發(fā)4242傳統(tǒng)模型的工作特點(diǎn)傳統(tǒng)軟件生存期模型的典型代表是“瀑布模型”。這種模型將軟件生存期劃分為若干階段，根據(jù)不同階段的工作特點(diǎn)，運(yùn)用不同的方法、技術(shù)和工具來完成該階段的任務(wù)。傳統(tǒng)思想之所以強(qiáng)調(diào)每一階段的嚴(yán)格性，尤其是開發(fā)初期要有良好的軟件說明，主要是源于過去軟件開發(fā)的經(jīng)驗(yàn)教訓(xùn)，即在開發(fā)的后期或運(yùn)行維護(hù)期間，修改不完善的規(guī)格說明要付出巨大的代價(jià)。43傳統(tǒng)模型的工作特點(diǎn)傳統(tǒng)軟件生存期模型的典型代表是“瀑什么是原型系統(tǒng)開發(fā)建立系統(tǒng)模型以后，還要進(jìn)行檢查。除了靜態(tài)檢查外，系統(tǒng)描述可以部分地模擬執(zhí)行，將執(zhí)行情況與對(duì)外部現(xiàn)實(shí)世界系統(tǒng)觀察得到的系統(tǒng)跟蹤信息進(jìn)行對(duì)照，檢查模型是否符合要求。這種建立系統(tǒng)模型并模擬執(zhí)行和檢查的辦法叫做系統(tǒng)原型開發(fā)。44什么是原型系統(tǒng)開發(fā)建立系統(tǒng)模型以后，還要進(jìn)行檢查。除了軟件系統(tǒng)的快速原型的概念的形成在實(shí)際工作中，特別是對(duì)于一些大型的軟件項(xiàng)目，在開發(fā)的早期用戶往往對(duì)系統(tǒng)只有一個(gè)模糊的想法，很難完全準(zhǔn)確地表達(dá)對(duì)系統(tǒng)的全面要求，軟件人員對(duì)于要解決的應(yīng)用問題認(rèn)識(shí)更是模糊不清。隨著開發(fā)工作向前推進(jìn)，用戶可能產(chǎn)生新的要求，或因環(huán)境變化，要求系統(tǒng)也隨之變化；開發(fā)者又可能在設(shè)計(jì)與實(shí)現(xiàn)的過程中遇到一些沒有預(yù)料到的困難，需要以改變需求來解脫困境。45軟件系統(tǒng)的快速原型的概念的形成在實(shí)際工作中，特別是對(duì)3.6.1軟件原型化方法概述通常，原型是指模擬某種產(chǎn)品的原始模型。在軟件開發(fā)過程中，原型是軟件一個(gè)早期可運(yùn)行的版本，它反映最終系統(tǒng)的部分重要特性。系統(tǒng)原型是軟件系統(tǒng)的初始版本，它可用來展示一些概念，給出設(shè)計(jì)選擇、發(fā)現(xiàn)問題和可能的解決方案。其目的就是為了有效的控制開發(fā)成本，使開發(fā)人員可以較早地在原型系統(tǒng)上驗(yàn)證自己的設(shè)計(jì)。463.6.1軟件原型化方法概述通常，原型是指模擬某軟件原型支持需求工程過程的活動(dòng)1.需求的導(dǎo)出系統(tǒng)原型允許用戶在上面實(shí)驗(yàn)，以便了解系統(tǒng)如何支持他們的工作的。在這個(gè)過程中，用戶可能產(chǎn)生有關(guān)需求的許多新的想法，同時(shí)發(fā)現(xiàn)系統(tǒng)的優(yōu)點(diǎn)和不足，進(jìn)而提出新的系統(tǒng)需求。2.需求的有效性驗(yàn)證原型系統(tǒng)可以暴露出錯(cuò)誤和遺漏的東西。一個(gè)經(jīng)過描述的功能可能是很有用且已經(jīng)是定義了的，但是，當(dāng)這個(gè)功能模塊與其他模塊一起工作時(shí)，用戶可能發(fā)現(xiàn)他們最初的想法是錯(cuò)誤的或是不完善的，必須修改系統(tǒng)描述以反映對(duì)需求的新的理解。47軟件原型支持需求工程過程的活動(dòng)1.需求的導(dǎo)出47系統(tǒng)原型開發(fā)的優(yōu)點(diǎn)1.開發(fā)人員和用戶之間的理解偏差在功能展示顯露出來。2.開發(fā)小組可能會(huì)在原型設(shè)計(jì)中發(fā)現(xiàn)需求的不完善和不一致。3.可以迅速展示一個(gè)應(yīng)用系統(tǒng)對(duì)管理的可行性和作用。4.原型可以用作書寫產(chǎn)量-質(zhì)量系統(tǒng)描述的基礎(chǔ)。5.原型可支持用戶的訓(xùn)練和系統(tǒng)的測試。48系統(tǒng)原型開發(fā)的優(yōu)點(diǎn)1.開發(fā)人員和用戶之間的理解偏差在功能展原型開發(fā)的過程模型49原型開發(fā)的過程模型49研究發(fā)現(xiàn)系統(tǒng)原型開發(fā)的其它優(yōu)點(diǎn)Gordon和Bieman經(jīng)過研究發(fā)現(xiàn)，在軟件過程中使用原型還具有如下的優(yōu)點(diǎn)：1.提高了系統(tǒng)的實(shí)用性。2.使系統(tǒng)與用戶需求更貼近。3.提高了系統(tǒng)的設(shè)計(jì)質(zhì)量。4.提高了系統(tǒng)的可維護(hù)性。5.減少了開發(fā)的投入。研究發(fā)現(xiàn)，用原型法來提高系統(tǒng)的實(shí)用性和更好地滿足用戶需求并不一定意味著開發(fā)成本提高。50研究發(fā)現(xiàn)系統(tǒng)原型開發(fā)的其它優(yōu)點(diǎn)Gordon和Biem3.6.2軟件過程中的原型開發(fā)原型開發(fā)的種類有兩種：1.進(jìn)化式原型采用進(jìn)化式的系統(tǒng)開發(fā)方法，就是在系統(tǒng)尚未完善的時(shí)候就呈現(xiàn)給用戶，邊修改邊完善，在完善過程中逐漸地把需求弄明白。2.拋棄式原型采用原型開發(fā)方法進(jìn)行需求分析和有效性驗(yàn)證，評(píng)估一結(jié)束，就拋棄掉原型，重建一個(gè)完整的系統(tǒng)。513.6.2軟件過程中的原型開發(fā)原型開發(fā)的種類有兩兩點(diǎn)重要區(qū)別1.進(jìn)化式原型的目標(biāo)是給用戶一個(gè)實(shí)用的系統(tǒng)。原型開發(fā)必須從對(duì)用戶需求把握最準(zhǔn)的部分做起，最優(yōu)處理這部分。而對(duì)用戶需求把握程度較差的部分和模糊的需求安排得稍后一些，可以在用戶明確要求后再處理。2.拋棄式原型開發(fā)的目標(biāo)是驗(yàn)證和導(dǎo)出需求。此時(shí)應(yīng)從理解得不夠好的那部分需求開始實(shí)現(xiàn)，因?yàn)橐獜哪繕?biāo)中發(fā)現(xiàn)問題，對(duì)明確的需求就沒必要去做原型。52兩點(diǎn)重要區(qū)別1.進(jìn)化式原型的目標(biāo)是給用戶一個(gè)實(shí)用的系統(tǒng)。原進(jìn)化式原型開發(fā)進(jìn)化式原型開發(fā)的思路是：先給出一個(gè)系統(tǒng)的最初實(shí)現(xiàn)，讓用戶去使用和評(píng)論，再不斷進(jìn)行細(xì)化和完善，經(jīng)過多個(gè)這樣的反復(fù)過程后形成最后完善的應(yīng)用系統(tǒng)。進(jìn)化式開發(fā)已經(jīng)成為快速應(yīng)用開發(fā)(RAD)和聯(lián)合應(yīng)用開發(fā)(JAD)技術(shù)中的一部分,已成為一個(gè)軟件開發(fā)的主流技術(shù)。53進(jìn)化式原型開發(fā)進(jìn)化式原型開發(fā)的思路是：先給出一個(gè)系統(tǒng)進(jìn)化式原型開發(fā)54進(jìn)化式原型開發(fā)54進(jìn)化式原型開發(fā)方法的優(yōu)勢1.加快系統(tǒng)交付的進(jìn)度現(xiàn)在的商業(yè)節(jié)奏加快意味著軟件支持能否快速到位是最根本的。在某些情況下，快速交貨就比提供完備功能或保證長期可維護(hù)性更為重要。2.用戶的參與用戶在軟件開發(fā)過程中的介入不僅僅意味著系統(tǒng)可以更好地理解軟件需求，還意味著可以使用戶逐漸喜歡系統(tǒng)，在工作中依賴它。55進(jìn)化式原型開發(fā)方法的優(yōu)勢1.加快系統(tǒng)交付的進(jìn)度55進(jìn)化式原型開法與快速開發(fā)方法的共同基本性質(zhì)1.描述、設(shè)計(jì)和實(shí)現(xiàn)三個(gè)過程是交叉進(jìn)行的，沒有詳細(xì)的系統(tǒng)描述，設(shè)計(jì)文檔一般都依賴于開發(fā)系統(tǒng)所使用的工具，用戶需求文檔只描述系統(tǒng)的最重要的特征。2.系統(tǒng)是逐漸增進(jìn)的。在每一次增進(jìn)過程中，最終用戶和其他系統(tǒng)項(xiàng)目的相關(guān)人員都參與到設(shè)計(jì)和評(píng)估中來。他們可能提出對(duì)系統(tǒng)改進(jìn)的意見。新的需求又會(huì)在隨后的版本中被實(shí)現(xiàn)。3.采用了快速開發(fā)技術(shù)。4.系統(tǒng)用戶界面都是交互式開發(fā)系統(tǒng)來實(shí)現(xiàn)的。56進(jìn)化式原型開法與快速開發(fā)方法的共同基本性質(zhì)1.描述、設(shè)計(jì)和進(jìn)化式原型開發(fā)方法應(yīng)注意的問題1.管理問題大型系統(tǒng)軟件管理機(jī)構(gòu)建立起來以處理軟件過程模型。軟件過程模型定期產(chǎn)生可交付的文檔來評(píng)估項(xiàng)目進(jìn)展的情況。原型的開發(fā)太快，以致產(chǎn)生大量的系統(tǒng)文檔。專業(yè)技術(shù)技能不可能應(yīng)用到每個(gè)開發(fā)的團(tuán)隊(duì)。2.維護(hù)問題連續(xù)不斷地對(duì)原型的修改很可能導(dǎo)致系統(tǒng)的崩潰。如果快速原型開發(fā)中使用了某項(xiàng)專門的技術(shù)，有可能在以后尋找具有相關(guān)知識(shí)的人來維護(hù)系統(tǒng)變得十分困難。3.契約問題客戶和軟件開發(fā)商之間正規(guī)的契約模型是基于系統(tǒng)描述的。57進(jìn)化式原型開發(fā)方法應(yīng)注意的問題1.管理問題57增量開發(fā)方法該開發(fā)方法避免了進(jìn)化式原型開發(fā)中的經(jīng)常性變更問題。即首先建立一個(gè)總的框架，以后就以該框架結(jié)構(gòu)為基礎(chǔ)進(jìn)行開發(fā)。在增量開發(fā)方法中，必須給出每一部分的需求和文檔。使得用戶的意見能及時(shí)地反饋，以減少錯(cuò)誤的出現(xiàn)。58增量開發(fā)方法該開發(fā)方法避免了進(jìn)化式原型開發(fā)中的經(jīng)常性變?cè)隽块_發(fā)方法59增量開發(fā)方法59拋棄式原型開發(fā)拋棄式原型開發(fā)的根本作用是弄清楚需求和為管理人員評(píng)估過程風(fēng)險(xiǎn)提供額外的信息。在拋棄式原型開發(fā)中，我們只注重其功能，而忽略其質(zhì)量標(biāo)準(zhǔn)和性能指標(biāo)，使這些功能經(jīng)過原型設(shè)計(jì)而得到深刻理解。經(jīng)過評(píng)估，原型被拋棄，不再作為系統(tǒng)開發(fā)的基礎(chǔ)。其原型開發(fā)和最終系統(tǒng)開發(fā)使用的語言也往往不一樣。60拋棄式原型開發(fā)拋棄式原型開發(fā)的根本作用是弄清楚需求和拋棄式原型開發(fā)61拋棄式原型開發(fā)61拋棄式原型方法存在以下問題1.為了盡快拿出原型，系統(tǒng)可能做了許多簡化，因而不可避免要遺漏一些重要特性。2.在客戶和承包商之間沒有一個(gè)能寫進(jìn)合同的對(duì)于原型實(shí)現(xiàn)的合法規(guī)定。3.非功能需求，若可靠性、安全性，在原型實(shí)現(xiàn)中不會(huì)得到充分反映。62拋棄式原型方法存在以下問題1.為了盡快拿出原型，系統(tǒng)可能3.6.3快速原型技術(shù)快速原型技術(shù)強(qiáng)調(diào)的是交付的速度，而非系統(tǒng)的性能、可維護(hù)性和可靠性。目前，有三種較實(shí)用的快速原型技術(shù)：1.動(dòng)態(tài)高級(jí)語言開發(fā)。2.數(shù)據(jù)庫編程。3.組件和應(yīng)用集成。633.6.3快速原型技術(shù)快速原型技術(shù)強(qiáng)調(diào)的是交付的快速原型技術(shù)64快速原型技術(shù)64使用動(dòng)態(tài)高級(jí)語言的開發(fā)動(dòng)態(tài)高級(jí)語言開發(fā)是一種包含運(yùn)行時(shí)數(shù)據(jù)管理強(qiáng)大功能的編程語言。每當(dāng)選擇一種語言時(shí)，需回答以下問題：1.問題的應(yīng)用領(lǐng)域是什么？2.需要什么樣的用戶交互？3.語言提供的支撐環(huán)境如何？動(dòng)態(tài)的高級(jí)語言可以混合使用以構(gòu)件系統(tǒng)原型。65使用動(dòng)態(tài)高級(jí)語言的開發(fā)動(dòng)態(tài)高級(jí)語言開發(fā)是一種包含運(yùn)行數(shù)據(jù)庫程序設(shè)計(jì)1.交互式表格定義開發(fā)者定義要顯示的各個(gè)域及其位置。2.表格之間的關(guān)聯(lián)開發(fā)者定義某個(gè)特定的輸入將導(dǎo)致后續(xù)的表格顯示。3.域驗(yàn)證開發(fā)者定義每個(gè)域輸入值的允許范圍。66數(shù)據(jù)庫程序設(shè)計(jì)1.交互式表格定義66組件和應(yīng)用集成如果系統(tǒng)中許多部分都可以復(fù)用而且不需重新進(jìn)行設(shè)計(jì)和實(shí)現(xiàn)，那么系統(tǒng)開發(fā)的時(shí)間就會(huì)縮短。利用可復(fù)用組件在系統(tǒng)描述中說明哪些可復(fù)用組件是可再利用的。67組件和應(yīng)用集成如果系統(tǒng)中許多部分都可以復(fù)用而且不需原型開發(fā)的兩個(gè)層次實(shí)現(xiàn)1.應(yīng)用層整個(gè)應(yīng)用系統(tǒng)與原型結(jié)合在一起，功能模塊可以共享。2.組件層單個(gè)組件集成進(jìn)標(biāo)準(zhǔn)的框架從而完成系統(tǒng)的構(gòu)造。

68原型開發(fā)的兩個(gè)層次實(shí)現(xiàn)1.應(yīng)用層68組件和應(yīng)用集成優(yōu)勢許多原型中的功能模塊可以以極低的成本來實(shí)現(xiàn)，如果原型用戶對(duì)這些較熟悉，就不需花費(fèi)額外的時(shí)間去學(xué)習(xí)這些功能。69組件和應(yīng)用集成優(yōu)勢許多原型中的功能模塊可以以極低的成本3.6.4軟件復(fù)用可復(fù)用的軟件與快速構(gòu)造原型關(guān)系很密切。一堆可復(fù)用的模塊單獨(dú)看可能是無用的，但快速構(gòu)造的原型系統(tǒng)就是靠它們連接起來而得到的。對(duì)建立軟件目標(biāo)系統(tǒng)而言，復(fù)用就是利用早先開發(fā)的對(duì)建立新系統(tǒng)有用的信息來生產(chǎn)新系統(tǒng)。它是一項(xiàng)活動(dòng)，而不是一個(gè)對(duì)象。703.6.4軟件復(fù)用可復(fù)用的軟件與快速構(gòu)造原型關(guān)系很密切。軟件復(fù)用的條件⑴必須有簡單而清晰的界面；⑵它們應(yīng)當(dāng)有高自包含性，即盡量不依賴其他模塊或數(shù)據(jù)結(jié)構(gòu)；⑶它們應(yīng)具有一些通用的功能。當(dāng)然，還應(yīng)有好的文檔，所有模塊的接口、功能和錯(cuò)誤條件描述應(yīng)遵守一定的規(guī)范。71軟件復(fù)用的條件⑴必須有簡單而清晰的界面；71軟件復(fù)用的范圍1)復(fù)用數(shù)據(jù)：指程序不做任何修改，甚至輸入輸出數(shù)據(jù)的格式也無需改動(dòng)，就可以從一個(gè)環(huán)境移到另一個(gè)環(huán)境中使用。2)復(fù)用模塊：早期可復(fù)用模塊的概念是指單個(gè)函數(shù)，它們不需要逐行編碼就可以連接到一個(gè)程序中去。3)復(fù)用結(jié)構(gòu)：有效的復(fù)用應(yīng)有一個(gè)結(jié)構(gòu)上的考慮，而不僅是將模塊連接在一起。4)復(fù)用設(shè)計(jì)：軟件設(shè)計(jì)與實(shí)現(xiàn)是兩個(gè)不同的階段。若對(duì)于同一個(gè)設(shè)計(jì)，可以采用不同的實(shí)現(xiàn)方法，則這樣的設(shè)計(jì)就是可復(fù)用的。5)復(fù)用規(guī)格說明：在基本需求不改變，或某一新問題與過去的某一軟件在某個(gè)抽象層次上屬于同一類的情況下，原規(guī)格說明仍可使用或參照使用。72軟件復(fù)用的范圍1)復(fù)用數(shù)據(jù)：指程序不做任何修改，甚至輸入輸軟件復(fù)用技術(shù)軟件復(fù)用技術(shù)可分為兩大類：合成技術(shù)和生成技術(shù)。1)合成技術(shù)：在合成技術(shù)中，構(gòu)件(BuildingBlocks)是復(fù)用的基石。構(gòu)件方法以抽象數(shù)據(jù)類型為理論基礎(chǔ)，借用了硬件中集成電路芯片的思想：即將功能細(xì)節(jié)與數(shù)據(jù)結(jié)構(gòu)隱藏封裝在構(gòu)件內(nèi)部，有著精心設(shè)計(jì)的接口。構(gòu)件在開發(fā)中像芯片那樣使用，它們可以組裝成更大的構(gòu)件。構(gòu)件可以是某一函數(shù)、過程、子程序、數(shù)據(jù)類型、算法等可復(fù)用軟件成份的抽象，利用構(gòu)件來構(gòu)造軟件系統(tǒng)，有較高的生產(chǎn)率和較短的開發(fā)周期。73軟件復(fù)用技術(shù)軟件復(fù)用技術(shù)可分為兩大類：合成技術(shù)和生成技術(shù)。7三種方式將構(gòu)件合成更大的構(gòu)件①連接。通常，標(biāo)準(zhǔn)函數(shù)庫中的標(biāo)準(zhǔn)函數(shù)是靠編譯和連接程序與其他模塊一起合成系統(tǒng)的②消息傳遞和繼承。例如smalltalk面向?qū)ο蟮某绦蛟O(shè)計(jì)體系結(jié)構(gòu)，就是通過消息傳遞和繼承機(jī)制把對(duì)象類與其相關(guān)的其他對(duì)象類聯(lián)系起來合成一個(gè)系統(tǒng)的。③管道機(jī)制。例如，UNIX中用管道(pipe)連接shell命令，使前一命令的輸出成為后一命令的輸入，用管道機(jī)制把多個(gè)shell命令連接在一起完成一個(gè)更復(fù)雜的功能。74三種方式將構(gòu)件合成更大的構(gòu)件①連接。通常，標(biāo)準(zhǔn)函數(shù)庫中的標(biāo)軟件復(fù)用技術(shù)2)生成技術(shù)：生成技術(shù)利用可復(fù)用的模式(Patterns)，通過生成程序產(chǎn)生一個(gè)新的程序或程序段，產(chǎn)生的程序可以看成是模式的實(shí)例。可復(fù)用的模式有兩種不同的形式：代碼模式和規(guī)則模式。前者的例子是應(yīng)用生成器，可復(fù)用的代碼模式就存在于生成器自身。通過特定的參數(shù)替換，生成抽象軟件模塊的具體實(shí)體。后者的例子是變換系統(tǒng)，它利用變換規(guī)則集合。其變換方法中通常采用超高級(jí)的規(guī)格說明語言，形式化地給出軟件的需求規(guī)格說明，利用程序變換系統(tǒng)(有時(shí)要經(jīng)過一系列變換)，把用超高級(jí)規(guī)格說明語言編寫的程序轉(zhuǎn)化成某種可執(zhí)行語言的程序。這種超高級(jí)語言抽象能力高，邏輯性強(qiáng)，形式化好，便于使用軟件者維護(hù)。75軟件復(fù)用技術(shù)2)生成技術(shù)：生成技術(shù)利用可復(fù)用的模式(Pat兩種復(fù)用技術(shù)比較構(gòu)件方法支持自底向上的軟件開發(fā)方法，應(yīng)當(dāng)具有硬軟件獨(dú)立性、可讀性、可理解性、正確性和可修改性。變換方法側(cè)重于程序的推導(dǎo)方式、推理規(guī)則，支持自頂向下的軟件開發(fā)技術(shù)。由于它的形式化程度高，抽象性強(qiáng)，一般軟件開發(fā)者不易掌握，在描述某些實(shí)際問題時(shí)也有困難。另外，經(jīng)過多次變換得到的可執(zhí)行程序的效率較低，在時(shí)間和存儲(chǔ)空間方面的需求較高，這都是需要解決的問題。可以將這兩種方法結(jié)合起來使用，取長補(bǔ)短，再吸收人工智能的研究成果，以知識(shí)庫為輔助工具，可促進(jìn)復(fù)用技術(shù)的成熟。76兩種復(fù)用技術(shù)比較構(gòu)件方法支持自底向上的軟件開發(fā)方法，應(yīng)當(dāng)具有3.7結(jié)構(gòu)化分析方法7777結(jié)構(gòu)化分析方法(StruturedAnalisys)結(jié)構(gòu)化分析是面向數(shù)據(jù)流進(jìn)行分析的方法，結(jié)構(gòu)化分析方法適用與數(shù)據(jù)處理類型軟件的需求分析。結(jié)構(gòu)化分析方法是利用抽象模型的概念，按照軟件內(nèi)部數(shù)據(jù)傳遞，變換的關(guān)系，自頂向下，逐步分解，直到找到滿足功能要求的所有可實(shí)現(xiàn)的軟件為止。結(jié)構(gòu)化方法使用以下幾個(gè)工具：數(shù)據(jù)流圖，數(shù)據(jù)字典，結(jié)構(gòu)化語言，判定樹和判定表等。78結(jié)構(gòu)化分析方法(StruturedAnalisys)結(jié)構(gòu)化3.7.1系統(tǒng)流程圖1．符號(hào)當(dāng)以概括的方式抽象地描繪一個(gè)物理系統(tǒng)時(shí)，僅僅使用圖3.7.1中列出的基本符號(hào)就夠了，其中每個(gè)符號(hào)表示系統(tǒng)中的一個(gè)部件。當(dāng)需要更具體地描繪一個(gè)物理系統(tǒng)時(shí)還需要使用圖3.7.2中列出的系統(tǒng)符號(hào)，利用這些符號(hào)可以把一個(gè)廣義的輸入／輸出操作具體化為讀／寫存儲(chǔ)在特殊設(shè)備上的文件（或數(shù)據(jù)庫），把一般的處理具體化為特定的程序或手工操作等等。793.7.1系統(tǒng)流程圖1．符號(hào)79例子某裝配廠有一座存放零件的倉庫，倉庫中現(xiàn)有的各種零件的數(shù)量以及每種零件的庫存量臨界值等數(shù)據(jù)記錄在庫存清單主文件中。當(dāng)倉庫中零件數(shù)量有變化時(shí)，應(yīng)該及時(shí)修改庫存清單主文件，如果那種零件的庫存量少于它的庫存量臨界值，則應(yīng)該報(bào)告給采購部門以便訂貨，規(guī)定每天向采購部門送一次訂貨報(bào)告。該裝配廠使用一臺(tái)小型計(jì)算機(jī)處理更新庫存清單主文件和產(chǎn)生訂貨報(bào)告的任務(wù)。零件庫存量的每一次變化稱為一個(gè)事務(wù)，由放在倉庫中的CRT終端輸入到計(jì)算機(jī)中；系統(tǒng)中的庫存清單程序?qū)κ聞?wù)進(jìn)行處理，更新存儲(chǔ)在磁盤上的庫存清單主文件，并且把必要的訂貨信息寫在磁帶上。最后，每天由報(bào)告生成程序讀一次磁帶，并且打印出訂貨報(bào)告。80例子某裝配廠有一座存放零件的倉庫，倉庫中現(xiàn)有的各種零件的數(shù)量例子81例子813.7.2數(shù)據(jù)流圖(DFD,DataFlowDiagram)數(shù)據(jù)流圖描繪系統(tǒng)的邏輯模型，圖中沒有任何具體的物理元素，只是描繪信息在系統(tǒng)中流動(dòng)和處理的情況。因?yàn)閿?shù)據(jù)流圖是邏輯系統(tǒng)的圖形表示，即使不是專業(yè)的計(jì)算機(jī)技術(shù)人員也容易理解，所以是極好的通信工具。823.7.2數(shù)據(jù)流圖(DFD,DataFlowDiag3.7.2數(shù)據(jù)流圖(DFD,DataFlowDiagram)1.符號(hào)數(shù)據(jù)流圖有四種基本符號(hào)：正方形（或立方體）表示數(shù)據(jù)的源點(diǎn)或終點(diǎn)；圓角矩形（或圓形）代表變換數(shù)據(jù)的處理；開口矩形（或兩條平行橫線）代表數(shù)據(jù)存儲(chǔ)；箭頭表示數(shù)據(jù)流，即特定數(shù)據(jù)的流動(dòng)方向。注意，數(shù)據(jù)流與程序流程圖中用箭頭表示的控制流有本質(zhì)不同，千萬不要混淆。熟悉程序流程圖的初學(xué)者在畫數(shù)據(jù)流圖時(shí)，往往試圖在數(shù)據(jù)流圖中表現(xiàn)分支條件或循環(huán)，殊不知這樣做將造成混亂，畫不出正確的數(shù)據(jù)流圖。在數(shù)據(jù)流圖中應(yīng)該描繪所有可能的數(shù)據(jù)流向，而不應(yīng)該描繪出現(xiàn)某個(gè)數(shù)據(jù)流的條件。(圖示)833.7.2數(shù)據(jù)流圖(DFD,DataFlowDiag數(shù)據(jù)流圖性質(zhì)①數(shù)據(jù)流圖中的箭頭僅能表示在系統(tǒng)中流動(dòng)的數(shù)據(jù)；②與程序流程圖不同，DFD不能表示程序的控制結(jié)構(gòu)；③DFD表現(xiàn)的范圍具有很大的靈活性。84數(shù)據(jù)流圖性質(zhì)①數(shù)據(jù)流圖中的箭頭僅能表示在系統(tǒng)中流動(dòng)的數(shù)據(jù)；例1假設(shè)一家工廠的采購部每天需要一張訂貨報(bào)表，報(bào)表按零件編號(hào)排序，表中列出所有需要再次訂貨的零件。對(duì)于每個(gè)需要再次訂貨的零件應(yīng)該列出下述數(shù)據(jù)：零件編號(hào)，零件名稱，訂貨數(shù)量，目前價(jià)格，主要供應(yīng)者，次要供應(yīng)者。零件入庫或出庫稱為事務(wù)，通過放在倉庫中的CRT終端把事務(wù)報(bào)告給訂貨系統(tǒng)。當(dāng)某種零件的庫存數(shù)量少于庫存量臨界值時(shí)就應(yīng)該再次訂貨。(勾畫分析表)85例1假設(shè)一家工廠的采購部每天需要一張訂貨報(bào)表，報(bào)表按零件編號(hào)例2以到銀行取款為例。某年某日儲(chǔ)戶到銀行把存折和取款單一并交給銀行出納員檢驗(yàn)。出納員核對(duì)賬目，一旦發(fā)現(xiàn)存折有效性問題、取款單填寫問題或是存折、帳卡與取款單不符等問題時(shí)均應(yīng)報(bào)告儲(chǔ)戶。在檢驗(yàn)通過后，出納員將取款信息登錄在存折和帳卡上，并通知付款。根據(jù)付款通知給儲(chǔ)戶付款。到此，整個(gè)取款過程完成。首先從問題描述中提取數(shù)據(jù)流圖的四種成分。數(shù)據(jù)的源點(diǎn)：儲(chǔ)戶、日歷（隱含）。數(shù)據(jù)的終點(diǎn)：儲(chǔ)戶處理有：檢驗(yàn)、登錄、付款。數(shù)據(jù)存儲(chǔ)：存折、帳卡數(shù)據(jù)流：儲(chǔ)戶提交的"存折和取款單"、帳卡提供的"帳卡信息"，檢驗(yàn)通不過時(shí)出納員告知的"檢查出的問題"、通過檢驗(yàn)后的"取款信息"、"付款通知"、付給儲(chǔ)戶的"現(xiàn)款"以及日歷提供的"提款時(shí)間信息"86例2以到銀行取款為例。某年某日儲(chǔ)戶到銀行把存折和取款單一并交例287例2873.7.2數(shù)據(jù)流圖(DFD,DataFlowDiagram)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)容，而不是僅僅反映它的某些成分。②不要使用空洞的、缺乏具體含義的名字（如“數(shù)據(jù)”、“信息”、“輸入”之類）。③如果在為某個(gè)數(shù)據(jù)流（或數(shù)據(jù)存儲(chǔ)）起名字時(shí)遇到了困難，則很可能是因?yàn)閷?duì)數(shù)據(jù)流圖分解不恰當(dāng)造成的，應(yīng)該試試重新分解，看是否能克服這個(gè)困難。883.7.2數(shù)據(jù)流圖(DFD,DataFlowDiag3.7.2數(shù)據(jù)流圖(DFD,DataFlowDiagram)⑵為處理命名①通常先為數(shù)據(jù)流命名，然后再為與之相關(guān)聯(lián)的處理命名。這樣命名比較容易，而且體現(xiàn)了人類習(xí)慣的“由表及里”的思考過程。②名字應(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í)遇到困難，則很可能是發(fā)現(xiàn)了分解不當(dāng)?shù)嫩E象，應(yīng)考慮重新分解。893.7.2數(shù)據(jù)流圖(DFD,DataFlowDiag3.7.2數(shù)據(jù)流圖(DFD,DataFlowDiagram)3.用途畫數(shù)據(jù)流圖的基本目的是利用它作為交流信息的工具。分析員把他對(duì)現(xiàn)有系統(tǒng)的認(rèn)識(shí)或?qū)δ繕?biāo)系統(tǒng)的設(shè)想用數(shù)據(jù)流圖描繪出來，供有關(guān)人員審查確認(rèn)。由于在數(shù)據(jù)流圖中通常僅僅使用四種基本符號(hào)，而且不包含任何有關(guān)物理實(shí)現(xiàn)的細(xì)節(jié)，因此，絕大多數(shù)用戶都可以理解和評(píng)價(jià)它。從數(shù)據(jù)流圖的基本目標(biāo)出發(fā)，可以考慮在一張數(shù)據(jù)流圖中包含多少個(gè)元素合適的問題。一些調(diào)查研究表明，如果一張數(shù)據(jù)流圖中包含的處理多于5～9個(gè)，人們就難于領(lǐng)會(huì)它的含義了。因此數(shù)據(jù)流圖應(yīng)該分層，并且在把功能級(jí)數(shù)據(jù)流圖細(xì)化后得到的處理超過9個(gè)時(shí)，應(yīng)該采用畫分圖的辦法，也就是把每個(gè)主要功能都細(xì)化為一張數(shù)據(jù)流分圖，而原有的功能級(jí)數(shù)據(jù)流圖用來描繪系統(tǒng)的整體邏輯概貌。903.7.2數(shù)據(jù)流圖(DFD,DataFlowDiag分層數(shù)據(jù)流圖1.概念為有效控制復(fù)雜度，在產(chǎn)生數(shù)據(jù)流圖時(shí)采用分層技術(shù)。2.組成把一個(gè)系統(tǒng)分為頂層DFD、中間層DFD和底層DFD。91分層數(shù)據(jù)流圖1.概念91分層數(shù)據(jù)流圖92分層數(shù)據(jù)流圖92分層數(shù)據(jù)流圖3.分層原則⑴父圖與子圖關(guān)系⑵編號(hào)⑶平衡規(guī)則⑷文件局部性⑸分解程度93分層數(shù)據(jù)流圖3.分層原則933.7.3數(shù)據(jù)字典(DD,DataDictionary)數(shù)據(jù)字典是關(guān)于數(shù)據(jù)的信息的集合，也就是對(duì)數(shù)據(jù)流圖中包含的所有元素的定義的集合。任何字典最主要的用途都是供人查閱對(duì)不了解的條目的解釋，數(shù)據(jù)字典的作用也正是在軟件分析和設(shè)計(jì)的過程中給人提供關(guān)于數(shù)據(jù)的描述信息。數(shù)據(jù)流圖和數(shù)據(jù)字典共同構(gòu)成系統(tǒng)的邏輯模型，沒有數(shù)據(jù)字典數(shù)，數(shù)據(jù)流圖就不嚴(yán)格，然而沒有數(shù)據(jù)流因數(shù)據(jù)字典也難于發(fā)揮作用。只有數(shù)據(jù)流圖和對(duì)數(shù)據(jù)流圖中每個(gè)元素的精確定義放在一起，才能共同構(gòu)成系統(tǒng)的規(guī)格說明。數(shù)據(jù)字典中所有的定義應(yīng)是嚴(yán)密的、精確的，不可有半點(diǎn)含混，不可有二義性。943.7.3數(shù)據(jù)字典(DD,DataDictionary3.7.3數(shù)據(jù)字典(DD,DataDictionary)1.數(shù)據(jù)字典的定義對(duì)在數(shù)據(jù)流圖中每一個(gè)命名的圖形元素均給予定義，其內(nèi)容有圖形元素的名字、別名或編號(hào)、分類、描述、定義、位置等。⑴數(shù)據(jù)流詞條描述數(shù)據(jù)流是數(shù)據(jù)結(jié)構(gòu)在系統(tǒng)內(nèi)傳播的路徑。一個(gè)數(shù)據(jù)流詞條有以下幾項(xiàng)內(nèi)容。⑵數(shù)據(jù)元素詞條描述圖中的每一個(gè)數(shù)據(jù)結(jié)構(gòu)都是由數(shù)據(jù)元素構(gòu)成的，數(shù)據(jù)元素是數(shù)據(jù)處理中最小的，不可再分的單位，它直接反映事物的某一特征。⑶數(shù)據(jù)文件詞條描述數(shù)據(jù)文件是數(shù)據(jù)結(jié)構(gòu)保存的地方。一個(gè)數(shù)據(jù)文件詞條有以下幾項(xiàng)內(nèi)容⑷加工邏輯詞條描述加工比較復(fù)雜，它到后來就是一段程序，加工的表達(dá)方式有判定表，判定樹如何結(jié)構(gòu)化語言等等，它們要全部寫在一個(gè)詞條中是有困難的。953.7.3數(shù)據(jù)字典(DD,DataDictionary3.7.3數(shù)據(jù)字典(DD,DataDictionary)2.定義數(shù)據(jù)的方法定義絕大多數(shù)復(fù)雜事物的方法，都是用被定義的事物的成分的某種組合表示這個(gè)事物，這些組成成分又由更低層的成分的組合來定義。從這個(gè)意義上說，定義就是自頂向下的分解，所以數(shù)據(jù)字典中的定義就是對(duì)數(shù)據(jù)自頂向下的分解。那么，應(yīng)該把數(shù)據(jù)分解到什么程度呢？一般說來，當(dāng)分解到不需要進(jìn)一步定義，每個(gè)和工程有關(guān)的人也都清楚其含義的元素時(shí)，這種分解過程就完成了。由數(shù)據(jù)元素組成數(shù)據(jù)的方式只有下述三種基本類型：⑴順序即以確定次序連接兩個(gè)或多個(gè)分量；⑵選擇即從兩個(gè)或多個(gè)可能的元素中選取一個(gè)；⑶重復(fù)即把指定的分量重復(fù)零次或多次。⑷可選即一個(gè)分量是可有可無的（重復(fù)零次或一次）。963.7.3數(shù)據(jù)字典(DD,DataDictionary3.7.3數(shù)據(jù)字典(DD,DataDictionary)符號(hào)含義解釋=被定義為+與例如，X=a+b,表示x由a和b組成[…，…]或例如，X=[a,b],X=[a|b],表示x由a或由b組成[…|…]或{…}重復(fù)例如，X={a},表示x由0個(gè)或多個(gè)a組成m{…}n重復(fù)例如，X=3{a}8,表示x中至少出現(xiàn)3次a，至多出現(xiàn)8次(…)可選例如，X=(a)表示a可在X中出現(xiàn),也可不出現(xiàn)“…”基本數(shù)據(jù)元素例如，X=“a”,表示x為取值為a的數(shù)據(jù)元素‥連接符例如，X=1..9,表示a可取1到9之中的任一值973.7.3數(shù)據(jù)字典(DD,DataDictionary例例：數(shù)據(jù)文件的存折格式的數(shù)據(jù)字典中的定義格式為：存折=戶名+所號(hào)+帳號(hào)+開戶日+性質(zhì)+(密印)+1{存取行}50戶名=2{字母}24所號(hào)=“000”…“999”注：儲(chǔ)蓄所編碼，規(guī)定三位數(shù)字帳號(hào)=“00000001”..“99999999”注：帳號(hào)規(guī)定由八位數(shù)字組成開戶日=年+月+日性質(zhì)=“1”..“6”注：“1”表示普通用戶，“5”表示工資戶等印密=”0”注：“1”表示普通用戶，“5”表示工資戶等存取行=日期+(摘要)+支出+存入+余額+操作+復(fù)核日期=年+月+日年=“00”..“99”月=“01”..“12”日=“01”..“31”摘要=1{字母}4注：表明該存取是存？是??？還是換？支出=金額注：金額規(guī)定不超過9999999.99元金額=“0000000.01”..“9999999.99”操作=“00001”..“50000”98例例：數(shù)據(jù)文件的存折格式的數(shù)據(jù)字典中的定義格式為：983.7.3數(shù)據(jù)字典(DD,DataDictionary)3.數(shù)據(jù)字典的用途數(shù)據(jù)字典最重要的用途是作為分析階段的工具。在數(shù)據(jù)字典中建立的一組嚴(yán)密一致的定義有助于改進(jìn)分析員和用戶之間的通信，因此將消除許多可能的誤解。對(duì)數(shù)據(jù)的這一系列嚴(yán)密一致的定義也有助于改進(jìn)在不同的開發(fā)人員或不同的開發(fā)小組之間的通信。如果要求所有開發(fā)人員都根據(jù)公共的數(shù)據(jù)字典描述數(shù)據(jù)和設(shè)計(jì)模塊，則能避免許多麻煩的接口問題。數(shù)據(jù)字典中包含的每個(gè)數(shù)據(jù)元素的控制信息是很有價(jià)值的。因?yàn)榱谐隽耸褂靡粋€(gè)給定的數(shù)據(jù)元素的所有程序（或模塊），所以很容易估計(jì)改變一個(gè)數(shù)據(jù)將產(chǎn)生的影響，并且能對(duì)所有受影響的程序或模塊作出相應(yīng)的改變。最后，數(shù)據(jù)字典是開發(fā)數(shù)據(jù)庫的第一步，而且是很有價(jià)值的一步。993.7.3數(shù)據(jù)字典(DD,DataDictionary3.7.3數(shù)據(jù)字典(DD,DataDictionary)4.數(shù)據(jù)字典的實(shí)現(xiàn)目前實(shí)現(xiàn)數(shù)據(jù)字典有三種常見的途徑：全人工過程，全自動(dòng)化過程（利用數(shù)據(jù)字典處理程序）和混合過程（用正文編輯程序，報(bào)告生成程序等已有的實(shí)用程序幫助人工過程）。不論使用哪種途徑實(shí)現(xiàn)的數(shù)據(jù)字典都應(yīng)該具有下述特點(diǎn)：⑴通過名字能方便地查閱數(shù)據(jù)的定義；⑵沒有冗余；⑶盡量不重復(fù)在規(guī)格說明的其他組成部分中已經(jīng)出現(xiàn)的信息；⑷容易更新和修改；⑸能單獨(dú)處理描述每個(gè)數(shù)據(jù)元索的信息；⑹定義的書寫方法簡單方便而且嚴(yán)格。此外，如果再帶有產(chǎn)生交叉參照表、錯(cuò)誤檢測、一致性校驗(yàn)等功能則更好。1003.7.3數(shù)據(jù)字典(DD,DataDictionary3.7.3數(shù)據(jù)字典(DD,DataDictionary)如果暫時(shí)還沒有自動(dòng)的數(shù)據(jù)字典處理程序，建議采用卡片形式書寫數(shù)據(jù)字典，每張卡片上保存描述一個(gè)數(shù)據(jù)元素的信息。這種做法較好地實(shí)現(xiàn)了上述要求，特別是更新和修改起來很方便，能夠單獨(dú)處理每個(gè)數(shù)據(jù)元素的信息。每張卡片上主要應(yīng)該包含下述這樣一些信息：名字、別名描述、定義、位置。當(dāng)開發(fā)過程進(jìn)展到能夠知道數(shù)據(jù)元素的控制信息和使用特點(diǎn)時(shí)，把這些信息記錄在卡片的背面。1013.7.3數(shù)據(jù)字典(DD,DataDictionary卡片字典的例子名字：訂貨報(bào)表別名：訂貨信息描述：每天一次送給采購員的需要訂貨的零件表定義：訂貨報(bào)表＝零件編號(hào)+零件名稱+訂貨數(shù)量+目前價(jià)格+主要供應(yīng)者+次要供應(yīng)者位置：輸出到打印機(jī)名字：零件編號(hào)別名：描述：唯一地標(biāo)識(shí)庫存清單中一個(gè)特定零件的關(guān)鍵域定義：零件編號(hào)＝8{字符}8位置：訂貨報(bào)表訂貨信息庫存清單名字：訂貨數(shù)量別名：描述：某個(gè)零件一次訂貨的數(shù)量定義：訂貨數(shù)量＝1{數(shù)字}5位置：訂貨報(bào)表訂貨信息102卡片字典的例子名字：訂貨報(bào)表名字：零件編號(hào)名字：訂貨數(shù)量103.7.4加工邏輯說明在數(shù)據(jù)流圖中，每個(gè)加工框中只簡單地寫上了一個(gè)加工名，這顯然不能表達(dá)加工的全部內(nèi)容。隨著自頂向下逐步細(xì)化，功能越來越具體，加工邏輯也越來越精細(xì)。到最底一層，加工邏輯詳細(xì)到可以實(shí)現(xiàn)的程度，因此稱為“原子加工”或“基本加工”。如果能夠?qū)懗雒恳粋€(gè)基本加工的全部詳細(xì)邏輯功能，再自底向上綜合，就能完成全部邏輯加工。1033.7.4加工邏輯說明在數(shù)據(jù)流圖中，每個(gè)加工框中3.7.4加工邏輯說明在寫基本加工邏輯的說明時(shí)，應(yīng)滿足如下要求：⑴對(duì)數(shù)據(jù)流圖的每一個(gè)基本加工，必須有一個(gè)加工邏輯說明；⑵加工邏輯說明必須描述基本加工如何把輸入數(shù)據(jù)流變換為輸出數(shù)據(jù)流的加工規(guī)則；⑶加工邏輯說明必須描述實(shí)現(xiàn)加工的策略而不是實(shí)現(xiàn)加工的細(xì)節(jié)；目前用于寫加工邏輯說明的工具有結(jié)構(gòu)化語言、判定表和判定樹。1043.7.4加工邏輯說明在寫基本加工邏輯的說明時(shí)，3.7.4加工邏輯說明1.結(jié)構(gòu)化語言所謂結(jié)構(gòu)化語言是一種介于自然語言和形式化語言之間的半形式化語言。它是在自然語言基礎(chǔ)上加了一些限制而得到的語言，是使用有限的詞匯和有限的語句來描述加工邏輯。結(jié)構(gòu)化英語的詞匯表由英語命令動(dòng)詞、數(shù)據(jù)字典中定義的名字、有限的自定義詞和控制結(jié)構(gòu)關(guān)鍵詞IF-THEN-ELSE、WHILE-DO、REPEAT-UNTIL、CASE-OF等組成。其動(dòng)詞的含義要具體，盡可能少用或不用形容詞和副詞。1053.7.4加工邏輯說明1.結(jié)構(gòu)化語言1053.7.4加工邏輯說明下面是商店業(yè)務(wù)處理系統(tǒng)中“檢查發(fā)貨單”的例子。IFtheinvoiceexceeds$500THEN(發(fā)貨單金額超過$500)IFtheaccounthasanyinvoicemorethan60daysoverdueTHEN(欠款超過60天)theconfirmationpendingresolutionofthedebt(在償還欠款前不予批準(zhǔn))ELSE(accountisingoodstanding)(欠款未超期)issueconfirmationandinvoice(發(fā)批準(zhǔn)書及發(fā)貨單)ENDIFELSE(invoice$500orless)(發(fā)貨單金額未超過$500)IFtheaccounthasanyinvoicemorethan60daysoverdueTHEN(欠款超過60天)issueconfirmation,invoiceandwritemessageoncreditactionreport(發(fā)批準(zhǔn)書，發(fā)貨單及賒欠報(bào)告)ELSE(accountisingoodstanding)(欠款未超過)issueconfirmationandinvoice(發(fā)批準(zhǔn)書及發(fā)貨單)ENDIFENDIF1063.7.4加工邏輯說明下面是商店業(yè)務(wù)處理系統(tǒng)中“檢查發(fā)3.7.4加工邏輯說明2.判定表判定表是描述多條件、多目標(biāo)動(dòng)作的廣為使用的形式化工具。判定表通常有四部分組成，見下圖，用粗實(shí)線分開。左上部分是條件定義部分，左下部分是動(dòng)作定義部分，右上部分是條件值列部分，右下部分是選定的動(dòng)作列部分。條件定義條件取值列動(dòng)作定義選定的動(dòng)作列在條件定義部分由上到下分別列出所有條件。條件的上下次序允許調(diào)換。在動(dòng)作定義部分由上到下依次列出所有的目標(biāo)動(dòng)作。在條件取值列部分，與條件定義次序相對(duì)應(yīng)的列出個(gè)條件的取值。在選定的動(dòng)作列部分，按照條件取值組合所選定的目標(biāo)動(dòng)作。1073.7.4加工邏輯說明2.判定表?xiàng)l件定義條件取值列3.7.4加工邏輯說明3.判定樹判定樹實(shí)質(zhì)上是判定表的一種變形。它們只是形式上的區(qū)別，在本質(zhì)上是一樣的。判定樹繪制的通常規(guī)律是：⑴被描述的問題（或處理名稱）作為樹根放在左邊。判定樹是由左向右的水平放置的樹；⑵由左向右，在樹的上方依次列出問題的所有條件名稱。⑶所選目標(biāo)動(dòng)作作為樹頁畫在圖的最后邊。1083.7.4加工邏輯說明3.判定樹108判定樹例子109判定樹例子1093.7.5圖形工具1.層次方框圖

層次方框圖用樹形結(jié)構(gòu)的一系列多層次的矩形框描繪數(shù)據(jù)的層次結(jié)構(gòu)。樹形結(jié)構(gòu)的頂層是一個(gè)單獨(dú)的矩形框，它代表完整的數(shù)據(jù)結(jié)構(gòu)，下面的各層矩形框代表這個(gè)數(shù)據(jù)的子集，最底層的各個(gè)框代表組成這個(gè)數(shù)據(jù)的實(shí)際數(shù)據(jù)元素（不能再分割的元素）。1103.7.5圖形工具1.層次方框圖1103.7.5圖形工具例如，描繪一家計(jì)算機(jī)公司全部產(chǎn)品的數(shù)據(jù)結(jié)構(gòu)可以用圖中的層次方框圖表示。這家公司的產(chǎn)品由硬件、軟件和服務(wù)三類產(chǎn)品組成，軟件產(chǎn)品又分為系統(tǒng)軟件和應(yīng)用軟件，系統(tǒng)軟件又進(jìn)一步分為操作系統(tǒng)、編譯程序和軟件工具，……。1113.7.5圖形工具例如，描繪一家計(jì)算機(jī)公司全部3.7.5圖形工具2.Warnier圖法國計(jì)算機(jī)科學(xué)家Warnier提出了表示信息層次結(jié)構(gòu)的另外一種圖形工具。和層次方框圖類似，Warnier圖也用樹形結(jié)構(gòu)描繪信息，但是這種圖形工具比層次方框圖提供了更豐富的描繪手段。用Warnier圖可以表明信息的邏輯組織，也就是說，它可以指出一類信息或一個(gè)信息量是重復(fù)出現(xiàn)的，也可以表示特定信息在某一類信息中是有條件地出現(xiàn)的。因?yàn)橹貜?fù)和條件約束是說明軟件處理過程的基礎(chǔ)，所以很容易把Warnier圖轉(zhuǎn)變成軟件設(shè)計(jì)的工具。1123.7.5圖形工具2.Warnier圖1123.7.5圖形工具3.IPO圖IPO圖是輸入／處理／輸出圖的簡稱，它是美國IBM公司發(fā)展完善起來的一種圖形工具，能夠方便地描繪輸入數(shù)據(jù)、對(duì)數(shù)據(jù)的處理和輸出數(shù)據(jù)之間的關(guān)系。IPO圖使用的基本符號(hào)既少又簡單，因此很容易學(xué)會(huì)使用這種圖形工具。它的基本形式是在左邊的框中列出有關(guān)的輸入數(shù)據(jù)，在中間的框內(nèi)列出主要的處理，在右邊的框內(nèi)列出產(chǎn)生的輸出數(shù)據(jù)。處理框中列出處理的次序暗示了執(zhí)行的順序，但是用這些基本符號(hào)還不足以精確描述執(zhí)行處理的詳細(xì)情況。在IPO圖中還用類似向量符號(hào)的粗大箭頭清楚地指出數(shù)據(jù)通信的情況。1133.7.5圖形工具3.IPO圖1133.7.5圖形工具1143.7.5圖形工具1143.7.5圖形工具IPO圖中包含的附加信息主要有系統(tǒng)名稱、圖的作者，完成的日期，本圖描述的模塊的名字，模塊在層次圖中的編號(hào)，調(diào)用本模塊的模塊清單，本模塊調(diào)用的模塊的清單，注釋，以及本模塊使用的局部數(shù)據(jù)元素等。在需求分析階段可以使用IPO圖簡略地描述系統(tǒng)的主要算法（即數(shù)據(jù)流圖中各個(gè)處理的基本算法）。當(dāng)然，在需求分析階段，IPO圖中的許多附加信息暫時(shí)還不具備，但是在軟件設(shè)計(jì)階段可以進(jìn)一步補(bǔ)充修正這些圖，作為設(shè)計(jì)階段的文檔。這正是在需求分析階段用IPO圖作為描述算法的工具的重要優(yōu)點(diǎn)。1153.7.5圖形工具IPO圖中包含的附加信息主要有演講完畢，謝謝觀看！演講完畢，謝謝觀看！第3章需求工程與需求分析117第3章需求工程與需求分析13.1基本的軟件需求1182基本的軟件需求軟件項(xiàng)目中百分之四十至百分之六十的問題都是在需求分析階段埋下的“禍根”?？稍S多組織仍在那些基本的項(xiàng)目功能上采用一些不合規(guī)范的方法，這樣導(dǎo)致的后果便是一條鴻溝（期望差異）—開發(fā)者開發(fā)的與用戶所想得到的軟件存在著巨大期望差異。119基本的軟件需求軟件項(xiàng)目中百分之四十至百分之六十的問題基本的軟件需求在軟件工程中，所有的風(fēng)險(xiǎn)承擔(dān)者(stakeholder)都感興趣的就是需求分析階段。這些風(fēng)險(xiǎn)承擔(dān)者包括客戶、用戶、業(yè)務(wù)或需求分析員(負(fù)責(zé)收集客戶需求并編寫文檔，以及負(fù)責(zé)客戶與開發(fā)機(jī)構(gòu)之間聯(lián)系溝通的人)、開發(fā)人員、測試人員、用戶文檔編寫者、項(xiàng)目管理者和客戶管理者。這部分工作若處理好了，能開發(fā)出很出色的產(chǎn)品，同時(shí)會(huì)使客戶感到滿意，開發(fā)者也倍感滿足、充實(shí)。若處理不好，則會(huì)導(dǎo)致誤解、挫折、障礙以及潛在質(zhì)量和業(yè)務(wù)價(jià)值上的威脅。因?yàn)樾枨蠓治龅於塑浖こ毯晚?xiàng)目管理的基礎(chǔ)。120基本的軟件需求在軟件工程中，所有的風(fēng)險(xiǎn)承擔(dān)者(st3.1.1軟件需求的定義⑴用戶解決問題或達(dá)到目標(biāo)所需的條件或權(quán)能（Capability）。⑵系統(tǒng)或系統(tǒng)部件要滿足合同、標(biāo)準(zhǔn)、規(guī)范或其它正式規(guī)定文檔所需具有的條件或權(quán)能。⑶一種反映上面⑴或⑵所描述的條件或權(quán)能的文檔說明。1213.1.1軟件需求的定義⑴用戶解決問題或達(dá)到目標(biāo)所3.1.1軟件需求的定義1.一些關(guān)于“需求”的解釋需求的關(guān)鍵的問題是一定要編寫需求文檔。如果只有一堆郵件、貼條、會(huì)談過幾次或一些零碎的對(duì)話，你就確信你已明白用戶的需求，那完全是自欺欺人。

許多的需求分析專家給出了不同形式的需求定義，但從這些不同形式的定義不難發(fā)現(xiàn)：并沒有一個(gè)清晰、毫無二義性的“需求”術(shù)語存在，真正的“需求”實(shí)際上在人們的腦海中。任何文檔形式的需求（例如：需求規(guī)格說明）僅是一個(gè)模型，一種敘述（Lawrence1998）。我們需要確保所有項(xiàng)目風(fēng)險(xiǎn)承擔(dān)者在描述需求的那些名詞的理解上務(wù)必達(dá)成共識(shí)。1223.1.1軟件需求的定義1.一些關(guān)于“需求”的解釋63.1.1軟件需求的定義2．需求的層次

下面這些定義是需求工程領(lǐng)域中常見術(shù)語的定義說明。軟件需求包括三個(gè)不同的層次——業(yè)務(wù)需求、用戶需求和功能需求（包括非功能需求）。⑴業(yè)務(wù)需求（businessrequirement）反映了組織機(jī)構(gòu)或客戶對(duì)系統(tǒng)、產(chǎn)品高層次的目標(biāo)要求，它們?cè)陧?xiàng)目視圖與范圍文檔中予以說明。⑵用戶需求（userrequirement）文檔描述了用戶使用產(chǎn)品必須要完成的任務(wù)，這在使用實(shí)例（usecase）文檔或方案腳本（scenario）說明中予以說明。⑶功能需求(functionalrequirement)定義了開發(fā)人員必須實(shí)現(xiàn)的軟件功能，使得用戶能完成他們的任務(wù)，從而滿足了業(yè)務(wù)需求。所謂特性（feature）是指邏輯上相關(guān)的功能需求的集合，給用戶提供處理能力并滿足業(yè)務(wù)需求。1233.1.1軟件需求的定義2．需求的層次73.1.1軟件需求的定義1243.1.1軟件需求的定義83.1.2需求的開發(fā)和管理需求中名詞術(shù)語的混淆將導(dǎo)致對(duì)科目（規(guī)范，discipline）叫法的不一致。一些作者把整個(gè)需求范圍稱之為“需求工程”，另一些則稱之為“需求管理”。軟件專家認(rèn)為可把整個(gè)軟件需求工程研究領(lǐng)域劃分為需求開發(fā)和需求管理兩部分更合適：1253.1.2需求的開發(fā)和管理需求中名詞術(shù)語的混淆將導(dǎo)3.1.2需求的開發(fā)和管理需求開發(fā)可進(jìn)一步分為：需求獲取(elicitation)、分析(analysis)、編寫規(guī)格說明(specification)和驗(yàn)證(verification)四個(gè)階段。需求開發(fā)活動(dòng)包括以下幾個(gè)方面：⑴確定產(chǎn)品所期望的用戶類。⑵獲取每個(gè)用戶類的需求。⑶了解實(shí)際用戶任務(wù)和目標(biāo)以及這些任務(wù)所支持的業(yè)務(wù)需求。⑷分析源于用戶的信息以區(qū)別用戶任務(wù)需求、功能需求、業(yè)務(wù)規(guī)則、質(zhì)量屬性、建議解決方法和附加信息。1263.1.2需求的開發(fā)和管理需求開發(fā)可進(jìn)一步分為：需3.1.2需求的開發(fā)和管理⑸將系統(tǒng)級(jí)的需求分為幾個(gè)子系統(tǒng)，并將需求中的一部份分配給軟件組件。⑹了解相關(guān)質(zhì)量屬性的重要性。⑺商討實(shí)施優(yōu)先級(jí)的劃分。⑻將所收集的用戶需求編寫成規(guī)格說明和模型。⑼評(píng)審需求規(guī)格說明，確保對(duì)用戶需求達(dá)到共同的理解與認(rèn)識(shí)，并在整個(gè)開發(fā)小組接受說明之前將問題都弄清楚。1273.1.2需求的開發(fā)和管理⑸將系統(tǒng)級(jí)的需求分為幾個(gè)3.1.2需求的開發(fā)和管理需求管理需要“建立并維護(hù)在軟件工程中同客戶達(dá)成的契約”(CMU/SEI1995)。這種契約都包含在編寫的需求規(guī)格說明與模型中。通常的需求管理活動(dòng)包括：⑴定義需求基線（迅速制定需求文檔的主體）。⑵評(píng)審提出的需求變更、評(píng)估每項(xiàng)變更的可能影響從而決定是否實(shí)施它。⑶以一種可控制的方式將需求變更融入到項(xiàng)目中。⑷使當(dāng)前的項(xiàng)目計(jì)劃與需求一致。⑸估計(jì)變更需求所產(chǎn)生影響并在此基礎(chǔ)上協(xié)商新的承諾(約定)。⑹讓每項(xiàng)需求都能與其對(duì)應(yīng)的設(shè)計(jì)、源代碼和測試用例聯(lián)系起來以實(shí)現(xiàn)跟蹤。⑺在整個(gè)項(xiàng)目過程中跟蹤需求狀態(tài)及其變更情況。1283.1.2需求的開發(fā)和管理需求管理需要“建立并維3.1.2需求的開發(fā)和管理需求開發(fā)和需求管理之間的區(qū)別1293.1.2需求的開發(fā)和管理需求開發(fā)和需求管理之間的區(qū)別133.1.3需求工程的作用1．支持項(xiàng)目的開發(fā)。

需求工程過程是軟件開發(fā)階段的前提和基礎(chǔ)。2．支持測試和驗(yàn)證

需求規(guī)格說明書將為項(xiàng)目測試和驗(yàn)證提供基準(zhǔn)，可以用來檢查設(shè)計(jì)和驗(yàn)證系統(tǒng)。3．支持維護(hù)

維護(hù)階段的工作同以下幾個(gè)方面緊密聯(lián)系：⑴修改在測試階段中尚未檢查出來的少量殘留編碼錯(cuò)誤。⑵軟件運(yùn)行一段時(shí)間后，因環(huán)境因素的改變而產(chǎn)生的軟件的適應(yīng)性維護(hù)。⑶用戶在軟件交付使用后又重新提出擴(kuò)充功能的需求時(shí)的軟件維護(hù)。4．支持項(xiàng)目承包商需求的證實(shí)過程為擬構(gòu)造系統(tǒng)的正確性提供了進(jìn)一步的根據(jù)。5．支持管理