需求分析與解決方案設(shè)計(jì)1

1、主講：吳明元2 0 0 8 . 0 92第1章 軟件需求基礎(chǔ)知識(shí)為什么要需求分析為什么要需求分析 需求分析具有決策性、方向性、策略性的作用，他在軟件開發(fā)的過(guò)程中具有舉足輕重的地位。因此，對(duì)需求分析應(yīng)足夠的重視，在一個(gè)大型軟件系統(tǒng)的開發(fā)中，他的作用要遠(yuǎn)遠(yuǎn)大于程序設(shè)計(jì)。 3項(xiàng)目涉眾客戶: 為達(dá)到其公司的業(yè)務(wù)目標(biāo)而投資項(xiàng)目或購(gòu)買產(chǎn)品。用戶：直接或間接與產(chǎn)品打交道，是客戶的一部分。需求分析員：負(fù)責(zé)編寫需求并傳達(dá)給開發(fā)團(tuán)隊(duì)。開發(fā)人員：設(shè)計(jì)、實(shí)現(xiàn)和維護(hù)產(chǎn)品。測(cè)試人員：確定產(chǎn)品的行為是否與預(yù)計(jì)的相一致。文檔編制人員：負(fù)責(zé)編寫用戶手冊(cè)、培訓(xùn)資料和系統(tǒng)幫助。項(xiàng)目經(jīng)理：制定項(xiàng)目計(jì)劃并帶領(lǐng)開發(fā)人員獲得成功。法律人員

2、：確保產(chǎn)品符合所有相關(guān)法規(guī)。生產(chǎn)人員：制造包含該軟件的產(chǎn)品。市場(chǎng)營(yíng)銷: 技術(shù)支持及其他與產(chǎn)品和客戶打交道的人員。本章將幫助您：理解軟件需求工程的一些重要術(shù)語(yǔ)。區(qū)分需求開發(fā)與需求管理。保持對(duì)潛在的與需求相關(guān)的問(wèn)題的警覺(jué)性。了解完善的需求應(yīng)該具備的特征。軟件或系統(tǒng)項(xiàng)目涉眾(stake holder，產(chǎn)品或項(xiàng)目相關(guān)人員)的利益之間的相互作用在需求過(guò)程中表現(xiàn)得最為強(qiáng)烈。項(xiàng)目涉眾包括：41.1 軟件需求的定義4軟件行業(yè)存在這樣一個(gè)問(wèn)題，用于描述需求工作的術(shù)語(yǔ)沒(méi)有統(tǒng)一的定義。4對(duì)同一項(xiàng)需求，不同的人會(huì)有不同的描述，稱其為用戶需求、軟件需求、功能需求、系統(tǒng)需求、技術(shù)需求、業(yè)務(wù)需求或產(chǎn)品需求。4客戶對(duì)需求的定

3、義，在開發(fā)人員看來(lái)可能只是高級(jí)別的產(chǎn)品概念；而開發(fā)人員的需求概念對(duì)用戶來(lái)說(shuō)也許就是詳細(xì)的用戶界面設(shè)計(jì)。4需求必須被記錄成文檔，這一點(diǎn)很重要。51.1.1 對(duì)需求的不同解釋4IEEE的軟件工程標(biāo)準(zhǔn)術(shù)語(yǔ)表將需求定義為: 用戶為解決某個(gè)問(wèn)題或達(dá)到某個(gè)目標(biāo)而需具備的條件或能力。系統(tǒng)或系統(tǒng)組件為符合合同、標(biāo)準(zhǔn)、規(guī)范或其他正式文檔而必須滿足的條件或必須具備的能力。上述第一項(xiàng)或第二項(xiàng)中定義的條件和能力的文檔表達(dá)。 注意 : 不要一廂情愿地認(rèn)為項(xiàng)目涉眾對(duì)需求的理解是一致的。應(yīng)該事先給出定義，才能保證大家談?wù)摰氖峭粋€(gè)問(wèn)題。 6需求分析定義4需求分析是指理解用戶需求，就軟件功能與客戶達(dá)成一致，為問(wèn)題涉及的信息、

4、功能及系統(tǒng)行為建立模型，將用戶需求精確化、完全化、最終形成需求規(guī)格說(shuō)明的一個(gè)復(fù)雜過(guò)程。 從廣義上理解：需求分析包括需求的獲取、分析、規(guī)格說(shuō)明、變更、驗(yàn)證、管理的一系列需求工程。狹義上理解：需求分析指需求的分析、定義過(guò)程。7 1.1.2 需求的層次4 軟件需求包括3個(gè)不同的層次業(yè)務(wù)需求、用戶需求和功能需求:4 除此之外，每個(gè)系統(tǒng)還有各種非功能需求。圖1.1中的模型給出了各種需求關(guān)系的示意圖。 業(yè)務(wù)需求(Business requirement)表示組織或客戶高層次的目標(biāo)。 用戶需求(user requirement)描述的是用戶的目標(biāo)，或用戶要求系統(tǒng)必須能完成的任務(wù)。 功能需求(funetion

5、al requirement)規(guī)定開發(fā)人員必須在產(chǎn)品中實(shí)現(xiàn)的軟件功能，用戶利用這些功能來(lái)完成任務(wù)，滿足業(yè)務(wù)需求。 功 能 性 需 求 非 功 能 性 需 求 業(yè) 務(wù) 需 求 遠(yuǎn) 景 和 范 圍 文 檔 用 戶 需 求 用 例 文 檔 軟 件 需 求 規(guī) 范 系 統(tǒng) 需 求 功 能 需 求 約 束 外 部 界 面 質(zhì) 量 屬 性 業(yè) 務(wù) 需 求 圖1.18 1.1.3 不屬于需求的內(nèi)容4需求規(guī)格說(shuō)明中不包括(除已知約束外的)設(shè)計(jì)和實(shí)現(xiàn)的細(xì)節(jié)、項(xiàng)目的計(jì)劃信息，以及測(cè)試信息。4項(xiàng)目中通常還包括其他類型的需求，如開發(fā)環(huán)境需求，進(jìn)度或預(yù)算限制，幫助新用戶跟上進(jìn)度的培訓(xùn)需求，或者發(fā)布產(chǎn)品使其轉(zhuǎn)入支持環(huán)境的

6、需求。這些都屬于項(xiàng)目需求而不是產(chǎn)品需求 。 9 1.2 需求的開發(fā)與管理 4 需求領(lǐng)域的術(shù)語(yǔ)問(wèn)題，有的作者稱其為需求工程；也有人稱之為需求管理。把軟件需求工程劃分為需求開發(fā)和需求管理，如圖1.2所示。 需求工程 需求開發(fā) 需求管理 獲取 分析 編寫規(guī)約 確認(rèn) 圖1.2軟件需求工程的組成10 1.2.1 需求開發(fā) 4 需求開發(fā)可進(jìn)一步細(xì)分為獲取(Elicitation)、分析(analysis)、規(guī)格說(shuō)明(specification)和確認(rèn)(Validation)。 4 這些子學(xué)科涵蓋了為軟件和軟件相關(guān)產(chǎn)品收集、評(píng)估和記錄需求相關(guān)的所有活動(dòng)，包括： 確定產(chǎn)品將要面對(duì)的各類用戶。 從各類用戶的代表

7、處收集需求。 了解用戶的任務(wù)和目標(biāo)，以及這些任務(wù)要實(shí)現(xiàn)的業(yè)務(wù)目標(biāo)。 分析從用戶處得到的信息，將用戶的任務(wù)目標(biāo)與功能需求、非功能需求、業(yè)務(wù)規(guī)則、解決方案建議及其他無(wú)關(guān)信息區(qū)分開來(lái)。 將頂層的需求分配到系統(tǒng)構(gòu)架內(nèi)定義好的軟件組件中。 了解各質(zhì)量屬性的相對(duì)重要性。 協(xié)商需求的實(shí)現(xiàn)優(yōu)先級(jí)。 將收集的用戶需求表述為書面的需求規(guī)格說(shuō)明和模型。 審閱需求文檔，以確保在認(rèn)識(shí)上與用戶聲明的需求相一致。應(yīng)在開發(fā)小組接受需求之前解決所有分岐。11 1.2.2 需求管理 4 需求管理的任務(wù)是“與客戶就軟件項(xiàng)目的需求達(dá)成并保持一致” 。 4 需求管理包括下列活動(dòng)： 定義需求基線(某一時(shí)刻，對(duì)特定版本中已達(dá)成一致的需求內(nèi)

8、容的描述)。 審查需求變更請(qǐng)求，評(píng)估其可能產(chǎn)生的影響以決定是否批準(zhǔn)。 以可控的方式將批準(zhǔn)的需求變更融入項(xiàng)目中。 保持項(xiàng)目計(jì)劃與需求的同步。 估計(jì)需求變更的影響，在此基礎(chǔ)上協(xié)商新的需求約定。 跟蹤每項(xiàng)需求，找到與其對(duì)應(yīng)的設(shè)計(jì)、源代碼和測(cè)試用例(test case)。 在項(xiàng)目開發(fā)過(guò)程中，始終跟蹤需求的狀態(tài)和變更。12 1.2.2 需求管理4圖1.3從另一個(gè)角度反映了需求開發(fā)與需求管理間的區(qū)別。 市場(chǎng)營(yíng)銷 客戶 管理層 需求 需求開發(fā) 基線需求 分析 記錄 審閱 協(xié)商 需求管理 當(dāng)前基線 修訂的基線 市場(chǎng)營(yíng)銷 客戶 管理層 變更 需求 需求變更過(guò)程 項(xiàng)目 變更 項(xiàng)目環(huán)境 13本次課結(jié)束思考題1.什么

9、是需求分析？2.軟件需求的參與人員有哪些？3.為什么要需求分析？14 1.3 所有項(xiàng)目都有需求4需求在軟件項(xiàng)目中的重要地位 ：軟件系統(tǒng)開發(fā)過(guò)程中最難的部分是對(duì)要開發(fā)什么作出準(zhǔn)確的判斷。所有概念性工作中最難的是建立詳細(xì)的技術(shù)需求，包括所有與用戶、機(jī)器和其他軟件系統(tǒng)的接口。4在開始開發(fā)軟件之前，往往無(wú)法確定所有的需求。這種情況下，可以采用迭代和增量方法，每次實(shí)現(xiàn)一部分需求，得到用戶反饋后再進(jìn)入下一循環(huán)。 15 1.4 優(yōu)秀的團(tuán)隊(duì)遇到糟糕 的需求 4 需求問(wèn)題導(dǎo)致的主要后果是返工重復(fù)做您認(rèn)為早已做好的事情。4 返工的成本占了總開發(fā)成本的30%50 % ，而對(duì)于返工的情況，70%80%是因需求錯(cuò)誤引起

10、的。4 從圖1.4可以看出，在項(xiàng)目末期才發(fā)現(xiàn)缺陷，對(duì)其進(jìn)行改正的成本要比在缺陷剛產(chǎn)生不久時(shí)修改的成本高得多。 開發(fā)階段 需求 設(shè)計(jì) 代碼 測(cè)試 運(yùn)行 120 100 80 60 40 20 改正缺陷的成本 圖1.416 1.4.1 用戶參與不足4開發(fā)人員往往也不重視用戶的參與，原因是他們認(rèn)為與用戶打交道不像寫代碼那么有趣，或者自以為已經(jīng)知道了用戶想要什么。4用戶參與不足將導(dǎo)致不能在項(xiàng)目早期及時(shí)發(fā)現(xiàn)需求中的缺陷，從而延誤項(xiàng)目的完成。4在整個(gè)項(xiàng)目開發(fā)過(guò)程中，開發(fā)團(tuán)隊(duì)必須始終與實(shí)際用戶直接合作，這種合作非常必要而且不可替代。 17 1.4.2 用戶需求擴(kuò)展4由于開發(fā)過(guò)程中需求的不斷發(fā)展與增加，項(xiàng)目往

11、往會(huì)落后于計(jì)劃的進(jìn)度并超出預(yù)算。4出現(xiàn)這種情況是因?yàn)闆](méi)有依據(jù)對(duì)需求的規(guī)模和復(fù)雜度的實(shí)際評(píng)估來(lái)制訂計(jì)劃，而不斷修改需求又使情況變得更糟。4問(wèn)題的責(zé)任部分在于用戶不斷提出修改需求的要求，部分在于開發(fā)人員處理這種要求的方式。 4要控制項(xiàng)目范圍的改變：首先應(yīng)明確項(xiàng)目的業(yè)務(wù)目標(biāo)、全局規(guī)劃、范圍、限制、成功標(biāo)準(zhǔn)以及產(chǎn)品的預(yù)計(jì)用途。然后參考這一框架對(duì)所有新特性和需求變更進(jìn)行評(píng)估。 18 1.4.3 有岐義的需求4岐義表現(xiàn)為同一讀者可以對(duì)一項(xiàng)需求聲明作出多種解釋，或者不同的讀者對(duì)同一需求產(chǎn)生不同的理解。 4岐義會(huì)導(dǎo)致以下幾點(diǎn)：涉眾對(duì)產(chǎn)品懷有不同的期望。因此最終交付的產(chǎn)品會(huì)讓部分人感到意外。有岐義的需求使開發(fā)人

12、員的時(shí)間浪費(fèi)在解決無(wú)需解決的問(wèn)題上。有岐義的需求導(dǎo)致測(cè)試人員與開發(fā)人員對(duì)產(chǎn)品功能的理解不同，從而使測(cè)試人員也要浪費(fèi)時(shí)間來(lái)解決這些差異。4消除歧義的辦法之一是讓代表不同觀點(diǎn)的人對(duì)需求作正式的檢查 。19 1.4.4 鍍金問(wèn)題4開發(fā)人員為產(chǎn)品添加了一項(xiàng)需求說(shuō)明中沒(méi)有提到的功能，他認(rèn)為“用戶肯定會(huì)喜歡的”。這就是所謂的“鍍金問(wèn)題(gold plating)”。 4開發(fā)人員和需求分析員不應(yīng)擅自添加特性，應(yīng)該把創(chuàng)意和備選方案提交給客戶，讓他們做決定。4要避免鍍金問(wèn)題，就應(yīng)該追溯每項(xiàng)功能的來(lái)源，弄清楚為什么添加該功能。 20 1.4.5 過(guò)于抽象的需求 營(yíng)銷人員或經(jīng)理經(jīng)常喜歡只給出一個(gè)粗略的說(shuō)明，他們希望

13、開發(fā)人員在開發(fā)過(guò)程中充實(shí)它。這種方式對(duì)研究性項(xiàng)目或需求特別靈活的項(xiàng)目或許管用，但是需要緊密合作的團(tuán)隊(duì)，而且僅限于開發(fā)小型系統(tǒng)。大多數(shù)情況下，這種做法的結(jié)果是使開發(fā)人員受挫，讓客戶失望。21 1.4.6 忽略了某類用戶4用戶所使用的產(chǎn)品特性、產(chǎn)品的使用頻率以及用戶自身的經(jīng)驗(yàn)水平不盡相同。4因此，多數(shù)產(chǎn)品都擁有不同的用戶群。如果一開始沒(méi)能找出產(chǎn)品的所有重要用戶群，就會(huì)有某些用戶需求得不到滿足。確定所有用戶群后，還要保證獲得各類用戶的需求 。22 1.4.7 不準(zhǔn)確的計(jì)劃4不能充分理解需求，就會(huì)作出過(guò)于樂(lè)觀的估計(jì)，最終不可避免地陷入超支的泥潭。4造成軟件成本估算失敗的最主要原因包括頻繁變更需求、遺漏

14、需求、未與用戶充分溝通、需求的說(shuō)明不精確，以及對(duì)需求的分析不透徹等。 23 1.5 優(yōu)質(zhì)需求過(guò)程的好處4 實(shí)現(xiàn)有效的需求工程過(guò)程可以讓組織受益匪淺。減少開發(fā)后期以及整個(gè)維護(hù)過(guò)程中不必要的返工，可帶來(lái)極大的回報(bào)。4 下面列出的好處并不能完全量化，但確實(shí)存在： 減少需求缺陷 減少開發(fā)過(guò)程中的返工 減少不必要的特性 降低改進(jìn)成本 加快開發(fā)進(jìn)度 提高溝通效率 控制需求范圍的改變 項(xiàng)目更有序 對(duì)系統(tǒng)測(cè)試的評(píng)估更準(zhǔn)確 提高客戶和開發(fā)人員的滿意度24 1.6 優(yōu)秀需求的特點(diǎn)4如何才能將好的需求規(guī)格說(shuō)明與那些有問(wèn)題的區(qū)分開來(lái)？4這一節(jié)首先對(duì)說(shuō)明中的單條需求(即需求陳述)特點(diǎn)進(jìn)行討論，然后將介紹SRS（需求規(guī)格

15、說(shuō)明）作為整體應(yīng)具備的特點(diǎn)。4如果想知道您的需求是否具備這些特點(diǎn)，最好的辦法就是請(qǐng)幾位項(xiàng)目相關(guān)人員仔細(xì)審閱您的SRS。不同的人會(huì)發(fā)現(xiàn)不同的問(wèn)題。例如，需求分析人員和開發(fā)人員無(wú)法準(zhǔn)確判斷完備性和正確性，而用戶則無(wú)法評(píng)價(jià)技術(shù)可行性。25 1.6.1 需求陳述的特點(diǎn) 4 每一項(xiàng)用戶需求、業(yè)務(wù)需求和功能需求都應(yīng)具備下列性質(zhì) 。 完整性| 每一項(xiàng)需求都必須完整地描述即將交付使用的功能。每一項(xiàng)需求都必須完整地描述即將交付使用的功能。 正確性| 每一項(xiàng)需求都必須準(zhǔn)確地描述將要開發(fā)的功能。每一項(xiàng)需求都必須準(zhǔn)確地描述將要開發(fā)的功能。 可行性| 需求必須能夠在系統(tǒng)及其運(yùn)行環(huán)境的已知能力和約束條件內(nèi)實(shí)現(xiàn)。需求必須能

16、夠在系統(tǒng)及其運(yùn)行環(huán)境的已知能力和約束條件內(nèi)實(shí)現(xiàn)。 必要性| 每一項(xiàng)需求記錄的功能都必須是用戶的真正需要，或者是為符合外部系統(tǒng)每一項(xiàng)需求記錄的功能都必須是用戶的真正需要，或者是為符合外部系統(tǒng)需求或某一標(biāo)準(zhǔn)而必須具備的功能。需求或某一標(biāo)準(zhǔn)而必須具備的功能。 有優(yōu)先次序| 為每一項(xiàng)功能需求、特性或用例指定一個(gè)實(shí)現(xiàn)優(yōu)先級(jí)，以表明它在產(chǎn)品的為每一項(xiàng)功能需求、特性或用例指定一個(gè)實(shí)現(xiàn)優(yōu)先級(jí)，以表明它在產(chǎn)品的某一版本中的重要程度。某一版本中的重要程度。 無(wú)歧義| 一項(xiàng)需求聲明對(duì)所有讀者應(yīng)該只有一種一致的解釋，然而自然語(yǔ)言卻極易一項(xiàng)需求聲明對(duì)所有讀者應(yīng)該只有一種一致的解釋，然而自然語(yǔ)言卻極易產(chǎn)生歧義。產(chǎn)生歧義。

17、 可驗(yàn)證性| 看看您能否設(shè)計(jì)一些測(cè)試方法或使用其他驗(yàn)證方法，如檢查或演示來(lái)判斷看看您能否設(shè)計(jì)一些測(cè)試方法或使用其他驗(yàn)證方法，如檢查或演示來(lái)判斷產(chǎn)品是否正確實(shí)現(xiàn)了需求。產(chǎn)品是否正確實(shí)現(xiàn)了需求。 26 1.6.2 需求規(guī)格說(shuō)明的特點(diǎn)4 需求規(guī)格說(shuō)明中所包含的整體需求集還必須具備下列特性。 完整性|不能遺漏任何需求或必要的信息。不能遺漏任何需求或必要的信息。|需求遺漏問(wèn)題很難被發(fā)現(xiàn)，因?yàn)樗鼈儾](méi)有列出來(lái)。需求遺漏問(wèn)題很難被發(fā)現(xiàn)，因?yàn)樗鼈儾](méi)有列出來(lái)。 一致性|需求的一致性是指需求不會(huì)與同一類型的其他需求或更高層次的業(yè)需求的一致性是指需求不會(huì)與同一類型的其他需求或更高層次的業(yè)務(wù)、系統(tǒng)或用戶需求發(fā)生沖突

18、。務(wù)、系統(tǒng)或用戶需求發(fā)生沖突。|必須在開發(fā)前解決需求不一致的問(wèn)題。必須在開發(fā)前解決需求不一致的問(wèn)題。 可修改性|必須能夠?qū)Ρ仨毮軌驅(qū)RS作必要的修訂，并可以為每項(xiàng)需求維護(hù)修改的歷史作必要的修訂，并可以為每項(xiàng)需求維護(hù)修改的歷史記錄。記錄。 可跟蹤性|需求如果是可跟蹤的，就能找到它的來(lái)源、它對(duì)應(yīng)的設(shè)計(jì)單元、實(shí)需求如果是可跟蹤的，就能找到它的來(lái)源、它對(duì)應(yīng)的設(shè)計(jì)單元、實(shí)現(xiàn)它的源代碼以及用于驗(yàn)證其是否被正確實(shí)現(xiàn)的測(cè)試用例?，F(xiàn)它的源代碼以及用于驗(yàn)證其是否被正確實(shí)現(xiàn)的測(cè)試用例。 271.7需求分析的任務(wù)、過(guò)程和方法需求分析的任務(wù)、過(guò)程和方法1.7.1需求分析的任務(wù)需求分析的任務(wù)4簡(jiǎn)言之,需求分析的任務(wù)就是

19、解決“做什么”的問(wèn)題,就是要全面地理解用戶的各項(xiàng)要求,并準(zhǔn)確地表達(dá)所接受的用戶需求。包括以下幾個(gè)方面：確定對(duì)系統(tǒng)的綜合要求分析系統(tǒng)的數(shù)據(jù)要求導(dǎo)出系統(tǒng)的邏輯模型修正系統(tǒng)開發(fā)計(jì)劃281.7.2 需求分析過(guò)程需求分析過(guò)程需求分析階段的工作可進(jìn)一步分為：?jiǎn)栴}識(shí)別、分析與綜合、編寫規(guī)格說(shuō)明和評(píng)審四個(gè)階段。(這些子項(xiàng)包括軟件類產(chǎn)品中需求收集、評(píng)價(jià)、編寫文檔等所有活動(dòng)。)4 問(wèn)題識(shí)別就是從系統(tǒng)角度來(lái)理解軟件,確定對(duì)所開發(fā)系統(tǒng)的綜合要求,并提出這些需求的實(shí)現(xiàn)條件,以及需求應(yīng)該達(dá)到的標(biāo)準(zhǔn).這些需求包括：功能需求(做什么),性能需求(要達(dá)到什么指標(biāo)),環(huán)境需求(如機(jī)型,操作系統(tǒng)等),可靠性需求(不發(fā)生故障的概率）

20、,安全保密需求,用戶界面需求,資源使用需求(軟件運(yùn)行是所需的內(nèi)存,CPU等),軟件成本消耗與開發(fā)進(jìn)度需求,預(yù)先估計(jì)以后系統(tǒng)可能達(dá)到的目標(biāo).4 分析與綜合逐步細(xì)化所有的軟件功能,找出系統(tǒng)各元素間的聯(lián)系,接口特性和設(shè)計(jì)上的限制,分析他們是否滿足需求,剔除不合理部分,增加需要部分.最后,綜合成系統(tǒng)的解決方案,給出要開發(fā)的系統(tǒng)的詳細(xì)邏輯模型(做什么的模型)。4 制訂規(guī)格說(shuō)明書即編制文檔,描述需求的文檔稱為軟件需求規(guī)格說(shuō)明書.請(qǐng)注意,需求分析階段的成果是需求規(guī)格說(shuō)明書,向下一階段提交。4 評(píng)審對(duì)功能的正確性，完整性和清晰性，以及其它需求給予評(píng)價(jià)。評(píng)審?fù)ㄟ^(guò)才可進(jìn)行下一階段的工作，否則重新進(jìn)行需求分析。29

21、1.7.3 需求分析的方法需求分析的方法4 需求分析的方法有很多.這里只強(qiáng)調(diào)原型化方法，其它的方法如：結(jié)構(gòu)化方法，動(dòng)態(tài)分析法等(個(gè)人認(rèn)為,對(duì)初學(xué)者不必深究這些方法，實(shí)際上很少用)在此不討論。4 原型化方法就是盡可能快地建造一個(gè)粗糙的系統(tǒng)原型化方法就是盡可能快地建造一個(gè)粗糙的系統(tǒng), ,這系統(tǒng)實(shí)現(xiàn)這系統(tǒng)實(shí)現(xiàn)了目標(biāo)系統(tǒng)的某些或全部功能，了目標(biāo)系統(tǒng)的某些或全部功能，但是這個(gè)系統(tǒng)可能在可靠性，界面的友好性或其他方面上存在缺陷。建造這樣一個(gè)系統(tǒng)的目的是為了考察某一方面的可行性，如算法的可行性，技術(shù)的可行性，或考察是否滿足用戶的需求等。如，為了考察是否滿足用戶的要求，可以用某些軟件工具快速的建造一個(gè)原型系統(tǒng)，這個(gè)系統(tǒng)只是一個(gè)界面，然后聽取用戶的意見，改進(jìn)這個(gè)原型。以后的目標(biāo)系統(tǒng)就在原型系統(tǒng)的基礎(chǔ)上開發(fā)。301.7.3需求分析的方法需求分析的方法4原型主要有三種類型:探索型，實(shí)驗(yàn)型，進(jìn)化型。 探索型:目的是要弄清楚對(duì)目標(biāo)系統(tǒng)的要求,確定所希望的特性,并探討多種方案的可行性。 實(shí)驗(yàn)型:用于大規(guī)模開發(fā)和實(shí)現(xiàn)前,考核方案是否合適,規(guī)格說(shuō)明是否可靠。 進(jìn)化型:目的不在于改進(jìn)規(guī)格說(shuō)明,而是將系統(tǒng)建造得易于變化,在改進(jìn)原型的過(guò)程中,逐步將原型進(jìn)化成最終系統(tǒng)。4在使用原型化方法時(shí)有