【導(dǎo)讀】軟件工程課件第3章軟件需求分析。軟件需求規(guī)格說明書SRS. 需求獲取的常用方法。分析模型描述工具。讓用戶和開發(fā)者共同明確將要開發(fā)的是什么樣的系統(tǒng)。張秘書開購書證明，學(xué)生憑證明到教材科王會計開購書發(fā)票向李出納員交納。書款，拿領(lǐng)書單到書庫找保管員領(lǐng)書。B）去掉模型中非計算機本質(zhì)的因素后得到的購書邏輯模型。原有系統(tǒng)的數(shù)據(jù)（帳冊、報表。。借鑒已有的類似軟件產(chǎn)品。用戶代表、領(lǐng)域?qū)＜液拖到y(tǒng)分析員。充分準(zhǔn)備，尋找共同語言。事先準(zhǔn)備一些問題。交流時循序漸進、逐步逼近。分析用戶要求實現(xiàn)的全部功能。存儲容量及后援存儲。例2“應(yīng)力分析程序必須在一分種內(nèi)生成任何一個梁的應(yīng)力報告?！皺C場雷達系統(tǒng)一個月內(nèi)不能出現(xiàn)2次以上故障”。系統(tǒng)出錯后可以允許的最大恢復(fù)時間。警告出錯處理需求。“最多不要超過7個。數(shù)據(jù)流圖中描述的是數(shù)據(jù)流而不是控制流。著這個箭頭流動，這個箭頭應(yīng)該從圖中刪

　　

【正文】 3)根據(jù)采購部門發(fā)來的進貨通知單處理進貨，并修改庫存，并從缺貨記錄中取出缺貨訂單進行供貨處理。 4)根據(jù)留底的訂單記錄進行銷售統(tǒng)計 (分別按顧客所在地區(qū)、銷售日期、銷售貨物名稱、顧客名稱統(tǒng)計 )，打印統(tǒng)計表給經(jīng) 理。 根據(jù)上述的功能描述，畫出分層數(shù)據(jù)流程圖。 5．用數(shù)據(jù)詞典的公式法描述完整的存折信息 6．用判定樹和判定表描述 VIP客戶問題：若本次客戶的的消費超過 $1000，并且顧客信譽好，或者盡管其信譽不好，但他是超過 10 年的老客戶，那么優(yōu)先處理該客戶的業(yè)務(wù) ：一個學(xué)生選課系統(tǒng)的分層 DFD 及其數(shù)據(jù)詞典 常用的分析方法： 面向數(shù)據(jù)流的結(jié)構(gòu)化分析方法（ SA） 面向數(shù)據(jù)結(jié)構(gòu)的 Jackson 方法（ JSD） 結(jié)構(gòu)化數(shù)據(jù)系統(tǒng)開發(fā)方法（ DSSD） 面向?qū)ο蟮姆治龇椒ǎ?OOA）等 面向數(shù)據(jù)流進行需求分析的方法 —— 結(jié)構(gòu)化分析方法適合于數(shù)據(jù)處理類型軟件的需求分析 編制需求分析階段的文檔 ?? 軟件需求說明書 ?? 數(shù)據(jù)要求說明書 ?? 初步的用戶手冊 ?? 修改、完善與確定軟件開發(fā)實施計劃 深入描述軟件的功能和性能 確定軟件設(shè)計的約束和軟件同其它系統(tǒng)元素的接口細節(jié) 定義軟件的其它有效性需求 （ 1）第一張圖是包括人工操作在內(nèi)的系統(tǒng)模型 分析需求，去掉模型中非計算機本質(zhì)的因素： 1，如張、王。人是可能變動的，但是他們的工作崗位是不變的，歸結(jié)為審查、開發(fā)票、開書單、發(fā)書 2。確定人工和目標(biāo)系統(tǒng)的功能劃分，其中收費 、發(fā)書必須是由人工完成的，所以在計算機目標(biāo)系統(tǒng)模型中去掉發(fā)書！ 3。經(jīng)過復(fù)審需求，學(xué)生不該購買或書已經(jīng)賣完，則“無效書單“ 得到第二張圖 （ 2）在后面的分析建模中要將圖建模為 DFD圖（見后） 結(jié)構(gòu)化分析模型描述工具 結(jié)構(gòu)化分析模型 DFD、 DD和 PSPEC CFD、 CSPEC 和 STD ER 圖 面向?qū)ο蠓治瞿Ｐ停ê罄m(xù)） 用例圖，對象 關(guān)系圖，對象 行為圖 有些數(shù)據(jù)加工不是數(shù)據(jù)觸發(fā)的，而是由實時發(fā)生的事件觸發(fā)的，無法用傳統(tǒng)的 DFD 圖來表示。 因此在功能模型之外擴充了行為模型，引進了 CFD(Control Flow Diagram)圖， STD(Status Transfer Diagram)圖， CSPEC(Control Specification)等工具進行描述。 頂層圖被稱為是圖 0 的“父圖” , 圖 0 稱為是頂層圖的“子圖”；同樣，圖0是 圖 l、圖 2和圖 3 的“父圖”，圖 l、圖 2 和圖 3是圖 0 的“子圖”。 子圖的編號就是父圖中相應(yīng)加工的編號。 2) 子圖中加工的編號由子圖號、小數(shù)點、局部號連接而成。 頂層圖只有一張，故不必編號，下一層的圖可以編號為 0，圖中加工的編號就是 、 、 ，通常我們刪去小數(shù)點前面的 0，所以這些加工的編號就是 3。有了這樣的規(guī)則，只要數(shù)一下子圖編號的小數(shù)點數(shù)，就可知道這張于圖位于哪一層，另外，根據(jù)編號就可知道某一張圖的父圖是哪一張 。 如果父圖和子圖不平衡，這套數(shù)據(jù)流圖就無法理解 2) 避免用空洞的名字，如“數(shù)據(jù)”、“信息”、“輸入”、“輸出”之類，因為這種名字缺乏具體的含義。 3) 如果發(fā)現(xiàn)難以為某個數(shù)據(jù)流命名，這往往是數(shù)據(jù)流圖分解不當(dāng)?shù)恼髡?，此時可以試試重新分解是否能解決這個難題。 例 3。 16 父圖和子圖是不 平衡的，因為子圖中沒有輸入數(shù)據(jù)流與父圖中加工2的輸入流 M 相對應(yīng)。另外，子圖的輸出數(shù)據(jù)流 S在父圖中也沒有出現(xiàn) 例 3。 17 父圖和子圖平衡嗎？從圖上看，子圖與父圖中相應(yīng)加工并不具有相同的輸入和輸出，但是如果從詞典中查出：父圖只稱為“訂貨單”的數(shù)據(jù)流是由“客戶”、“帳號”和“數(shù)量”三部分?jǐn)?shù)據(jù)組成的，那么就可得出結(jié)論：這兩張圖是平衡的 兩張數(shù)據(jù)流圖是平衡的，但是子圖中的文件 ALPHA 為什么在父圖中沒有畫出呢？這是因為 ALPHA 是完全局部于加工 的、它并不是父圖中各個加工之間的交界面，根據(jù)“抽象”原則，在畫父圖 時，只需畫出加工和加工之間的聯(lián)系，而不必畫出各個加工內(nèi)部的細節(jié)，所以父圖中不必畫文件 ALPHA，同理，數(shù)據(jù)流 XXX、YYY 也不必畫出。 一個文件要到哪一層才畫出來呢？其原則是，當(dāng)文件被用作數(shù)據(jù)流圖中某些加工之間的交界面時，這個文件就必須畫出來 ，“決定比賽名單”這個加工根據(jù)“項目”和“運動員名單”產(chǎn)生“項目參加者”，如果“運動員名單”和“項目參加者”組成如下： 運動員名單 =隊名 +姓名 +項目 項目參加者 =項目 +姓名 +運動員 號 檢查結(jié)果：“決定比賽名單”這個加工要輸出“運動員號”這個數(shù)據(jù)，但是并沒有接收到它，所以一定有數(shù)據(jù)流被遺漏了。 措施：補上相應(yīng)數(shù)據(jù)流。 中，加工“開發(fā)票”根據(jù)“訂貨單”和“價目”文件開出“發(fā)票”，如果這些數(shù)據(jù)的組成如下： 訂貨單 =單位名 +貨名 +貨號 +數(shù)量 價目 =貨名 +單價 發(fā)票 =單位名 +貨名 +數(shù)量 +單價 +總計 檢查結(jié)果：“開發(fā)票”這個加工并不使用“貨號”這個數(shù)據(jù)，經(jīng)過同用戶商量 ，如果確實是不必要的，就可將它刪去。 措施：刪去訂貨單數(shù)據(jù)流中的“貨號”成分。 圖 的父圖和子圖有個明顯的錯誤：只有流向文件 DELTA 的數(shù)據(jù)流而沒有從該文件流出的數(shù)據(jù)流，即只有寫文件的加工而沒有讀文件的加工，這說明一定是某些加工被遺漏了。 應(yīng)減少數(shù)據(jù)流圖中加工間的數(shù)據(jù)流 ，使各個加工相對獨立。 檢查：圖 中，加工 2與其他加工的聯(lián)系相當(dāng)復(fù)雜，輸入輸出數(shù)據(jù)流達9個之多，很難獨立理解。 檢查結(jié)果：分解不合適。 措施：考慮重新分解。 數(shù)據(jù)詞典與數(shù)據(jù)流圖配合，能清楚 地表達數(shù)據(jù)處理的要求 詞條描述 —— 對于在數(shù)據(jù)流圖中每一個被命名的圖形元素，均加以定義，其內(nèi)容有 :名字，別名或編號，分類，描述，定義，位置，其它，等 ：見后 P4243, 例 演示是動畫的，但實際的圖是靜態(tài)的， 那么如何表示狀態(tài)的變遷？系統(tǒng)的 行為？ — STD