需求工程第03章2025/5/282第三章需求工程3.1概述3.2需求獲取方法3.3需求分析的任務(wù)與原則3.4需求建模方法3.5需求圖形工具3.6需求驗(yàn)證3.7需求管理2025/5/2833.1概述

3.1.1軟件需求定義

軟件需求分類

需求規(guī)格說明

需求工程概念

需求工程過程2025/5/2845.2軟件需求的分類軟件需求的定義2025/5/2853.1概述軟件需求工程的目的是定義軟件所需要解決的問題。軟件需求是要把一個(gè)定義不足和模糊的問題轉(zhuǎn)換為一個(gè)定義良好而準(zhǔn)確的問題，進(jìn)而找到解決問題的方案。2025/5/2863.1概述主要困難：軟件開發(fā)人員與用戶雙方固有的矛盾需求具有易變性和難以表述性 需求錯(cuò)誤的高頻性和修復(fù)的高成本性2025/5/287軟件開發(fā)的目標(biāo)是什么？開發(fā)高質(zhì)量的軟件；在預(yù)定的時(shí)間和預(yù)算約束下完成；軟件要能夠滿足顧客的需求。2025/5/288但實(shí)際情況是什么樣子？調(diào)查報(bào)告的數(shù)字是這樣的…51%15%34%StandishGroup2004SucceededChallengedFailed用戶參與程度高： 16%

用戶高層的支持： 14%對需求的清晰陳述： 12%缺乏用戶參與： 13%

需求規(guī)格說明不完整： 12%需求頻繁的發(fā)生變化： 12%結(jié)論：對用戶需求的管理水平是決定軟件成敗的重要原因2025/5/289[案例分析1]“只有結(jié)婚后才可以修改姓名嗎？”Phil開發(fā)了一套人力資源軟件，有一天他接到了人力資源部Maria打來的…Maria一個(gè)同事想把自己名字改為SparkleStarlight，但系統(tǒng)不允許，能幫忙嗎？Phil她嫁給了一個(gè)姓Starlight的人嗎？Maria不，她并沒有結(jié)婚，她只是想改名字而已；Phil系統(tǒng)只支持在改變婚姻狀況時(shí)才可以改名字。Maria可是每個(gè)人只要愿意就可以隨時(shí)改變自己的名字啊。Phil這并不是我的錯(cuò)！在開發(fā)系統(tǒng)之前，你從來沒有向我提起過有這種需求！Maria不管如何，請盡快把這個(gè)功能修改完畢，否則Sparkle無法支付她的銀行帳單。Phil如果你一開始就告訴我你想隨時(shí)改變某人的名字，那這些就都不會發(fā)生！……2025/5/2810“錯(cuò)誤的需求”的擴(kuò)散效應(yīng)問題正確的需求錯(cuò)誤的需求正確的設(shè)計(jì)基于“錯(cuò)誤的需求”的設(shè)計(jì)錯(cuò)誤的設(shè)計(jì)基于“錯(cuò)誤的設(shè)計(jì)”的編碼正確的編碼錯(cuò)誤的編碼基于“錯(cuò)誤的需求”的編碼2025/5/2811“錯(cuò)誤的需求”的修復(fù)代價(jià)“構(gòu)建一個(gè)軟件系統(tǒng)最困難的部分是確定構(gòu)建什么…在出錯(cuò)之后會嚴(yán)重影響隨后實(shí)現(xiàn)的系統(tǒng)，并且在以后的修補(bǔ)是如此的困難…”2025/5/2812“錯(cuò)誤的需求”所帶來的后果早期的需求錯(cuò)誤可能造成重新進(jìn)行規(guī)格說明、設(shè)計(jì)、編碼和測試改變訂單：告訴用戶和操作員用一個(gè)修正后的版本來代替有缺陷的版本糾正活動：消除由于不正確的系統(tǒng)錯(cuò)誤造成的一切危害，可能涉及到賠償客戶損失以及重新運(yùn)行系統(tǒng)等報(bào)廢：即使設(shè)計(jì)、代碼和測試完成得很好，由于它們是根據(jù)不正確的需求產(chǎn)生的，所以不得不被丟棄收回有缺陷的軟件產(chǎn)品以及相關(guān)的用戶手冊技術(shù)人員為客戶重新安裝新軟件所必須支付的服務(wù)成本2025/5/2813根本原因是什么？需求的鴻溝(期望差異)：開發(fā)者開發(fā)的與用戶所想得到的軟件存在著巨大期望差異。2025/5/2814什么是“軟件需求”軟件需求(SoftwareRequirements)：用戶解決問題以達(dá)到特定目標(biāo)所需的能力；系統(tǒng)或系統(tǒng)構(gòu)件要滿足的合同、標(biāo)準(zhǔn)、規(guī)范或其他正式文檔所需具備的能力； ——IEEE,1997指用戶對軟件的功能與性能需求,就是用戶希望軟件能夠做什么事情,完成哪些功能，達(dá)到哪些性能等。軟件需求：以一種清晰、簡潔、一致且無二義性的方式，描述用戶對目標(biāo)軟件系統(tǒng)在功能、行為、性能、設(shè)計(jì)約束等方面的期望，是在開發(fā)過程中對系統(tǒng)的約束。需求通常用于表達(dá)“做什么”，而不描述“如何做”。2025/5/2815“軟件需求”的作用“RequirementistheBasicsofQuality”充分理解現(xiàn)實(shí)中的業(yè)務(wù)問題，并作為軟件設(shè)計(jì)的基礎(chǔ)；為軟件項(xiàng)目的成本、時(shí)間、風(fēng)險(xiǎn)估計(jì)提供準(zhǔn)確的依據(jù)；減少開發(fā)工作量，避免將時(shí)間與資源浪費(fèi)在設(shè)計(jì)與實(shí)現(xiàn)錯(cuò)誤的需求上；通過提供需求文檔和需求基線，來有效的管理系統(tǒng)演化與變更；作為顧客與開發(fā)團(tuán)隊(duì)之間正式合同的一部分；為最終的驗(yàn)收測試提供標(biāo)準(zhǔn)和依據(jù)；2025/5/2816關(guān)于“需求”的例子CourseRegistrationSystem(學(xué)生選課系統(tǒng))某大學(xué)希望采用計(jì)算機(jī)管理學(xué)生的選課學(xué)生可以在一個(gè)學(xué)期開始之前選擇該學(xué)期開設(shè)的某些課程老師可以使用選課系統(tǒng)獲得選課學(xué)生的名單，并登記學(xué)生的課程學(xué)習(xí)成績學(xué)生不希望自己的學(xué)習(xí)成績被他人查閱……(你可以補(bǔ)充嗎？)以下描述是否屬于需求？為什么？系統(tǒng)通過JDBC與Oracle數(shù)據(jù)庫CourseDB建立連接，并使用T-SQL語句從CourseOffering數(shù)據(jù)表中獲得課程的開設(shè)信息。2025/5/28175.2軟件需求的分類軟件需求的分類2025/5/2818不同層次的軟件需求2025/5/28191.業(yè)務(wù)需求業(yè)務(wù)需求(BusinessRequirements)：客戶對于系統(tǒng)的高層次目標(biāo)要求(high-levelobjectives)

，定義了項(xiàng)目的遠(yuǎn)景和范疇(visionandscope)業(yè)務(wù)：屬于哪類業(yè)務(wù)范疇？應(yīng)完成什么功能？為何目的？客戶：軟件為誰服務(wù)？目標(biāo)客戶是誰？特性：區(qū)別于其他競爭產(chǎn)品的特性是什么？價(jià)值：價(jià)值體現(xiàn)在那些方面？優(yōu)先級：功能特性的優(yōu)先級次序是什么？[例]“圖書資料管理系統(tǒng)”的業(yè)務(wù)需求該系統(tǒng)使用計(jì)算機(jī)實(shí)現(xiàn)圖書資料日常管理，提高工作效率和服務(wù)質(zhì)量；該系統(tǒng)可讓用戶在網(wǎng)絡(luò)上查詢與瀏覽電子資料，改變原有的借閱模式；由于版權(quán)的限制，某些電子資料只能瀏覽/打印，但不能下載。2025/5/28202.用戶需求(目標(biāo)需求)用戶需求(UserRequirements)：從用戶角度描述的系統(tǒng)功能需求與非功能需求，通常只涉及系統(tǒng)的外部行為而不涉及內(nèi)部特性。[例]用戶可以通過Internet隨時(shí)查詢圖書信息和個(gè)人借閱情況，并可以快速查找和瀏覽需要的電子資料；[功能需求]用戶通過Internet查詢圖書信息；[功能需求]用戶通過Internet瀏覽個(gè)人借閱情況；[功能需求]用戶通過Internet查找和瀏覽電子資料；[非功能需求]隨時(shí)、快速2025/5/2821業(yè)務(wù)需求與用戶需求的對比針對CourseRegistrationSystem業(yè)務(wù)需求由于實(shí)行學(xué)分制管理，學(xué)校領(lǐng)導(dǎo)希望用計(jì)算機(jī)管理學(xué)生選課。課程信息維護(hù)、選課管理、課程成績登記和查詢等業(yè)務(wù)全部由手工方式改為計(jì)算機(jī)應(yīng)用。用戶需求教務(wù)管理員希望能夠增加、修改和刪除學(xué)校的課程目錄，并且設(shè)置各學(xué)期課程的開設(shè)信息。學(xué)生希望能夠在學(xué)期開始之前查詢所有開設(shè)課程的詳細(xì)信息，并能夠通過校園網(wǎng)進(jìn)行選課。學(xué)生希望在選課期間系統(tǒng)能夠24小時(shí)使用，系統(tǒng)使用方便快捷。2025/5/28223.功能需求功能需求(FunctionalRequirements,FR)：系統(tǒng)應(yīng)該提供的功能或服務(wù)，通常涉及用戶或外部系統(tǒng)與該系統(tǒng)之間的交互，不考慮系統(tǒng)內(nèi)部的實(shí)現(xiàn)細(xì)節(jié)；[例]用戶可從圖書資料庫中查詢或者選擇其中一個(gè)子集；系統(tǒng)可提供適當(dāng)?shù)臑g覽器供用戶閱讀館藏文獻(xiàn)；用戶每次借閱圖書應(yīng)對應(yīng)一個(gè)唯一的標(biāo)識號，它被記錄到用戶的賬戶上；2025/5/28234.非功能需求非功能需求(Non-FunctionalRequirements,NFR)：從各個(gè)角度對系統(tǒng)的約束和限制，反映了客戶對軟件系統(tǒng)質(zhì)量和性能(qualityandperformance)的額外要求，如響應(yīng)時(shí)間、數(shù)據(jù)精度、可靠性等。[例]系統(tǒng)在20秒內(nèi)響應(yīng)所有的請求；系統(tǒng)應(yīng)該每周7天、每天24小時(shí)都可使用；對一個(gè)沒有經(jīng)驗(yàn)的用戶而言，經(jīng)過2小時(shí)培訓(xùn)即可使用系統(tǒng)所有功能。注意：非功能需求隱含了對可選設(shè)計(jì)方案的一些關(guān)鍵影響體系結(jié)構(gòu)設(shè)計(jì)(e.g.,體系結(jié)構(gòu)風(fēng)格選擇)算法設(shè)計(jì)(e.g.,排序策略的選擇)2025/5/2824非功能需求的度量NFR：檢驗(yàn)起來非常困難，一般采用一些可度量的特性進(jìn)行描述。例如：即使對一個(gè)沒有經(jīng)驗(yàn)的用戶，系統(tǒng)也應(yīng)該很容易使用，且是用戶錯(cuò)誤降到最少；修改為：對一個(gè)沒有經(jīng)驗(yàn)的用戶來說，經(jīng)過2個(gè)小時(shí)的培訓(xùn)就應(yīng)該使用系統(tǒng)的全部功能。在這樣的培訓(xùn)之后，一個(gè)有經(jīng)驗(yàn)的用戶每天的出錯(cuò)平均數(shù)不應(yīng)超過2次。2025/5/2825NFR：檢驗(yàn)起來非常困難，一般采用一些可度量的特性進(jìn)行描述。非功能需求的度量非功能特性度量指標(biāo)速度每秒處理的事務(wù)用戶的響應(yīng)時(shí)間屏幕的刷新速度存儲空間字節(jié)數(shù)

RAM芯片數(shù)可用性培訓(xùn)時(shí)間幫助頁面數(shù)可靠性平均失敗時(shí)間系統(tǒng)無效的概率失敗發(fā)生率容錯(cuò)性失敗后的重啟次數(shù)事件引起失敗的比例失敗時(shí)數(shù)據(jù)崩潰的可能性2025/5/2826一個(gè)例子：拼寫檢查器業(yè)務(wù)需求：“用戶能有效地糾正文檔中的拼寫錯(cuò)誤”；用戶需求：“找出文檔中的拼寫錯(cuò)誤并通過一個(gè)提供的替換項(xiàng)列表來供選擇替換拼錯(cuò)的詞”；功能性需求：找到拼寫錯(cuò)誤的單詞并以高亮度提示顯示提供替換詞的對話框?qū)崿F(xiàn)整個(gè)文檔范圍的替換非功能性需求：正確的找到至少95%以上的錯(cuò)詞并100%的加以正確替換拼寫檢查的速度應(yīng)至少達(dá)到5000詞/秒。2025/5/28275.約束條件約束條件(Constraints)：系統(tǒng)設(shè)計(jì)和實(shí)現(xiàn)時(shí)必須滿足的限制條件，對其進(jìn)行權(quán)衡或調(diào)整是相當(dāng)困難的，甚至是不可能的；例如：系統(tǒng)必須用C++或其他面向?qū)ο笳Z言編寫；系統(tǒng)用戶接口需要采用圖形化界面；任取10秒，一個(gè)特定應(yīng)用所消耗的可用計(jì)算能力平均不超過50%；系統(tǒng)開發(fā)過程和交付文檔需遵循GB/T8567-2006標(biāo)準(zhǔn)；通訊接口必須符合ISO七層架構(gòu)。來源：法規(guī)政策、硬件/資源限制、開發(fā)語言、等等。2025/5/28286.業(yè)務(wù)規(guī)則業(yè)務(wù)規(guī)則(BusinessRule)：對某些功能的可執(zhí)行性或內(nèi)部執(zhí)行邏輯的一些限定條件。通常表達(dá)為“如果…，那么…”的形式通常是一些容易發(fā)生變化的功能；例如：如果借書卡類型為“教師”，那么一次借閱的最大數(shù)量為8本；如果訂單金額大于10000元，那么該訂單的折扣為10%；如果采購單金額在10萬到50萬之間，那么需要總經(jīng)理審批；2025/5/28297.外部接口需求外部接口需求(ExternalInterfaceRequirement)：描述系統(tǒng)與其所處的外部環(huán)境之間如何進(jìn)行交互，包括：用戶接口需求(UI)硬件接口需求軟件接口需求通信接口需求例如：“從<某些設(shè)備>讀取信號”“給<一些其它系統(tǒng)>發(fā)送消息”“以<某種格式>讀取文件”“能控制<一些硬件>”“采用<某種類型的>用戶界面”2025/5/2830關(guān)于需求的一些例子系統(tǒng)必須有能力支持100個(gè)以上的并發(fā)用戶，每個(gè)用戶可以處理操作任務(wù)的任選組合，平均響應(yīng)時(shí)間應(yīng)該小于1秒，最大響應(yīng)時(shí)間應(yīng)小于5秒。必須在對話窗口的中間顯示錯(cuò)誤警告，使用紅色的、14點(diǎn)加粗Arial字體。系統(tǒng)必須有能力存儲平均操作連續(xù)100天所產(chǎn)生的事務(wù)。系統(tǒng)應(yīng)該在5分鐘內(nèi)計(jì)算出給定季度的總銷售稅。系統(tǒng)應(yīng)該在1分鐘內(nèi)從1000000條記錄中檢索出一個(gè)銷售訂單。系統(tǒng)必須支持100個(gè)Windows工作站的并行訪問。系統(tǒng)可從各型號的modem上讀取信號作為系統(tǒng)輸入。2025/5/2831需求規(guī)格說明2025/5/28323.1概述

需求規(guī)格說明 需求規(guī)格說明是指軟件所應(yīng)滿足的全部要求，并用文檔方式完整和精確描述。全部要求是指軟件系統(tǒng)必須提供的功能和性能、約束條件和限制。2025/5/28335.2軟件需求的分類好的需求vs壞的需求2025/5/2834好的需求應(yīng)具備的特征完整性：每一項(xiàng)需求都必須將所要實(shí)現(xiàn)的功能描述清楚正確性：每一項(xiàng)需求都必須準(zhǔn)確地陳述其要開發(fā)的功能；可行性：每一項(xiàng)需求都必須是在已知系統(tǒng)和環(huán)境的權(quán)能和限制范圍內(nèi)可以實(shí)施的必要性：每一項(xiàng)需求都應(yīng)把客戶真正所需要的和最終系統(tǒng)所需遵從的標(biāo)準(zhǔn)記錄下來劃分優(yōu)先級：給每項(xiàng)需求、特性或使用實(shí)例分配一個(gè)實(shí)施優(yōu)先級以指明它在特定產(chǎn)品中所占的分量無二義性：對所有需求說明的讀者都只能有一個(gè)明確統(tǒng)一的解釋可驗(yàn)證性：檢查一下每項(xiàng)需求是否能通過設(shè)計(jì)測試用例或其它驗(yàn)證方法，如用演示、檢測等來確定產(chǎn)品是否確實(shí)按需求實(shí)現(xiàn)2025/5/2835產(chǎn)生不合格需求的原因無足夠用戶參與——“我不明白為什么要花那么多功夫收集需求”——“與其與用戶討論浪費(fèi)時(shí)間，不如寫代碼有意思”——“我已經(jīng)明白用戶需求了”用戶需求的不斷增加——若不斷增加新需求，項(xiàng)目就越來越龐大以致超過其計(jì)劃及預(yù)算范圍——開發(fā)中不斷延續(xù)的變更會使其整體結(jié)構(gòu)日漸紊亂，補(bǔ)丁代碼也使得整個(gè)程序難以理解和維護(hù)2025/5/2836產(chǎn)生不合格需求的原因模棱兩可的需求——諸多讀者對需求說明產(chǎn)生了不同的理解——單個(gè)讀者能用不止一個(gè)方式來解釋某個(gè)需求說明——后果：返工，重做一些你認(rèn)為已做好的事情不必要的特性——“畫蛇添足”，開發(fā)人員力圖增加一些“用戶欣賞”但需求規(guī)格說明中并未涉及的新功能——客戶可能要求一些看上去很“酷”，但缺乏實(shí)用價(jià)值的功能，而實(shí)現(xiàn)這些功能只能徒耗時(shí)間和成本2025/5/2837產(chǎn)生不合格需求的原因過于精簡的規(guī)格說明——給開發(fā)人員帶來挫折，使他們在不正確的假設(shè)前提和極其有限的指導(dǎo)下工作——給客戶帶來煩惱，他們無法得到他們所設(shè)想的產(chǎn)品忽略了用戶分類——軟件由不同的人使用其不同的特性——使用頻繁程度有所差異——使用者受教育程度和經(jīng)驗(yàn)水平也不盡相同不準(zhǔn)確的計(jì)劃——對需求分析缺乏理解會導(dǎo)致過分樂觀的估計(jì)——原因：頻繁的需求變更、遺漏的需求、與用戶交流不夠、質(zhì)量低下的需求規(guī)格說明和不完善的需求分析2025/5/2838[案例分析2]“他們忙，沒有時(shí)間與你討論需求…”Contoso公司的CEOGerhard約見軟件開發(fā)小組Cynthia，商討為公司開發(fā)新系統(tǒng)的事情…Gerhard我們需要建立一套化學(xué)制品跟蹤信息系統(tǒng)，可以記錄并查詢庫房或某個(gè)實(shí)驗(yàn)室中已有的化學(xué)藥品…你們小組能在五個(gè)月內(nèi)開發(fā)出該系統(tǒng)嗎？Cynthia我已經(jīng)明白這個(gè)項(xiàng)目的重要性了，但在我制定計(jì)劃前，我們必須收集一些系統(tǒng)的需求。Gerhard你什么意思？我不是剛告訴你我的需求了嗎？Cynthia你只說明了整個(gè)項(xiàng)目的概念與目標(biāo)，這些高層次的業(yè)務(wù)需求并不能為我們提供足夠的詳細(xì)信息以確定究竟要開發(fā)什么樣的軟件，以及需要多長時(shí)間。我需要一些分析人員與一些知道系統(tǒng)使用要求的化學(xué)專家進(jìn)行討論，然后才能真正明白達(dá)到業(yè)務(wù)目標(biāo)所需的各種功能和用戶的要求。Gerhard那些化學(xué)專家都非常忙，沒有時(shí)間與你們詳細(xì)討論各種細(xì)節(jié)，你不能讓你的手下的人說明要做的系統(tǒng)嗎？Cynthia如果我們只是憑空猜想用戶要求，結(jié)果不會令人滿意。Gerhard行了，行了，我們沒有那么多時(shí)間，我來告訴你需求，請馬上開始開發(fā)系統(tǒng)，并隨時(shí)將你們的進(jìn)展情況告訴我?！?025/5/2839好需求與壞需求1.在現(xiàn)實(shí)情況中，用戶存錢時(shí)并不需要信用檢查，因此這個(gè)需求描述是錯(cuò)誤的2.“適當(dāng)?shù)男袆印睂Σ煌娜藖碚f有不同的解釋，顯然是歧義的。改正：如果用戶試圖透支，系統(tǒng)將顯示錯(cuò)誤信息并拒絕取款操作。3.“盡快”是不可驗(yàn)證的，應(yīng)該給出具體數(shù)量值。改正：系統(tǒng)將在20秒內(nèi)響應(yīng)所有有效的請求。4.與5是矛盾的。考慮以下需求是否滿足“好需求”的標(biāo)準(zhǔn)，如不是，該如何修正？在用戶每次存錢時(shí)系統(tǒng)將進(jìn)行信用檢查；如果用戶試圖透支，系統(tǒng)將采取適當(dāng)?shù)男袆樱幌到y(tǒng)將盡可能快的響應(yīng)所有有效的請求；系統(tǒng)允許立即使用所存資金；只有在手工驗(yàn)證所存資金后，系統(tǒng)才能允許使用它；2025/5/2840需求規(guī)格說明軟件需求規(guī)格說明的一般格式：1．引言2．任務(wù)概述3．?dāng)?shù)據(jù)描述4．功能要求5．性能需求6．運(yùn)行需求7．其他要求（如可使用性、安全保密、可維護(hù)性、可移植性等）8．附錄2025/5/2841需求規(guī)格說明需求規(guī)格說明的特性如下：1．完整性 2.正確性3.可行性4.必要性5.無歧義性6.可驗(yàn)證性7.劃分優(yōu)先級2025/5/2842需求工程2025/5/28433.1概述

3.1.4需求工程概念需求工程就是應(yīng)用工程化的方法、技術(shù)和規(guī)格來開發(fā)和管理軟件的需求。需求工程的目標(biāo)是獲取高質(zhì)量的軟件需求。需求工程突出了工程化原則，強(qiáng)調(diào)以系統(tǒng)化、條理化和重復(fù)化的方法進(jìn)行軟件需求的相關(guān)活動，從而增強(qiáng)了管理性和降低了需求開發(fā)的成本2025/5/28443.1概述

3.1.4需求工程概念需求工程的任務(wù)：1．確定待開發(fā)的軟件系統(tǒng)的用戶，并獲取用戶的需求信息。2．分析用戶的需求信息，并按需求類型分類，過濾掉非需求的信息。3．根據(jù)需求信息建立軟件系統(tǒng)的邏輯模型和需求模型，確定非功能需求和約束條件及限制。2025/5/28453.1概述

3.1.4需求工程概念需求工程的任務(wù)：4．根據(jù)收集的需求信息和邏輯模型編寫需求規(guī)格說明及文檔。5．評審需求規(guī)格說明。6．當(dāng)需求變更時(shí)，對需求規(guī)格說明及需求變更實(shí)施進(jìn)行管理。2025/5/28463.1概述

需求工程過程需求工程過程分為需求開發(fā)和需求管理兩階段。2025/5/28473.1概述

需求工程過程1.需求獲取

確定和收集與待開發(fā)的軟件系統(tǒng)相關(guān)的用戶需求信息。2.需求分析

對獲得的用戶需求信息進(jìn)行分析和綜合，找出錯(cuò)誤和沖突及遺漏的地方，獲得用戶的準(zhǔn)確的需求，進(jìn)而建立軟件系統(tǒng)的邏輯模型或需求模型。3.需求定義

利用描述語言、標(biāo)準(zhǔn)格式書寫軟件系統(tǒng)的需求規(guī)格說明和文檔。2025/5/28483.1概述

需求工程過程4.需求驗(yàn)證

審查和驗(yàn)證軟件系統(tǒng)需求規(guī)格說明，進(jìn)而確定需求規(guī)格說明是否正確描述了用戶對軟件系統(tǒng)的需求。5.需求管理

需求管理的任務(wù)是管理軟件系統(tǒng)的需求規(guī)格說明和文檔，評估需求變更帶來的影響及成本費(fèi)用，跟蹤軟件需求的狀態(tài)，管理需求規(guī)格說明的版本等。2025/5/2849需求狀態(tài)跟蹤需求工程的總體流程需求獲取需求分析需求規(guī)格說明(SRS)需求驗(yàn)證客戶(client)終端用戶(user)市場人員維護(hù)人員基線(baseline)需求管理需求變更過程需求變更項(xiàng)目變更需求開發(fā)需求管理2025/5/2850需求開發(fā)所包含的活動確定產(chǎn)品所期望的用戶類獲取每個(gè)用戶類的需求了解實(shí)際用戶任務(wù)和目標(biāo)以及這些任務(wù)所支持的業(yè)務(wù)需求分析源于用戶的信息以區(qū)別用戶需求、功能需求、非功能需求、約束條件、建議解決方法和附加信息將系統(tǒng)級的需求分為幾個(gè)子系統(tǒng)，并將需求中的一部份分配給軟件構(gòu)件了解相關(guān)非功能屬性的重要性商討實(shí)施優(yōu)先級的劃分將所收集的用戶需求編寫成規(guī)格說明和模型評審需求規(guī)格說明，確保對用戶需求達(dá)到共同的理解與認(rèn)識，并在整個(gè)開發(fā)小組接受說明之前將問題都弄清楚2025/5/2851(1)需求獲取需求獲取(RequirementElicitation)：通過與用戶的交流，對現(xiàn)有系統(tǒng)的觀察及對任務(wù)進(jìn)行分析，從而開發(fā)、捕獲和修訂用戶的需求對用戶進(jìn)行分類聆聽每一類用戶的需求分析和整理所獲取的需求形成文檔化的描述簽字確認(rèn)2025/5/2852(2)需求分析需求分析(RequirementAnalysis)：對收集到的需求進(jìn)行提煉、分析和審查，為最終用戶所看到的系統(tǒng)建立概念化的分析模型定義系統(tǒng)的邊界建立軟件原型分析需求可行性確定需求優(yōu)先級建立需求分析模型創(chuàng)建數(shù)據(jù)字典2025/5/2853(3)形成需求規(guī)格說明需求規(guī)格說明(SoftwareRequirementSpecification,SRS)：需求開發(fā)的結(jié)果精確的、形式化的闡述一個(gè)軟件系統(tǒng)必須提供的功能、非功能、所要考慮的限制條件等作為用戶和開發(fā)者之間的一個(gè)契約是用戶、分析人員和設(shè)計(jì)人員之間進(jìn)行理解和交流的手段2025/5/2854(4)需求驗(yàn)證需求驗(yàn)證(RequirementVerification)：以需求規(guī)格說明為輸入，通過評審、模擬或快速原型等途徑，分析需求規(guī)格的正確性和可行性，發(fā)現(xiàn)存在的錯(cuò)誤或缺陷并及時(shí)更改和補(bǔ)充。2025/5/2855(5)需求管理需求管理(RequirementManagement)定義需求基線(迅速制定需求文檔的主體)評審提出的需求變更、評估每項(xiàng)變更的可能影響從而決定是否實(shí)施它以一種可控制的方式將需求變更融入到項(xiàng)目中使當(dāng)前的項(xiàng)目計(jì)劃與需求一致估計(jì)變更需求所產(chǎn)生影響并在此基礎(chǔ)上協(xié)商新的承諾(約定)讓每項(xiàng)需求都能與其對應(yīng)的設(shè)計(jì)、源代碼和測試用例聯(lián)系起來以實(shí)現(xiàn)跟蹤在整個(gè)項(xiàng)目過程中跟蹤需求狀態(tài)及其變更情況2025/5/2856需求管理需求管理變更控制版本控制需求跟蹤需求狀態(tài)跟蹤建議變更分析影響做出決策交流合并測量需求穩(wěn)定性確定需求文檔版本定義對其他需求的連接鏈定義對其他系統(tǒng)元素的連接鏈定義需求狀態(tài)跟蹤需求狀態(tài)2025/5/2857需求管理與需求開發(fā)的關(guān)系2025/5/28583.2需求獲取方法2025/5/2859需求獲取的基本步驟了解領(lǐng)域背景知識客戶分類(按角色)CxO部門經(jīng)理業(yè)務(wù)員管理員交流需求紀(jì)要問題？分類整理功能需求非功能需求約束條件業(yè)務(wù)規(guī)則外部接口需求建議解決方案優(yōu)先級排序沖突消解簽字確認(rèn)業(yè)務(wù)需求用戶需求2025/5/2860需求獲取的基本步驟第1步：了解相關(guān)背景和領(lǐng)域/行業(yè)的知識，確定產(chǎn)品所期望的用戶類；第2步：與客戶企業(yè)或組織的高層人員進(jìn)行交流，了解實(shí)際用戶任務(wù)和目標(biāo)以及這些任務(wù)所支持的業(yè)務(wù)需求；第3步：與客戶企業(yè)或組織的底層人員進(jìn)行交流，獲取每個(gè)用戶類的詳細(xì)的用戶需求；第4步：整理需求紀(jì)要，發(fā)現(xiàn)新問題，并重復(fù)1-3步；第5步：需求分類和組織，以區(qū)別功能需求、非功能需求、約束條件、業(yè)務(wù)規(guī)則、外部接口需求、建議解決方法和附加信息；第6步：優(yōu)先排序和沖突解決；第7步：得到最終需求清單，并與客戶做最終簽字確認(rèn)。2025/5/2861“看似簡單，實(shí)際卻很難…”——“需求獲取？不就是問問題嗎？這有什么難的？”2025/5/2862需求獲取過程2025/5/28633.2需求獲取方法1．確定需求開發(fā)計(jì)劃 本項(xiàng)工作的基本任務(wù)是確定需求開發(fā)的步驟，提出收集需求活動的具體安排和進(jìn)度。2．確定項(xiàng)目范圍和目標(biāo) 項(xiàng)目目標(biāo)主要指項(xiàng)目開發(fā)的目的和意義，以及軟件系統(tǒng)的目標(biāo)。3．確定調(diào)查對象 確定調(diào)查對象的基本任務(wù)是明確地確定來自不同層次的需求來源和用戶，并將其分類。2025/5/28643.2需求獲取方法4．實(shí)地收集用戶需求信息 實(shí)地收集需求信息階段的任務(wù)是到現(xiàn)場實(shí)地調(diào)查和與用戶交流，收集和理解用戶需求信息。5．確定非功能性需求 非功能需求是表明軟件能否良好運(yùn)行的定性指標(biāo)。常用的非功能性需求如下：①可靠性②可用性③安全性④互操作性⑤易用性⑥可維護(hù)性⑦可移植性⑧可用性⑨健壯性2025/5/2865需求獲取技術(shù)需求獲取的關(guān)鍵：溝通和交流所要避免的問題：交流障礙、溝通不全、意見沖突所要必備的條件：較高的技術(shù)水平、豐富的實(shí)踐經(jīng)驗(yàn)、較強(qiáng)的人際交往能力可能采取的手段：用戶訪談、現(xiàn)場考察、專家咨詢、會議討論、…2025/5/2866需求獲取技術(shù)面對面訪談(face-to-faceinterviewing)專題討論會(workshop)現(xiàn)場觀察(observingonthescene)頭腦風(fēng)暴(brainstorming)多種方法要復(fù)合在一起使用，效果更好2025/5/2867面對面訪談2025/5/2868面對面訪談需求獲取中最直接的方法：用戶面談(interviewing)“看起來很美”，但“做起來并不容易”——需求分析者個(gè)人的偏見、事先的理解、以往的經(jīng)驗(yàn)積累是導(dǎo)致面談失敗的最重要原因——在面談時(shí)，忘掉一切以往所作的事情，通過問題啟發(fā)，傾聽對方的陳述——不要把自己放在“專家”的位置上2025/5/2869如何提問？“每個(gè)人都能提問題，但并不等于人人都會提問題…”封閉式問題：對錯(cuò)判斷或多項(xiàng)選擇題，回答只需要一兩個(gè)詞開放式問題：這種問題需要解釋和說明，同時(shí)向?qū)Ψ奖硎灸銓λ麄冋f的話很感興趣，還想了解更多的內(nèi)容。通過提問題增強(qiáng)你對談話進(jìn)展和方向的控制問題不能過于寬泛最開始的問題不能太難不能在提問之前就已經(jīng)表示不贊同談話之前有意識的準(zhǔn)備一些備用問題2025/5/2870訪談問題的分類上下文無關(guān)的問題(context-freequestions)：充分理解用戶的問題，不涉及具體的解決方案客戶是誰？最終用戶是誰？不同用戶的需求是否不同？這種需求目前的解決方案是什么？解決方案相關(guān)的問題(solution-contextquestions)：通過這類問題，探尋特定的解決方案并得到用戶認(rèn)可你希望如何解決這個(gè)問題？你覺得該問題這樣解決如何？2025/5/2871面談之前確立面談目的確定要包括的相關(guān)用戶確定參加會議的項(xiàng)目小組成員建立要討論的問題和要點(diǎn)列表復(fù)查有關(guān)文檔和資料確立時(shí)間和地點(diǎn)通知所有參加者有關(guān)會議的目的、時(shí)間和地點(diǎn)2025/5/2872面談之中Step1：事先準(zhǔn)備一系列上下文無關(guān)的問題，并將其記錄下來以便面談時(shí)參考；Step2：面談前，了解一下要面談的客戶公司的背景資料，不要選擇自己能回答的問題而浪費(fèi)時(shí)間；Step3：面談過程中，參考事先準(zhǔn)備的面談模板，以保證提出的問題是正確的。將答案記錄到紙面上，并指出和記錄下未回答條目和未解決問題；Step4：面談之后，分析總結(jié)面談記錄。2025/5/2873面談之后復(fù)查筆記的準(zhǔn)確性、完整性和可理解性把所收集的信息轉(zhuǎn)化為適當(dāng)?shù)哪Ｐ秃臀臋n確定需要進(jìn)一步澄清的問題域向參加會議的每一個(gè)人發(fā)出此次面談的minutes(會議紀(jì)要)。2025/5/2874面談記錄的示例(1)第一部分：建立客戶或用戶情況表第二部分：評估問題詢問用戶對哪些類型的問題缺乏好的解決方案它們是什么？(不斷的問“還有嗎？”)第三部分：理解用戶環(huán)境誰是用戶？他們的經(jīng)歷和經(jīng)驗(yàn)如何？用戶的預(yù)期如何？第四部分：扼要說明理解情況你剛才告訴我：(用自己的話復(fù)述客戶描述的問題)這是否足以表達(dá)你現(xiàn)在的解決方案中存在的問題？如果有，你還有什么問題？2025/5/2875面談記錄的示例(2)第五部分：分析人員對客戶問題的輸入對每個(gè)問題進(jìn)行以下提問：這是一個(gè)實(shí)際的問題嗎？問題產(chǎn)生的原因是什么？現(xiàn)在如何解決的？希望如何解決？該問題的重要度如何？第六部分：評估自己的解決方案總結(jié)自己建議的解決方案；對自己方案的優(yōu)先級排序；第七部分：評估機(jī)會第八部分：評估可靠性、性能及其他需要2025/5/2876面談記錄的示例(3)第九部分：其他需求法律法規(guī)、環(huán)境、行業(yè)標(biāo)準(zhǔn)等；第十部分：總結(jié)性提問還有其他問題要問面談人嗎？尚未解決的問題有哪些？下次訪談的方式、地點(diǎn)、時(shí)間、參加人等；第十一部分：分析人員的總結(jié)總結(jié)出客戶/用戶確認(rèn)的三條優(yōu)先級最高的需求或問題。2025/5/2877面對面訪談的優(yōu)缺點(diǎn)分析優(yōu)點(diǎn)：人們很愿意談?wù)撟约旱墓ぷ?，并且總是很喜歡接受訪談；缺點(diǎn)：大多數(shù)人都采用專業(yè)術(shù)語和“行話”，而太多的專業(yè)術(shù)語讓需求工程師難以理解，往往造成很多誤解；有些需求對用戶來說太普通了，以至于他們不自覺地認(rèn)為這些需求太基本，不值得去提。但它們對需求工程師來說卻不是顯而易見的。這往往會造成某些需求被忽略；2025/5/2878需求研討會(Workshop)2025/5/2879需求研討會(Workshop)2025/5/2880需求研討會(Workshop)通過讓所有相關(guān)人員一起參加某個(gè)單一會議來定義需求或設(shè)計(jì)系統(tǒng)，也稱聯(lián)合應(yīng)用設(shè)計(jì)會議(JointApplicationDesign,JAD)。系統(tǒng)相關(guān)者在短暫而緊湊的時(shí)間段內(nèi)集中在一起，一般為1至2天，與會者可以在應(yīng)用需求上達(dá)成共識、對操作過程盡快取得統(tǒng)一意見。協(xié)助建立一支高效團(tuán)隊(duì)，圍繞一個(gè)目的：項(xiàng)目的成功；所有人員都暢所欲言；促進(jìn)用戶與開發(fā)團(tuán)隊(duì)之間達(dá)成共識；能夠揭露和解決那些妨礙項(xiàng)目成功的行政問題；最終很快產(chǎn)生初步的系統(tǒng)定義。2025/5/2881需求研討會(Workshop)專題討論會準(zhǔn)備參加會議人員：主持人、用戶、技術(shù)人員、項(xiàng)目組人員安排日程通常在具有相應(yīng)支持設(shè)備的專用房間進(jìn)行舉行會議可能出現(xiàn)人員之間的責(zé)備或沖突，主持人應(yīng)掌握討論氣氛并控制會場最重要的部分是自由討論階段，這種技術(shù)非常符合專題討論會的氣氛，并且營造一種創(chuàng)造性的和積極的氛圍，同時(shí)可以獲得所有相關(guān)者的意見分配會議時(shí)間，記錄所有言論2025/5/2882現(xiàn)場觀察用戶可能無法有效全面的表達(dá)自己的需求，通過面談和會議也難以獲得完整信息；在這種情況下，現(xiàn)場觀察用戶的工作流程有助于更深入全面了解需求。兩種方式：被動觀察：用戶實(shí)地工作，需求分析人員在旁邊看主動觀察：需求分析人員直接參與用戶的實(shí)際工作2025/5/2883頭腦風(fēng)暴(Brainstorming)2025/5/2884頭腦風(fēng)暴(Brainstorming)一般以8-12人最佳：人數(shù)太少不利于交流信息和激發(fā)思維；人數(shù)太多則不容易掌握，并且每個(gè)人發(fā)言的機(jī)會相對減少明確分工：1名主持人、2名記錄員成功要點(diǎn)：自由暢談延遲批判、禁止批評禁止批評、自我批評、自謙追求數(shù)量會后：修剪、分組、排序適用場合：產(chǎn)品型系統(tǒng)，需要具有創(chuàng)新性特征，尚未投放市場，無明確的客戶。2025/5/28853.3需求分析的任務(wù)與原則

需求分析的任務(wù)

需求分析的原則

2025/5/2886需求工程過程需求工程過程分為需求開發(fā)和需求管理兩階段。2025/5/28873.3需求分析的任務(wù)與原則

需求分析的任務(wù)需求分析的基本任務(wù)是分析與綜合已收集到的需求信息，通過分析找出需求信息內(nèi)在聯(lián)系和可能的矛盾，通過綜合找出解決問題的方法并建立系統(tǒng)的邏輯模型。具體地說，需求分析是提煉、分析和審查已收集到的需求信息，找出真正的和具體的需求，并確保所有相關(guān)人員都理解其含義。2025/5/28883.3需求分析的任務(wù)與原則

需求分析的任務(wù)繪制系統(tǒng)關(guān)聯(lián)圖 關(guān)聯(lián)圖是用于定義系統(tǒng)與系統(tǒng)外部實(shí)體間的界限和接口的簡單模型。

2.創(chuàng)建用戶接口原型 當(dāng)開發(fā)人員或用戶不能確定軟件需求時(shí)，開發(fā)一個(gè)用戶接口原型(可能的局部實(shí)現(xiàn))，這樣使得許多概念和可能發(fā)生的事更為直觀明了。2025/5/28893.3需求分析的任務(wù)與原則

需求分析的任務(wù)3.分析需求可行性 在允許的成本、性能要求下，分析每項(xiàng)需求實(shí)施的可行性。4.確定需求的優(yōu)先級 應(yīng)用分析方法來確定使用實(shí)例、產(chǎn)品特性或單項(xiàng)需求實(shí)現(xiàn)的優(yōu)先級。5.為需求建立模型 需求的圖形分析模型是軟件需求規(guī)格說明的補(bǔ)充說明。2025/5/28903.3需求分析的任務(wù)與原則

需求分析的任務(wù)6.創(chuàng)建數(shù)據(jù)字典 數(shù)據(jù)字典是對系統(tǒng)用到的所有數(shù)據(jù)項(xiàng)和結(jié)構(gòu)的定義，以確保開發(fā)人員使用統(tǒng)一的數(shù)據(jù)定義。7.質(zhì)量功能調(diào)配 質(zhì)量功能調(diào)配是一種高級系統(tǒng)技術(shù)，它將產(chǎn)品特性、屬性與對客戶的重要性聯(lián)系起來。該技術(shù)提供了一種分析方法以明確那些是客戶最為關(guān)注的特性。2025/5/28913.3需求分析的任務(wù)與原則

3.3.2需求分析的原則1．必須能夠表達(dá)和理解問題的數(shù)據(jù)域和功能域 對于計(jì)算機(jī)程序處理的數(shù)據(jù)，其數(shù)據(jù)域應(yīng)包括數(shù)據(jù)流、數(shù)據(jù)內(nèi)容和數(shù)據(jù)結(jié)構(gòu)。就是將一種形式的數(shù)據(jù)轉(zhuǎn)換成另一種形式的數(shù)據(jù)。2025/5/28923.3需求分析的任務(wù)與原則

3.3.2需求分析的原則2.按自頂向下、逐層分解問題

分解問題是把問題以某種方式分解為幾個(gè)較易理解的部分，并確定各部分間的接口，從而實(shí)現(xiàn)整體功能。在需求分析階段，軟件的功能域和信息域都能做進(jìn)一步的分解。這種分解可以是同一層次上的，稱為橫向分解；也可以是多層次的縱向分解。2025/5/28933.3需求分析的任務(wù)與原則

3.3.2需求分析的原則3.要給出系統(tǒng)的邏輯視圖和物理視圖這對系統(tǒng)滿足處理需求所提出的邏輯限制條件和系統(tǒng)中其他成分提出的物理限制條件是必不可少的。

軟件需求的邏輯視圖給出軟件要達(dá)到的功能和要處理數(shù)據(jù)之間的關(guān)系。軟件需求的物理視圖給出處理功能和數(shù)據(jù)結(jié)構(gòu)的實(shí)際表示形式。

2025/5/28943.4需求建模方法

結(jié)構(gòu)化需求建模方法

數(shù)據(jù)流圖

數(shù)據(jù)字典

2025/5/28953.4需求建模方法需求建模方法的共同特性： 1．提供描述手段 2．提供基本步驟建模方法主要包括結(jié)構(gòu)化的需求建模方法和面向?qū)ο蟮男枨蠼７椒?025/5/28963.4需求建模方法

結(jié)構(gòu)化需求建模方法基本特點(diǎn)是表達(dá)問題時(shí)盡可能使用圖形符號的形式，設(shè)計(jì)數(shù)據(jù)流圖時(shí)只考慮系統(tǒng)必須完成的基本功能，不必考濾如何具體實(shí)現(xiàn)這些功能。基本思想是按照由抽象到具體、逐層分解的方法，確定軟件系統(tǒng)內(nèi)部的數(shù)據(jù)流、變換關(guān)系，并用數(shù)據(jù)流圖表示。描述手段①一套分層的數(shù)據(jù)流圖②一本詞典③其他補(bǔ)充材料2025/5/2897數(shù)據(jù)流圖(DFD)數(shù)據(jù)流圖(DataFlowDiagram,DFD)：結(jié)構(gòu)化系統(tǒng)分析的基本工具描繪數(shù)據(jù)在系統(tǒng)中各邏輯功能模塊之間的流動和處理過程，是一種功能模型主要刻畫“功能的輸入和輸出數(shù)據(jù)”、“數(shù)據(jù)的源頭和目的地”2025/5/2898DFD的主要元素銷售訂單1錄入訂單銷售訂單客戶數(shù)據(jù)流加工數(shù)據(jù)存儲外部實(shí)體2025/5/2899DFD的主要元素(1)：加工加工(又稱數(shù)據(jù)處理，dataprocessing)：對數(shù)據(jù)流進(jìn)行某些操作或變換。收集、排序、選擇、聚集、分析等加工要有名字，通常是動詞短語，簡明地描述完成什么事情在分層的數(shù)據(jù)流圖中，加工還應(yīng)編號三種類型：計(jì)算機(jī)自動加工、手工加工、人機(jī)協(xié)作的加工1錄入訂單2審核訂單2025/5/28100DFD的主要元素(2)：數(shù)據(jù)存儲數(shù)據(jù)存儲(datastorage，也稱文件)：需要在外存儲器上保存的數(shù)據(jù)，它可以是數(shù)據(jù)庫文件或任何形式的數(shù)據(jù)組織。以名詞命名銷售訂單銷售訂單銷售訂單2025/5/28101DFD的主要元素(3)：外部實(shí)體外部實(shí)體(externalentity)：本系統(tǒng)外部環(huán)境中的實(shí)體(包括人員、組織或其他軟件系統(tǒng))也稱為“數(shù)據(jù)源點(diǎn)/數(shù)據(jù)終點(diǎn)”，表示產(chǎn)生數(shù)據(jù)的源頭或消費(fèi)數(shù)據(jù)的終點(diǎn)以名詞短語命名不能直接訪問數(shù)據(jù)存儲客戶學(xué)生庫存系統(tǒng)旅行社2025/5/28102DFD的主要元素(4)：數(shù)據(jù)流銷售訂單數(shù)據(jù)流(dataflow)：數(shù)據(jù)在系統(tǒng)內(nèi)傳播的路徑由一組成分固定的數(shù)據(jù)組成。由于數(shù)據(jù)流是流動中的數(shù)據(jù)，所以必須有流向應(yīng)用名詞或名詞短語命名可能是紙張上的數(shù)據(jù)、電子數(shù)據(jù)、通過網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)等可能存在于：外部實(shí)體與加工之間；加工與加工之間；加工與數(shù)據(jù)存儲之間2025/5/28103DFD的簡單練習(xí)背景：用戶輸入a、b、c、d四個(gè)值，系統(tǒng)計(jì)算(a+b)*(c+a*d)，并將結(jié)果輸出到一個(gè)文件中存儲。問題：繪制該系統(tǒng)的DFD2025/5/28104DFD的層次性DFD的層次性：自頂向下的分解(top-down)DFD的兩種類型：環(huán)境關(guān)聯(lián)DFD圖(Context-levelDFD，或ContextDiagram)：也稱頂層DFD圖，描述了系統(tǒng)與外部環(huán)境之間的數(shù)據(jù)輸入/輸出關(guān)系；系統(tǒng)內(nèi)部DFD圖(Inner-levelDFD)：描述系統(tǒng)內(nèi)部各功能模塊之間的數(shù)據(jù)流動關(guān)系0-層DFD圖1-層DFD圖…N層DFD圖2025/5/28105頂層DFD頂層DFD圖(關(guān)聯(lián)圖)通過系統(tǒng)和外部世界之間的聯(lián)系來描述系統(tǒng)的范圍確定了通過某一接口與系統(tǒng)相連的外部實(shí)體，同時(shí)也確定了外部實(shí)體和系統(tǒng)之間的數(shù)據(jù)流只包含一個(gè)加工，用以表示被開發(fā)的系統(tǒng)，然后考慮該系統(tǒng)有哪些輸入數(shù)據(jù)、輸出數(shù)據(jù)流編號：02025/5/28106示例：頂層DFD2025/5/281070層DFD將頂層DFD圖中的系統(tǒng)分解為若干個(gè)子系統(tǒng)，決定每個(gè)子系統(tǒng)間的數(shù)據(jù)接口和活動關(guān)系，得到0層DFD圖；編號：1、2、…、n2025/5/28108底層DFD針對0層DFD中的每一個(gè)子系統(tǒng)，對其繼續(xù)分解得到細(xì)化的加工，進(jìn)而逐漸向下構(gòu)造得到1層DFD、2層DFD、…、n層DFD，一直到不能或不需再分解為止。最底層DFD中的加工稱為“基本加工”。編號：1層DFD：1.1、1.2、…、1.n2層DFD：、、…、…2025/5/28109底層DFD0層DFD1層DFD2025/5/28110數(shù)據(jù)流的分解2025/5/28111如何識別數(shù)據(jù)流通過識別“事件”來識別數(shù)據(jù)流，進(jìn)而識別得到加工、數(shù)據(jù)存儲事件的分類：外部事件(Externalevents)：外部實(shí)體與系統(tǒng)進(jìn)行交互(顧客下訂單、供應(yīng)商的貨物到達(dá))決策事件(Decisionevents)：需要外部實(shí)體為系統(tǒng)某些業(yè)務(wù)做出決策(是否接受訂單)時(shí)間性事件(Temporalevents)：由時(shí)間所觸發(fā)的周期性時(shí)間(每月25號編制下月計(jì)劃、每天17點(diǎn)盤點(diǎn)庫存)狀態(tài)事件(Stateevents)：由某些數(shù)據(jù)的變化所自動觸發(fā)的事件(當(dāng)庫存量下降到100以下時(shí)，啟動采購流程)2025/5/28112繪制DFD的一些基本原則把數(shù)據(jù)存儲放在0層數(shù)據(jù)流圖或更低層子圖上，不要放在頂層的關(guān)聯(lián)圖上使用數(shù)據(jù)流圖時(shí)，不要試圖讓數(shù)據(jù)流圖反映處理的順序，忽略系統(tǒng)的運(yùn)行時(shí)的時(shí)間特性加工通過數(shù)據(jù)存儲進(jìn)行通訊，而盡量避免從一個(gè)過程直接流到另一過程2025/5/28113繪制DFD的一些基本原則外部實(shí)體1外部實(shí)體2數(shù)據(jù)流數(shù)據(jù)存儲1外部實(shí)體1數(shù)據(jù)流數(shù)據(jù)存儲1外部實(shí)體1數(shù)據(jù)流數(shù)據(jù)存儲1數(shù)據(jù)流數(shù)據(jù)存儲2數(shù)據(jù)不能直接由一個(gè)數(shù)據(jù)存儲直接流到另一個(gè)數(shù)據(jù)存儲數(shù)據(jù)不能直接從一個(gè)外部實(shí)體直接流到一個(gè)數(shù)據(jù)存儲數(shù)據(jù)不能直接從一個(gè)數(shù)據(jù)存儲直接流到一個(gè)外部實(shí)體數(shù)據(jù)不能直接在外部實(shí)體之間流動2025/5/28114繪制DFD的一些基本原則數(shù)據(jù)流是單向的任何加工必須有輸入和輸出數(shù)據(jù)流對現(xiàn)有加工進(jìn)行持續(xù)的分解和組合，直到所有加工之間達(dá)到較高的聚合度；盡量將每一張DFD上的所有元素?cái)?shù)目控制在7-12個(gè)。2025/5/28115父圖與子圖的平衡下層DFD中的輸入輸出數(shù)據(jù)流同上層DFD中相應(yīng)加工的輸入輸出數(shù)據(jù)流必須一致，此即父圖與子圖的平衡。1.1加工1.2加工1.3加工abcde1.1.1加工1.1.2加工1.1.3加工aa1a2bc2025/5/28116父圖與子圖的平衡數(shù)據(jù)流本身可以分解，但其包含的數(shù)據(jù)內(nèi)容應(yīng)保持平衡1.1加工1.2加工1.3加工abcde1.3.1加工1.3.2加工1.3.3加工cc1c2d1d2d1+d2=d2025/5/28117DFD實(shí)例：銷售系統(tǒng)某企業(yè)銷售管理系統(tǒng)：接受顧客的訂單，檢驗(yàn)訂單，若庫存有貨，進(jìn)行供貨處理，即修改庫存，給倉庫開備貨單，并且將訂單留底；若庫存量不足，將缺貨訂單登入缺貨記錄。根據(jù)缺貨記錄進(jìn)行缺貨統(tǒng)計(jì)，將缺貨通知單發(fā)給采購部門，以便采購。根據(jù)采購部門發(fā)來的進(jìn)貨通知單處理進(jìn)貨，即修改庫存，并從缺貨記錄中取出缺貨訂單進(jìn)行供貨處理。根據(jù)留底的訂單進(jìn)行銷售統(tǒng)計(jì)，打印統(tǒng)計(jì)表給經(jīng)理。繪制上述系統(tǒng)的頂層、0層、1層DFD圖2025/5/28118銷售系統(tǒng)頂層DFD2025/5/28119銷售系統(tǒng)0層DFD2025/5/28120銷售系統(tǒng)1層DFD2025/5/28121銷售系統(tǒng)1層DFD2025/5/28122銷售系統(tǒng)1層DFD2025/5/28123DFD樹頂層DFD0層DFD1層DFD2層DFD2025/5/28124數(shù)據(jù)流圖1．?dāng)?shù)據(jù)流圖的含義數(shù)據(jù)流圖從數(shù)據(jù)傳遞和加工的角度，以圖形的方式刻畫數(shù)據(jù)流從輸入到輸出的傳輸變換過程。

2．?dāng)?shù)據(jù)流圖的特性（1）抽象性（2）概括性（3）層次性3.數(shù)據(jù)流圖基本符號（1）源點(diǎn)（2）加工（3）數(shù)據(jù)流（4）數(shù)據(jù)存儲文件4．?dāng)?shù)據(jù)流圖的用途--作為交流信息的工具。2025/5/28125數(shù)據(jù)流圖5．?dāng)?shù)據(jù)流圖的優(yōu)缺點(diǎn)

(1)總體概念強(qiáng)，每一層都明確強(qiáng)調(diào)干什么，需要什么，給出什么。

(2)可以反映出數(shù)據(jù)的流向和處理過程。

(3)由于自頂向下分析，容易及早發(fā)現(xiàn)并修正系統(tǒng)各部分的邏輯錯(cuò)誤。

(4)容易與計(jì)算機(jī)處理相對照。

(5)不直觀

(6）人工繪制太麻煩，工作量較大。2025/5/28126數(shù)據(jù)流圖6．?dāng)?shù)據(jù)流圖的畫法(1)畫數(shù)據(jù)流圖的一般原則畫數(shù)據(jù)流圖的基本步驟概括地說，就是自外向內(nèi)，自頂向下，逐層細(xì)化，完善求精。(2)數(shù)據(jù)流圖的分層方法

2025/5/28127數(shù)據(jù)流圖7．?dāng)?shù)據(jù)流圖的繪制與其他流程圖的差別(1)數(shù)據(jù)流圖與系統(tǒng)流程圖的區(qū)別將物流與資金流排除在外(2)數(shù)據(jù)流與程序流程圖的區(qū)別只反映數(shù)據(jù)的流向、處理邏輯和必要的數(shù)據(jù)存儲，它不反映處理邏輯的先后的時(shí)間順序2025/5/28128數(shù)據(jù)流圖7．?dāng)?shù)據(jù)流圖的繪制與其他流程圖的差別(3)數(shù)據(jù)流與程序結(jié)構(gòu)圖的區(qū)別不反映控制關(guān)系、調(diào)用關(guān)系、控制流，只畫數(shù)據(jù)流(4)數(shù)據(jù)流與控制流的區(qū)別有數(shù)據(jù)（指表示事物的信息，而不是控制信號）流過2025/5/28129數(shù)據(jù)字典1．?dāng)?shù)據(jù)字典的定義數(shù)據(jù)字典是定義目標(biāo)系統(tǒng)中使用的所有數(shù)據(jù)元素和結(jié)構(gòu)的含義、類型、數(shù)量值、格式和度量單位、精度及允許取值范圍內(nèi)的共享數(shù)據(jù)倉庫。2．?dāng)?shù)據(jù)字典的內(nèi)容（l）數(shù)據(jù)流（2）數(shù)據(jù)項(xiàng)（3）數(shù)據(jù)結(jié)構(gòu)（4）數(shù)據(jù)存儲（5）處理邏輯（6）外部實(shí)體3．定義數(shù)據(jù)的方法--對數(shù)據(jù)自頂向下的分解2025/5/28130數(shù)據(jù)字典4．?dāng)?shù)據(jù)字典的用途數(shù)據(jù)字典最重要的用途是作為分析階段的工具。

5．?dāng)?shù)據(jù)字典的實(shí)現(xiàn)目前實(shí)現(xiàn)數(shù)據(jù)字典有三種常見的途徑：全人工過程，全自動化過程（利用數(shù)據(jù)字典處理程序）和混合過程（用正文編輯程序、報(bào)告生成程序等已有的實(shí)用程序幫助人工過程）。2025/5/28131數(shù)據(jù)字典(DD)DFD只是繪制了系統(tǒng)各功能之間的數(shù)據(jù)流動和處理關(guān)系，還需進(jìn)一步考慮各數(shù)據(jù)的具體內(nèi)容。采用數(shù)據(jù)字典(DataDictionary)作為描述工具對于DFD中出現(xiàn)的所有被命名的圖形元素(數(shù)據(jù)流、數(shù)據(jù)項(xiàng)、數(shù)據(jù)存儲、加工)在DD中作為一個(gè)詞條加以定義，使得每一個(gè)圖形元素的名字都有一個(gè)確切的解釋。DD所有的定義應(yīng)是嚴(yán)密的、精確的，不可有半點(diǎn)含混，不可有二義性。2025/5/28132數(shù)據(jù)字典的格式符號含義示例=被定義為+與x=a+b[…|…]或x=[a|b]{…}m重復(fù)(最多m次，最少n次)x={a}5n2{…}重復(fù)x={a}(…)可選x=(a)“…”基本數(shù)據(jù)元素x=“a”..連接符x=1..92025/5/28133數(shù)據(jù)字典的格式：示例1國內(nèi)機(jī)票=姓名+身份證號+日期+航班號+起點(diǎn)+終點(diǎn)+費(fèi)用

姓名=[{字母}|{漢字}

]

航班號=[CA|MU|CZ|SC|FM]+“1000”..“9999”

181522025/5/28134數(shù)據(jù)字典的格式：示例2存折=戶名+開戶行號+賬號+開戶日期+性質(zhì)+(印密)+存取記錄戶名={字母}開戶行號=“001”..”999”賬號=“00000001”..”99999999”開戶日期=年+月+日性質(zhì)=“1”..”6”印密=“0”存取行=日期+(摘要)+支出+存入+余額+操作員+復(fù)核員2025/5/28135數(shù)據(jù)項(xiàng)的定義數(shù)據(jù)項(xiàng)：不可再分解的數(shù)據(jù)單位，包括：名稱描述數(shù)據(jù)類型長度(精度)取值范圍及缺省值計(jì)量單位相關(guān)數(shù)據(jù)元素及數(shù)據(jù)結(jié)構(gòu)數(shù)據(jù)項(xiàng)名稱：產(chǎn)品編碼

別名：Product_No

簡述：用來唯一標(biāo)識產(chǎn)品的文字

類型：字符串

長度：10

取值范圍及含義：

第1位：進(jìn)口/國產(chǎn)

第2-4位：類別

第5-7位：規(guī)格

第8-10位：品名編號示例2025/5/28136數(shù)據(jù)流的定義數(shù)據(jù)流來源數(shù)據(jù)流去向數(shù)據(jù)流的組成流動屬性描述：頻率、數(shù)據(jù)量等數(shù)據(jù)流名稱：訂單

別名：無

簡述：顧客訂貨時(shí)填寫的項(xiàng)目

來源：顧客

去向：加工1“檢驗(yàn)訂單”

數(shù)據(jù)流量：1000份/每周

組成：編號+訂貨日期+顧客編號+地址+電話+

銀行賬號+貨物名稱+規(guī)格+數(shù)量頻率：平均40條/天示例2025/5/28137數(shù)據(jù)存儲的定義文件名描述數(shù)據(jù)結(jié)構(gòu)數(shù)據(jù)存儲方式關(guān)鍵碼存取頻率和數(shù)據(jù)量安全性要求數(shù)據(jù)存儲名稱：庫存記錄

別名：無

簡述：存放庫存所有可供產(chǎn)品的信息

組成：產(chǎn)品編號+名稱+生產(chǎn)廠家+單價(jià)+庫存量

組織方式：索引文件，以產(chǎn)品編號為關(guān)鍵字

查詢要求：要求能隨時(shí)查詢示例2025/5/28138示例：數(shù)據(jù)字典(1)某酒店所提供的服務(wù)系統(tǒng)的功能為：客人可以通過撥分機(jī)號聯(lián)絡(luò)酒店內(nèi)的其他房間，也可撥外線號碼與酒店外聯(lián)絡(luò)。分機(jī)號從8201至8299。外線號碼需先撥0，然后加撥市話號碼或長途號碼。長途號碼由區(qū)號和市話號碼組成，其中區(qū)號可以為010、021~029、0300~0999中的任意一個(gè)數(shù)字串。市話號碼是任意7位或8位長度的數(shù)字串。2025/5/28139示例：數(shù)據(jù)字典(1)“號碼”的數(shù)據(jù)字典：號碼=[分機(jī)號|外線號碼]分機(jī)號=8201..8299外線號碼=0+[市話號碼|長途號碼]市話號碼={數(shù)字}長途號碼=區(qū)號+市話號碼區(qū)號=[010|021..029|0300..0999]2025/5/28140示例：數(shù)據(jù)字典(2)名字： 零件編號別名： 編碼描述： 唯一的標(biāo)識庫存清單中一個(gè)特定零件定義： 零件編號={字符}8位置： 庫存清單 采購訂單 訂貨報(bào)表名字： 采購訂單別名： 采購單描述： 由各部門采購人員定期向供應(yīng)商發(fā)出的單據(jù)定義： 采購訂單=供應(yīng)商ID+供應(yīng)商名稱+采購日期+總金額