軟件工程課件學習3

11---第3章需求分析軟件需求分析：“做什么？”

需求分析的過程是開發(fā)人員與用戶共同協(xié)商，準確地定義未來系統(tǒng)的目標，確定為了滿足用戶的需求系統(tǒng)必須做什么。并且使用軟件開發(fā)人員和用戶都能理解的語言準確地表達出來，即用<需求規(guī)格說明書>規(guī)范的形式準確地表達用戶的需求。3第3章需求分析

開發(fā)一個軟件系統(tǒng)前，必須了解用戶的期望和要求--->軟件需求--->需求分析過程

重要性：軟件開發(fā)的基礎和前提最終目標軟件系統(tǒng)驗收的標準避免或者盡早剔除早期的錯誤需求分析4需求的重要性Standish-Group對350家公司的8000個軟件項目作過一次調查其中，31%的項目的結局是被取消。引致這些項目失敗的原因是：

13.1%不完整的產(chǎn)品要求；

12.4%缺乏用戶的參與；10.6%缺少資源（人力、財力）；

9.9%不現(xiàn)實的期望；9.3%高層領導支持不足；

8.7%產(chǎn)品要求與指標的改變；8.1%沒有訂計劃；7.5%不再需耍該開發(fā)中的系統(tǒng)。其中，與產(chǎn)品需求有關的（1,2,4,和6項）占了44.1%。這些數(shù)據(jù)突出地顯示了軟件產(chǎn)品需求在軟件開發(fā)中的重要性。2023/7/205需求分析的重要性5點事實軟件生命周期中，一個錯誤發(fā)現(xiàn)得越晚，修復錯誤的費用越高6需求分析的重要性許多錯誤是潛伏的，并且在錯誤產(chǎn)生后很長一段時間才被檢查出來在需求過程中會產(chǎn)生很多錯誤DeMarco在一份研究報告中指出，被檢查出來的錯誤的56％產(chǎn)生的根源可以追溯到需求階段。AIRMICS所進行的一項調查發(fā)現(xiàn)，在一份美國軍方大型管理信息系統(tǒng)的需求現(xiàn)格說明書(SRS)中存在著500多個錯誤，當然這僅僅是一個軟件項目中的一次調查。在需求階段，代表性的錯誤為疏忽、不一致和二義性美國海軍研究實驗室從20世紀70年代起就對軟件開發(fā)技術不斷地進行研究。他們對海軍A—7E—它機上的”宅行操作程序進行實地測試，以驗證許多新設想的可行性。得出的研究數(shù)據(jù)表明：A—7E項目中77％的需求錯誤特點是不明確：疏忽、不一致和二義性。按錯誤類型對這些錯誤分布進行分析的結果是：49％不正確的事實，31％疏忽，l3％不一致，5％二義性7需求分析的重要性8需求分析的重要性需求錯誤是可以被檢查出來的參與需求分析的人系統(tǒng)分析師、需求闡釋者、客戶代表、用戶代表、開發(fā)方領導、項目經(jīng)理、架構設計師、領域專家、財務人員、市場人員、軟件質量保證（SQA，SoftwareQualityAssure）人員、程序員、測試人員、部署人員、技術文檔編寫人員、培訓人員等。需求分析的場所調研時，在客戶現(xiàn)場編纂軟件需求規(guī)約文檔時，可以在開發(fā)單位復審相關的需求文檔時，根據(jù)需要來安排參與需求分析的人有哪些，場所在哪11第3章需求分析需求分析

IEEE軟件工程標準詞匯表將需求定義為：

（1）用戶解決問題或達到目標所需的條件或能力。

（2）系統(tǒng)或系統(tǒng)部件要滿足合同、標準、規(guī)范或其它正式規(guī)定文檔所需具有的條件或能力。

（3）一種反映上面（1）或（2）所描述的條件或能力的文檔說明。

12

困難：

片面性,不完全

模糊性,不準確

不一致性,歧義等等

因此必須使用系統(tǒng)的方法、借助于一系列行之有效的技術和工具進行需求分析

需求分析需求分析

應用系統(tǒng)復雜，龐大按層次劃分軟件需求業(yè)務需求(businessrequirement)反映了組織機構或客戶對系統(tǒng)、產(chǎn)品高層次的目標要求，它們在項目視圖與范圍文檔中予以說明。業(yè)務需求描述了企業(yè)一組概要性的目標，概要性的目標可能要依靠多個用戶目標來實現(xiàn)。用戶需求(userrequirement)文檔描述了用戶使用產(chǎn)品必須要完成的任務，這在使用實例(usecase)文檔或方案腳本(scenario)說明中予以說明。用戶需求描述了用戶目標，是具體明確的任務，但還不是詳細的細節(jié)。功能需求(functionalrequirement)定義了開發(fā)人員必須實現(xiàn)的軟件功能，使得用戶能完成他們的任務，從而滿足了業(yè)務需求。三類需求的關系業(yè)務需求項目視圖與范圍文檔用戶需求使用實例文檔功能需求軟件需求規(guī)格說明書非功能需求概要目標層次用戶目標層次功能層次軟件需求的非功能性需求非功能需求:定義產(chǎn)品必須遵從的標準、規(guī)范和合約；外部界面的具體細節(jié)；性能要求；設計或實現(xiàn)的約束條件及質量屬性。非功能需求過程需求產(chǎn)品需求外部需求軟件交付互操作性實現(xiàn)方法標準法規(guī)成本可用性軟件性能存儲空間可靠性可移植性安全性軟件需求分析的困難(1)客戶說不清楚需求有些客戶對需求只有朦朧的感覺，當然說不清楚具體的需求。農(nóng)夫和耕牛的故事有些客戶心里非常清楚想要什么，但卻說不明白。我的鞋是什么樣的？“不懂裝懂”或者“半懂充內行”的客戶令人恐懼2.1軟件需求的概念軟件需求的復雜性(2)需求自身經(jīng)常變動2.1軟件需求的概念需求變更原因--客戶方：對信息系統(tǒng)的了解不夠對業(yè)務需求表達不清對自身業(yè)務抽象程度不夠對需求重視程度不夠與開發(fā)人員配合不夠業(yè)務范圍不斷拓展業(yè)務流程不斷變更管理模式不斷創(chuàng)新客戶的能力不足，可以進行適當?shù)呐嘤?，可改善一點。屬于態(tài)度問題，需要高層領導協(xié)調。不可避免。只能通過合同約束或有限度接受，或通過技術提高軟件適應能力。軟件需求的復雜性(2)需求自身經(jīng)常變動2.1軟件需求的概念需求變更原因—軟件人員：溝通技巧不高需求工程技術不精需求人員知識儲備不夠不了解客戶方的業(yè)務流程調研范圍不確定需求不夠細致、明確項目管理不規(guī)范需求描述存在歧義合同對客戶方約束不夠

個人能力或經(jīng)驗不足。軟件組織的能力不足19§1.需求分析的任務1、確定要求(1)功能要求(5)接口需求(2)性能要求(6)約束(3)可靠性和可用性需求(7)逆向需求(4)出錯處理需求(8)將來可能提出的要求§1.需求分析的任務20§1.需求分析的任務2、分析系統(tǒng)的數(shù)據(jù)要求⑴建立概念模型(conceptualmodels):E-RDiagram⑵形象描繪數(shù)據(jù)結構:DataHierarchy,WarnierDiagram,⑶數(shù)據(jù)結構規(guī)范化(Normalization)3、導出系統(tǒng)的邏輯模型：抽取其“做什么”的本質

4、修正系統(tǒng)計劃：重估成本、進度等需求文檔22§

2.與用戶溝通的方法1.訪談訪談（或稱為會談）是最早開始運用的獲取用戶需求的技術，也是迄今為止仍然廣泛使用的主要的需求分析技術。兩種基本形式——正式的和非正式的訪談某出版社系統(tǒng)調查表某出版社系統(tǒng)調查表25

情景分析技術—就是對用戶運用目標系統(tǒng)解決某個具體問題的方法和結果進行分析。情景分析的用處：●它能在某種程度上演示產(chǎn)品的行為，從而便于用戶理解，而且還可能進一步揭示出一些系統(tǒng)分析員目前還不知道的需求?！裼捎谇榫胺治鲚^易為用戶所理解，因此，使用這種技術能保證用戶在需求分析過程中始終扮演一個積極主動的角色?！?/p>

2.與用戶溝通的方法262.面向數(shù)據(jù)流自頂向下求精

§

2.與用戶溝通的方法分析追蹤數(shù)據(jù)流圖用戶復查細化數(shù)據(jù)流圖有補充修正無補充修正需要分解不需分解圖3.1需求分析基本過程27倉庫管理員采購員事務定貨報表定貨系統(tǒng)數(shù)據(jù)流圖更新庫存清單1.2產(chǎn)生報表2D1庫存清單D2定貨信息接收事務1.1處理定貨1.3庫存清單定貨信息定貨信息例：分析銷售趨勢統(tǒng)計功能283.簡易的應用規(guī)格說明技術傳統(tǒng)訪談技術用戶和開發(fā)者往往會區(qū)分“我們和他們”

這種方法提倡用戶與開發(fā)者密切合作，共同標識問題，提出解決方案的要素，商討不同的方法并指定基本的需求。面向團隊的需求收集法§

2.與用戶溝通的方法29面向團隊的需求收集法：（用戶與開發(fā)者配合）1）初步訪談；2）開發(fā)者和用戶分別寫出“產(chǎn)品需求”；3）開會討論，各自展示需求列表；4）得出一致意見，為需求列表制定小型規(guī)格說明；5）根據(jù)會議成果，起草完整的軟件需求規(guī)格說明。304.快速建立軟件原型

快速原型就是快速建立起來的旨在演示目標系統(tǒng)主要功能的可運行的程序。構建原型的要點是，它應該實現(xiàn)用戶看得見的功能(例如，屏幕顯示或打印報表)，省略目標系統(tǒng)的“隱含”功能(例如，修改文件)?！?/p>

2.與用戶溝通的方法特性1：快速特性2：容易修改31為了快速地構建和修改原型，通常使用下述3種方法和工具：第四代技術(2)可重用的軟件構件(3)形式化規(guī)格說明和原型環(huán)境

§

2.與用戶溝通的方法32

結構化分析導出的分析模型包括數(shù)據(jù)模型、功能模型和行為模型。該模型以“數(shù)據(jù)字典”為核心，描述了軟件使用的所有數(shù)據(jù)對象，圍繞這個核心的是“實體關系圖”、“數(shù)據(jù)流圖”和“狀態(tài)轉換圖”。具體形式如下圖所示：§

3.分析建模與規(guī)格說明33

§

3.分析建模與規(guī)格說明34

實體關系圖（ER）：數(shù)據(jù)建模的基礎，描述數(shù)據(jù)對象及其關系；數(shù)據(jù)流圖（DF）：功能建模的基礎，描述數(shù)據(jù)怎樣轉換以及轉換的功能；狀態(tài)轉換圖（ST）：行為建模的基礎，表示系統(tǒng)的各種行為狀態(tài)以及狀態(tài)間的轉換方式。

§

3.分析建模與規(guī)格說明35§4.實體-聯(lián)系圖

為了把用戶的數(shù)據(jù)要求清晰明確地表達出來，系統(tǒng)分析員通常建立一個概念性的數(shù)據(jù)模型（也稱為信息模型）。概念性數(shù)據(jù)模型是一種面向問題的數(shù)據(jù)模型，是按照用戶的觀點來對數(shù)據(jù)和信息建模。它描述了從用戶角度看到的數(shù)據(jù)，它反映了用戶的現(xiàn)實環(huán)境，且與在軟件系統(tǒng)中的實現(xiàn)方法無關。最常用的表示概念性數(shù)據(jù)模型的方法，是實體-聯(lián)系方法（Entity-RelationshipApproach）。361.數(shù)據(jù)對象:是對軟件必須理解的復合信息的表示。在ER圖中用矩形框代表實體。3.屬性:屬性定義了數(shù)據(jù)對象的性質。在ER圖中用橢圓形或圓角矩形表示實體（或聯(lián)系）的屬性2.聯(lián)系:數(shù)據(jù)對象彼此之間相互連接的方式稱為聯(lián)系，也稱為關系。聯(lián)系可分為以下三類：（1）一對一聯(lián)系（1∶1）（2）一對多聯(lián)系（1∶N）（3）多對多聯(lián)系（M∶N）§4.實體-聯(lián)系圖所謂復合信息是指具有一系列不同性質或屬性的事物，因此，僅有單個值的事物(例如寬度)不是數(shù)據(jù)對象。37§4.實體-聯(lián)系圖教師學生課程學號姓名系年級職務性別職稱性別姓名教工號教學成績學分學時課名課程號圖3.2某校教學管理ER圖MN1N練習設某汽車運輸公司數(shù)據(jù)庫中有三個實體集。一是“車隊”實體集，屬性有車隊號、車隊名等；二是“車輛”實體集，屬性有牌照號、廠家、出廠日期等；三是“司機”實體集，屬性有司機編號、姓名、電話等。設車隊與司機之間存在“聘用”聯(lián)系，每個車隊可聘用若干司機，但每個司機只能應聘于一個車隊，車隊聘用司機有個聘期；車隊與車輛之間存在“擁有”聯(lián)系，每個車隊可擁有若干車輛，但每輛車只能屬于一個車隊；司機與車輛之間存在著“使用”聯(lián)系，司機使用車輛有使用日期和公里數(shù)兩個屬性，每個司機可使用多輛汽車，每輛汽車可被多個司機使用。N1公里數(shù)擁有使用日期車輛牌照號廠家出廠日期N車隊號車隊車隊名聘用聘期司機司機編號姓名電話1使用MN用E-R圖表示某個工廠物資管理的概念模型實體倉庫：倉庫號、面積、電話號碼零件：零件號、名稱、規(guī)格、單價、描述供應商：供應商號、姓名、地址、電話號碼、帳號項目：項目號、預算、開工日期職工：職工號、姓名、年齡、職稱實體之間的聯(lián)系如下：一個倉庫可以存放多種零件，一種零件可以存放在多個倉庫中。倉庫和零件具有多對多的聯(lián)系。用庫存量來表示某種零件在某個倉庫中的數(shù)量。一個倉庫有多個職工當倉庫保管員，一個職工只能在一個倉庫工作，倉庫和職工之間是一對多的聯(lián)系。職工實體型中具有一對多的聯(lián)系職工之間具有領導-被領導關系。即倉庫主任領導若干保管員。供應商、項目和零件三者之間具有多對多的聯(lián)系練習ER圖練習答案42§5數(shù)據(jù)規(guī)范化

軟件系統(tǒng)經(jīng)常使用各種長期保存的信息，這些信息通常以一定方式組織并存儲在數(shù)據(jù)庫或文件中，為減少數(shù)據(jù)冗余，避免出現(xiàn)插入異常或刪除異常，簡化修改數(shù)據(jù)的過程，通常需要把數(shù)據(jù)結構規(guī)范化。第一范式(1NF)數(shù)據(jù)冗余程度最大，第五范式(5NF)數(shù)據(jù)冗余程度最小。43下面給出第一、第二和第三范式的定義：(1)第一范式每個屬性值都必須是原子值，即僅僅是一個簡單值而不含內部結構。(2)第二范式滿足第一范式條件，而且每個非關鍵字屬性都由整個關鍵字決定(而不是由關鍵字的一部分來決定)?！?數(shù)據(jù)規(guī)范化44(3)第三范式符合第二范式的條件，每個非關鍵字屬性都僅由關鍵字決定，而且一個非關鍵字屬性不能僅僅是對另一個非關鍵字屬性的進一步描述(即一個非關鍵字屬性值不依賴于另一個非關鍵字屬性值)?！?數(shù)據(jù)規(guī)范化例：假定學生關系表為Student(學號,姓名,年齡,所在學院,學院地點,學院電話)，關鍵字為單一關鍵字"學號"，因為存在如下決定關系：

(學號)→(姓名,年齡,所在學院,學院地點,學院電話)這個數(shù)據(jù)庫是符合2NF的，但是不符合3NF，因為存在如下決定關系：

(學號)→(所在學院)→(學院地點,學院電話)45

狀態(tài)轉換圖通過描述狀態(tài)以及導致系統(tǒng)改變狀態(tài)的事件來表示系統(tǒng)的行為，它沒有表示出系統(tǒng)所執(zhí)行的處理，只表示了處理結果可能的狀態(tài)轉換?！?.狀態(tài)轉換圖46

§6.狀態(tài)轉換圖1狀態(tài)狀態(tài)是任何可以被觀察到的系統(tǒng)行為模式，一個狀態(tài)代表系統(tǒng)的一種行為模式。

在狀態(tài)圖中定義的狀態(tài)主要有：初態(tài)（即初始狀態(tài)）、終態(tài)（即最終狀態(tài)）和中間狀態(tài)。在一張狀態(tài)圖中只能有一個初態(tài)，而終態(tài)則可以有0至多個。472事件事件是在某個特定時刻發(fā)生的事情，它是對引起系統(tǒng)從一個狀態(tài)轉換到另一個狀態(tài)的外界事件的抽象。

簡而言之，事件就是引起系統(tǒng)狀態(tài)轉換的控制信息?！?.狀態(tài)轉換圖48§6.狀態(tài)轉換圖3.符號在狀態(tài)圖中，初態(tài)用實心圓表示，終態(tài)用一對同心圓（內圓為實心圓）表示。中間狀態(tài)用圓角矩形表示，可以用兩條水平橫線把它分成上、中、下3個部分。上面部分為狀態(tài)的名稱，這部分是必須有的；中間部分為狀態(tài)變量的名字和值，這部分是可選的；下面部分是活動表，這部分也是可選的。49狀態(tài)圖中兩個狀態(tài)之間帶箭頭的連線稱為狀態(tài)轉換，箭頭指明了轉換方向。狀態(tài)變遷通常是由事件觸發(fā)的，在這種情況下應在表示狀態(tài)轉換的箭頭線上標出觸發(fā)轉換的事件表達式；如果在箭頭線上未標明事件，則表示在源狀態(tài)的內部活動執(zhí)行完之后自動觸發(fā)轉換?！?.狀態(tài)轉換圖50事件表達式的語法如下：事件說明［守衛(wèi)條件］／動作表達式事件說明的語法為：事件名(參數(shù)表)。守衛(wèi)條件是一個布爾表達式。如果同時使用事件說明和守衛(wèi)條件，則當且僅當事件發(fā)生且布爾表達式為真時，狀態(tài)轉換才發(fā)生。如果只有守衛(wèi)條件沒有事件說明，則只要守衛(wèi)條件為真狀態(tài)轉換就發(fā)生。動作表達式是一個過程表達式，當狀態(tài)轉換開始時執(zhí)行該表達式?！?.狀態(tài)轉換圖51圖3.3狀態(tài)圖中使用的主要符號§6.狀態(tài)轉換圖52例子為了具體說明怎樣用狀態(tài)圖建立系統(tǒng)的行為模型，下面舉一個例子。圖3.4是人們非常熟悉的電話系統(tǒng)的狀態(tài)圖。圖中表明，沒有人打電話時電話處于閑置狀態(tài)；有人拿起聽筒則進入撥號音狀態(tài)，到達這個狀態(tài)后，電話的行為是響起撥號音并計時；這時如果拿起聽筒的人改變主意不想打了，他把聽筒放下(掛斷)，電話重又回到閑置狀態(tài)；如果拿起聽筒很長時間不撥號(超時)，則進入超時狀態(tài)；……。53斷線閑置撥號通話撥號音do:響撥號音超時do:響蜂鳴音存儲的信息do:播放信息接通中do:試接通振鈴do:振鈴忙音do:響忙音拿起聽筒數(shù)字數(shù)字有效號碼已接通受話人回話受話人掛斷電話掛斷電話超時掛斷電話超時無效號碼信息播完占線例：電話的狀態(tài)圖狀態(tài)機圖：電梯思考與練習手機開機時，處于空閑狀態(tài)；當用戶開始呼叫某人時，手機進入撥號狀態(tài)；如果呼叫成功，進入通話狀態(tài)；如果呼叫不成功，重新進入空閑狀態(tài)。在空閑狀態(tài)被呼叫，進入響鈴狀態(tài)；如果用戶接聽，進入通話狀態(tài)；如果一分鐘不接聽，重新進入空閑狀態(tài)。思考與練習57數(shù)據(jù)流圖是結構化分析的基本工具，體現(xiàn)了自頂向下逐步求精的分析過程，確定了系統(tǒng)的任務流和數(shù)據(jù)流；

實體關系圖描述了系統(tǒng)的數(shù)據(jù)關系，從而幫助開發(fā)人員分析和理解系統(tǒng)數(shù)據(jù)的組成，并為系統(tǒng)設計階段定義系統(tǒng)數(shù)據(jù)庫的物理結構打下基礎；

狀態(tài)轉換圖描述了系統(tǒng)狀態(tài)之間的變化過程，它對于實時系統(tǒng)和控制系統(tǒng)尤為重要。

58§7.

其他圖形工具層次方框圖Warnier圖IPO圖59

層次方框圖用樹形結構的一系列多層次的矩形框描繪數(shù)據(jù)的層次結構。樹形結構的頂層是一個單獨的矩形框，它代表完整的數(shù)據(jù)結構，下面的各層矩形框代表這個數(shù)據(jù)的子集，最底層的各個框代表組成這個數(shù)據(jù)的實際數(shù)據(jù)元素（不能再分割的元素）。層次方框圖產(chǎn)品硬件軟件服務處理機存儲器外部設備系統(tǒng)軟件應用軟件軟件服務硬件維修培訓編譯程序軟件工具操作系統(tǒng)圖3.5層次方框圖的一個例子應發(fā)工資實發(fā)工資基本工資

獎金扣款水電扣款缺勤扣款個人所得稅扣款出勤獎業(yè)績獎其它補貼

補貼國家津貼職務津貼交通補貼部門補貼

津貼國家工資62

法國計算機科學家Warnier提出了表示信息層次結構的另外一種圖形工具。用Warnier圖可以指出一類信息或一個信息量是重復出現(xiàn)的，也可以表示特定信息在某一類信息中是有條件地出現(xiàn)的。因為重復和條件約束是說明軟件處理過程的基礎，所以很容易把Warnier圖轉變成軟件設計的工具。Warnier圖軟件產(chǎn)品軟件工具編輯程序（P3）應用軟件編譯程序（P2）操作系統(tǒng)（P1）系統(tǒng)軟件測試驅動程序（P4）設計輔助工具（P5）⊕圖3.4Warnier圖的一個例子2023/7/2063例子{：層次（n1,n2):重復n1到n2次：二者擇一例：頭條新聞地區(qū)隊頭版國內新聞體育新聞職業(yè)隊本地新聞拳擊社論(1,1)經(jīng)營簡訊專欄(1,3)報紙社論讀者來信(1,3)副刊商業(yè)新聞雇員簡訊諷刺漫畫(0,1)一般新聞體育新聞聯(lián)播招生副刊商業(yè)新聞廣告招聘廣告求助細化64IPO圖是輸入／處理／輸出圖的簡稱，它是美國IBM公司發(fā)展完善起來的一種圖形工具，能夠方便地描繪輸入數(shù)據(jù)、對數(shù)據(jù)的處理和輸出數(shù)據(jù)之間的關系。IPO圖舊的主文件事務文件1.校驗主記錄2.校驗事務記錄3.更新主記錄有效的主記錄有效的事務記錄更新后的主文件輸入處理輸出圖3.7IPO圖的一個例子IPO圖輸入／處理／輸出（InputProcessOutput）圖的簡稱?！纠空衅缚荚嚦煽児芾硐到y(tǒng)的IPO圖。66

本書建議使用一種改進的IPO圖（也稱為IPO表），這種圖中包含某些附加信息，在軟件設計過程中將比原始的IPO圖更有用。IPO表系統(tǒng)：模塊：編號：作者：日期：被調用：調用：輸入：輸出：處理：局部數(shù)據(jù)元素：注釋：圖3.8改進的IPO圖的形式67軟件系統(tǒng)中15%的錯誤起源于錯誤的需求?！褚恢滦浴裢暾浴瘳F(xiàn)實性●有效性四個方面驗證軟件需求:§8.驗證軟件需求68用于需求分析的軟件應該滿足下列要求：1）必須有形式化的語法2）使用這個軟件工具能夠導出詳細的文檔3）必須提供分析規(guī)格說明書的不一致性和冗余性的手段4）使用這個軟件工具后，應該能夠改進通信狀況用于需求分析的軟件工具69

RSL（需求陳述語言）：信息集ASSMPASCAL模擬程序

PSL/PSA（問題陳述語言/問題陳述分析程序）系統(tǒng)

70需求分析的步驟1、調查研究（1）沿數(shù)據(jù)流圖回溯：數(shù)據(jù)流圖的輸出端是系統(tǒng)的最終目的。向回確定每個數(shù)據(jù)元素的來源，可加細數(shù)據(jù)流圖及數(shù)據(jù)字典，并將相關算法記錄在IPO圖中。（2）用戶復查

基本思想:“自頂向下，逐步求精”

,抽象和分解71§9.需求分析的步驟2、分析與綜合（1）問題的具體分析：細化數(shù)據(jù)流圖

加細前后的I/O須相同。

分解到須考慮具體實現(xiàn)的代碼時即可仃止（2）方案的綜合723、修正計劃：成本和進度的更準確估計4、書寫文檔：《需求規(guī)格說明書》不需分解有補充修正無補充修正分析追蹤數(shù)據(jù)流圖用戶復查細化數(shù)據(jù)流圖需要分解§9.需求分析的步驟73需求規(guī)格說明書封面：

文檔編號：

版本號：

文檔名稱：項目名稱：項目負責人：

年月日編寫：核對：審核：批準：開發(fā)單位：

74需求規(guī)格說明書內容：⑴系統(tǒng)規(guī)格說明：

系統(tǒng)概貌功能要求

性能要求運行要求

可能增加的要求

DFD

IPO⑵數(shù)據(jù)要求：

DD

Hierarchy或WarnierDiagram⑶用戶系統(tǒng)描述

——初步用戶手冊：從用戶的觀點考慮系統(tǒng)

系統(tǒng)功能、性能

使用與步驟等⑷修正的開發(fā)計劃：

成本估計資源使用計劃

進度計劃2023/7/2075圖書館系統(tǒng)1一.項目說明開發(fā)計算機圖書管理系統(tǒng)。主要進行四個方面的管理：圖書的購入、借閱、歸還及注銷。

1.購入新書時需要為該書編制圖書卡片,包括分類目錄號、流水號、書名、作者、內容摘要、價格和購書日期等信息，寫入圖書目錄文件中。

2.讀者借書時填寫借書單,包括讀者號、欲借圖書分類目錄號。系統(tǒng)首先檢查該讀者號是否有效，若無效，則拒絕借書；否則進一步檢查所借圖書是否超過最大限制數(shù)(5本)，若已達到最大限制數(shù)(5本)，則拒絕借書；否則，讀者可以借出該書，登記圖書分類目錄號、讀者號、借閱日期等，寫回到借書文件中去。

3.讀者還書時,根據(jù)圖書流水號,從借書文件中讀出和該圖書相關的借閱記錄,表明還書日期,再寫回借書文件中；如果圖書逾期未還，則處以相應罰款。2023/7/2076圖書館系統(tǒng)2圖書管理系統(tǒng)圖書管理人員系統(tǒng)時鐘讀者查詢要求圖書管理要求統(tǒng)計表讀者情況圖書情況付款單當前日期頂層DFD4.在某些情況下需要對圖書館的圖書進行清理工作，對一些過時或無繼續(xù)保留價值的圖書要注銷(從圖書文件中刪除相關記錄)