【正文】 所觸發(fā)的周期性時(shí)間 (每月25號編制下月計(jì)劃、每天 17點(diǎn)盤點(diǎn)庫存 ) – 狀態(tài)事件 (State events)：由某些數(shù)據(jù)的變化所自動(dòng)觸發(fā)的事件 (當(dāng)庫存量下降到 100以下時(shí)，啟動(dòng)采購流程 ) 2023/1/30 112 繪制 DFD的一些基本原則 外部實(shí)體 1數(shù)據(jù)流 2數(shù)據(jù)流 1外部實(shí)體 2數(shù)據(jù)流 4數(shù)據(jù)流 3數(shù)據(jù)存儲(chǔ) 1數(shù)據(jù)存儲(chǔ) 20 系統(tǒng)數(shù)據(jù)流1 加工 12加工 2? 把數(shù)據(jù)存儲(chǔ)放在 0層數(shù)據(jù)流圖或更低層子圖上，不要放在頂層的關(guān)聯(lián)圖上 ? 使用數(shù)據(jù)流圖時(shí)，不要試圖讓數(shù)據(jù)流圖反映處理的順序，忽略系統(tǒng)的運(yùn)行時(shí)的時(shí)間特性 ? 加工通過數(shù)據(jù)存儲(chǔ)進(jìn)行通訊，而盡量避免從一個(gè)過程直接流到另一過程 2023/1/30 113 繪制 DFD的一些基本原則 外部實(shí)體 1 外部實(shí)體 2 數(shù)據(jù)流 數(shù)據(jù)存儲(chǔ) 1 外部實(shí)體 1 數(shù)據(jù)流 數(shù)據(jù)存儲(chǔ) 1 外部實(shí)體 1 數(shù)據(jù)流 數(shù)據(jù)存儲(chǔ) 1 數(shù)據(jù)流 數(shù)據(jù)存儲(chǔ) 2 ? 數(shù)據(jù)不能直接由一個(gè)數(shù)據(jù)存儲(chǔ)直接流到另一個(gè)數(shù)據(jù)存儲(chǔ) ? 數(shù)據(jù)不能直接從一個(gè)外部實(shí)體直接流到一個(gè)數(shù)據(jù)存儲(chǔ) ? 數(shù)據(jù)不能直接從一個(gè)數(shù)據(jù)存儲(chǔ)直接流到一個(gè)外部實(shí)體 ? 數(shù)據(jù)不能直接在外部實(shí)體之間流動(dòng) 2023/1/30 114 數(shù)據(jù)流 1加工數(shù)據(jù)流2加工繪制 DFD的一些基本原則 ? 數(shù)據(jù)流是單向的 ? 任何加工必須有輸入和輸出數(shù)據(jù)流 ? 對現(xiàn)有加工進(jìn)行持續(xù)的分解和組合，直到所有加工之間達(dá)到較高的聚合度； ? 盡量將每一張 DFD上的所有元素?cái)?shù)目控制在 712個(gè)。 ? 問題：繪制該系統(tǒng)的 DFD 2023/1/30 104 DFD的層次性 加工實(shí)實(shí)1 23 ? DFD的層次性： 自頂向下的分解 (topdown) ? DFD的兩種類型： – 環(huán)境關(guān)聯(lián) DFD圖 (Contextlevel DFD，或 Context Diagram)：也稱頂層DFD圖 ，描述了系統(tǒng)與外部環(huán)境之間的數(shù)據(jù)輸入 /輸出關(guān)系； – 系統(tǒng)內(nèi)部 DFD圖 (Innerlevel DFD)： 描述系統(tǒng)內(nèi)部各功能模塊之間的數(shù)據(jù)流動(dòng)關(guān)系 ? 0層 DFD圖 ? 1層 DFD圖 ? … ? N層 DFD圖 2023/1/30 105 頂層 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ù)流 – 編號： 0 0系統(tǒng)外部實(shí)體 I1外部實(shí)體 I2外部實(shí)體 In…外部實(shí)體 O1外部實(shí)體 O2外部實(shí)體 Om…輸入信息 1輸入信息 2輸入信息 n輸出信息 1輸出信息 2輸出信息 n2023/1/30 106 示例：頂層 DFD 學(xué)生教師教務(wù)部課程安排注冊請求0課程注冊系統(tǒng)班級列表課程安排數(shù)據(jù)2023/1/30 107 0層 DFD ? 將頂層 DFD圖中的系統(tǒng)分解為若干個(gè)子系統(tǒng)，決定每個(gè)子系統(tǒng)間的數(shù)據(jù)接口和活動(dòng)關(guān)系，得到 0層 DFD圖； ? 編號： … 、 n 學(xué)生教師教務(wù)部課程安排注冊請求1 安排課表2 學(xué)生注冊3產(chǎn)生班級列表班級列表提供的課程學(xué)生信息庫 課程注冊信息課程安排數(shù)據(jù)2023/1/30 108 底層 DFD ? 針對 0層 DFD中的每一個(gè)子系統(tǒng)，對其繼續(xù)分解得到細(xì)化的加工，進(jìn)而逐漸向下構(gòu)造得到 1層 DFD、 2層 DFD、 … 、 n層 DFD， 一直到不能或不需再分解為止。 – 以名詞命名 銷售訂單 銷售訂單 銷售訂單 顧客庫存信息庫顧客信用庫發(fā)票付款當(dāng)前庫存1 銷售產(chǎn)品更新后的庫存顧客信息當(dāng)前信用度2023/1/30 101 DFD的主要元素 (3)：外部實(shí)體 ? 外部實(shí)體 (external entity)：本系統(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ù)存儲(chǔ) 客戶 學(xué)生 庫存系統(tǒng) 旅行社 2023/1/30 102 DFD的主要元素 (4)：數(shù)據(jù)流 銷售訂單 客戶1錄入訂單銷售訂單2審核訂單訂單 訂單訂單? 數(shù)據(jù)流 (data flow)：數(shù)據(jù)在系統(tǒng)內(nèi)傳播的路徑 – 由一組成分固定的數(shù)據(jù)組成。 ? 描述手段 ① 一套分層的數(shù)據(jù)流圖 ② 一本詞典 ③ 其他補(bǔ)充材料 2023/1/30 97 數(shù)據(jù)流圖 (DFD) ? 數(shù)據(jù)流圖 (Data Flow Diagram, DFD)： 結(jié)構(gòu)化系統(tǒng)分析的基本工具 – 描繪數(shù)據(jù)在系統(tǒng)中各邏輯功能模塊之間的流動(dòng)和處理過程，是一種功能模型 – 主要刻畫“功能的輸入和輸出數(shù)據(jù)”、“數(shù)據(jù)的源頭和目的地” 2023/1/30 98 DFD的主要元素 銷售訂單 1 錄入訂單 銷售訂單 客戶 數(shù)據(jù)流 加工 數(shù)據(jù)存儲(chǔ) 外部實(shí)體 2023/1/30 99 DFD的主要元素 (1)：加工 ? 加工 (又稱數(shù)據(jù)處理， data processing)：對數(shù)據(jù)流進(jìn)行某些操作或變換。 2023/1/30 94 2023/1/30 95 ? 需求建模方法的共同特性 ： 1． 提供描述手段 2． 提供基本步驟 ? 建模方法主要包括結(jié)構(gòu)化的需求建模方法和面向?qū)ο蟮男枨蠼７椒? 2023/1/30 96 ? 基本特點(diǎn)是表達(dá)問題時(shí)盡可能使用圖形符號的形式 ， 設(shè)計(jì)數(shù)據(jù)流圖時(shí)只考慮系統(tǒng)必須完成的基本功能 ， 不必考濾如何具體實(shí)現(xiàn)這些功能 。 ? 軟件需求的邏輯視圖給出軟件要達(dá)到的功能和要處理數(shù)據(jù)之間的關(guān)系 。 這種分解可以是同一層次上的 ， 稱為橫向分解；也可以是多層次的縱向分解 。 2023/1/30 92 需求分析的任務(wù)與原則 需求分析的原則 、 逐層分解問題 ? 分解問題是把問題以某種方式分解為幾個(gè)較易理解的部分 ， 并確定各部分間的接口 ，從而實(shí)現(xiàn)整體功能 。 2023/1/30 91 需求分析的任務(wù)與原則 需求分析的原則 1． 必須能夠表達(dá)和理解問題的數(shù)據(jù)域和功能域 對于計(jì)算機(jī)程序處理的數(shù)據(jù) ， 其數(shù)據(jù)域應(yīng)包括數(shù)據(jù)流 、 數(shù)據(jù)內(nèi)容和數(shù)據(jù)結(jié)構(gòu) 。 7. 質(zhì)量功能調(diào)配 質(zhì)量功能調(diào)配是一種高級系統(tǒng)技術(shù)，它將產(chǎn)品特性、屬性與對客戶的重要性聯(lián)系起來。 5. 為需求建立模型 需求的圖形分析模型是軟件需求規(guī)格說明的補(bǔ)充說明。 2023/1/30 89 需求分析的任務(wù)與原則 3. 分析需求可行性 在允許的成本、性能要求下，分析每項(xiàng)需求實(shí)施的可行性。 2023/1/30 88 需求分析的任務(wù)與原則 1. 繪制系統(tǒng)關(guān)聯(lián)圖 關(guān)聯(lián)圖是用于定義系統(tǒng)與系統(tǒng)外部實(shí)體間的界限和接口的簡單模型。 需 求 獲 取 需 求 分 析 需 求 描 述 需 求 驗(yàn) 證 需 求 管 理需 求 開 發(fā) 過 程 需 求 管 理 過 程2023/1/30 87 需求分析的任務(wù)與原則 ? 需求分析的基本任務(wù)是分析與綜合已收集到的需求信息，通過分析找出需求信息內(nèi)在聯(lián)系和可能的矛盾，通過綜合找出解決問題的方法并建立系統(tǒng)的邏輯模型。 ? 兩種方式： – 被動(dòng)觀察：用戶實(shí)地工作，需求分析人員在旁邊看 – 主動(dòng)觀察：需求分析人員直接參與用戶的實(shí)際工作 2023/1/30 83 頭腦風(fēng)暴 (Brainstorming) 2023/1/30 84 頭腦風(fēng)暴 (Brainstorming) ? 一般以 812人最佳： – 人數(shù)太少不利于交流信息和激發(fā)思維；人數(shù)太多則不容易掌握，并且每個(gè)人發(fā)言的機(jī)會(huì)相對減少 ? 明確分工： 1名主持人、 2名記錄員 ? 成功要點(diǎn)： – 自由暢談 – 延遲批判、禁止批評 – 禁止批評、自我批評、自謙 – 追求數(shù)量 ? 會(huì)后：修剪、分組、排序 ? 適用場合：產(chǎn)品型系統(tǒng)，需要具有創(chuàng)新性特征，尚未投放市場，無明確的客戶。 ? 協(xié)助建立一支高效團(tuán)隊(duì)，圍繞一個(gè)目的：項(xiàng)目的成功； ? 所有人員都暢所欲言； ? 促進(jìn)用戶與開發(fā)團(tuán)隊(duì)之間達(dá)成共識(shí)； ? 能夠揭露和解決那些妨礙項(xiàng)目成功的行政問題； ? 最終很快產(chǎn)生初步的系統(tǒng)定義。這往往會(huì)造成某些需求被忽略； 2023/1/30 78 需求研討會(huì) (Workshop) 2023/1/30 79 需求研討會(huì) (Workshop) 2023/1/30 80 需求研討會(huì) (Workshop) ? 通過讓所有相關(guān)人員一起參加某個(gè)單一會(huì)議來定義需求或設(shè)計(jì)系統(tǒng)，也稱聯(lián)合應(yīng)用設(shè)計(jì)會(huì)議 (Joint Application Design, JAD)。 2023/1/30 77 面對面訪談的優(yōu)缺點(diǎn)分析 ? 優(yōu)點(diǎn)： – 人們很愿意談?wù)撟约旱墓ぷ?，并且總是很喜歡接受訪談； ? 缺點(diǎn)： – 大多數(shù)人都采用專業(yè)術(shù)語和“行話”，而太多的專業(yè)術(shù)語讓需求工程師難以理解，往往造成很多誤解； – 有些需求對用戶來說太普通了，以至于他們不自覺地認(rèn)為這些需求太基本，不值得去提。 2023/1/30 73 面談之后 ? 復(fù)查筆記的準(zhǔn)確性、完整性和可理解性 ? 把所收集的信息轉(zhuǎn)化為適當(dāng)?shù)哪Ｐ秃臀臋n ? 確定需要進(jìn)一步澄清的問題域 ? 向參加會(huì)議的每一個(gè)人發(fā)出此次面談的 minutes(會(huì)議紀(jì)要 )。 ? 通過提問題增強(qiáng)你對談話進(jìn)展和方向的控制 ? 問題不能過于寬泛 ? 最開始的問題不能太難 ? 不能在提問之前就已經(jīng)表示不贊同 ? 談話之前有意識(shí)的準(zhǔn)備一些備用問題 2023/1/30 70 訪談問題的分類 ? 上下文無關(guān)的問題 (contextfree questions)：充分理解用戶的問題，不涉及具體的解決方案 – 客戶是誰？ – 最終用戶是誰？ – 不同用戶的需求是否不同？ – 這種需求目前的解決方案是什么？ ? 解決方案相關(guān)的問題 (solutioncontext questions)：通過這類問題，探尋特定的解決方案并得到用戶認(rèn)可 – 你希望如何解決這個(gè)問題？ – 你覺得該問題這樣解決如何？ 2023/1/30 71 面談之前 ? 確立面談目的 ? 確定要包括的相關(guān)用戶 ? 確定參加會(huì)議的項(xiàng)目小組成員 ? 建立要討論的問題和要點(diǎn)列表 ? 復(fù)查有關(guān)文檔和資料 ? 確立時(shí)間和地點(diǎn) ? 通知所有參加者有關(guān)會(huì)議的目的、時(shí)間和地點(diǎn) 2023/1/30 72 面談之中 ? Step 1：事先準(zhǔn)備一系列上下文無關(guān)的問題，并將其記錄下來以便面談時(shí)參考； ? Step 2：面談前，了解一下要面談的客戶公司的背景資料，不要選擇自己能回答的問題而浪費(fèi)時(shí)間； ? Step 3：面談過程中，參考事先準(zhǔn)備的面談模板，以保證提出的問題是正確的。 2023/1/30 55 (5) 需求管理 ? 需求管理 (Requirement Management) – 定義需求基線 (迅速制定需求文檔的主體 ) – 評審提出的需求變更、評估每項(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)及其變更情況 2023/1/30 56 需求管理 需求管理 變更控制 版本控制