合工大計算機專業(yè)相關(guān)課件軟件工程需求分析zhhf

第三章（第四至六講）軟件需求分析一、軟件需求分析概念二、軟件需求分析的任務(wù)和過程三、需求的獲取與描述四、結(jié)構(gòu)化分析方法五、形式化分析技術(shù)本章的主要內(nèi)容一、需求的相關(guān)概念問題空間人們利用認(rèn)識現(xiàn)實世界和描述現(xiàn)實問題的方法描述有關(guān)問題解空間人們利用計算機能夠接受的語言和方法描述有關(guān)問題消除語義斷層系統(tǒng)責(zé)任與系統(tǒng)邊界系統(tǒng)責(zé)任指所開發(fā)的系統(tǒng)應(yīng)該具備的職能。目標(biāo)系統(tǒng)與外部實體（與系統(tǒng)打交道的人或物）之間應(yīng)具有明確的邊界。域產(chǎn)品平臺控制計算機行為者？業(yè)務(wù)域電梯用戶行為客戶軟件需求（Requirements) 需求是指用戶或者客戶對要開發(fā)的軟件系統(tǒng)的要求。需求的內(nèi)容在“問題定義”中得到最抽象的描述（可能是招標(biāo)文件）。需求是關(guān)于系統(tǒng)將要完成什么(what)工作的描述,必須經(jīng)過所有涉眾(stakeholder)的認(rèn)可,其目的是徹底解決客戶所期望解決的問題。IEEE的需求定義用戶為解決某個問題或達(dá)到某個目標(biāo)而需具備的條件或能力。系統(tǒng)或系統(tǒng)組件為符合合同、標(biāo)準(zhǔn)、規(guī)范或其它正式文檔而必須滿足的條件或必須具備的能力。上述第一項或第二項中定義的條件和能力的文檔表達(dá)。

——

IEEE的軟件工程標(biāo)準(zhǔn)術(shù)語表（1990）Sommerville的需求定義對應(yīng)該實現(xiàn)什么功能的說明；可以是系統(tǒng)運行方式或系統(tǒng)特征與屬性的描述；可能是對系統(tǒng)開發(fā)過程的約束。

——

Sommerville，Sawyer（1997）軟件需求的類型功能需求系統(tǒng)可以完成的所有事情涉及與本系統(tǒng)有接口的其他系統(tǒng)的所有事情非功能需求軟件開發(fā)過程中必須遵守的約束（Constraint)。是對可以使用的資源和軟件質(zhì)量的各個方面的限制，往往會影響軟件工程師做決策的自由度。非功能需求應(yīng)是可驗證的（Verifiable)。目標(biāo)系統(tǒng)的限制性能實時性、精確度、資源利用率等可靠性有效性、完整性安全/保密性安全性、保密性運行限制使用頻度、運行期限、控制方式、操作要求物理限制系統(tǒng)規(guī)模等限制開發(fā)維護的限制開發(fā)類型實用性開發(fā)、試驗性開發(fā)開發(fā)工作量的估計開發(fā)方法質(zhì)量控制標(biāo)準(zhǔn)、里程碑和評審、驗收標(biāo)準(zhǔn)優(yōu)先性和可修改性可維護性需求分析(RequirementsAnalysis)指開發(fā)人員為了準(zhǔn)確地理解和表達(dá)用戶要求，進行細(xì)致的調(diào)查分析，將用戶非形式的需求陳述轉(zhuǎn)化為完整的需求定義，再由需求定義轉(zhuǎn)換到相應(yīng)的形式功能規(guī)約的過程。Requirementsanalysis

resultsinthespecificationofsoftware’soperationalcharacteristics；indicatessoftware’sinterfacewithothersystemelements;andestablishesconstraintsthatsoftwaremustmeet.需求分析越來越難問題域的復(fù)雜性越來越高。交流障礙。(涉眾的文化背景不同；自然語言的多義性，一語雙關(guān)等）。完整性問題。（用戶對問題的陳述往往是不完備的；用戶意見不統(tǒng)一，需求之間可能存在著矛盾；涉及許多細(xì)節(jié)）需求易變性。（需求永遠(yuǎn)不會穩(wěn)定，往往存在錯誤的需求）應(yīng)該足夠重視需求分析軟件項目中40%~60%的缺陷都是由需求分析階段的過失所致（Daivs1993，Leffingwell1997）對歐洲軟件行業(yè)的大規(guī)模調(diào)查顯示：確定和管理用戶需求是問題最多的兩個環(huán)節(jié)（ESPITI1995）許多軟件問題都源于收集、記錄、協(xié)商和修改產(chǎn)品需求過程中的方式不當(dāng)信息收集方式不正規(guī)沒有明確提出想要的功能常常存在未經(jīng)溝通的錯誤假設(shè)需求的定義不夠充分未經(jīng)仔細(xì)考慮進行需求變更

······有關(guān)軟件錯誤和需求分析的一組事實在軟件生命周期中，一個錯誤發(fā)現(xiàn)得越晚，修復(fù)的費用也越高。許多錯誤是潛伏的，并且在錯誤產(chǎn)生后很長一段時間才被檢查出來。在需求過程中會產(chǎn)生很多錯誤和誤解，人與人之間的“通信”障礙無法避免。需求階段代表性的錯誤：疏忽、不一致、二義性。需求錯誤是可以被檢查和審查出來的。對項目需求狀況作出快速評估（1）項目前景（vision)和范圍(scope)未曾明確定義客戶太忙，沒時間與需求分析和開發(fā)人員一起討論需求用戶代理（如開發(fā)經(jīng)理、用戶負(fù)責(zé)人、營銷人員等）自詡可以代表用戶，其實不能準(zhǔn)確說出用戶的要求需求只存在于那些所謂專家的腦子里，沒有被記錄下來對項目需求狀況作出快速評估（2）客戶堅持所有需求都很重要，不愿排出它們的優(yōu)先次序開發(fā)人員在編碼過程中發(fā)現(xiàn)需求有歧義，缺少足夠的信息，只能去猜測開發(fā)人員與客戶溝通時只關(guān)心用戶界面，忽略了用戶需要用軟件做什么客戶簽字確認(rèn)了需求卻又一直提出修改要求對項目需求狀況作出快速評估（3）項目范圍因接受需求變更而擴大，卻沒有相應(yīng)地增加投入或剪裁功能，進度因而被延誤需求變更的請求被弄丟，開發(fā)人員和客戶都不了解所有變更請求的狀態(tài)開發(fā)人員按照客戶要求實現(xiàn)的功能無人問津需求規(guī)格說明中的要求都實現(xiàn)了客戶卻不滿意領(lǐng)域分析（DomainAnalysis)DomainAnalysisSourcesofDomainKnowledgeDomainAnalysisModelTechnicalliteratureExistingapplicationsCustomersurveysExpertadviceCurrent/futurerequirementsClasstaxonomiesReusestandardsFunctionalmodelsDomainlanguages整個軟件項目的涉眾（stakeholder）客戶（Customer）用戶（User）需求分析員開發(fā)人員測試人員項目經(jīng)理：負(fù)責(zé)制定項目計劃保證和項目順利進行法律人員：確保產(chǎn)品符合所有相關(guān)法規(guī)市場營銷、技術(shù)支持人員與產(chǎn)品和客戶打交道的其他人員資金需求合同義務(wù)軟件系統(tǒng)需求客戶發(fā)起系統(tǒng)開發(fā)用戶使用系統(tǒng)開發(fā)者建立系統(tǒng)

軟件開發(fā)的主要涉眾之間的關(guān)系需求分析的涉眾合同監(jiān)督人員，提出里程碑（Milestones）和約束系統(tǒng)開發(fā)進度的計劃需求者：客戶(Customer)和使用者(User)。開發(fā)者項目管理者，必須理解建立和使用目標(biāo)系統(tǒng)所可能產(chǎn)生的后果。系統(tǒng)分析員，分析階段活動的主體。設(shè)計員，依據(jù)需求提出可接受的解決方案。測試員，確保軟件系統(tǒng)滿足每一需求。系統(tǒng)分析員應(yīng)具有的素質(zhì)綜合能力總體規(guī)劃，抽象和分解，本質(zhì)確認(rèn)的能力過程能力保證整個過程的善始善終的能力交流能力理解和表達(dá)能力技術(shù)水平了解問題域和描述解空間的能力二、軟件需求分析的任務(wù)與過程深入描述軟件的功能和性能確定軟件設(shè)計的約束和軟件同其它系統(tǒng)元素的接口細(xì)節(jié)定義軟件的其它有效性需求研究用戶要求,準(zhǔn)確地表達(dá)被接受的用戶要求確定被開發(fā)軟件系統(tǒng)的系統(tǒng)元素將功能和信息結(jié)構(gòu)分配到這些系統(tǒng)元素中需求分析的任務(wù)就是借助于當(dāng)前系統(tǒng)的邏輯模型導(dǎo)出目標(biāo)系統(tǒng)的邏輯模型，解決目標(biāo)系統(tǒng)的“做什么”的問題。通常軟件開發(fā)項目是要實現(xiàn)目標(biāo)系統(tǒng)的物理模型目標(biāo)系統(tǒng)的具體物理模型是由它的邏輯模型經(jīng)實例化，即具體到某個業(yè)務(wù)領(lǐng)域而得到的需求獲取和分析的步驟通過對現(xiàn)實環(huán)境的研究，獲得系統(tǒng)具體模型。去掉具體模型的非本質(zhì)因素，抽取出當(dāng)前系統(tǒng)的邏輯模型分析當(dāng)前系統(tǒng)和目標(biāo)系統(tǒng)的差別，建立目標(biāo)系統(tǒng)的邏輯模型。對目標(biāo)系統(tǒng)進行完善和補充，寫出完整的需求分析。

學(xué)生在學(xué)校教材科購買教材的系統(tǒng)的例子

一、 通過對現(xiàn)實環(huán)境的研究，獲得系統(tǒng)具體 物理模型購書發(fā)票購書單書購書證明購書申請學(xué)生學(xué)生李保管孫出納錢會計趙秘書

學(xué)生在學(xué)校教材科購買教材的系統(tǒng)的例子

二、 去掉具體模型的非本質(zhì)因素，抽取出當(dāng)前 系統(tǒng)的邏輯模型發(fā)票購書單書有效單購書單學(xué)生學(xué)生發(fā)書開領(lǐng)書單開發(fā)票有效性

學(xué)生在學(xué)校教材科購買教材的系統(tǒng)的例子

三、 分析當(dāng)前系統(tǒng)和目標(biāo)系統(tǒng)的差別， 建立目標(biāo)系統(tǒng)的邏輯模型。發(fā)票購書單書購書單學(xué)生學(xué)生發(fā)書開領(lǐng)書單審查并開發(fā)票

學(xué)生在學(xué)校教材科購買教材的系統(tǒng)的例子四、 對目標(biāo)系統(tǒng)進行完善和補充，寫出完整 的需求說明。五、 對需求說明進行復(fù)審，直到確認(rèn)文檔齊 全并符合用戶的全部需求為止。無效書單發(fā)票購書單購書單學(xué)生學(xué)生開領(lǐng)書單審查并開發(fā)票需求規(guī)格說明書SRSSRS（softwarerequirementsspecification)：引言：問題定義所確定的目標(biāo)和范圍 數(shù)據(jù)描述：數(shù)據(jù)流圖，數(shù)據(jù)字典等等 功能描述：功能要求文檔（可形式化描述）性能描述：性能要求文檔 質(zhì)量保證：描述交付前需要進行的各種測試和驗 收標(biāo)準(zhǔn) 其它：運行要求、將來可能的要求三、軟件需求獲取與分析技術(shù)觀察（Observation)面談(Interviewing)頭腦風(fēng)暴(Brainstorming)原型化(PaperprototypeorRapidprototype)非正式用例分析(Informalusecaseanalysis)需求階段所要獲取的主要內(nèi)容物理環(huán)境(PhysicalEnvironment)接口(Interfaces)用戶或人的因素(Factors)功能(Functionality)文檔(Documentation)數(shù)據(jù)(Data)資源(Resources)安全性(Security)質(zhì)量保證(QualityAssurance)設(shè)備的主要用途，在哪里發(fā)揮什么作用？所須設(shè)置的設(shè)備的多少？環(huán)境限制等，如溫度、濕度或磁聲干擾？1）物理環(huán)境描述(PhysicalEnvironment)來自一個或多個其他系統(tǒng)的輸入？對一個或多個其它系統(tǒng)的輸出？數(shù)據(jù)是否必須預(yù)先進行規(guī)定的格式化處理？數(shù)據(jù)是否需要預(yù)先存放的介質(zhì)？2）接口描述（InterfaceDescription）誰使用系統(tǒng)？有幾種類型的用戶？每種類型用戶的技術(shù)水平怎樣？對每型用戶需要什么樣的培訓(xùn)？用戶理解、使用系統(tǒng)的難易度怎樣？用戶誤用系統(tǒng)的困難程度怎樣？3）用戶和人為因素系統(tǒng)將做什么？系統(tǒng)將在何時做？有幾種操作方式？系統(tǒng)能在何時、怎樣被改變或增強？對執(zhí)行速度，響應(yīng)時間或數(shù)據(jù)流量有何限制和約束？4）功能描述（FunctionDescription）5）文檔（Documents）需要多少文檔？是聯(lián)機文檔還是靜態(tài)文檔或者二者皆可？文檔所面向的對象（讀者）？6）數(shù)據(jù)（Data）I/O數(shù)據(jù)格式應(yīng)該是什么樣的？數(shù)據(jù)收或發(fā)的頻度？數(shù)據(jù)的精確度系統(tǒng)流經(jīng)的數(shù)據(jù)流量？數(shù)據(jù)必須在何時予以保存，保存多久？7）資源描述（ResourceDescription）建立和維護系統(tǒng)都要什么材料、人員或其他資源？開發(fā)者必須具有哪些技術(shù)？系統(tǒng)占用多少物理空間？對開發(fā)規(guī)定了時間表了？對用于開發(fā)或軟硬件上的資金有限制？對系統(tǒng)或信息的存取必須在我們的控制之下？不同用戶的數(shù)據(jù)之間將如何實現(xiàn)隔離？不同用戶程序之間，以及和操作系統(tǒng)間怎樣隔離？系統(tǒng)如何備份？備份副本必須被存于一個不同的位置？應(yīng)采取措施防火，防水防盜等安全措施？8）安全描述(Security)系統(tǒng)必須有效檢測并隔離故障？平均無故障時間規(guī)定為多少？對一次失敗后重啟系統(tǒng)有一個最大時間？系統(tǒng)如何將變化合并到設(shè)計？維護僅僅是糾正錯誤，還是包括改進系統(tǒng)？對資源和響應(yīng)時間使用什么樣的有效度量？系統(tǒng)移植性、可維護性等要求？如何向別人示范系統(tǒng)的特征？9）質(zhì)量保證(QualityAssurance)結(jié)構(gòu)化分析方法Z語言，RSL，RSML等（形式化的需求描述語言）原型需求分析方法面向?qū)ο蠓椒ǎ軌蚋玫叵罢Z義斷層”）軟件需求分析方法學(xué)HowtoExpressRequirementsStaticdescriptionsDynamicdescriptionsObject-orientedspecificationFormalMethods1）StaticDescriptions數(shù)據(jù)流圖、數(shù)據(jù)字典、加工說明等（p31）判定表（DecisionTables）（p63）判定樹E-R模型（p52）層次方框圖、Warnier圖、IPO圖（p58）WarnierDiagramsSoftwareproductsSystemApplicationOS(n1)Compiler(n2)SoftwareToolEditor(n3)Testdriver(n4)CADtool(n5)IPODiagramsOldmasterfilesOtherfilesInputProcessOutputVertifyPrimaryRecordVertifyOrtherRecordUpdaterecordValidPrimaryRecordValidOrtherRecordUpdatedfilesANewFormofIPOIPOSystem:Modules:Date:NO.Call:BeCalled:Input:Output:Process:Localdata:Annotation:E-R模型（Entity-Relationship)概念模型（E-R圖）邏輯模型（二維表的定義）物理模型（存儲空間的定義，如定義各個字段的大?。?shù)據(jù)庫的設(shè)計一般應(yīng)經(jīng)過由概念模型到邏輯模型，再到物理模型的映射過程。數(shù)據(jù)結(jié)構(gòu)的規(guī)范化1970年，IBM的E.F.Godd提出關(guān)系模型，由二維表表示。按照屬性間的依賴程度區(qū)分關(guān)系規(guī)范化的程度，由范式（NormalForm)來表示。1NF：表中不能有表（每個信息項必須是一個不 可分割的數(shù)據(jù)項）2NF：非主屬性由關(guān)鍵字唯一確定3NF：任何非主屬性間不存在函數(shù)依賴，即非主屬性相互獨立。DecisionTablesRule1Rule2Rule3Rule4Rule5HighstandardizedexamscoresTFFFFHighgrades—TFFFOutsideactivities——TFFGoodmendations———TFSendrejectionletterXXXSendadmissionformsXX2）DynamicDescriptionsFunctionalDescriptionsandTransitionDiagrams（p55)EventTablesPetriNets（p72)FunctionalDescriptionsStateiStatekConditionjTransitionDiagramsSiSkEventorConditionX狀態(tài)遷移圖是描述系統(tǒng)的狀態(tài)如何響應(yīng)外部的信號進行推移的一種圖形表示。圓圈“○”表示可得到的系統(tǒng)狀態(tài)箭頭“→”表示從一種狀態(tài)向另一種狀態(tài)的遷移。TransitionDiagrams→TransitionTableS1S2S3011100CurrentstateInputNextStateS10S2S11S1S20S2S21S1S30S1S31S3例如,當(dāng)有多個申請占用CPU運行的進程時,有關(guān)CPU分配的進程的狀態(tài)遷移。t1─中斷事件

t2─中斷已處理t3─分配CPUt4─用完CPU時間可得到的狀態(tài)＝就緒，運行，等待生成的事件＝t1，t2，t3，t4t1─中斷事件

t2─中斷已處理t3─分配CPUt4─用完CPU時間狀態(tài)遷移圖的優(yōu)點狀態(tài)之間的關(guān)系能夠直觀地捕捉到由于狀態(tài)遷移圖的單純性，能夠機械地分析許多情況，可很容易地建立分析工具FenceDiagramshowingStateTransitions

(Null)RequestedOnwaitinglistConfirmedUsedCanceledArchive(Hotelreservations)EventTablesModeEvent1Event2Event3Event4GraphicsAction1Action80XArchitectureXAction2followedbyAction3Action5,6inparallel0Native0Action4Action1,2,3Action7UMLnotationforstatetransitionS1S2conditionactionsObjectClassMethodorOperationEncapsulationInheritancehierarchyMultipleInheritancePolymorphism3）Object-orientedspecification4）FormalMethodsTheEncyclopediaofSoftwareEngineeringdefinesformalmethodsinthefollowingmanner:Amethodisformalifithasasoundmathematicalbasis,typicallygivenbyaformalspecificationlanguage.Thisbasisprovidesameansofpreciselydefiningnotionslikeconsistencyandcompleteness,andmorerelevantly,specification,implementationandcorrectness.對需求說明書的要求正確性無二義性（需求確實是用戶所需嗎？）完整性（完備性，包括用戶需要的每一功能或性能）一致性（需求之間不能互相矛盾）可檢驗性（非計算機人員可以理解）可實現(xiàn)性（有效性，需求是能夠現(xiàn)實的嗎？硬件系統(tǒng)的支持力度怎樣？）可修改性可跟蹤性注釋對需求規(guī)約的驗證驗證的方法復(fù)審和進一步需求分析實現(xiàn)原型系統(tǒng)支持需求分析工具驗證的主要內(nèi)容一致性驗證現(xiàn)實性驗證（需求是現(xiàn)實的嗎？）完整性（完備性）和有效性驗證四、面向數(shù)據(jù)流的結(jié)構(gòu)化分析方法YourdonE.和ConstantineL.等人提出是一種結(jié)構(gòu)化分析（StructuredAnalysis）方法。分析與描述工具數(shù)據(jù)流圖（DataflowDiagram）數(shù)據(jù)字典(DataDictionary,orDataaboutData)結(jié)構(gòu)化英語判定表和判定樹數(shù)據(jù)流圖中的主要圖形元素數(shù)據(jù)流圖描述銀行取款過程的數(shù)據(jù)流圖數(shù)據(jù)流與數(shù)據(jù)加工之間的關(guān)系數(shù)據(jù)流圖的層次結(jié)構(gòu)為了表達(dá)數(shù)據(jù)處理過程的數(shù)據(jù)加工情況，需要采用層次結(jié)構(gòu)的數(shù)據(jù)流圖。按照系統(tǒng)的層次結(jié)構(gòu)進行逐步分解，并以分層的數(shù)據(jù)流圖反映這種結(jié)構(gòu)關(guān)系，能清楚地表達(dá)和容易理解整個系統(tǒng)數(shù)據(jù)流圖的層次結(jié)構(gòu)在多層數(shù)據(jù)流圖中，頂層流圖僅包含一個加工，它代表被開發(fā)系統(tǒng)。它的輸入流是該系統(tǒng)的輸入數(shù)據(jù)，輸出流是系統(tǒng)所輸出數(shù)據(jù)底層流圖是指其加工不需再做分解的數(shù)據(jù)流圖，它處在最底層中間層流圖則表示對其上層父圖的細(xì)化。它的每一加工可能繼續(xù)細(xì)化，形成子圖。頂層流圖是一種高層的系統(tǒng)邏輯模型這個數(shù)據(jù)流圖只有一個，它反映了目標(biāo)系統(tǒng)要實現(xiàn)的功能確定系統(tǒng)的邊界：內(nèi)部實體和外部實體商店業(yè)務(wù)處理系統(tǒng)的頂層數(shù)據(jù)流圖數(shù)據(jù)流圖繪制步驟首先確定系統(tǒng)的輸入和輸出根據(jù)商店業(yè)務(wù)，畫出頂層數(shù)據(jù)流圖，以反映最主要業(yè)務(wù)處理流程經(jīng)過分析，商店業(yè)務(wù)處理的主要功能應(yīng)當(dāng)有銷售、采購、會計三大項。主要數(shù)據(jù)流輸入的源點和輸出終點是顧客和供應(yīng)商。然后從輸入端開始，根據(jù)商店業(yè)務(wù)工作流程，畫出數(shù)據(jù)流流經(jīng)的各加工框，逐步畫到輸出端，得到第一層數(shù)據(jù)流圖第一層數(shù)據(jù)流圖加細(xì)每一個加工框

銷售細(xì)化采購細(xì)化檢查和修改數(shù)據(jù)流圖的原則數(shù)據(jù)流圖上所有圖形符號只限于前述四種基本圖形元素數(shù)據(jù)流圖的主圖必須包括前述四種基本元素，缺一不可數(shù)據(jù)流圖的主圖上的數(shù)據(jù)流必須封閉在外部實體之間每個加工至少有一個輸入數(shù)據(jù)流和一個輸出數(shù)據(jù)流在數(shù)據(jù)流圖中，需按層給加工框編號。編號表明該加工所處層次及上下層的親子關(guān)系檢查和修改數(shù)據(jù)流圖的原則(cont.)規(guī)定任何一個數(shù)據(jù)流子圖必須與它上一層的一個加工對應(yīng)，兩者的輸入數(shù)據(jù)流和輸出數(shù)據(jù)流必須一致。此即父圖與子圖的平衡可以在數(shù)據(jù)流圖中加入物質(zhì)流，幫助用戶理解數(shù)據(jù)流圖圖上每個元素都必須有名字?jǐn)?shù)據(jù)流圖中不可夾帶控制流初畫時可以忽略瑣碎的細(xì)節(jié)，以集中精力于主要數(shù)據(jù)流機票預(yù)定系統(tǒng)頂層圖旅行社機票預(yù)定系統(tǒng)旅客取票單訂票單取票單機票機票預(yù)定系統(tǒng)0層圖旅行社預(yù)定機票1顧客取票2旅客取票通知單機票文件訂票單機票取票單一個數(shù)據(jù)流圖的例子帳單有效訂票單分類并檢索訂票記賬航班目錄記賬文件訂票單旅客旅行社旅行社準(zhǔn)備機票取票單航班機票文件有效取票單取票單機票數(shù)據(jù)流圖實例——采購管理系統(tǒng)P32數(shù)據(jù)詞典數(shù)據(jù)詞典與數(shù)據(jù)流圖配合，能清楚地表達(dá)數(shù)據(jù)處理的要求詞條描述——對于在數(shù)據(jù)流圖中每一個被命名的圖形元素，均加以定義，其內(nèi)容有:名字，別名或編號，分類，描述，定義，位置，其它，等（1）數(shù)據(jù)流詞條描述數(shù)據(jù)流名：說明：簡要介紹作用即它產(chǎn)生的原因和結(jié)果數(shù)據(jù)流來源：來自何方數(shù)據(jù)流去向：去向何處數(shù)據(jù)流組成：數(shù)據(jù)結(jié)構(gòu)數(shù)據(jù)量流通量：數(shù)據(jù)量，流通量（2）數(shù)據(jù)元素詞條描述數(shù)據(jù)元素名：類型：數(shù)字（離散值，連續(xù)值），文字（編碼類型）長度：取值范圍：相關(guān)的數(shù)據(jù)元素及數(shù)據(jù)結(jié)構(gòu)：（3）數(shù)據(jù)文件詞條描述數(shù)據(jù)文件名：簡述：存放的是什么數(shù)據(jù)輸入數(shù)據(jù)：輸出數(shù)據(jù)：數(shù)據(jù)文件組成：數(shù)據(jù)結(jié)構(gòu)存儲方式：順序，直接，關(guān)鍵碼存取頻率：（4）加工邏輯詞條描述加工名：加工編號：反映該加工的層次簡要描述：加工邏輯及功能簡述輸入數(shù)據(jù)流：輸出數(shù)據(jù)流：加工邏輯：簡述加工程序，加工順序（5）源點及匯(終)點詞條描述名稱：外部實體名簡要描述：什么外部實體有關(guān)數(shù)據(jù)流：數(shù)目：數(shù)據(jù)結(jié)構(gòu)的描述

符號

含義

舉例＝被定義為＋與

x=a＋b[...,...]或[...|...]或

x=[a,b]，x=[a|b]{...}或m{...}n重復(fù)

x={a}，x=3{a}8(...)可選

x=(a)“...”基本數(shù)據(jù)元素

x=“a”.. 連結(jié)符

x=1..9存折格式存折＝戶名＋所號＋帳號＋開戶日＋性質(zhì)＋（印密）＋1{存取行}50戶名＝2{字母}24所號＝“001”..“999”帳號＝“00000001”..“99999999”開戶日＝年＋月＋日性質(zhì)＝“1”..“6”注：“1”表示普通戶，“5”表示工資戶等印密＝“0”注：印密在存折上不顯示存取行＝日期＋（摘要）＋支出＋存入＋余額＋操作＋復(fù)核基本加工邏輯說明對數(shù)據(jù)流圖的每一個基本加工，必須有一個基本加工邏輯說明基本加工邏輯說明必須描述基本加工如何把輸入數(shù)據(jù)流變換為輸出數(shù)據(jù)流的加工規(guī)則加工邏輯說明必須描述實現(xiàn)加工的策略而不是實現(xiàn)加工的細(xì)節(jié)加工邏輯說明中包含的信息應(yīng)是充足的，完備的，有用的，沒有重復(fù)的多余信息用于寫加工邏輯說明的工具?

結(jié)構(gòu)化英語?

判定表?

判定樹（1）結(jié)構(gòu)化英語結(jié)構(gòu)化英語的詞匯表由英語命令動詞數(shù)據(jù)詞典中定義的名字有限的自定義詞邏輯關(guān)系詞

IF_THEN_ELSE、

CASE_OF、

WHILE_DO、

REPEAT_UNTIL等組成。是一種介于自然語言和形式化語言之間的語言語言的正文用基本控制結(jié)構(gòu)進行分割，加工中的操作用自然語言短語來表示其基本控制結(jié)構(gòu)有三種：簡單陳述句結(jié)構(gòu)：避免復(fù)合語句；重復(fù)結(jié)構(gòu)：WHILE_DO

或

REPEAT_UNTIL結(jié)構(gòu)。判定結(jié)構(gòu)：IF_THEN_ELSE

或

CASE_OF結(jié)構(gòu)；商店業(yè)務(wù)處理系統(tǒng)中“檢查發(fā)貨單”IF發(fā)貨單金額超過$500THENIF欠款超過了60天THEN

在償還欠款前不予批準(zhǔn)

ELSE（欠款未超期）發(fā)批準(zhǔn)書，發(fā)貨單

ENDIFELSE（發(fā)貨單金額未超過$500）

IF欠款超過60天THEN

發(fā)批準(zhǔn)書，發(fā)貨單及賒欠報告ELSE（欠款未超期）發(fā)批準(zhǔn)書，發(fā)貨單

ENDIFENDIF（2）判定表如果數(shù)據(jù)流圖的加工需要依賴于多個邏輯條件的取值，使用判定表來描述比較合適以“檢查發(fā)貨單”為例（3）判定樹判定樹也是用來表達(dá)加工邏輯的一種工具。有時侯它比判定表更直觀。結(jié)構(gòu)化分析方法小結(jié)

主要基于功能分解，僅是一個靜態(tài)模型，沒有反映處理的順序，即控制流程。因此，不適合描述實時控制系統(tǒng)。使用DFD在分析與描述“數(shù)據(jù)要求”方面是有局限的，DFD應(yīng)與數(shù)據(jù)庫技術(shù)中的ER圖結(jié)合起來。DFD不適合人機界面系統(tǒng)的需求。為更精確的描述軟件需求，提高軟件系統(tǒng)的可靠性、安全性，需用更形式化的描述方法。五、形式化分析技術(shù)非形式化與形式化方法的比較（p65）應(yīng)用形式化方法的準(zhǔn)則有窮狀態(tài)機Petri網(wǎng)Z語言非形式化方法的缺點矛盾（相互沖突的需求陳述）二義性（存在不同方式理解的陳述）含糊性（不確定性，不可驗證性）抽象層次混亂

……形式化方法的優(yōu)點能夠簡潔準(zhǔn)確地描述需求各個階段活動間的平滑過渡,便于實現(xiàn)軟件開發(fā)的自動化提