【文章內(nèi)容簡(jiǎn)介】 組基本需求說明后，通過快速分析構(gòu)造出一個(gè)小型的軟件系統(tǒng)，滿足用戶的基本要求。使得用戶可在試用原型系統(tǒng)的過程中得到親身感受和受到啟發(fā)，做出反應(yīng)和評(píng)價(jià)。然后開發(fā)者根據(jù)用戶的意見對(duì)原型加以改進(jìn)。隨著不斷試驗(yàn)、糾錯(cuò)、使用、評(píng)價(jià)和修改，獲得新的原型版本，如 此周而復(fù)始，逐步減少分析和通信中的誤解，彌補(bǔ)不足之處，進(jìn)一步確定各種需求細(xì)節(jié)，適應(yīng)需求的變更，從而提高了最終產(chǎn)品的質(zhì)量。 (1) 原型的分類 由于運(yùn)用原型的目的和方式不同，原型可分為以下兩種不同的類型： ① 廢棄型：先構(gòu)造一個(gè)功能簡(jiǎn)單而且質(zhì)量要求不高的模型系統(tǒng)，針對(duì)這個(gè)模型系統(tǒng)反復(fù)進(jìn)行分析修改，形成比較好的設(shè)計(jì)思想，據(jù)此設(shè)計(jì)出更加完整、準(zhǔn)確、一致、可靠的最終系統(tǒng)。系統(tǒng)構(gòu)造完成后，原來的模型系統(tǒng)就被廢棄不用。 ② 追加型或演化型：先構(gòu)造一個(gè)功能簡(jiǎn)單而且質(zhì)量要求不高的模型系統(tǒng)，作為最終系 12 統(tǒng)的核心，然后通過不斷地 擴(kuò)充修改，逐步追加新要求，最后發(fā)展成為最終系統(tǒng)。 有人把廢棄型原型又細(xì)分為探索型和實(shí)驗(yàn)型。探索型原型的目的是要弄清對(duì)目標(biāo)系統(tǒng)的要求，確定所希望的特性，并探討多種方案的可行性。它主要針對(duì)開發(fā)目標(biāo)模糊，用戶和開發(fā)者對(duì)項(xiàng)目都缺乏經(jīng)驗(yàn)的情況。而實(shí)驗(yàn)型原型用于大規(guī)模開發(fā)和實(shí)現(xiàn)之前，考核方案是否合適，規(guī)格說明是否可靠。 (2) 原型類型的選擇 1984 年 Boar 提出一系列選擇原型化方法的因素。如果是在需求分析階段要使用原型化方法，必須從系統(tǒng)結(jié)構(gòu)、邏輯結(jié)構(gòu)、用戶特征、應(yīng)用約束、項(xiàng)目管理和項(xiàng)目環(huán)境等多方面來考慮，以決定是否 采用原型化方法。 系統(tǒng)結(jié)構(gòu)：聯(lián)機(jī)事務(wù)處理系統(tǒng)，相互關(guān)聯(lián)的應(yīng)用系統(tǒng)適合于用原型化方法，而批處理、批修改等結(jié)構(gòu)不適宜用原型化方法。 邏輯結(jié)構(gòu)：有結(jié)構(gòu)的系統(tǒng)，如操作支持系統(tǒng)、管理信息系統(tǒng)、記錄管理系統(tǒng)等適合于用原型化方法，而基于大量算法的系統(tǒng)不適宜用原型化方法。 用戶特征：不滿足于預(yù)先做系統(tǒng)定義說明，愿意為定義和修改原型投資，不易肯定詳細(xì)需求，愿意承擔(dān)決策的責(zé)任，準(zhǔn)備積極參與的用戶是適合于使用原型的用戶。 應(yīng)用約束：對(duì)已經(jīng)運(yùn)行系統(tǒng)的補(bǔ)充，不能用原型化方法。 項(xiàng)目管理：只有項(xiàng)目負(fù)責(zé)人愿意使用原型化方法，才 適合于用原型化的方法。 項(xiàng)目環(huán)境：需求說明技術(shù)應(yīng)當(dāng)根據(jù)每個(gè)項(xiàng)目的實(shí)際環(huán)境來選擇。 當(dāng)系統(tǒng)規(guī)模很大、要求復(fù)雜、系統(tǒng)服務(wù)不清晰時(shí)，在需求分析階段先開發(fā)一個(gè)系統(tǒng)原型是很值得的。特別是當(dāng)性能要求比較高時(shí)，在系統(tǒng)原型上先做一些試驗(yàn)也是很必要的。 1992 年 Andriole 給出 6 個(gè)問題，用來幫助選擇原型方法。表 指明了對(duì)這些問題的典型答案和對(duì)使用原型方法的建議。 表 選擇適當(dāng)?shù)脑头椒? 問 題 廢棄型原型法 演化型原型法 其它預(yù)備工作 目標(biāo)系統(tǒng)要解決的問題弄清楚了嗎？ 是 是 否 問題可以被建模嗎？ 是 是 否 客戶能夠確定基本需求嗎？ 是 ∕ 否 是 ∕ 否 否 需求已經(jīng)被建立而且比較穩(wěn)定了嗎？ 否 是 是 有模糊不清的需求嗎？ 是 否 是 需求中有矛盾嗎？ 是 否 是 (3) 原型生存期 原型的開發(fā)和使用過程叫做原型生存期。圖 （ a）是原型生存期的模型，圖 （ b）是模型 的細(xì)化。 13 圖 原型生存期 ① 快速分析 ：在分析者和用戶的緊密配合下，快速確定軟件系統(tǒng)的基本要求。 ② 構(gòu)造原型 ：在快速分析基礎(chǔ)上，根據(jù)基本需求，盡快實(shí)現(xiàn)一個(gè)可運(yùn)行的系統(tǒng)。 ③ 運(yùn)行和評(píng)價(jià)原型 ：用戶在開發(fā)者指導(dǎo)下試用原型，在試用的過程中考核評(píng)價(jià)原型的特性，分析其運(yùn)行結(jié)果是否滿足規(guī)格說明的要求，以及規(guī)格說明描述是否滿足用戶愿望。 ④ 修正和改進(jìn) ：根據(jù)修改意見進(jìn)行修改。 如果用修改原型的過程代替快速分析，就形成了原型開發(fā)的迭代過程。開發(fā)者和用戶在一 次次的迭代過程中不斷將原型完善，以接近系統(tǒng)的最終要求。 ⑤ 判定原型完成 ：經(jīng)過修改或改進(jìn)的原型，達(dá)到參與者一致認(rèn)可，則原型開發(fā)的迭代過程可以結(jié)束。為此，應(yīng)判斷有關(guān)應(yīng)用的實(shí)質(zhì)是否已經(jīng)掌握，迭代周期是否可以結(jié)束等。 判定的結(jié)果有兩個(gè)不同的轉(zhuǎn)向，一是繼續(xù)迭代驗(yàn)證，一是進(jìn)行詳細(xì)說明。 ⑥ 判斷原型細(xì)部是否說明 ：判斷組成原型的細(xì)部是否需要嚴(yán)格地加以說明。原型化方法允許對(duì)系統(tǒng)必要成分或不能通過模型進(jìn)行說明的成分進(jìn)行嚴(yán)格的詳細(xì)的說明。 ⑦ 原型細(xì)部的說明 ：對(duì)于那些不能通過原型說明的所有項(xiàng)目，仍需通過文件加以說明。嚴(yán) 格說明的成分要作為原型化方法的模型編入詞典。 ⑧ 判定原型效果 ：考察用戶新加入的需求信息和細(xì)部說明信息，看其對(duì)模型效果有什么影響 ? 是否會(huì)影響模塊的有效性 ? 如果模型效果受到影響，甚至導(dǎo)致模型失效，則要進(jìn)行修正和改進(jìn)。 ⑨ 整理原型和提供文檔。 總之，利用原型化技術(shù)，可為軟件的開發(fā)提供一種完整的、靈活的、近似動(dòng)態(tài)的規(guī)格說明方法。 (4) 原型開發(fā)技術(shù) 通常用于構(gòu)造原型的一些技術(shù)包括可執(zhí)行規(guī)格說明、基于場(chǎng)景的設(shè)計(jì)、自動(dòng)程序設(shè)計(jì)、專用語言、可復(fù)用的軟件構(gòu)件和簡(jiǎn)化假設(shè)等等。其中前三種還適用于用戶界面的設(shè)計(jì)。 ? 可執(zhí)行規(guī)格說明 ：可執(zhí)行規(guī)格說明是用于需求規(guī)格說明的一種自動(dòng)化技術(shù)?？蓤?zhí)行規(guī)格說明語言可描述系統(tǒng)要“做什么”，但它并不描述系統(tǒng)要“怎樣做”。使用這種方法，人們可以直接觀察他們用語言規(guī)定的任何系統(tǒng)性行為?？蓤?zhí)行規(guī)格說明包括形式化規(guī)格說明、有限狀態(tài)模型和可執(zhí)行的數(shù)據(jù)流圖。 ? 基于場(chǎng)景的設(shè)計(jì) ：一個(gè)場(chǎng)景可模擬在系統(tǒng)運(yùn)行期間用戶經(jīng)歷的事件。它提供了輸入─處理─輸出的屏幕格式和有關(guān)對(duì)話的模型。因此，場(chǎng)景能夠給用戶顯示系統(tǒng)的逼真的視圖， 14 使用戶得以判斷是否符合他的意圖。 ? 自動(dòng)程序設(shè)計(jì) ：自動(dòng)程序設(shè)計(jì)是可執(zhí)行規(guī)格說 明的替身，主要是指在程序自動(dòng)生成環(huán)境的支持下，利用計(jì)算機(jī)實(shí)現(xiàn)軟件的開發(fā)。它可以自動(dòng)地或半自動(dòng)地把用戶的非過程性問題規(guī)格說明轉(zhuǎn)換為某種高級(jí)語言程序，主要手段有以下 4 種： ? 專用語言 ：專用語言是應(yīng)用領(lǐng)域的模型化語言。在原型開發(fā)中使用專用語言，可方便用戶和軟件開發(fā)者在計(jì)劃中的系統(tǒng)特性方面的交流。 ? 軟件復(fù)用技術(shù) ：軟件復(fù)用技術(shù)可分為兩大類：合成技術(shù)和生成技術(shù)。 ① 合成技術(shù)：可復(fù)用的軟件構(gòu)件可以是對(duì)某一函數(shù)、過程、子程序、數(shù)據(jù)類型、算法等可復(fù)用軟件成份的抽象，利用這些構(gòu)件來構(gòu)造軟件系統(tǒng)。用構(gòu)件合成較大的構(gòu)件 有三種方式：一是連接；二是消息傳遞和繼承；三是管道 (pipe)機(jī)制。 ② 生成技術(shù)：利用可復(fù)用的模式，通過生成程序產(chǎn)生一個(gè)新的程序或程序段，產(chǎn)生的程序可以看做是模式的實(shí)例?？蓮?fù)用的模式有兩種不同的形式：代碼模式和規(guī)則模式。前者的例子是應(yīng)用生成器，可復(fù)用的代碼模式就存在于生成器自身。通過特定的參數(shù)替換，生成抽象軟件模塊的具體實(shí)體。后者的例子是變換系統(tǒng)，它通常采用超高級(jí)的規(guī)格說明語言，形式化地給出軟件的需求規(guī)格說明，利用程序變換系統(tǒng)（有時(shí)要經(jīng)過一系列的變換），把用超高級(jí)規(guī)格說明語言編寫的程序轉(zhuǎn)化成某種可執(zhí)行語言 的程序。 ? 簡(jiǎn)化假設(shè) ：簡(jiǎn)化假設(shè)是在開發(fā)過程中使設(shè)計(jì)者迅速得到一個(gè)簡(jiǎn)化的系統(tǒng)所做的假設(shè)。盡管這些假設(shè)可能實(shí)際上并不能成立，但它們?cè)谠烷_發(fā)過程中可以使開發(fā)者的注意力集中在一些主要的方面。 6. 軟件需求規(guī)格說明和需求評(píng)審 (1) 制定軟件需求規(guī)格說明的原則 1979 年由 Balzer 和 Goldman 提出了做出良好規(guī)格說明的 8 條原則。 原則 1：功能與實(shí)現(xiàn)分離，即描述要“做什么”而不是“怎樣實(shí)現(xiàn)” 原則 2：要求使用面向處理的規(guī)格說明語言，討論來自環(huán)境的各種刺激可能導(dǎo)致系統(tǒng)做出什么樣的功能性反應(yīng)，來定義一個(gè)行為模 型，從而得到“做什么”的規(guī)格說明。 原則 3：如果目標(biāo)軟件只是一個(gè)大系統(tǒng)中的一個(gè)元素，那么整個(gè)大系統(tǒng)也包括在規(guī)格說明的描述之中。描述該目標(biāo)軟件與系統(tǒng)的其它系統(tǒng)元素交互的方式。 原則 4：規(guī)格說明必須包括系統(tǒng)運(yùn)行的環(huán)境。 原則 5：系統(tǒng)規(guī)格說明必須是一個(gè)認(rèn)識(shí)的模型，而不是設(shè)計(jì)或?qū)崿F(xiàn)的模型。 原則 6：規(guī)格說明必須是可操作的。規(guī)格說明必須是充分完全和形式的，以便能夠利用它決定對(duì)于任意給定的測(cè)試用例，已提出的實(shí)現(xiàn)方案是否都能滿足規(guī)格說明。 原則 7：規(guī)格說明必須容許不完備性并允許擴(kuò)充。 原則 8：規(guī)格說明必須局部化和松散的耦 合。它所包括的信息必須局部化，這樣當(dāng)信息被修改時(shí)，只要修改某個(gè)單個(gè)的段落（理想情況）。同時(shí)，規(guī)格說明應(yīng)被松散地構(gòu)造（即耦合），以便能夠很容易地加入和刪去一些段落。 盡管 Balzer和 Goldman提出的這 8條原則主要用于基于形式化規(guī)格說明語言之上的需求定義的完備性，但這些原則對(duì)于其它各種形式的規(guī)格說明都適用。當(dāng)然要結(jié)合實(shí)際來應(yīng)用上述的原則。 (2) 軟件需求規(guī)格說明 軟件需求規(guī)格說明是分析任務(wù)的最終產(chǎn)物，通過建立完整的信息描述、詳細(xì)的功能和行為描述、性能需求和設(shè)計(jì)約束的說明、合適的驗(yàn)收標(biāo)準(zhǔn)，給出對(duì)目標(biāo)軟件的 各種需求。 表 給出簡(jiǎn)化的大綱作為軟件需求規(guī)格說明的框架。 15 表 軟件需求規(guī)格說明的框架 Ⅰ . 引言 Ⅱ . 信息描述 ⅰ數(shù)據(jù)流 ⅱ控制流 Ⅲ . 功能描述 ⅰ處理說明 ⅱ限制∕局限 ⅲ 性能需求 ⅳ 設(shè)計(jì)約束 ⅴ 支撐圖 ⅰ控制規(guī)格說明 ⅱ 設(shè)計(jì)約束 Ⅳ . 行為描述 Ⅴ . 檢驗(yàn)標(biāo) 準(zhǔn) Ⅵ . 參考書目 Ⅶ . 附錄 (3) 需求規(guī)格說明評(píng)審 作為需求分析階段工作的復(fù)查手段，在需求分析的最后一步，應(yīng)該對(duì)功能的正確性、完整性和清晰性，以及其它需求給予評(píng)價(jià)。評(píng)審的主要內(nèi)容是： 系統(tǒng)定義的目標(biāo)是否與用戶的要求一致； 系統(tǒng)需求分析階段提供的文檔資料是否齊全； 文檔中的所有描述是否完整、清晰、準(zhǔn)確反映用戶要求； 與所有其它系統(tǒng)成分的重要接口是否都已經(jīng)描述； 被開發(fā)項(xiàng)目的數(shù)據(jù)流與數(shù)據(jù)結(jié)構(gòu)是否足夠，確定； 所有圖表是否清楚，在不補(bǔ)充說明時(shí)能否理解； 主要功能是否已包括在規(guī)定的軟件范圍之內(nèi)，是否都已充分說明； 軟件的行為和它必須處理的信息、必須完成的功能是否一致； 設(shè)計(jì)的約束條件或限制條件是否符合實(shí)際； 是否考慮了開發(fā)的技術(shù)風(fēng)險(xiǎn)； 是否考慮過軟件需求的其它方案； 是否考慮過將來可能會(huì)提出的軟件需求； 是否詳細(xì)制定了檢驗(yàn)標(biāo)準(zhǔn)，它們能否對(duì)系統(tǒng)定義是否成功進(jìn)行確認(rèn)； 有沒有遺漏，重復(fù)或不一致的地方； 用戶是否審查了初步的用戶手冊(cè)或原型； 軟件開發(fā)計(jì)劃中的估算是否受到了影響。 為保證軟件需求定義的 質(zhì)量，評(píng)審應(yīng)以專門指定的人員負(fù)責(zé)，并按規(guī)程嚴(yán)格進(jìn)行。評(píng)審結(jié)束應(yīng)有評(píng)審負(fù)責(zé)人的結(jié)論意見及簽字。除分析員之外，用戶／需求者，開發(fā)部門的管理者，軟件設(shè)計(jì)、實(shí)現(xiàn)、測(cè)試的人員都應(yīng)當(dāng)參加評(píng)審工作。一般，評(píng)審的結(jié)果都包括了一些修改意見，待修改完成后再經(jīng)評(píng)審?fù)ㄟ^，才可進(jìn)入設(shè)計(jì)階段。 三、 習(xí)題 【 21】軟件需求分析階段的工作，可以分為以下 4個(gè)方面：對(duì)問題的識(shí)別、分析與綜合、編寫需求分析文檔以及 ( )。 供選擇的答案： A. 總結(jié) B. 階段性報(bào)告 C. 需求分析評(píng)審 D. 以上答案都不正確 【 22】各種需求方法都有它們共同適用的 ( )。 供選擇的答案： A．說明方法 B．描述方式 C. 準(zhǔn)則 D．基本原則 【 23】 軟件需求分析的任務(wù)不應(yīng)包括 ( A )。進(jìn)行需求分析可使用多種工具，但 ( B ) 16 是不適用的。在需求分析中，分析員要從用戶那里解決的最重要的問題是 ( C )。需求規(guī)格說明書的內(nèi)容不應(yīng)當(dāng)包括 ( D )。該文檔在軟件開發(fā)中具有重要的作用，但其作用不應(yīng)當(dāng)包括 ( E )。 供選擇的答案： A. ① 問題分析 ② 信息域分析 ③ 結(jié)構(gòu)化程序設(shè)計(jì) ④ 確定邏輯模型 B. ① 數(shù)據(jù)流圖 ② 判定表 ③ PAD 圖 ④ 數(shù)據(jù)詞典 C. ① 要讓軟件做什么 ② 要給該軟件提供哪些信息 ③ 要求軟件工作效率如何 ④ 要讓軟件具有什么樣的結(jié)構(gòu) D. ① 對(duì)重要功能的描述 ② 對(duì)算法的詳細(xì)過程性描述 ③ 軟件確認(rèn)準(zhǔn)則 ④ 軟件的性能 E. ① 軟件設(shè)計(jì)的依據(jù) ② 用戶和開發(fā)人員對(duì)軟件要“做什么”的共同理解 ③ 軟件驗(yàn)收的依據(jù) ④ 軟件可行性分析的依據(jù) 【 24】原型化方法是用戶和軟件開發(fā)人員之間進(jìn)行的一種交互過程，適用于 ( A )系統(tǒng)。它從用戶界面的開發(fā)入手，首先形成 ( B )，用戶 ( C )，并就 ( D )提出意見，它是一種 ( E )型的設(shè)計(jì)過程。 供選擇的答案： A. ① 需求不確定性高的 ② 需求確定的 ③ 管理信息 ④ 決策支持 B. ① 用戶界面使用手冊(cè)