軟件需求工程 課件全套 第1-13章 需求工程概述-需求工程與軟件開發(fā)管理

第1章需求工程概述

目錄需求工程的重要性什么是軟件需求軟件需求的分類需求工程需求規(guī)格說明其它基本概念1-11-21-31-41-51-61-1需求工程的重要性軟件開發(fā)的風(fēng)險(xiǎn)軟件需求的重要性軟件日益復(fù)雜化，大型化，開發(fā)成本越來越高，風(fēng)險(xiǎn)也越來越大。Standish集團(tuán)：約有31%的軟件項(xiàng)目在完成之前被取消，52%的項(xiàng)目實(shí)際花費(fèi)成本為預(yù)算成本的189%據(jù)該公司分析，項(xiàng)目失敗或嚴(yán)重超支的八個(gè)最重要原因中有五個(gè)都與需求相關(guān)：需求不完整缺乏用戶的參與客戶期望不實(shí)際需求和需求規(guī)格說明的變更提供許多不必要的功能1-1需求工程的重要性案例一：倫敦股票交易項(xiàng)目TAURUS案例二：Swanick空中交通控制系統(tǒng)花費(fèi)了數(shù)百萬英鎊后于1993年被取消，總損失預(yù)計(jì)達(dá)到了幾億英鎊。據(jù)調(diào)查顯示，許多問題源于未能協(xié)調(diào)那些不一致的需求。原計(jì)劃在1998年完工，但直到2001年尚未交付使用，額外開支高達(dá)1億英鎊以上。據(jù)調(diào)查顯示，一個(gè)主要原因是“缺乏健壯的需求規(guī)格說明導(dǎo)致無法繼續(xù)進(jìn)行系統(tǒng)實(shí)現(xiàn)”。1-1需求工程的重要性需求工程的作用需求工程是項(xiàng)目核心DavisA.M.：需求階段檢查和修復(fù)一個(gè)錯(cuò)誤所需的費(fèi)用只有編碼階段的1/5到1/10，而在維護(hù)階段做同樣的工作所需付出的代價(jià)卻是編碼階段的20倍。意味著維護(hù)階段修復(fù)錯(cuò)誤的代價(jià)與需求階段修復(fù)同樣錯(cuò)誤的代價(jià)相差最高200倍。諸多調(diào)查研究表明，盡管項(xiàng)目失敗涉及的原因多種多樣，但項(xiàng)目失敗時(shí)，需求問題通常正是核心問題。在軟件開發(fā)過程中，必須盡早、有效地發(fā)現(xiàn)和解決需求相關(guān)的問題。1-1需求工程的重要性1-2什么是軟件需求軟件需求A.Davis：軟件需求是從軟件外部能發(fā)現(xiàn)的，軟件所具有的，滿足于用戶的特點(diǎn)、功能及屬性等的集合。I.Sommerville：需求是問題信息和系統(tǒng)行為、特性、設(shè)計(jì)和實(shí)現(xiàn)約束的描述的集合。M.Jackson：需求是客戶希望在問題域內(nèi)產(chǎn)生的效果。IEEE關(guān)于軟件需求的定義對(duì)于用戶，是用戶解決問題或達(dá)到目標(biāo)所需的條件或能力。對(duì)于軟件系統(tǒng)，是系統(tǒng)或系統(tǒng)部件要滿足合同、標(biāo)準(zhǔn)、規(guī)范或其它正式規(guī)定文檔所需具有的條件或能力。1-2什么是軟件需求1-3軟件需求的分類指實(shí)現(xiàn)的軟件系統(tǒng)功能應(yīng)達(dá)到的技術(shù)指標(biāo)。如計(jì)算效率和精度、可靠性和可維護(hù)性等。性能需求指軟件開發(fā)人員在設(shè)計(jì)和實(shí)現(xiàn)軟件系統(tǒng)時(shí)的限制。如開發(fā)語言，使用的數(shù)據(jù)庫。主要描述軟件系統(tǒng)必須完成的任務(wù)、實(shí)際業(yè)務(wù)或工作流程等。指開發(fā)人員必須實(shí)現(xiàn)的軟件功能或軟件系統(tǒng)應(yīng)具有的外部行為。反映組織機(jī)構(gòu)或客戶對(duì)系統(tǒng)和產(chǎn)品提出的高層次的目標(biāo)要求。約束與限制功能需求業(yè)務(wù)需求目標(biāo)需求從用戶多年來對(duì)軟件的實(shí)際需求來看，軟件需求大致分類如下：1-3軟件需求的分類功能需求描述系統(tǒng)的功能；由性能需求和約束與限制構(gòu)成的非功能需求則為實(shí)現(xiàn)這些功能需求設(shè)定約束與限制；軟件需求間的關(guān)系可分層次表達(dá)，如下圖所示：1-3軟件需求的分類案例：文字處理系統(tǒng)相關(guān)的部分需求的分類目標(biāo)需求：用戶使用系統(tǒng)能有效地糾正文檔中的拼寫錯(cuò)誤，并且系統(tǒng)能滿足用戶的業(yè)務(wù)要求以及提高用戶的工作效率。1-3軟件需求的分類業(yè)務(wù)需求：當(dāng)找到文檔中的拼寫錯(cuò)誤時(shí)，通過一個(gè)可供選擇的單詞表，并在選擇單詞表中的某一個(gè)單詞后替換掉原來的單詞。功能需求：查找文檔中的單詞，并高亮度地顯示出錯(cuò)的單詞。用對(duì)話框顯示可供選擇的單詞表。實(shí)現(xiàn)整個(gè)文檔范圍內(nèi)的替換。性能需求：檢查單詞的速度快，準(zhǔn)確率要求達(dá)到99％，系統(tǒng)的有效性和可靠性要高等。約束與限制：文件內(nèi)部格式要與word系統(tǒng)一致。開發(fā)平臺(tái)為Linux系統(tǒng)，以及使用C語言等1-4需求規(guī)格說明需求規(guī)格說明定義高質(zhì)量需求規(guī)格說明的特征軟件需求規(guī)格說明亦稱軟件需求規(guī)約或功能規(guī)格說明，是需求工程最終產(chǎn)生的結(jié)果，是軟件所應(yīng)滿足的全部需求，可用文檔的形式陳述這些需求。是項(xiàng)目相關(guān)人員對(duì)將要開發(fā)的軟件系統(tǒng)所達(dá)成的共識(shí)，是進(jìn)行系統(tǒng)設(shè)計(jì)、實(shí)現(xiàn)、測試和驗(yàn)收的基本依據(jù)。同時(shí)還代表權(quán)限的移交點(diǎn)，是軟件開發(fā)最為重要的文檔。需求規(guī)格說明在開發(fā)過程中十分重要，一個(gè)質(zhì)量較高的規(guī)格說明應(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)先級(jí)：給每項(xiàng)需求、特性或使用實(shí)例分配一個(gè)實(shí)施優(yōu)先級(jí)。無二義性：對(duì)所有需求說明都只能由一個(gè)明確統(tǒng)一的解釋。可驗(yàn)證性：檢查每項(xiàng)需求是否能通過設(shè)計(jì)測試用例或其他的驗(yàn)證方法。1-4需求規(guī)格說明1-2需求工程定義需求工程DavisA.M.：軟件需求是“直到把軟件分解為實(shí)際架構(gòu)組件之前的所有活動(dòng)”BaryI.k：需求工程是指對(duì)問題域及需求做調(diào)查研究和描述，設(shè)計(jì)滿足哪些需求的解系統(tǒng)的特性，并用文檔給與說明1-5需求工程定義什么是需求工程高質(zhì)量需求規(guī)格說明的特征是指應(yīng)用工程化的方法、技術(shù)和規(guī)格來開發(fā)和管理軟件的需求，其目標(biāo)是要獲取高質(zhì)量的軟件需求。與軟件工程中的需求分析概念相比，需求工程突出了工程化的原則，強(qiáng)調(diào)以系統(tǒng)化、條理化、可重復(fù)化的方法和技術(shù)進(jìn)行與軟件需求相關(guān)的活動(dòng)。從不同形式的需求工程定義來看，需求工程應(yīng)該是由一系列與軟件需求活動(dòng)組成的。需求工程可認(rèn)為是由需求的開發(fā)活動(dòng)和管理活動(dòng)組成的，因此需求工程的任務(wù)可概要表示如下：確定待開發(fā)的軟件系統(tǒng)的用戶類，并獲取他們的需求信息。分析用戶的需求信息，按軟件需求的類型分類需求信息，過濾掉不是需求的信息。根據(jù)軟件需求信息建立軟件系統(tǒng)的邏輯模型或需求模型，確認(rèn)非功能需求和約束條件及限制。根據(jù)收集的需求信息和邏輯模型編寫需求規(guī)格說明及其文檔。評(píng)審需求規(guī)格說明。當(dāng)需求發(fā)生變更時(shí)，對(duì)需求規(guī)格說明及需求變更實(shí)施進(jìn)行管理。1-5需求工程定義1-6其他一些基本概念04利用計(jì)算機(jī)系統(tǒng)所提供服務(wù)的人。直接操作計(jì)算機(jī)系統(tǒng)的人，就是直接使用系統(tǒng)軟件的人。用戶掌握經(jīng)費(fèi)的人，通常有權(quán)決定軟件需求，客戶也可以是用戶。正式接受新開發(fā)或修改后的硬件和軟件系統(tǒng)的某個(gè)人或組織?？蛻魹榭蛻糸_發(fā)軟件系統(tǒng)的人?？蛻艉蛙浖_發(fā)人員可以屬于同一組織，也可以不同屬。軟件開發(fā)人員項(xiàng)目相關(guān)人員與提出和定義軟件需求相關(guān)的人，包括所有的用戶、客戶和軟件開發(fā)人員。1-6其他一些基本概念第2章軟件工程與需求工程

目錄軟件工程軟件開發(fā)過程模型需求工程與軟件開發(fā)軟件需求的開發(fā)和管理過程2-12-22-32-42-1軟件工程軟件工程軟件危機(jī)指工程方法開發(fā)和維護(hù)軟甲的過程和有關(guān)技術(shù)，主要適用對(duì)象是大型軟件。研究的基本內(nèi)容包括軟件開發(fā)過程、軟件開發(fā)和維護(hù)的方法與技術(shù)、軟件開發(fā)和維護(hù)工具系統(tǒng)、質(zhì)量評(píng)價(jià)和質(zhì)量保證、軟件管理和軟件開發(fā)環(huán)境等。指人們難以控制軟件的開發(fā)和維護(hù)，具體表現(xiàn)為：大型軟件系統(tǒng)十分復(fù)雜，很難理解和維護(hù)軟件開發(fā)周期過長大型軟件系統(tǒng)的可靠性差軟件費(fèi)用往往超出預(yù)算2-1軟件工程軟件危機(jī)讓人們認(rèn)識(shí)到需要工程化的方法來開發(fā)和維護(hù)軟件。2-2軟件開發(fā)過程模型軟件開發(fā)過程模型軟件生命期該模型是為獲得高質(zhì)量的軟件系統(tǒng)所需完成的一系列任務(wù)的框架。它規(guī)定了完成各項(xiàng)任務(wù)的工作步驟。在軟件工程的初期，軟件生命期的概念被提出，用標(biāo)準(zhǔn)的形式表示和定義了軟件生存過程。指的是軟件從軟件計(jì)劃開始，經(jīng)歷需求分析和定義、設(shè)計(jì)、編碼、測試、運(yùn)行、維護(hù)直到廢止為止的期間，被視為軟件開發(fā)過程模型的依據(jù)2-2軟件開發(fā)過程模型2-2-1瀑布式模型瀑布式開發(fā)模型是最早依據(jù)軟件生命期開發(fā)的模型，亦稱軟件生命期模型，如下圖所示。其特點(diǎn)是階段間具有順序性和依賴性，各階段必須完成規(guī)定的文檔，從而在審查文檔的基礎(chǔ)上保證軟件的質(zhì)量等。2-2軟件開發(fā)過程模型瀑布式模型只提供了一個(gè)完成軟件開發(fā)和維護(hù)任務(wù)的指導(dǎo)性框架，缺乏具體的實(shí)施方法和技術(shù)，也并非以線性方式進(jìn)行。在實(shí)際的軟件開發(fā)工作中還存在著反復(fù)。例如，在設(shè)計(jì)中發(fā)現(xiàn)需求比較含糊，則需回到需求分析與定義階段重新講行外理。2-2-1瀑布式模型瀑布式開發(fā)模型各階段都有明確的分工和任務(wù)，并且彼此間緊密相關(guān)，后一階段的工作需要依據(jù)前一階段的工作結(jié)果展開，各階段基本任務(wù)如下：軟件開發(fā)計(jì)劃：確定軟件開發(fā)項(xiàng)目必須完成的總目標(biāo)，統(tǒng)籌項(xiàng)目資源，產(chǎn)生任務(wù)計(jì)劃書以及項(xiàng)目可行性報(bào)告。需求分析與定義：軟件開發(fā)人員與用戶一起理解和表達(dá)用戶需求，產(chǎn)生需求規(guī)格說明。設(shè)計(jì)：分為總體設(shè)計(jì)和詳細(xì)設(shè)計(jì)兩個(gè)子階段。總體設(shè)計(jì)階段根據(jù)軟件需求規(guī)格說明建立軟件系統(tǒng)的結(jié)構(gòu)，描述軟件系統(tǒng)的具體功能和接口，詳細(xì)設(shè)計(jì)階段產(chǎn)生編碼階段所需的一系列模塊設(shè)計(jì)規(guī)格說明。編碼：根據(jù)設(shè)計(jì)要求,使用某種程序設(shè)計(jì)語言編寫程序。測試：對(duì)軟件系統(tǒng)進(jìn)行檢查和測試，及時(shí)地發(fā)現(xiàn)和糾正軟件系統(tǒng)中的故障和邏輯錯(cuò)誤，并產(chǎn)生測試報(bào)告等。測試也可分為單元測試和綜合測試。維護(hù)：通過各種必要的維護(hù)活動(dòng)保證軟件系統(tǒng)正常運(yùn)行,并能持久地滿足用戶的需求。2-2軟件開發(fā)過程模型2-2-1瀑布式模型瀑布式模型在20世紀(jì)80年代之前一直是唯一廣泛乎田的生命期模型，現(xiàn)在仍然是軟件工程中應(yīng)用得最廣泛的模型。傳統(tǒng)的瀑布式模型也存在諸多問題：在實(shí)際開發(fā)工作中，用戶的需求需要逐步完善，而模糊的需求導(dǎo)致開發(fā)的軟件不能夠令用戶滿意或者用戶的需求需要更改時(shí)，都會(huì)導(dǎo)致軟件開發(fā)工作按瀑布式模型的步驟從頭開始，增加了軟件開發(fā)的難度。由于模型各階段的界線劃分清晰獨(dú)立，而且參加人員和開發(fā)人員也都相對(duì)獨(dú)立，在階段間移交信息（文檔）的過程中，個(gè)人的理解的不同或者當(dāng)事人不在時(shí)，容易產(chǎn)生誤解。這容易導(dǎo)致開發(fā)出的軟件系統(tǒng)與用戶需求產(chǎn)生偏差。用戶的參與程度不夠。軟件的運(yùn)行版本要等到測試后才會(huì)出現(xiàn)，用戶也只能在需求分析與定義階段和測試階段的后期參與到開發(fā)工作中，在相當(dāng)長的一段時(shí)間內(nèi)沒有參與其中。2-2軟件開發(fā)過程模型2-2-2快速原型模型軟件原型是指待開發(fā)的軟件系統(tǒng)的部分實(shí)現(xiàn)，而快速原型是在完成最終可運(yùn)行軟件系統(tǒng)之前快速建立實(shí)驗(yàn)性的、可在計(jì)算機(jī)上運(yùn)行的程序(原型)，然后給予評(píng)價(jià)的過程。該模型是針對(duì)瀑布式模刑存在的不足而提出的改進(jìn)模型，下圖表示了它的基本過程。2-2軟件開發(fā)過程模型該模型的基本思想是快速建立一個(gè)實(shí)現(xiàn)了若干功能(不要求完全)的可運(yùn)行模型來啟發(fā)、揭示和不斷完善用戶需求，直到滿足用戶的全部需求為止。對(duì)于開發(fā)出的原型，其用途是獲知用戶的真正需求，一旦需求確定了，原型將被拋棄。所以重要的是必須迅速地構(gòu)建原型并根據(jù)用戶意見修改原型。UNIXShell和超文本都是廣泛使用的快速原型語言。最近的趨勢是使用第四代語言(4GL)來構(gòu)建快速原型。當(dāng)快速原型的某個(gè)部分是利用軟件工具由計(jì)算機(jī)自動(dòng)生成的時(shí)候，也可以將這部分用到最終的軟件產(chǎn)品中。2-2-2快速原型模型使用快速原型模型的目的：明確并完善需求。作為一種需求工具，原型初步實(shí)現(xiàn)系統(tǒng)的一部分。探索設(shè)計(jì)選擇方案。作為一種設(shè)計(jì)工具，探索界面技術(shù)，用于評(píng)價(jià)以后的技術(shù)方案?？梢园l(fā)展為最終的產(chǎn)品。作為一種構(gòu)造工具，原型是產(chǎn)品最初若干基本功能的實(shí)現(xiàn)。2-2軟件開發(fā)過程模型快速原型模型的特點(diǎn)：開發(fā)過程雖然仍與瀑布式模型相同，彌補(bǔ)了瀑布式模型的一些不足。使用戶的需求明確化，也可減少用戶需求的遺漏或用戶頻繁修改需求的可能性。用戶可以充分地參與到軟件開發(fā)中?？焖僭湍Ｐ鸵泊嬖谥蛔阒帲河脩粢子谝曉蜑檎疆a(chǎn)品?？焖僭拖到y(tǒng)對(duì)于軟件系統(tǒng)的開發(fā)環(huán)境要求較多,在一定程度上影響了其使用的范圍和實(shí)用價(jià)值。2-2-3漸增式模型漸增式模型亦稱增量模型，其基本思想是從核心功能開始,通過不斷地改進(jìn)和擴(kuò)充，使得軟件系統(tǒng)能適應(yīng)用戶需求的變動(dòng)和擴(kuò)充，從而獲得柔性較高的軟件系統(tǒng)。其開發(fā)過程如下圖所示，在實(shí)現(xiàn)各個(gè)構(gòu)件之前需要全部完成需求分析和概要設(shè)計(jì)工作。2-2軟件開發(fā)過程模型漸增式模型類似快速原型模型，都盡可能快給用戶提供可用的軟件系統(tǒng)，但快速原型模型主要根據(jù)用戶需求較為模糊的部分優(yōu)先開發(fā)原型。而漸增式模型則從功能明確、設(shè)計(jì)技術(shù)上不確定因素很少的核心功能優(yōu)先開發(fā)，并且分批地逐步向用戶提交產(chǎn)品。2-2-3漸增式模型漸增式模型的特點(diǎn)：能在短時(shí)間向用戶提交可完成部分功能的產(chǎn)品。能逐步增強(qiáng)產(chǎn)品功能，以使用戶有較充裕的時(shí)間學(xué)習(xí)和適應(yīng)新的軟件系統(tǒng)。漸增式模型存在如下一些不足之處:在把每個(gè)新增的構(gòu)件或功能集成到現(xiàn)有的軟件系統(tǒng)中時(shí)，必須不破壞該軟件系統(tǒng)。在設(shè)計(jì)軟件系統(tǒng)的體系結(jié)構(gòu)時(shí)，要充分考慮其開放性，加入新構(gòu)件的過程必須簡單和方便。2-2軟件開發(fā)過程模型2-2-4螺旋式模型軟件開發(fā)過程種存在各種各樣的風(fēng)險(xiǎn)。因此，在軟件的開發(fā)過程中應(yīng)該考慮各種風(fēng)險(xiǎn)問題。螺旋式模型的基本思想是：將瀑布式模型與快速原型模型結(jié)合到一起，加上風(fēng)險(xiǎn)分析。2-2軟件開發(fā)過程模型理解這種模型的一個(gè)簡便方法是把它看作在每個(gè)階段之前都增加風(fēng)險(xiǎn)分析。該模型的開發(fā)過程為依螺旋方式旋轉(zhuǎn)，其4個(gè)方面的活動(dòng)分布在簡稱為坐標(biāo)系的4個(gè)象限上,這些活動(dòng)如左圖所示。2-2-4螺旋式模型螺旋式模型的特點(diǎn)如下：適用于軟件開發(fā)機(jī)構(gòu)內(nèi)部開發(fā)大規(guī)模軟件項(xiàng)目。對(duì)于可選方案和約束條件的強(qiáng)調(diào)有利于已有軟件的重用，也有助于把軟件質(zhì)量作為軟件開發(fā)的一個(gè)重要目標(biāo)。減少過多測試或測試不足所帶來的風(fēng)險(xiǎn)。該模型要求軟件開發(fā)人員具有豐富的風(fēng)險(xiǎn)評(píng)估經(jīng)驗(yàn)和專門知識(shí)，這往往是大部分軟件開發(fā)人員所不具備的。2-2軟件開發(fā)過程模型2-2-5敏捷模型該模型是一種可快速應(yīng)對(duì)需求變化的開發(fā)方法，非常適合于移動(dòng)互聯(lián)網(wǎng)時(shí)代用戶需求快速迭代的項(xiàng)目，它將變更作為軟件開發(fā)的常態(tài)，采用“輕量級(jí)”方法來適應(yīng)不斷變化的需求。軟件開發(fā)中呈現(xiàn)敏捷性的四個(gè)關(guān)鍵點(diǎn)：個(gè)體和互動(dòng)高于流程和工具、可工作的軟件高于詳盡的文檔、客戶合作高于合同談判、響應(yīng)變化高于遵循計(jì)劃。2-2軟件開發(fā)過程模型該模型包含了迭代和增量開發(fā)的內(nèi)涵，不均形式地向用戶頻繁交付可執(zhí)行的程序，同時(shí)將傳統(tǒng)軟件生命周期不同階段的名稱重命名為用戶故事、驗(yàn)收測試、測試驅(qū)動(dòng)的開發(fā)、重構(gòu)、持續(xù)集成，左圖展示了敏捷模型的一般開發(fā)過程。2-2-5敏捷模型特定變種的敏捷模型：極限編程、Scrum、動(dòng)態(tài)系統(tǒng)開發(fā)方法、敏捷統(tǒng)一過程、特性驅(qū)動(dòng)開發(fā)等。常用的是極限編程和Scrum以及這兩者的混合型。該模型的特點(diǎn)是：輕量、適應(yīng)性強(qiáng)，能快速響應(yīng)需求的變化。支持快速編碼，基于用戶使用的檢驗(yàn)結(jié)果對(duì)于可能的錯(cuò)誤快速進(jìn)行重構(gòu)。相比于瀑布模型、螺旋模型等傳統(tǒng)開發(fā)模型，在系統(tǒng)內(nèi)外部復(fù)雜因素增加時(shí)，項(xiàng)目開發(fā)的成功率更高。2-2軟件開發(fā)過程模型該模型存在的問題則是局限于小型開發(fā)團(tuán)隊(duì)，是否適合于大型項(xiàng)目和大型開發(fā)團(tuán)隊(duì)存在較多的爭議和質(zhì)疑。2-2-6基于組件的模型軟件組件是指包含、可編程、可重用、與語言無關(guān)的軟件單元，作為構(gòu)造軟件的“零部件”，可被用來構(gòu)造其他軟件。該模型依賴于可復(fù)用的軟件組件和能集成這些組件的框架，其開發(fā)過程下圖所示。2-2軟件開發(fā)過程模型在基于組件的模型中，需求定義、測試和維護(hù)階段與其他模型類似，中間階段則有較大差異。2-2-6基于組件的模型該模型中間階段的基本任務(wù)如下：組件分析：針對(duì)需求定義，搜尋可滿足功能的組件。需求修改：根據(jù)可獲得的組件信息重新對(duì)需求進(jìn)行分析，并對(duì)需求進(jìn)行修改。使用復(fù)用的系統(tǒng)設(shè)計(jì)：分析已獲得的軟件組件，設(shè)計(jì)系統(tǒng)框架組織組件，可重復(fù)使用一個(gè)框架。開發(fā)和集成：當(dāng)所需的組件缺乏現(xiàn)成產(chǎn)品時(shí)，自行開發(fā)后與已有的組件集成為完整軟件系統(tǒng)。基于組件的模型的特點(diǎn)是：減少了軟件開發(fā)的工作量，從而降低了軟件開發(fā)成本，并有利于快速交付。成熟的組件已經(jīng)過大量的驗(yàn)證，有利于提高軟件質(zhì)量，降低開發(fā)風(fēng)險(xiǎn)。但基于組件的模型也存在一些不足：若過于依賴現(xiàn)有的組件而對(duì)原始需求的修改，容易導(dǎo)致最終開發(fā)的系統(tǒng)不符合用戶的真正需求。外部組件的版本更新不受自己控制，進(jìn)而導(dǎo)致難以控制所開發(fā)系統(tǒng)的進(jìn)化。2-2軟件開發(fā)過程模型2-3需求工程在軟件開發(fā)中的地位2-3-1需求工程對(duì)軟件開發(fā)中的影響需求工程是軟件開發(fā)過程中的一個(gè)階段，處于軟件開發(fā)的開始階段，提供了軟件項(xiàng)目其余部分得以實(shí)施的根基，能夠避免軟件以錯(cuò)誤的基礎(chǔ)進(jìn)行開發(fā)，因此，需求工程在軟件開發(fā)中起著十分重要的作用。需求工程對(duì)軟件開發(fā)的影響如下:需求是制訂項(xiàng)目計(jì)劃的基礎(chǔ)。開發(fā)資源和進(jìn)度安排的估算都應(yīng)建立在對(duì)最終軟件系統(tǒng)的真正理解上。需求工程所產(chǎn)生的最終產(chǎn)物(需求規(guī)格說明)是軟件設(shè)計(jì)和軟件實(shí)現(xiàn)的基礎(chǔ)。軟件設(shè)計(jì)工作要根據(jù)功能需求來確定系統(tǒng)的結(jié)構(gòu)和模塊，而模塊又是編寫代碼的依據(jù)。需求規(guī)格說明是測試工作和用戶驗(yàn)收軟件系統(tǒng)的依據(jù)。測試人員需要根據(jù)用戶需求開展測試。此外，軟件系統(tǒng)能否最終滿足用戶需求，與需求規(guī)格說明能否正確和完整地反映用戶需求是緊密相關(guān)的。需求規(guī)格說明是軟件維護(hù)工作的依據(jù)。2-3需求工程在軟件開發(fā)中的地位2-3-2需求工程面臨的困難需求工程是人們通過不斷地認(rèn)識(shí)和深入研究而形成的結(jié)果，對(duì)軟件開發(fā)的影響是很大的。隨著軟件系統(tǒng)日益大型和復(fù)雜化，軟件需求的開發(fā)和管理也日益復(fù)雜，而且需求工程自身也面臨諸多有待解決的問題，如:需求獲取與需求分析的困難性。有些需求可能用戶也不是很清楚;需要用戶與開發(fā)人之間進(jìn)行充分的交流和協(xié)商；需求間的沖突和矛盾的檢查以及解決；需求是否完整和確定；合適的需求建模的方法和技術(shù)。需求描述語言和規(guī)范化的困難性。怎樣規(guī)范化用戶需求；規(guī)范化哪些用戶需求；非形式化和形式化描述語言的使用。2-3需求工程在軟件開發(fā)中的地位2-3-2需求工程面臨的困難需求驗(yàn)證的困難性。需求規(guī)格說明正確性的確認(rèn)和驗(yàn)證；驗(yàn)證的方法和技術(shù);如何進(jìn)行自動(dòng)驗(yàn)證。需求管理的困難性。需求規(guī)格說明書的質(zhì)量保證；需求規(guī)格說明書的版本管理；需求變更的控制。如何解決這些困難和問題，決定需求工程的目的、研究內(nèi)容和所要完成的實(shí)際工作。2-3需求工程在軟件開發(fā)中的地位2-4需求工程的開發(fā)和管理過程需求工程的目標(biāo)需求工程的目標(biāo)就是給出待開發(fā)或待完善的軟件系統(tǒng)的一個(gè)清晰的、完整的、無二義性的和精確的描述，并最終產(chǎn)生高質(zhì)量的軟件需求規(guī)格說明，這需要通過需求工程中一系列的活動(dòng)完成的。2-4需求工程的開發(fā)和管理過程需求工程的開發(fā)和管理過程軟件需求的開發(fā)和管理過程是由導(dǎo)出、確認(rèn)和維護(hù)軟件系統(tǒng)需求規(guī)格說明的一系列活動(dòng)織成的。實(shí)際上，一個(gè)完整的過程描述應(yīng)該包括要執(zhí)行的活動(dòng)、活動(dòng)的組織或調(diào)度、每個(gè)活動(dòng)的負(fù)責(zé)人、活動(dòng)的輸人和輸出、用于支持開發(fā)和維護(hù)需求的工具等。在過程的實(shí)際執(zhí)行中出現(xiàn)問題時(shí)，還需要對(duì)過程進(jìn)行改進(jìn)。這是過程管理方面的內(nèi)容，可用CMM(CapabilityMaturityModel)方法來評(píng)估需求工程的成熟度問題。2-4需求工程的開發(fā)和管理過程需求工程的開發(fā)和管理過程需求工程的開發(fā)和管理過程可大致劃分為如右圖所示的需求開發(fā)和需求管理兩個(gè)階段。需求開發(fā)主要產(chǎn)生正式的需求規(guī)格說明，需求管理主要根據(jù)需求的變化對(duì)需求規(guī)格說明的內(nèi)容及版本進(jìn)行管理。此外，對(duì)于需求開發(fā)階段又可再細(xì)分為如下兩個(gè)階段：用戶的意圖分析：收集、婦納和整理用戶提出的各種問題和要求(比較含糊)，弄清系統(tǒng)要做什么，應(yīng)做什么，然后將它們明確化。需求規(guī)范化：從邏輯上完整地和嚴(yán)格地描述所要開發(fā)的系統(tǒng)，并保證其能反映用戶的需求。2-4需求工程的開發(fā)和管理過程需求工程的開發(fā)和管理過程在需求工程的實(shí)際處理過程中，為了如實(shí)地反映出需求工程的實(shí)際執(zhí)行過程，需求工程過程可進(jìn)一步劃分為如下圖所示的若干階段。細(xì)分后需求開發(fā)階段的四個(gè)活動(dòng)的主要任務(wù)如下:需求獲?。捍_定和收集與軟件系統(tǒng)相關(guān)的、來自不同來源和對(duì)象的用戶需求信息。需求分析：對(duì)獲得的用戶需求信息進(jìn)行分析和綜合，以獲得用戶對(duì)軟件系統(tǒng)的真正需求，建立軟件系統(tǒng)的邏輯模型(或需求模型)。需求定義：使用適當(dāng)?shù)拿枋稣Z言，按標(biāo)準(zhǔn)的格式描述軟件系統(tǒng)的需求，并產(chǎn)生需求規(guī)格說明及其相應(yīng)文檔。需求驗(yàn)證：審查和驗(yàn)證需求規(guī)格說明是否正確和完整地表達(dá)了用戶對(duì)軟件系統(tǒng)的需求。需求管理的任務(wù)需求工程存在的問題有效地管理軟件系統(tǒng)的需求規(guī)格說明及其相應(yīng)文檔，評(píng)估需求變更帶來的潛在影響及可能的成本費(fèi)用，跟蹤軟件需求的狀態(tài)，管理需求規(guī)格說明的版本等。需求工程過程中各個(gè)階段相對(duì)獨(dú)立，基本按線性方式執(zhí)行但在實(shí)施過程中也存在反復(fù)的情況，如需求驗(yàn)證發(fā)現(xiàn)需求規(guī)格說明中有問題，則需要返回到需求分析階段重新分析，甚至也可能返回到需求獲取階段重新收集需求信息等。2-4需求工程的開發(fā)和管理過程第3章需求獲取

目錄確定需求開發(fā)計(jì)劃確定項(xiàng)目的目標(biāo)和范圍確定調(diào)查對(duì)象實(shí)地收集需求信息3-13-23-33-4確定非功能需求3-5在收集需求信息中應(yīng)注意的問題3-6使用場景技術(shù)的需求獲取3-7軟件需求獲取軟件需求獲取(簡稱需求獲取)階段的任務(wù)簡單地說就是獲取用戶的需求信息。開發(fā)人員需要從用戶所提供的大量信息中分析和理解用戶真正的需求，需求獲取階段的活動(dòng)可大致劃分為右圖所示的一系列工作。需求獲取3-1確定需求開發(fā)計(jì)劃基本任務(wù)需求工程的安排確定需求開發(fā)的實(shí)施步驟，并給出收集需求活動(dòng)的具體安排和進(jìn)度。重點(diǎn)：分析、理解和描述用戶的需求，著重于軟件系統(tǒng)“做什么”。需求工程是軟件開發(fā)過程中的一個(gè)階段，故其所占用的時(shí)間和費(fèi)用有限，需要注意的是：只能考慮與需求開發(fā)相關(guān)的工作。安排進(jìn)度時(shí)應(yīng)考慮困難性和靈活性。安排進(jìn)度和時(shí)間時(shí)應(yīng)考慮書寫和整理需求規(guī)格說明及其文檔3-1確定需求開發(fā)計(jì)劃3-2確定項(xiàng)目的目標(biāo)和范圍確定項(xiàng)目范圍的益處基本任務(wù)可以判斷用戶所提出的需求信息是否對(duì)項(xiàng)目合適。有些用戶需求信息可能是建議，這些建議是項(xiàng)目之外的，但可能有價(jià)值。根據(jù)項(xiàng)目目標(biāo)把項(xiàng)目相關(guān)人員定位到一個(gè)共同的和明確的方向上，并決定軟件系統(tǒng)的范圍。項(xiàng)目目標(biāo)：主要包括項(xiàng)目開發(fā)的目的和意義，以及軟件系統(tǒng)應(yīng)實(shí)現(xiàn)的目標(biāo)(即目標(biāo)需求)。項(xiàng)目范圍：指軟件系統(tǒng)具體應(yīng)包括和不應(yīng)包括的部分，以及軟件系統(tǒng)所涉及的各個(gè)方面。目標(biāo)需求會(huì)來源于各個(gè)不同的人，需要在制定需求規(guī)格說明之前予以解決他們的目標(biāo)需求的沖突。3-2確定項(xiàng)目的目標(biāo)和范圍3-3確定調(diào)查對(duì)象基本任務(wù)根據(jù)需求層次分類用戶明確地確定來自不同層次的需求來源和用戶，并將其分類。缺乏用戶參與以及最終形成的用戶需求不完整會(huì)導(dǎo)致開發(fā)項(xiàng)目失敗。軟件的需求分為目標(biāo)需求、業(yè)務(wù)需求和功能及非功能需求三個(gè)層次，故根據(jù)需求的層次來區(qū)分不同的用戶：提出目標(biāo)需求的用戶。提出業(yè)務(wù)需求和功能需求的用戶。軟件開發(fā)人員，主要是指系統(tǒng)分析員。3-3

確定調(diào)查對(duì)象根據(jù)用戶特點(diǎn)分類用戶用戶代表的義務(wù)為了避免忽視和遺漏某些用戶的情況，可以根據(jù)用戶的某些方面將用戶分類：根據(jù)用戶所在的部門和職責(zé)，如計(jì)劃部門、銷售部門、財(cái)務(wù)部門等。根據(jù)用戶使用系統(tǒng)的頻繁度和優(yōu)先級(jí)等。根據(jù)用戶掌握的計(jì)算機(jī)知識(shí)和使用計(jì)算機(jī)的熟練程度。根據(jù)直接使用和非直接使用軟件系統(tǒng)的情況。每類用戶的代表或聯(lián)絡(luò)人等人代表著特定的用戶類，充當(dāng)該用戶類與開發(fā)人員之間的“窗口”。用戶代表從他所代表的用戶類中收集需求信息，協(xié)調(diào)他所代表的用戶在需求表達(dá)上的不一致和矛盾，為用戶類整理成統(tǒng)一的需求信息。此外，用戶代表應(yīng)具有如右表所示的義務(wù)：3-3

確定調(diào)查對(duì)象其他軟件需求來源需求信息除了來自用戶類外，還可來自其他方面，為了不遺漏必要的需求信息，還需考慮從其他地方能收集到的需求信息，下列是幾個(gè)典型的軟件需求來源：直接和間接使用軟件系統(tǒng)的用戶。系統(tǒng)需求規(guī)格說明。市場調(diào)查和用戶問卷調(diào)查。已開發(fā)的和待開發(fā)的同類軟件系統(tǒng)的描述和文檔。對(duì)人工系統(tǒng)中存在的問題的報(bào)告。觀察正在工作的用戶。用戶工作內(nèi)容的分析。3-3

確定調(diào)查對(duì)象需求的決策者大量需求信息會(huì)包含一些不一致和含糊的需求，需要確定誰是需求的決策者來根據(jù)具體情況，對(duì)存在問題的需求信息做出決定。在處理有問題的需求信息時(shí)，決策者并不是固定不變的，而是根據(jù)實(shí)際中可能發(fā)生的具體問題來確定。例如：當(dāng)開發(fā)人員想象中的系統(tǒng)與用戶需求不一致時(shí)，決策者為用戶。3-4實(shí)地收集需求信息3-4-1實(shí)地收集需求信息面臨的困難實(shí)地收集需求信息并不簡單，軟件開發(fā)人員需要與用戶進(jìn)行充分的交流，聽取用戶對(duì)軟件系統(tǒng)的看法和意見，需要用戶花費(fèi)時(shí)間來講解他們的業(yè)務(wù)流程和工作內(nèi)容。因此，開發(fā)人員往往會(huì)遇到如下一些困難:能提出軟件需求的用戶可能覺得沒有充分的時(shí)間與開發(fā)人員進(jìn)行交流和討論。有時(shí)用戶希望通過簡單的方法和說明，或者通過簡單回答開發(fā)人員的詢問后，軟件開發(fā)人員就能清楚地理解他們的需求。用戶和開發(fā)人員只考慮自己的利益。用戶本身不能提出明確的需求。開發(fā)人員缺乏用戶的業(yè)務(wù)知識(shí)，而用戶也缺乏計(jì)算機(jī)方面的知識(shí)。3-4

實(shí)地收集需求信息3-4-2實(shí)地調(diào)查的步驟為獲得充分的用戶需求信息，須實(shí)地進(jìn)行調(diào)查并與用戶交流，因此，有步驟地進(jìn)行實(shí)地調(diào)查相當(dāng)重要的。實(shí)地調(diào)查通常分為三個(gè)步驟：向掌握“全局”的負(fù)責(zé)人調(diào)查。掌握“全局”的負(fù)責(zé)人包括組織機(jī)構(gòu)的負(fù)責(zé)人和高層管理人員。向部門負(fù)責(zé)人調(diào)查。部門負(fù)責(zé)人不但熟悉本部門的各項(xiàng)業(yè)務(wù)和業(yè)務(wù)流程，也熟悉部門之間的相互關(guān)系。向業(yè)務(wù)人員調(diào)查。業(yè)務(wù)人員熟悉自身工作的處理細(xì)節(jié)，如具體數(shù)據(jù)或表格的作用、來源和去向、類型、精度、處理要求和輸人/輸出的格式等。上述調(diào)查步驟中，步驟2和步驟3是一個(gè)反復(fù)的過程，每次調(diào)查之前要制定調(diào)查提綱并作記錄，交由用戶審查核實(shí)，以保證需求信息的可靠和準(zhǔn)確。3-4

實(shí)地收集需求信息3-4-3實(shí)地收集需求信息的方式獲取需求的工作只能通過用戶和開發(fā)人員間有效的合作和交流才能成功。為了提高合作和交流的效率，需要有較好的交流方式和手段。開發(fā)人員與用戶的交流可采取如下幾種方式：座談會(huì)的方式。通過會(huì)議獲得用戶需求信息是用戶與開發(fā)人員交流的一種很好的方式，也是相當(dāng)常見的方式。書面咨詢的方式。書面咨詢的方式是由軟件開發(fā)人員將所關(guān)心的和有待澄清的問題以書面形式提交給用戶。利用用例表示方法。用例是了解用戶的業(yè)務(wù)流程和澄清含糊細(xì)節(jié)的好方法，用于描述軟件系統(tǒng)與一個(gè)外部“執(zhí)行者”的交互順序，主要體現(xiàn)執(zhí)行者完成一次任務(wù)的過程。3-4

實(shí)地收集需求信息3-4-4需求信息的分類對(duì)于一個(gè)復(fù)雜的軟件系統(tǒng)，通過收集而得到的用戶需求信息是相當(dāng)龐大和復(fù)雜的，開發(fā)人員必須把收集到的全部需求信息分成不同的類型后，一方面為編制需求規(guī)格說明和其他文檔等提供基本材料，另一方面也為刪除一些不是真正需求的信息提供依據(jù)。因此，給出需求信息的類型是一項(xiàng)重要的工作，需求信息可大致分類如下：目標(biāo)需求:描述用戶或開發(fā)機(jī)構(gòu)通過產(chǎn)品可獲得的利益和利潤，以及與產(chǎn)品相關(guān)的發(fā)展規(guī)劃等方面的信息。用例說明：有關(guān)利用系統(tǒng)完成業(yè)務(wù)任務(wù)或如何實(shí)現(xiàn)用戶目標(biāo)的陳述可能就是用例。業(yè)務(wù)規(guī)則：一些活動(dòng)只能在特定的條件下由一些特定的人來完成。功能需求：客戶要求系統(tǒng)具有哪些功能和行為。外部接口需求：這類需求描述了系統(tǒng)與外部的聯(lián)系。限制：指一些合理限制設(shè)計(jì)者和程序員選擇的條件。數(shù)據(jù)定義：描述一個(gè)數(shù)據(jù)項(xiàng)或一個(gè)復(fù)雜的業(yè)務(wù)數(shù)據(jù)結(jié)構(gòu)的格式、允許值或默認(rèn)值。解決方案：描述了用戶與系統(tǒng)交互的特定方法，使系統(tǒng)產(chǎn)生一系列活動(dòng)。3-4

實(shí)地收集需求信息3-5確定非功能需求非功能需求指的是衡量軟件能否良好運(yùn)行的定性指標(biāo)。非功能需求很難定義，由于缺乏定量指標(biāo)，因此很難根據(jù)這些需求來評(píng)價(jià)軟件系統(tǒng)，這也是開發(fā)出來的軟件系統(tǒng)與用戶所需的軟件系統(tǒng)之間存在差異的主要原因。對(duì)軟件系統(tǒng)的非功能需求有很多，此處僅列舉一些用戶所關(guān)心的非功能需求：可靠性：指軟件系統(tǒng)能夠在給定的時(shí)間和環(huán)境條件下完成所需功能的概率?？蓴U(kuò)充性：軟件系統(tǒng)能夠方便和容易地增加新功能的能力。安全性：涉及防止非法訪問系統(tǒng)功能，防止數(shù)據(jù)丟失，防止病毒感染和防止私人數(shù)據(jù)進(jìn)入系統(tǒng)等。健壯性：指軟件系統(tǒng)與其他系統(tǒng)交換數(shù)據(jù)和服務(wù)的難易程度。易使用性：指用戶學(xué)習(xí)和使用軟件系統(tǒng)功能的簡易程度，可維護(hù)性：指在軟件系統(tǒng)中發(fā)現(xiàn)并糾正一個(gè)故障或進(jìn)行一次更改的簡易程度?？梢浦残裕褐笇⒁粋€(gè)軟件系統(tǒng)從一個(gè)運(yùn)行環(huán)境移植到另一個(gè)運(yùn)行環(huán)境所需的工作量的度量。可重用性：指組成軟件系統(tǒng)中的某個(gè)部件除了在最初開發(fā)的系統(tǒng)中能使用外，還可以在其他應(yīng)用系統(tǒng)中使用的程度。3-5

確定非功能需求收集非功能需求的方法在收集需求信息時(shí)，必須根據(jù)用戶對(duì)系統(tǒng)的期望來確定非功能需求。大多數(shù)用戶并不可能提出具體的和量化的非功能需求。開發(fā)人員在收集非功能需求信息時(shí)，要注意使用一些方法，例如:將不同用戶類代表提出的可能很重要的非功能需求進(jìn)行綜合，并根據(jù)其中的每個(gè)需求設(shè)計(jì)出許多方法，然后根據(jù)用戶的回答，使這些需求更明確化。開發(fā)人員與用戶一起對(duì)每一個(gè)非功能需求制定可測試和可驗(yàn)證的具體標(biāo)準(zhǔn)。設(shè)計(jì)與非功能需求相沖突的假設(shè)示例，利用反例來提示用戶。3-5

確定非功能需求3-6在收集需求信息中應(yīng)注意的問題收集信息過程中的問題收集需求信息中會(huì)遇到許多的困難。這些困難有些是發(fā)生在與用戶的交流方面，有些則屬技術(shù)問題，需由軟件開發(fā)人員給予注意和解決。在收集過程中，要注意如下問題:應(yīng)能適當(dāng)?shù)卣{(diào)整收集范圍。盡量把用戶所做的假設(shè)解釋清楚，特別是發(fā)生沖突的部分。盡量理解用戶用于表達(dá)他們需求的思維過程。在收集需求信息時(shí)，應(yīng)盡量避免受不熟悉細(xì)節(jié)的影響。應(yīng)盡量避免討論一些具體的解決方案。需求信息收集工作的結(jié)束。決定收集工作的結(jié)束并沒有一個(gè)簡單和嚴(yán)格的標(biāo)準(zhǔn)，需根據(jù)實(shí)際情況進(jìn)行判斷。例如:用戶不可能再提供更多新的需求信息。用戶重復(fù)提出以前已提出的需求信息。與用戶的討論開始進(jìn)入設(shè)計(jì)方面的工作。開發(fā)人員本身已提不出更多的問題。安排收集工作的結(jié)束時(shí)間已到。3-6在收集需求信息中應(yīng)注意的問題3-7使用場景技術(shù)的需求獲取3-7-1場景的定義及構(gòu)成場景是指用戶與軟件系統(tǒng)為實(shí)現(xiàn)某個(gè)目標(biāo)而進(jìn)行交互活動(dòng)過程的描述，可視為是對(duì)使用系統(tǒng)經(jīng)歷的解釋。場景的構(gòu)成可以有不同的形式，應(yīng)由如下幾個(gè)方面的內(nèi)容構(gòu)成：執(zhí)行者(用戶)。進(jìn)入場景前系統(tǒng)狀態(tài)的描述。執(zhí)行者的目的。動(dòng)作和事件系列(包括正?；蚍钦Ｊ录?。通常，場景應(yīng)具有下述特征:場景代表某些用戶可見的功能，可用于描述一個(gè)具體的系統(tǒng)功能。場景總是被參與者啟動(dòng)，并向參與者提供可識(shí)別的信息。場景必須是完整的。下圖表示了一個(gè)用自然語言描述的某人切斷PC電源的場景。3-7使用場景技術(shù)的需求獲取3-7-2場景的表示除了可用自然語言表示場景外，也可使用圖形、動(dòng)漫畫等其他表示形式。場景也可與快速原型方法結(jié)合使用。此外，也可利用一些已有的半形式化的圖形表示方法和技術(shù)(如流程圖、狀態(tài)圖、時(shí)序圖)以及形式化的方法和技術(shù)(如CCS、CSP、Z語言等)來表示場景。場景的一些典型表示形式如下表所示。3-7使用場景技術(shù)的需求獲取場景的使用者可以根據(jù)具體情況有選擇地使用上述表示形式，也可組合使用幾種表示形式。對(duì)于某些水平較高的專業(yè)技術(shù)人員，可以使用更加適合的特殊人工語言來描述場景。在需求信息的獲取中，由于用戶的參與相當(dāng)重要，使用非形式化的表示形式是合適的，形式化的表示形式對(duì)于用戶來說難以理解。3-7-3場景的種類場景描述執(zhí)行者的目標(biāo)，分為正常場景和失敗場景，正常場景注重目標(biāo)實(shí)現(xiàn)過程和效率，失敗場景注重分析失敗原因。找到執(zhí)行者不能達(dá)到目標(biāo)的理由可以成為改進(jìn)軟件系統(tǒng)的參考因素。場景進(jìn)一步可分為正向場景和逆向場景，前者描述所希望實(shí)現(xiàn)的目標(biāo)，后者描述用戶不希望的需求。逆向場景是有效的需求信息收集工具，可避免混入無用的需求信息。場景之間可以建立關(guān)系和精化處理，如擴(kuò)展關(guān)系和使用關(guān)系。若干場景中的相同動(dòng)作可以提取出來構(gòu)成一個(gè)單獨(dú)的場景。大部分場景在項(xiàng)目需求獲取階段產(chǎn)生，并隨著需求分析的深入不斷發(fā)現(xiàn)。此外新發(fā)現(xiàn)的場景應(yīng)及時(shí)補(bǔ)充進(jìn)已有的場景集合中。3-7使用場景技術(shù)的需求獲取3-7-4場景技術(shù)的特點(diǎn)場景技術(shù)把軟件系統(tǒng)的需求信息文本化，有助于在實(shí)現(xiàn)軟件系統(tǒng)前明確用戶與軟件系統(tǒng)的相互作用。此外，場景技術(shù)還具有如下特點(diǎn)：可以把當(dāng)前系統(tǒng)存在的問題作為實(shí)例記錄下來。可以成為項(xiàng)目相關(guān)人員間的共同語言。由于場景描述了軟件系統(tǒng)的操作，比較具體，易理解性較好。通過場景使得提出和獲得需求的雙方之間能建立起相應(yīng)的理解。另一方面，在使用場景技術(shù)時(shí)，也要注意如下問題:場景的數(shù)量，即一個(gè)軟件項(xiàng)目應(yīng)該寫多少個(gè)場景沒有限制標(biāo)準(zhǔn)。場景的冗余問題。應(yīng)盡量避免場景描述的內(nèi)容發(fā)生重疊。應(yīng)防止場景描述內(nèi)容的冗長。3-7使用場景技術(shù)的需求獲取3-8基于用例的需求獲取用例的定義Jacobson：用例用于描述軟件系統(tǒng)與一個(gè)外部“執(zhí)行者”(actor)的交互順序用例與前述的場景并不是同一概念。用例通常用于描述可發(fā)生的所有事件序列，而場景則是描述其中的一部分。用例也可以說是場景的集合，一個(gè)場景是用例的實(shí)例。體現(xiàn)了執(zhí)行者完成一項(xiàng)任務(wù)的過程。執(zhí)行者可為一個(gè)人或一個(gè)應(yīng)用軟件系統(tǒng)，也可以是硬件或者某些與軟件系統(tǒng)交互以實(shí)現(xiàn)某些目標(biāo)的外部實(shí)體。在利用用例建立系統(tǒng)模型時(shí)，軟件系統(tǒng)被視為一個(gè)黑盒子，并可使用自然語言順序地描述軟件系統(tǒng)與外部執(zhí)行者的相互作用。3-8

基于用例的需求獲取3-8

基于用例的需求獲取ATM的用例模型自動(dòng)取款機(jī)的用例模型如右圖所示：用結(jié)構(gòu)化自然語言的形式描述ATM正常工作的用例則如圖所示：軟件需求用例名：用例的名稱。前提條件：啟動(dòng)用例的條件。執(zhí)行者：用例的主導(dǎo)者目的：用例的目的。3-8基于用例的需求獲取結(jié)束條件:用例結(jié)束時(shí)應(yīng)滿足的條件?；拘蛄?描述在滿足前提條件下啟動(dòng)用例后，按時(shí)間順序正常發(fā)生的執(zhí)行者與軟件異常序列:按時(shí)間順序描述在正常序列的相互作用中發(fā)生異常情況時(shí)，軟件系統(tǒng)與執(zhí)行者的相互作用備注:應(yīng)向設(shè)計(jì)者轉(zhuǎn)達(dá)除功能需求以外的非功能需求、設(shè)計(jì)約束條件和限制，以及有待解決的事項(xiàng)等。第4章需求分析

目錄建立系統(tǒng)關(guān)聯(lián)圖分析需求的可行性構(gòu)建用戶接口原型需求建模確定需求的優(yōu)先級(jí)別建立數(shù)據(jù)詞典4-14-24-34-44-54-64-1建立系統(tǒng)關(guān)聯(lián)圖確定系統(tǒng)范圍的目的關(guān)聯(lián)圖一、要界定收集需求信息的范圍，提高需求獲取的效率。二、把項(xiàng)目相關(guān)人員定位到一個(gè)共同的、明確的方向上。指用于描述系統(tǒng)與外部實(shí)體間的界限和接口的模型，而且明確通過接口的信息流和物質(zhì)流。關(guān)聯(lián)圖的建立類似于傳統(tǒng)的結(jié)構(gòu)化需求建模方法中建立的0層圖。整個(gè)要開發(fā)的系統(tǒng)表示為一個(gè)橢圓，橢圓內(nèi)標(biāo)識(shí)該系統(tǒng)的名字，用帶標(biāo)識(shí)的有向邊表示系統(tǒng)與外部實(shí)體間的關(guān)系和信息(或物質(zhì))流向，用方框表示系統(tǒng)外部實(shí)體等。此外，關(guān)聯(lián)圖不明確描述系統(tǒng)的內(nèi)部過程和數(shù)據(jù)。4-1建立系統(tǒng)關(guān)聯(lián)圖例：某培訓(xùn)中心管理信息系統(tǒng)的關(guān)聯(lián)圖該系統(tǒng)應(yīng)具有記錄和分類由電子郵件或信函表達(dá)的信息，處理報(bào)名、詢問、注銷和付款，以及輸出回答信息的功能。該系統(tǒng)外的實(shí)體主要是學(xué)員和系統(tǒng)的操作員等。系統(tǒng)的關(guān)聯(lián)圖如下圖：4-1建立系統(tǒng)關(guān)聯(lián)圖建立系統(tǒng)關(guān)聯(lián)圖的好處是項(xiàng)目相關(guān)人員一開始不必去考慮太多的細(xì)節(jié)，而是把注意力集中在軟件系統(tǒng)的接口方面，并且為分析用戶需求提供很好的依據(jù)。關(guān)聯(lián)圖以圖形方式表示系統(tǒng)的范圍使得項(xiàng)目相關(guān)人員更易于理解和審查。4-2分析需求的可行性基本任務(wù)需求分析的風(fēng)險(xiǎn)類型在允許的成本和性能要求以及系統(tǒng)的范圍內(nèi)，分析每項(xiàng)需求得以實(shí)施的可能性。目的在于明確與每項(xiàng)需求相關(guān)聯(lián)的風(fēng)險(xiǎn)，包括一些與其他方面的沖突、對(duì)外部環(huán)境的依賴和某些技術(shù)的障礙等。與高風(fēng)險(xiǎn)相關(guān)的需求最有可能導(dǎo)致軟件開發(fā)工作的失敗。在實(shí)際需求分析中應(yīng)考慮的風(fēng)險(xiǎn)類型如下:性能風(fēng)險(xiǎn)：實(shí)現(xiàn)這項(xiàng)需求可能導(dǎo)致整個(gè)系統(tǒng)性能的下降。安全風(fēng)險(xiǎn)：實(shí)現(xiàn)這項(xiàng)需求可能導(dǎo)致無法滿足整個(gè)系統(tǒng)的安全需求。過程風(fēng)險(xiǎn)：實(shí)現(xiàn)這項(xiàng)需求可能導(dǎo)致需要對(duì)常規(guī)的開發(fā)過程做修改。實(shí)現(xiàn)技術(shù)風(fēng)險(xiǎn)：實(shí)現(xiàn)這項(xiàng)需求可能需要使用不熟悉的實(shí)現(xiàn)技術(shù)。數(shù)據(jù)庫風(fēng)險(xiǎn)：實(shí)現(xiàn)這項(xiàng)需求可能導(dǎo)致系統(tǒng)不支持的非標(biāo)準(zhǔn)數(shù)據(jù)。日程風(fēng)險(xiǎn)：實(shí)現(xiàn)這項(xiàng)需求可能遇到技術(shù)困難，并危及系統(tǒng)原定的開發(fā)日程。外部接口風(fēng)險(xiǎn)：實(shí)現(xiàn)這項(xiàng)需求可能涉及外部接口。穩(wěn)定風(fēng)險(xiǎn)：這項(xiàng)需求可能是易變的，將導(dǎo)致開發(fā)過程的重大變動(dòng)。4-2分析需求的可行性4-3構(gòu)建用戶接口原型基本任務(wù)拋棄型原型和進(jìn)化型原型對(duì)于軟件開發(fā)人員或用戶不能明確化的需求，通過建立相應(yīng)的用戶接口原型然后評(píng)估該原型，使得項(xiàng)目相關(guān)人員能更好理解所要解決的問題。用戶接口原型：指一個(gè)可能的局部實(shí)現(xiàn)，而不是整個(gè)系統(tǒng)，這樣可使許多概念和可能發(fā)生的事更為直觀明了。拋棄型原型：指在原型達(dá)到預(yù)期目的后將其拋棄。在構(gòu)建該原型時(shí)，可以忽略具體的軟件構(gòu)造技術(shù)，亦即以最小的代價(jià)構(gòu)造拋棄型原型。在需求分析中遇到具有不確定性、二義性、不完整或含糊特征的需求時(shí)，最合適的方法是建立拋棄型原型。進(jìn)化型原型是在需求清楚定義的情況下，以漸增式方式構(gòu)建原型，并使原型最終能成為軟件產(chǎn)品的一部分。進(jìn)化型原型一開始具有較好健壯性和高質(zhì)量的代碼，對(duì)于描述同一功能來說，構(gòu)建進(jìn)化型原型要比構(gòu)建拋棄性原型所花的時(shí)間多。4-3

構(gòu)建用戶接口原型構(gòu)建方法紙上原型化方法：代價(jià)小而且特別有效，主要是把系統(tǒng)的某部分實(shí)現(xiàn)以場景的形式，并通過書面材料呈現(xiàn)給用戶。自動(dòng)原型化方法：用第四代語言或其他開發(fā)環(huán)境來開發(fā)一個(gè)可執(zhí)行的原型。需要編寫軟件來模擬系統(tǒng)的功能，而且在構(gòu)建原型中要使用合適的高級(jí)語言和支持環(huán)境。例如：編程語言：VisualBasic、Smalltalk和第四代語言等腳本語言：Perl和Python等。商品化構(gòu)建原型的工具包和圖形用戶界面工具等?；赪eb、可以快速修改的HTML語言，以及Java語言等。人工模擬原型化方法：根據(jù)用戶的輸入由人模擬系統(tǒng)的響應(yīng)，用戶的輸入被傳遞到模擬系統(tǒng)的人，然后由人作出響應(yīng)。4-3構(gòu)建用戶接口原型4-4確定需求的優(yōu)先級(jí)劃分優(yōu)先級(jí)的重要性分配需求優(yōu)先級(jí)的方法幫助項(xiàng)目相關(guān)人員判斷系統(tǒng)的核心需求，并有助于項(xiàng)目相關(guān)人員集中于重點(diǎn)問題的交流和協(xié)商。需求優(yōu)先級(jí)之間的關(guān)聯(lián)可以幫助軟件開發(fā)人員決定軟件體系結(jié)構(gòu)，還可以幫助解決可能發(fā)生的設(shè)計(jì)沖突。根據(jù)需求的優(yōu)先級(jí)能權(quán)衡合理的項(xiàng)目范圍和進(jìn)度安排、預(yù)算、人力資源以及質(zhì)量目標(biāo)的要求。優(yōu)先級(jí)的分配應(yīng)當(dāng)由軟件開發(fā)人員和項(xiàng)目相關(guān)人員共同完成，最好是在做了一些初始的分析工作后，再進(jìn)行需求優(yōu)先級(jí)的分配，可根據(jù)具體情況把優(yōu)先級(jí)分成如下表所示的三類：4-4確定需求的優(yōu)先級(jí)4-5需求建模主要任務(wù)早期需求建模的方法導(dǎo)出目標(biāo)系統(tǒng)的邏輯模型(或需求模型)，以明確目標(biāo)系統(tǒng)“做什么”的問題，目標(biāo)系統(tǒng)指待開發(fā)的軟件系統(tǒng)。建立需求模型的目的是為了增強(qiáng)對(duì)用自然語言描述的需求規(guī)格說明的理解。需求建模就是把由文本表示的需求和由圖形或數(shù)學(xué)符號(hào)表示的需求結(jié)合起來，繪制出對(duì)目標(biāo)系統(tǒng)的完整性描述，以檢測軟件需求的一致性、完整性和錯(cuò)誤等。在需求建模中使用什么方法取決于建模的目的、時(shí)間和應(yīng)用領(lǐng)域(即對(duì)象)等。在眾多的需求分析方法中，早期(20世紀(jì)70年代中期)具有代表性的分析方法有：PSA/PSL：由美國密歇根大學(xué)在ISDOS項(xiàng)目中開發(fā)的需求定義語言PSL和分析工具PSA。SREM：由美國TRW公司開發(fā)，使用了需求描述語言RSL、表示處理流的R-Net,分析工具REVS，主要是面向?qū)崟r(shí)系統(tǒng)。SADT：由SoftTech公司開發(fā)，主要用方框表示動(dòng)作和處理，并在方框的上下左右用有向弧分別表示輸入、輸出、控制數(shù)據(jù)和使用的資源。4-5需求建模當(dāng)前需求建模的方法在上述方法的基礎(chǔ)上，人們又開發(fā)和推出了至今仍在使用的結(jié)構(gòu)化分析方法(StructuredAnalysis，SA)，SA方法簡單和易使用。但到了20世紀(jì)90年代初期，隨著面向?qū)ο蠓椒ǖ闹饾u完善，面向?qū)ο蟮男枨蠓治鲎鳛樾碌男枨蠓治龇椒ǔ蔀樾枨蠊こ讨械闹匾椒ㄖ??；诿嫦驅(qū)ο蟮姆治龊驮O(shè)計(jì)方法，人們近幾年來又提出了綜合多種圖形表示的UML語言以及一些與特殊方法相結(jié)合的需求分析方法。如面向問題域的分析方法、面向特征的需求分析方法、基于本體的需求分析方法和面向多視點(diǎn)的需求分析方法等。圖形表示的需求分析方法只能是一種半形式化的方法，在嚴(yán)格性方面尚有問題。因此，在現(xiàn)有的需求分析方法中還有一些比較嚴(yán)格的需求分析的描述方法，如VDM、Z符號(hào)、B方法和基于代數(shù)理論的方法等。4-5需求建模4-6建立數(shù)據(jù)詞典數(shù)據(jù)詞典的作用數(shù)據(jù)詞典：定義目標(biāo)系統(tǒng)中使用的所有數(shù)據(jù)元素和結(jié)構(gòu)的含義、類型、數(shù)量值、格式和度量單位、精度及允許取值范圍的共享數(shù)據(jù)倉庫。作用：確保軟件開發(fā)人員使用統(tǒng)一的數(shù)據(jù)定義，可提高需求分析、設(shè)計(jì)、實(shí)現(xiàn)和維護(hù)過程中的可跟蹤性，可把不同的需求文檔和需求模型緊密地結(jié)合到一起。數(shù)據(jù)詞典中的每個(gè)數(shù)據(jù)項(xiàng)對(duì)應(yīng)數(shù)據(jù)詞典中的一項(xiàng)記錄，并可根據(jù)實(shí)際情況使用簡單的符號(hào)予以定義。如數(shù)據(jù)項(xiàng)可表示成“數(shù)據(jù)項(xiàng)名=數(shù)據(jù)項(xiàng)定義”的形式，其中“數(shù)據(jù)項(xiàng)定義”又可表示為“數(shù)據(jù)類型＋數(shù)量值＋數(shù)量單位＋允許的取值范圍＋…”。4-6建立數(shù)據(jù)詞典第5章需求建模方法與技術(shù)

目錄什么是模型軟件工程中的模型結(jié)構(gòu)化的需求建模方法基于圖形的需求建模方法面向?qū)ο蟮男枨蠼７椒?-15-25-35-45-5需求建模軟件建模方法的特點(diǎn)主要是根據(jù)待開發(fā)軟件系統(tǒng)的需求利用某種建模方法建立該系統(tǒng)的邏輯模型（也稱需求模型或分析模型），以幫助軟件開發(fā)人員檢測軟件需求的一致性、完全性、二義性和錯(cuò)誤等。軟件建模方法都至少應(yīng)具備如下共同特點(diǎn)：提供描述手段：研制一個(gè)軟件系統(tǒng)涉及許多人，開發(fā)人員之間如何有效地進(jìn)行交流是項(xiàng)目成功的關(guān)鍵之一。提供基本步驟：研制一個(gè)軟件系統(tǒng)，特別是大型又復(fù)雜的系統(tǒng)，要考慮的問題很多，如果同時(shí)處理這些問題就會(huì)束手無策或者造成混亂。目前的需求建模方法中，主要使用的描述手段和技術(shù)是自然語言、圖形符號(hào)語言和形式語言等。需求建模方法與技術(shù)5-1什么是模型模型的定義模型的分類根據(jù)對(duì)模型的理解不同，模型的定義也是多種多樣的：由某些人根據(jù)其目的而對(duì)事物進(jìn)行的抽象描述。根據(jù)實(shí)物、設(shè)計(jì)圖或設(shè)想，按比例生態(tài)或其他特征制成的同實(shí)物相似的物體。當(dāng)一個(gè)數(shù)學(xué)結(jié)構(gòu)作為某個(gè)形式語言（即包括常符號(hào)、函數(shù)符號(hào)、謂詞符號(hào)的集合）的解釋時(shí)，稱為模型。為了理解事物而對(duì)事物作出的一種抽象，是對(duì)事物的一種無二義性的書面描述。模型通常不僅與客觀世界中某個(gè)特殊個(gè)體或現(xiàn)象相關(guān)，而且與許多甚至無限個(gè)個(gè)體相關(guān)。根據(jù)模型與客觀世界的關(guān)系,模型可大致分類如下：描述性模型：能真實(shí)和較完整地反映客觀世界(如照片)。規(guī)約性模型：能用于創(chuàng)造新事物的規(guī)約(如需求模型)。探測性模型：是過渡性的，經(jīng)常被修改而非最終決定的模型。軟件工程中的模型大部分是描述性模型，而需求模型既是描述性模型(描述問題域)，又是規(guī)約性模型(軟件的需求規(guī)格說明)。5-1什么是模型5-2軟件工程中的模型軟件工程中模型的概念軟件工程中模型的分類對(duì)客觀世界的問題領(lǐng)域進(jìn)行抽象并用某描述方法給予表示的結(jié)果稱為模型。特點(diǎn)：軟件工程中多數(shù)模型是用于表示問題領(lǐng)域中的元素以及元素間的關(guān)系或相互作用等。5-2軟件工程中的模型在軟件工程中，可根據(jù)具體的建模要求和抽象的內(nèi)容把模型分類如下：開發(fā)過程模型(規(guī)約性)：瀑布式模型、增量模型、螺旋式模型等。信息流模型(描述性)：DFD、SADT等。設(shè)計(jì)模型:類圖、功能層次圖等。交互作用模型：實(shí)例圖、交互作用圖、時(shí)序圖等。狀態(tài)遷移模型：狀態(tài)圖、Petri網(wǎng)等。用于構(gòu)造細(xì)節(jié)的原理模型：設(shè)計(jì)模式、實(shí)體關(guān)聯(lián)圖等。過程成熟度模型：CMM，SPICE(模型集合)。其他模型：可靠性模型、成本估算模型等。5-3結(jié)構(gòu)化的需求建模方法結(jié)構(gòu)化分析（SA）方法SA方法的基本特點(diǎn)是由美國Yourdon公司和密歇根大學(xué)在開發(fā)ISDOS工具系統(tǒng)時(shí)提出的，自20世紀(jì)70年代中期以來，一直是比較流行和普及的傳統(tǒng)需求分析技術(shù)之一。主要適用于數(shù)據(jù)處理，特別是大型管理信息系統(tǒng)的需求分析，主要用于分析系統(tǒng)的功能，是一種直接根據(jù)數(shù)據(jù)流劃分功能層次的分析方法。表達(dá)問題時(shí)盡可能使用圖形符號(hào)的方式，即使非計(jì)算機(jī)專業(yè)人員也易于理解。設(shè)計(jì)數(shù)據(jù)流圖時(shí)只考慮系統(tǒng)必須完成的基本功能，不需要考慮如何具體地實(shí)現(xiàn)這些功能。5-3結(jié)構(gòu)化的需求建模方法SA方法的完善自20世紀(jì)90年代初起，人們對(duì)SA方法進(jìn)行了擴(kuò)充。通過將方法用于分析實(shí)時(shí)控制系統(tǒng)的需求，在數(shù)據(jù)流圖中加入了控制成分。除了數(shù)據(jù)需求建模方法與技術(shù)流圖外，還有控制流圖(ControlFlowDiagram，CFD)，使得SA方法既能表示數(shù)據(jù)轉(zhuǎn)換，又能表示控制狀態(tài)的變化。5-3-1SA方法的基本思想按照由抽象到具體、逐層分解的方法，確定軟件系統(tǒng)內(nèi)部的數(shù)據(jù)流、變換（或加工）的關(guān)系，并用數(shù)據(jù)流圖給予表示。5-3結(jié)構(gòu)化的需求建模方法復(fù)雜系統(tǒng)的分解對(duì)于復(fù)雜的軟件系統(tǒng)，可將該系統(tǒng)分解成若干子系統(tǒng)直到子系統(tǒng)足夠簡單和易于理解為止，如下圖所示：5-3-2SA方法的描述手段SA方法的描述手段由三個(gè)部分組成：一套分層的數(shù)據(jù)流圖：主要說明系統(tǒng)由哪些部分組成，以及各部分之間的聯(lián)系。一本詞典：為數(shù)據(jù)流圖中出現(xiàn)的每個(gè)元素提供詳細(xì)的說明。其他補(bǔ)充材料：具體的補(bǔ)充和修改文檔的說明。5-3結(jié)構(gòu)化的需求建模方法1.數(shù)據(jù)流圖（DFD：DataFlowDiagram）描述系統(tǒng)內(nèi)部處理流程、用于表達(dá)軟件系統(tǒng)需求模型的一種圖形工具，亦即是描述系統(tǒng)中數(shù)據(jù)流程的圖形工具。右圖表示了一個(gè)DFD的簡單模型。數(shù)據(jù)流x從源點(diǎn)S流出，被加工P1，變換為數(shù)據(jù)流y，P1，執(zhí)行時(shí)要訪問文件F。然后數(shù)據(jù)流y被加工P2,變換為數(shù)據(jù)流z，并流向終點(diǎn)。5-3結(jié)構(gòu)化的需求建模方法1.數(shù)據(jù)流圖（DFD：DataFlowDiagram）(1）數(shù)據(jù)流數(shù)據(jù)流是由一組數(shù)據(jù)項(xiàng)組成的數(shù)據(jù)，通常用帶用帶標(biāo)識(shí)的有向孤給予表示。數(shù)據(jù)流可以從加工流向加工，或從源點(diǎn)流向加工，或從加工流向終點(diǎn)，或從加工流向文件，或從文件流向從加工。在數(shù)據(jù)流的命名中，不能使用缺乏具體含義的,詞如“數(shù)據(jù)”、“信息”等當(dāng)作為數(shù)據(jù)流名。不能把控制流作為數(shù)據(jù)流。例如，下圖描述了某個(gè)統(tǒng)計(jì)考生成績的軟件系統(tǒng)的DFD，其中“取考生成績”不是數(shù)據(jù)流而是控制流，故應(yīng)把“取考生成績”改為“考生成績”。5-3結(jié)構(gòu)化的需求建模方法1.數(shù)據(jù)流圖（DFD：DataFlowDiagram）(2）加工（變換）對(duì)數(shù)據(jù)進(jìn)行的操作或變換就稱為加工。各加工與數(shù)據(jù)流需求建模方法與技術(shù)或文件相連接。加工名應(yīng)反映該加工的含義，可如下命名加工名:最高層的加工可以是軟件系統(tǒng)的名字，如某管理信息等。加工的名字最好由一個(gè)謂語動(dòng)詞加上一個(gè)賓語組成，如“檢查合法性”、“分類成績”等。不能使用空洞或含糊的動(dòng)詞作為加工名，如“計(jì)算”、“分類”等。當(dāng)遇到未合適命名的加工時(shí)，可以考慮將加工分解，如“檢查并分類考生成績”等。(3）文件文件是存放數(shù)據(jù)的邏輯單位，且通常用圖形符號(hào)“”，“”和“”分別表示加工要寫文件，讀文件和讀寫文件。另外，在這個(gè)圖形符號(hào)中還要給出文件名。5-3結(jié)構(gòu)化的需求建模方法1.數(shù)據(jù)流圖（DFD：DataFlowDiagram）(4）源點(diǎn)和終點(diǎn)

用于表示數(shù)據(jù)的來源和最終去向，且通常用圖形方框給予表示。主要代表軟件系統(tǒng)外的實(shí)體，如人或其他軟件系統(tǒng)等，以說明數(shù)據(jù)的來龍去脈，使DFD更加清晰。例如：如右圖所示的4.1節(jié)中培訓(xùn)中心管理信息系統(tǒng)的關(guān)聯(lián)圖分解。5-3結(jié)構(gòu)化的需求建模方法2.分層的DFD對(duì)于大型而又復(fù)雜的軟件系統(tǒng)，如果用一張DFD說出所有的數(shù)據(jù)流和加工，整個(gè)圖就會(huì)變得相當(dāng)復(fù)雜和難以理解，為了控制復(fù)雜性，通常可采用分層的方法。分層的方法有目的地逐步增加細(xì)節(jié)，一套分層的數(shù)據(jù)流圖由頂層、底層和中間層組成：頂層(0層圖)：用于注明系統(tǒng)的邊界，即系統(tǒng)的輸人/輸出。中間層：描述加工的分解，其組成部分可進(jìn)一步分解。底層：由一些不能再分解的加工組成，這些加工足夠簡單，亦稱為基本加工。畫出完整的分層DFD尚需注意如下幾個(gè)問題：(1）應(yīng)區(qū)別于流程圖DFD注重于數(shù)據(jù)在系統(tǒng)中的流動(dòng)，在加工間的多股數(shù)據(jù)流之間不需考慮前后次序問題，加工只描述“做什么”，不考慮“怎么做”和執(zhí)行順序的問題。流程圖則需考慮對(duì)數(shù)據(jù)處理的次序和具體細(xì)節(jié)。5-3結(jié)構(gòu)化的需求建模方法2.分層的DFD(2）DFD的完整性問題在畫DFD時(shí)，可能會(huì)出現(xiàn)加工產(chǎn)生的輸出流并沒有輸出到其他任何加工或外部實(shí)體(如圖5-5a所示)，或者某些加工有輸入但不產(chǎn)生輸出(如圖5-5b所示)等情況。對(duì)于前者可能是遺漏加工或數(shù)據(jù)流多余，對(duì)于后者可能加工是多余的，或者遺漏了輸出流等。5-3結(jié)構(gòu)化的需求建模方法2.分層的DFD(3）DFD的一致性問題亦稱父圖與子圖的平衡問題，是指父圖中某加工的輸入/輸出與分解該加工的子圖的輸入/輸出必須完全一致，即輸入/輸出應(yīng)該相同。圖5-6a表示父圖與子圖平衡的情況，而圖5-6b表示父圖與子圖不平衡的情況。層次的分解通常是對(duì)加工進(jìn)行分解，但在有必要的情況下也可對(duì)數(shù)據(jù)流進(jìn)行分解。5-3結(jié)構(gòu)化的需求建模方法2.分層的DFD(4）在分層DFD中文件的表示通常，文件可以隸屬于分層DFD中的某一層或某幾層，即在抽象層中未用到的文件可以不表示出來，在子圖中用到的文件則表示在該子圖中。在抽象層中表示出的文件，則應(yīng)該在相應(yīng)的某(些)子圖中表示，當(dāng)文件共享于某些加工之間時(shí)，則該文件必須表示出來。5-3結(jié)構(gòu)化的需求建模方法2.分層的DFD(5）分解層次的深度逐層分解的目的是把復(fù)雜的加工分解成比較簡單和易于理解的基本加工。分解的層次應(yīng)根據(jù)軟件系統(tǒng)的復(fù)雜程度、人的能力等因素來決定，但通過大量的實(shí)踐得到了一些經(jīng)驗(yàn)性的準(zhǔn)則，例如：分解最好不超過7或8層，盡量減少分解層次。分解應(yīng)根據(jù)問題的邏輯特性進(jìn)行，不能硬性分解。每個(gè)加工分解為子加工后，子圖中的子加工數(shù)不要太多，通常為7~10個(gè)。上層可分解快些，下層應(yīng)該慢些，因?yàn)樯蠈颖容^抽象，易于理解。分解要均勻，即避免在一張DFD中，有些已是基本加工，另外一些還要分解為多層。分解的程度應(yīng)滿足兩個(gè)條件：一個(gè)是加工用幾句或十幾句話就可清楚地描述其含義，另一個(gè)是一個(gè)加工基本上只有一個(gè)輸入流和一個(gè)輸出流。5-3結(jié)構(gòu)化的需求建模方法3.畫分層的DFD的步驟(1）確定軟件系統(tǒng)的輸入/輸出數(shù)據(jù)流、源點(diǎn)和終點(diǎn)。這一步實(shí)際上決定系統(tǒng)的范圍。先確定源點(diǎn)和終點(diǎn)，以及輸入/輸出數(shù)據(jù)流，然后再考慮系統(tǒng)的處理或加工可以使系統(tǒng)的范圍稍大些，或參照有關(guān)的關(guān)聯(lián)圖，使得與軟件系統(tǒng)相關(guān)的內(nèi)容盡可能被包含進(jìn)來。(2）將基本系統(tǒng)模型加上源點(diǎn)和終點(diǎn)，構(gòu)成頂層DFD。基本系統(tǒng)模型是指把整個(gè)軟件系統(tǒng)視為一個(gè)數(shù)據(jù)變換，如圖5-7所示，該模型接受各種輸入，通過內(nèi)部變換產(chǎn)生各種輸出。頂層DFD也就是在前面所提到的系統(tǒng)關(guān)聯(lián)圖。5-3結(jié)構(gòu)化的需求建模方法3.畫分層的DFD的步驟(3）畫出各層的DFD根據(jù)DFD的分解情況逐層畫出DFD，畫每張DFD時(shí)可以遵循以下準(zhǔn)則：將所有軟件的輸入/輸出數(shù)據(jù)流用一連串加工連接起來。應(yīng)集中精力找出數(shù)據(jù)流。在找到數(shù)據(jù)流后，標(biāo)識(shí)該數(shù)據(jù)流，然后分析該數(shù)據(jù)流的組成成分及來去方向，并將其與加工連接。在加工被標(biāo)識(shí)后，再繼續(xù)尋找其他的數(shù)據(jù)流。當(dāng)加工需要用到共享和暫存數(shù)據(jù)時(shí)，設(shè)置文件及其標(biāo)識(shí)。分析加工的內(nèi)部，如果加工還比較抽象或其內(nèi)部還有數(shù)據(jù)流，則需將該加工進(jìn)一步分解，直至到達(dá)底層圖。為所有的數(shù)據(jù)流命名，命名的要求前面已介紹過。為所有加工命名編號(hào)。編號(hào)的方法如下：對(duì)于子圖的圖號(hào)，通常是父圖中相應(yīng)被分解加工的編號(hào)，加工編號(hào)=圖號(hào)＋小數(shù)點(diǎn)＋局部順序號(hào)。由于頂層DFD(0層圖)只有一張，只有一個(gè)加工，該加工不用編號(hào)，加工編號(hào)應(yīng)從第一層開始。5-3結(jié)構(gòu)化的需求建模方法3.畫分層的DFD的步驟(3）畫出各層的DFD畫DFD時(shí)還應(yīng)注意如下情況:畫圖時(shí)只考慮如何描述實(shí)際情況，不要急于考慮系統(tǒng)應(yīng)如何啟動(dòng)、如何工作、如何結(jié)束等與時(shí)間序列相關(guān)的問題。畫圖時(shí)可暫不考慮一些例外情況，如出錯(cuò)處理等。畫圖的過程是一個(gè)重復(fù)的過程，一次性成功的可能性較小，需要不斷地修改和完善。為便于理解，我們通過一個(gè)實(shí)例來說明畫DFD的方法。5-3結(jié)構(gòu)化的需求建模方法例：分布式患者監(jiān)護(hù)系統(tǒng)某醫(yī)院擬開發(fā)一個(gè)分布式患者監(jiān)護(hù)系統(tǒng)（PMS:PatientsMonitoringSystem）。PMS將用于監(jiān)視病房中每個(gè)患者的重要生理信號(hào)（如體溫、血壓、脈博信號(hào)等），并能定時(shí)更新和營理患者的病歷。此外，當(dāng)患者的生理信號(hào)超過醫(yī)生規(guī)定的安全范圍時(shí)，系統(tǒng)能立即通知護(hù)理人員，并且護(hù)理人員在需要時(shí)可隨時(shí)通過系統(tǒng)產(chǎn)生某患者有關(guān)報(bào)告。PMS的主要功能為：通過一個(gè)病床監(jiān)視器實(shí)現(xiàn)本地監(jiān)測，以獲得患者的生理信號(hào)。在護(hù)士辦公室實(shí)現(xiàn)中央監(jiān)測更新和管理患者病歷產(chǎn)生患者情況的報(bào)告以及報(bào)警信息5-3結(jié)構(gòu)化的需求建模方法例：分布式患者監(jiān)護(hù)系統(tǒng)根據(jù)前述畫DFD的方法，可得到PMS的DFD，如圖5-8所示。圖5-8a是根據(jù)步驟(1)和步驟2()得到的頂層圖。圖5-8b和圖5-8c根據(jù)步驟(3)畫出。圖5-8c是圖5-8b中的“中央監(jiān)測”加工分解后得到的子圖。5-3結(jié)構(gòu)化的需求建模方法4.數(shù)據(jù)詞典用于描述數(shù)據(jù)的具體含義和加工的說明，由數(shù)據(jù)詞典和DFD就可構(gòu)成軟件系統(tǒng)的邏輯模型(或需求模型)。由DFD中所有元素的“嚴(yán)格定義”組成，其作用就是為DFD中出現(xiàn)的每個(gè)元素提供詳細(xì)的說明，即DFD中出現(xiàn)的每個(gè)數(shù)據(jù)流名、文件名和加工名都在數(shù)據(jù)詞典中有一個(gè)條目以定義相應(yīng)的含義。當(dāng)需要查看DFD中某個(gè)元素的含義時(shí)，可借助于數(shù)據(jù)詞典。數(shù)據(jù)詞典中的條目類型如下：(1）數(shù)據(jù)流條目：用于定義數(shù)據(jù)流在數(shù)據(jù)流條目中主要說明由哪些數(shù)據(jù)項(xiàng)組成數(shù)據(jù)流，且數(shù)據(jù)流的定義也采用簡單的形式符號(hào)方式。

如：訂票單＝顧客信息+訂票日期+出發(fā)日期+航班號(hào)+目的地+……對(duì)于復(fù)雜的數(shù)據(jù)流，可采用向頂向下逐步細(xì)化的方式定義數(shù)據(jù)項(xiàng)。

如：顧客信息＝姓名+性別+身份證號(hào)+聯(lián)系電話當(dāng)數(shù)據(jù)項(xiàng)由多個(gè)更小的數(shù)據(jù)元素組成時(shí)，可利用集合符號(hào)“{}”給予說明。如：選修課程＝課程表+教師+教材課程表＝{課程名+星期幾+上課時(shí)間+教室}當(dāng)某些數(shù)據(jù)項(xiàng)是幾個(gè)不同的數(shù)據(jù)流的公用數(shù)據(jù)項(xiàng)時(shí)，可將它們列為專門的數(shù)據(jù)項(xiàng)條目。如：教室＝101|102|……航班號(hào)＝Mu712|Mu814|……5-3結(jié)構(gòu)化的需求建模方法4.數(shù)據(jù)詞典(1）數(shù)據(jù)流條目：用于定義數(shù)據(jù)流當(dāng)所有出現(xiàn)在DFD中的數(shù)據(jù)流都給予定義后，最后的工作就是對(duì)出現(xiàn)在數(shù)據(jù)流中的數(shù)據(jù)項(xiàng)進(jìn)行匯總，然后以表格的形式匯錄每一數(shù)據(jù)項(xiàng)。(2）文件條目文件條目除說明組成文件的所有數(shù)據(jù)項(xiàng)（與數(shù)據(jù)流的說明相同）外，還可說明文件的組成方式。如：

航班表文件＝{航班號(hào)+出發(fā)地+目的地+時(shí)間}

組成方式＝按航班號(hào)大小排列5-3結(jié)構(gòu)化的需求建模方法4.數(shù)據(jù)詞典(3）加工條目：用于說明加工加工條目主要描述加工的處理邏輯或“做什么”。加工條目并不描述具體的處理過程，但可以按處理的順序描述加工應(yīng)完成的一些功能，而且描述加工的手段通常使用自然語言，或者結(jié)構(gòu)化的人工語言，或者使用判定表或判定樹的形式。如：4.1節(jié)中某培訓(xùn)中心管理信息系統(tǒng)中的“處理報(bào)名”加工描述如下：根據(jù)報(bào)名要求查詢收費(fèi)標(biāo)準(zhǔn)文件，確定相應(yīng)費(fèi)用。學(xué)生注冊根據(jù)選修課程登錄課程統(tǒng)計(jì)文件產(chǎn)生注冊單等最后，由所有的數(shù)據(jù)條目、文件條目和加工條目就構(gòu)成一本數(shù)據(jù)詞典。5.其他補(bǔ)充材料這一部分的工作主要是定義各種輸入/輸出表格的形式，記錄與修改文檔相關(guān)的信息。如：記錄什么人什么時(shí)間修改什么內(nèi)容等。5-3結(jié)構(gòu)化的需求建模方法5.其他補(bǔ)充材料(3）加工條目：用于說明加工加工條目主要描述加工的處理邏輯或“做什么”。加工條目并不描述具體的處理過程，但可以按處理的順序描述加工應(yīng)完成的一些功能，而且描述加工的手段通常使用自然語言，或者結(jié)構(gòu)化的人工語言，或者使用判定表或判定樹的形式。如：4.1節(jié)中某培訓(xùn)中心管理信息系統(tǒng)中的“處理報(bào)名”加工描述如下：根據(jù)報(bào)名要求查詢收費(fèi)標(biāo)準(zhǔn)文件，確定相應(yīng)費(fèi)用。學(xué)生注冊根據(jù)選修課程登錄課程統(tǒng)計(jì)文件產(chǎn)生注冊單等最后，由所有的數(shù)據(jù)條目、文件條目和加工條目就構(gòu)成一本數(shù)據(jù)詞典。5-3-3示例說明（運(yùn)動(dòng)會(huì)管理系統(tǒng)）某學(xué)校擬開發(fā)一個(gè)運(yùn)動(dòng)會(huì)管理系統(tǒng)。有關(guān)運(yùn)動(dòng)會(huì)的業(yè)務(wù)流程如下：確定運(yùn)動(dòng)會(huì)的舉辦時(shí)間和地點(diǎn)，設(shè)置哪些項(xiàng)目，報(bào)名時(shí)間等確定一些限制規(guī)定，如每人最多可參加幾個(gè)項(xiàng)目，每個(gè)項(xiàng)目每隊(duì)最多可由多少人參加，取前幾名，打破單項(xiàng)比賽記錄后的處理等。由各參加隊(duì)提供報(bào)名單后，需給每個(gè)運(yùn)動(dòng)員編號(hào)，并統(tǒng)計(jì)每個(gè)項(xiàng)目的參加人數(shù)及名單，最后根據(jù)每個(gè)項(xiàng)目的參加人數(shù)等具體情況排出比賽日程。在運(yùn)動(dòng)會(huì)期間不斷接受各項(xiàng)目的比賽成績，及時(shí)公布單項(xiàng)名次，累計(jì)團(tuán)體總分。比賽結(jié)束后，公布最終的團(tuán)體名次。根據(jù)上述的業(yè)務(wù)流程，用SA方法來建立該運(yùn)動(dòng)會(huì)管理系統(tǒng)的需求模型。由于運(yùn)動(dòng)會(huì)有大量的數(shù)據(jù)需及時(shí)處理，打算用計(jì)算機(jī)來完成原來用手工進(jìn)行的工作，則需要分析運(yùn)動(dòng)會(huì)的業(yè)務(wù)流程，并獲得相應(yīng)的功能需求，明確計(jì)算機(jī)的系統(tǒng)需完成什么功能。為避免過于復(fù)雜，在此例中省去了SA方法中某些具體步驟，直接建立該系統(tǒng)最終的需求模型。5-3結(jié)構(gòu)化的需求建模方法5-3-3示例說明（運(yùn)動(dòng)會(huì)管理系統(tǒng)）按畫DFD的步驟建立運(yùn)動(dòng)會(huì)管理系統(tǒng)的需求模型：(1)建立系統(tǒng)的DFD圖5a表示第0層，主要描述系統(tǒng)的外部接口，即運(yùn)動(dòng)會(huì)的工作人員收到各隊(duì)送來的報(bào)名單后，錄入到計(jì)算機(jī)中。然后通過系統(tǒng)將運(yùn)動(dòng)員號(hào)碼單、各項(xiàng)成績等輸出給相關(guān)人員。系統(tǒng)將報(bào)名單提供給裁判長，由裁判長將確定的比賽項(xiàng)目、比賽成績等存入計(jì)算機(jī)5-3結(jié)構(gòu)化的需求建模方法5-3-3示例說明（運(yùn)動(dòng)會(huì)管理系統(tǒng)）(1)建立系統(tǒng)的DFD圖b是將系統(tǒng)實(shí)際分為兩個(gè)子系統(tǒng)(或加工):登記報(bào)名單和統(tǒng)計(jì)成績，以描述運(yùn)動(dòng)會(huì)前的準(zhǔn)備工作和運(yùn)動(dòng)會(huì)開始后系統(tǒng)應(yīng)完成的功能。5-3結(jié)構(gòu)化的需求建模方法5-3-3示例說明（運(yùn)動(dòng)會(huì)管理系統(tǒng)）(1)建立系統(tǒng)的DFD圖c是將“登記報(bào)名單”和“統(tǒng)計(jì)成績”這兩個(gè)加工進(jìn)行分解。5-3結(jié)構(gòu)化的需求建模方法5-3-3示例說明（運(yùn)動(dòng)會(huì)管理系統(tǒng)）(2)數(shù)據(jù)詞典說明前述的分層DFD只是描述系統(tǒng)的“分解”，即系統(tǒng)由哪些部分組成，以及各部分間的關(guān)系，并沒有說明這個(gè)系統(tǒng)中各加工和數(shù)據(jù)流的具體含義，如報(bào)名單、單項(xiàng)名次等。這些內(nèi)容應(yīng)在數(shù)據(jù)詞典中說明。下面給出部分?jǐn)?shù)據(jù)詞典的內(nèi)容，僅供參考。5-3結(jié)構(gòu)化的需求建模方法5-3-3示例說明（運(yùn)動(dòng)會(huì)管理系統(tǒng)）(2)數(shù)據(jù)詞典說明5-3結(jié)構(gòu)化的需求建模方法5-3-3示例說明（運(yùn)動(dòng)會(huì)管理系統(tǒng)）(2)數(shù)據(jù)詞典說明5-3結(jié)構(gòu)化的需求建模方法5-3-4SA方法的分析步驟軟件系統(tǒng)主要是用計(jì)算機(jī)系統(tǒng)取代已存在的人工數(shù)據(jù)處理系統(tǒng)，提高工作效率和自動(dòng)化程度。為簡單起見，將現(xiàn)實(shí)中已存在的人工系統(tǒng)稱為當(dāng)前系統(tǒng)，把待開發(fā)的計(jì)算機(jī)系統(tǒng)(主要是指軟件系統(tǒng))稱為目標(biāo)系統(tǒng)。兩種系統(tǒng)在實(shí)現(xiàn)細(xì)節(jié)方面存在一定的差別，SA方法的分析步驟如下：(1)理解和分析當(dāng)前的現(xiàn)實(shí)環(huán)境，以獲得當(dāng)前系統(tǒng)的具體模型具體模型必須忠實(shí)地反映人工系統(tǒng)的實(shí)際情況，軟件開發(fā)人員在獲取的需求信息的基礎(chǔ)上，利用DFD將現(xiàn)實(shí)環(huán)境中的人工系統(tǒng)表達(dá)出來。圖5-10表示一個(gè)簡單的具體模型實(shí)例，其中會(huì)計(jì)科、統(tǒng)計(jì)科、發(fā)票的紅色聯(lián)或白色聯(lián)出現(xiàn)在具體模型中。5-3結(jié)構(gòu)化的需求建模方法5-3-4SA方法的分析步驟(2)建立當(dāng)前系統(tǒng)的邏輯模型這一步從系統(tǒng)的具體模型中抽象出當(dāng)前系統(tǒng)的邏輯模型。當(dāng)前系統(tǒng)的邏輯模型應(yīng)反映當(dāng)前系統(tǒng)必須滿足的性質(zhì)，即當(dāng)前系統(tǒng)“做什么”。作用：在于除去具體模型中非本質(zhì)因素或一些“具體”因素。如圖5-10中的會(huì)計(jì)科可改為“開發(fā)票”，紅色聯(lián)和白色聯(lián)發(fā)票可分別改為發(fā)票的存根聯(lián)和付款聯(lián)等，從而獲得反映當(dāng)前系統(tǒng)的邏輯模型。圖5-11是對(duì)圖5-10修改后得到的當(dāng)前系統(tǒng)的邏輯模型。5-3結(jié)構(gòu)化的需求建模方法5-3-4SA方法的分析步驟(3)建立目標(biāo)系統(tǒng)的邏輯模型這一步主要是分析目標(biāo)系統(tǒng)與當(dāng)前系統(tǒng)在邏輯模型的差別，并建立目標(biāo)系統(tǒng)的邏輯模型，是SA方法的關(guān)鍵步驟。具體步驟如下：確定當(dāng)前系統(tǒng)邏輯模型的“改變范圍”，即決定目標(biāo)系統(tǒng)與當(dāng)前系統(tǒng)之間不可實(shí)現(xiàn)的部分。沿著當(dāng)前系統(tǒng)邏輯模型的底層DFD，逐個(gè)檢查每個(gè)基本加工。“改變范圍”視為一個(gè)加工，并確定此加工的輸入/輸出數(shù)據(jù)流，當(dāng)該加工比較抽象時(shí)，可將其進(jìn)行逐層分解，然后畫出各層的DFD。另一種方法：首先建立目標(biāo)系統(tǒng)的頂層DFD(O層)和第一層DFD(由若干子系統(tǒng)組成)，然后再參照當(dāng)前系統(tǒng)的邏輯模型，去掉其中所有“具體”因素和細(xì)化各子系統(tǒng)，最后可得到目標(biāo)系統(tǒng)的邏輯模型。5-3結(jié)構(gòu)化的需求建模方法5-3-4SA方法的分析步驟(4)進(jìn)一步完善目標(biāo)系統(tǒng)的邏輯模型完善的工作大致為：至今尚未說明的處理細(xì)節(jié)，如出錯(cuò)處理、系統(tǒng)的啟動(dòng)和結(jié)束方式。某些需要的輸入/輸出格式或用戶界面的說明。增加性能需求和其他一些約束限制等。由前三步可獲得用DFD和數(shù)據(jù)詞典表示的目標(biāo)系統(tǒng)的邏輯模型。5-3結(jié)構(gòu)化的需求建模方法5-4面向?qū)ο蟮男枨蠼７椒ㄐ枨蠼７椒嫦驅(qū)ο蟮男枨蠼７椒ǖ侥壳盀樯弦延性S多不同的版本，其中具有代表性的是OOD、OMT、OOSE、OOAP和UML等。本節(jié)將主要介紹基于OMT的需求建模方法。5-4面向?qū)ο蟮男枨蠼７椒?-4-1面向?qū)ο蠓椒ㄖ械囊恍┗靖拍?1)對(duì)象客觀世界中存在大量實(shí)體。實(shí)體可以是物理的，也可以是概念的，所謂對(duì)象就是以上的客觀實(shí)體的抽象，并且是構(gòu)成概念模型的基本單元。根據(jù)現(xiàn)實(shí)中客觀實(shí)體性質(zhì)的劃分，對(duì)象可以是如下的幾種類型:人類能感知的物理實(shí)體，如房子、汽車、飛機(jī)、山川等。人或者組織，如教師、學(xué)生、醫(yī)生、大學(xué)、科研處等?，F(xiàn)實(shí)中發(fā)生的事件，如讀書、上課、演出、訪間、交通事故等。兩個(gè)以上實(shí)體的相互作用，通常具有交易或接觸的性質(zhì)，如購買、納稅等。需要說明的概念，如政策、法律、規(guī)章制度等。5-4面向?qū)ο蟮男枨蠼７椒?-4-1面向?qū)ο蠓椒ㄖ械囊恍┗靖拍?1)對(duì)象此上述定義外，還有一些其他的定