4.1需求分析概述

4.2軟件需求的概念與層次

4.3獲取需求的目的和獲取需求常用的方法

4.4需求分析的目標和任務

4.5需求分析的過程

4.6需求分析的原則

4.7需求分析階段常見的問題及需求分析的技巧

4.8需求分析的方法

4.9軟件需求分析文檔4.1需求分析概述4.1.1需求因素對項目成敗的影響需求處理是軟件工程的起始階段，設計、實現等后繼階段的正確性都以它的正確性為前提。如果在需求處理過程中有錯誤未能解決，則其后的所有階段都會受到影響，因此與需求有關的錯誤修復代價較高，需求問題對軟件成敗的影響較大。人們應對需求分析階段的工作有足夠的認識。StandishGroup在1995年報告中公布的導致項目成功或失敗的因素的相關數據如表4.1～表4.3所示。4.1.2需求問題的高代價性統計表明，在需求階段發生的錯誤，如到了運行維護階段才發現，則在運行維護階段進行修復的代價可以高達需求階段修復代價的100～200倍(如圖4.1所示)。這種遞增效應也說明了需求問題的高代價性。4.1.3常見的需求定義錯誤在實踐和研究過程中，人們發現關于需求定義的錯誤是需求工程中一類非常常見和重要的問題，具體的錯誤主要有以下幾種：(1)需求并沒有反映用戶的真實需要。(2)模糊和歧義的需求。(3)信息遺漏。(4)不必要的需求。(5)不切實際的期望(UnrealisticExpectations)。2002年，Young也調查了常見的需求定義錯誤，并進行了分類，具體如圖4.2所示。4.1.4應用領域知識對需求分析人員的重要性由于計算機的專業知識是用來服務于社會的各個應用領域的，是要解決用戶工作中的實際問題的，因此，如何能正確理解用戶的實際需求僅有計算機專業知識是遠遠不夠的，還必須對相應的應用領域知識有所涉獵。為了啟發出客戶的要求，需求小組的成員必須熟悉該應用領域，即熟悉目標軟件產品通常在哪些領域使用。因此，每個需求分析組成員最初的任務就是熟悉應用領域，除非需求分析組成員已經在那個領域有過一些經歷。當與客戶和目標軟件的潛在用戶交流時，特別重要的一點是使用正確的術語。畢竟，這一點很難引起工作在某一特定領域的人的重視，除非訪談者使用適于該領域的術語。更重要的是，使用不合適的術語會導致曲解，甚至會交付一個有錯誤的軟件產品。如果需求小組的成員不理解該領域術語的細微差別，則可能會產生同樣的問題。專業的計算機人員希望在根據某一程序做決定前，每個程序的輸入由人工來仔細地檢查。但是對計算機越來越普遍的信任意味著依賴這類檢查的必然性顯然是不明智的。因此，對術語的誤解會造成軟件開發人員的疏忽，這不是危言聳聽。解決術語問題的一個辦法是建立一個術語表，術語表由該領域應用的技術詞匯列表和對應的解釋組成。當小組成員正忙于盡可能學習應用領域的相關知識時，就將初始的詞條插入術語表中。然后，需求小組成員一遇到新的術語就將該術語表更新。適當時還可打印出該術語表并分發給小組成員或下載到PDA(PersonalDigitalAssistant)。這樣的術語表不僅減少了客戶與開發者之間的誤解，而且對減少開發者之間的誤解也是很有必要的。一旦需求小組成員熟悉了該應用領域后，下一步就是建立業務模型。4.2軟件需求的概念與層次4.2.1軟件需求的概念軟件需求是指用戶對軟件的功能和性能的要求，就是用戶希望軟件能做什么事情，完成什么樣的功能，達到什么樣的性能。軟件人員要準確地理解用戶的要求，進行細致的調查分析，將用戶非形式的需求陳述轉化為完整的需求定義，再由需求定義轉化為相應形式的需求規格說明。對于軟件項目的需求，首先要理解用戶的要求，要澄清模糊的需求，與用戶達成共識。4.2.2需求的層次需求可分解為四個層次：業務需求、用戶需求、功能需求和非功能需求。業務需求反映了組織機構或客戶對系統、產品高層次的目標要求，由管理人員或市場分析人員確定。用戶需求描述了用戶通過使用本軟件產品必須要完成的任務，一般是用戶協助提供。功能需求定義了開發人員必須實現的軟件功能，使得用戶通過使用此軟件能完成他們的任務，從而滿足業務需求。對一個復雜產品來說，功能需求也許只是系統需求的一個子集。非功能需求是對功能需求的補充。它可分為兩類：一類是用戶關心的一些重要屬性，例如有效性、效率、靈活性、完整性、互操作性、可靠性、健壯性、可用性等。另一類是對開發者來說很重要的質量屬性，例如可維護性、可移植性、可復用性、可測試性等。軟件需求各組成部分之間的關系如圖4.3所示。4.3獲取需求的目的和獲取需求常用的方法4.3.1獲取需求的目的需求獲取的目的是從項目的戰略規劃開始建立最初的原始需求。為此，它需要研究系統將來的應用環境，確定系統的涉眾，了解現有的問題，建立新系統的目標，獲取為支持新系統目標而需要的業務過程細節和具體的用戶需求。4.3.2獲取需求常用的方法需求分析是軟件開發中最重要的環節，需求分析做得正確與否決定著軟件開發的成敗。要做好需求分析，最首要的是有正確的獲取需求的渠道和方法。常用的獲取需求的方法有訪談、問卷調查、情景分析、實地考察、構造原型等。(1)訪談。訪談是最早開始使用的獲取用戶需求的方法，也是目前仍廣泛使用的需求分析技術。訪談有兩種基本形式，即正式訪談和非正式訪談。正式訪談時，系統分析員將提出一些事先準備好的具體問題。而非正式訪談中，分析員可提出一些用戶可以自由回答的開放性問題。采用訪談方式時，分析員的主要任務是問題的設計，包括探討功能、非功能、例外情況的問題，甚至是一些看起來似乎很“愚蠢”的問題。必須把所有的討論記錄下來，同時還要做一定的整理，并請參與討論的用戶評論并更正。(2)問卷調查。問卷調查即把需要調查的內容制成表格交給用戶填寫。該方法在需要調查大量人員的意見時，十分有效。此方法的優點是用戶有較寬裕的考慮時間和回答時間。經過仔細考慮寫出的書面回答可能比被訪者對問題的口頭回答更準確，從而可以得到對提出的問題較為準確細致的回答。分析員仔細閱讀收回的調查表，然后再有針對性地訪問一些用戶，以便向他們詢問在分析調查表時發現的新問題。采用問卷調查方法的關鍵是調查表的設計。在開發的早期用戶與開發者之間缺乏共同語言，用戶可能對表格中的內容存在理解上的偏差。因此調查表的設計應簡潔、易懂、易填寫，同時還要注意用戶的特點和調查的策略。(3)情景分析。所謂情景分析就是對目標系統解決某個具體問題的方法和結果，給出可能的情景描述，以獲知用戶的具體需求。在訪談用戶的過程中使用情景分析技術往往是非常有效的，該技術的優點主要體現在下述兩個方面。①它能在某種程度上演示目標系統的行為，便于用戶理解，從而進一步揭示出一些分析員目前還不知道的需求。②需求分析的目標是獲知用戶的真實需求，而這一信息的唯一來源是用戶。因此，讓用戶起積極主動的作用對需求分析工作獲得成功是至關重要的。由于情景分析較易被用戶所理解，因此使得用戶在需求分析過程中能夠始終扮演一個積極主動的角色。(4)實地考察。分析人員到用戶工作現場，實際觀察用戶的手工操作過程也是一種行之有效的獲取需求的方法。在實際觀察過程中，分析人員必須注意，系統開發的目標不是手工操作過程的模擬，而是必須考慮最好的經濟效益、最快的處理速度、最合理的操作流程、最友好的用戶界面等因素。因此，分析人員在接受用戶關于應用問題及背景的知識的同時，應結合自己的軟件開發和軟件應用經驗，主動地剔除不合理的、一些暫時行為的用戶需求，從系統角度改進操作流程或規范，提出新的潛在的用戶需求。(5)構造原型。在系統開發的早期，以對用戶所進行的簡單需求分析為基礎，快速建立目標系統的原型。用戶可以通過原型進行評估并提出修改意見，從而使用戶明確需求。快速原型方法既可針對整個系統，也可針對系統的某部分功能。4.3獲取需求的目的和獲取需求常用的方法軟件需求分析的目標是深入描述軟件的功能和性能，確定軟件設計的約束和軟件同其他系統元素的接口細節，定義軟件的其他有效性需求。需求分析階段研究的對象是軟件項目的用戶要求。一方面，必須全面理解用戶的各項要求，但又不能全盤接受所有的要求；另一方面，要準確地表達被接受的用戶要求。只有經過確切描述的軟件需求才能成為軟件設計的基礎。通常軟件開發項目是要實現目標系統的物理模型。作為目標系統的參考，需求分析的任務就是借助于當前系統的邏輯模型導出目標系統的邏輯模型，解決目標系統“做什么”的問題。其實現步驟如圖4.4所示。需求分析階段所要完成的任務并不是如何去編制程序，做具體的工作，而是要確定系統必須完成哪些工作，實現哪些功能，也就是對目標系統提出完整、準確、具體、清晰的要求。即以軟件計劃階段的軟件工作范圍為指南，通過分析綜合建立分析模型，編制出軟件需求規格說明書。需求分析階段的具體任務如下：(1)確定對系統的綜合要求，具體要求如下：①系統界面要求，描述軟件系統的外部特性，即系統從外部輸入哪些數據，又向外部輸出哪些數據；②系統功能要求，列出軟件系統必須完成的所有功能；③系統性能要求，如響應時間、吞吐量、處理時間、對主存和外存的限制等；④安全性、保密性和可靠性要求；⑤系統的運行要求，如對硬件、支持軟件、數據通信接口等的要求；⑥異常處理要求，在運行過程中出現異常情況(如臨時性或永久性的資源故障、不合法或超出范圍的輸入數據、非法操作、數組越界等)時應采取的行動以及希望顯示的信息；⑦將來可能提出的要求，應該明確地列出那些雖然不屬于當前系統開發范疇，但是據分析將來可能會提出來的要求，其目的是為將來可能的擴充和修改做準備，便于需要時較容易地進行這種擴充和修改。(2)分析系統的數據要求。任何一個軟件從本質上來說都是信息處理系統，必然要與各種數據打交道。系統的數據要求包括基本數據元素，數據元素之間的邏輯關系、數據量、峰值等。常用的數據描述手段是實體-關系模型。(3)導出系統的邏輯模型。根據以上分析可導出詳細的邏輯模型。在結構化分析方法中常用數據流圖來描述。(4)修正項目開發計劃。在明確了用戶的真正需求后，可以更準確地估算軟件的成本和進度，從而對以前提出的軟件項目計劃進行必要的修正。(5)開發原型系統。對一些需求不夠明確的軟件，可以先開發一個原型系統，以驗證用戶的需求。目前已有一些較好的工具可供快速建立軟件的原型系統使用，這就為在軟件開發中采用樣機策略奠定了必要的物質基礎。原型法近年來已逐漸發展成為開發軟件的一種重要方法。4.5需求分析的過程需求分析階段的工作，可以分成問題識別、分析與綜合、編制需求分析階段的文檔、需求分析評審4個方面。具體的分析流程如圖4.5所示。4.6需求分析的原則目前，軟件需求分析的方法有很多，雖然各種方法都有其獨特的描述方法，

但這些方法都有它們共同適用的基本原則。

(1)必須能夠表達和理解問題的數據域和功能域。所有軟件定義與開發工作最終是為了解決數據處理問題，就是將一種形式的數據轉換成另一種形式的數據。其轉換過程必定經歷輸入數據、加工數據和產生結果數據等步驟。

對于計算機程序處理的數據，其數據域應包括數據流、數據內容和數據結構。

數據流即數據通過一個系統時的變化方式。輸入數據首先轉換成中間數據，

然后轉換成輸出結果數據。在此期間可以從已有的數據存儲(如磁盤文件或內存緩沖區)中引入附加數據。對數據進行轉換是程序中應有的功能或子功能。兩個轉換功能之間的數據傳遞就確定了功能間的接口。

數據內容即數據項。例如，學生名冊包含了班級、人數、每個學生的學號、姓名、性別、各科成績等。學生名冊的內容由它所包含的項定義。為了理解對學生名冊的處理，必須要理解它的數據內容。

數據結構即各種數據項的邏輯組織。數據是組織成表格，還是組織成有層次的樹型結構？在結構中數據項與其他哪些數據項相關？所有數據是在一個數據結構中，還是在幾個數據結構中？一個結構中的數據與其他結構中的數據如何聯系？這些問題都由數據結構分析來解決。

(2)必須按自頂向下、逐層分解的方式對問題進行分解和不斷細化。通常如果將軟件要處理的問題作為一個整體來看，則會顯得太大、太復雜、很難理解。可以把問題以某種方式分解為幾個較易理解的部分，并確定各部分間的接口，從而實現整體功能。

在需求分析階段，軟件的功能域和信息域都能做進一步的分解。這種分解可以是同一層次上的，稱為橫向分解；也可以是多層次的縱向分解。例如，把一個功能分解成幾個子功能，并確定這些子功能與父功能的接口，就屬于橫向分解。但如果繼續分解，把某些子功能又分解為小的子功能，某個小的子功能又分解為更小的子功能，則屬于縱向分解。

(3)要給出系統的邏輯視圖和物理視圖。

給出系統的邏輯視圖(邏輯模型)和物理視圖(物理模型)，這對系統滿足處理需求所提出的邏輯限制條件和系統中其他成分提出的物理限制條件是必不可少的。軟件需求的邏輯視圖給出軟件要達到的功能和將要處理數據之間的關系，而不是實現的細節。例如，一個學校的教材處理系統要從學生那里獲取訂單，系統讀取訂單的功能并不關心訂單數據的物理形式和用什么設備讀入，也就是說無須關心輸入的機制，只是讀取顧客的訂單而已。類似地，系統中檢查庫存的功能只關心庫存文件的數據結構，而不關心庫存文件在計算機中的具體存儲方式。軟件需求的邏輯描述是軟件設計的基礎。

軟件需求的物理視圖給出處理功能和數據結構的實際表示形式，這往往是由設備決定的。如一些軟件靠終端鍵盤輸入數據，另一些軟件靠模-數轉換設備提供數據。分析員必須弄清系統元素對軟件的限制，并考慮功能和信息結構的物理表示。4.7需求分析階段常見的問題及需求分析的技巧4.7.1需求分析階段常見的問題捕捉真正的需求是困難的。需求分析中最具有挑戰性的問題是如何捕獲真正的需求，如圖4.6所示。對需求的誤解將會直接影響著后期的開發工作，一旦需求分析中出現了漏洞或偏差，將會導致較大的風險。一些國外企業的業務較規范，需求很清楚，但國內企業或組織往往不能清楚地描述自己的需求，造成軟件項目管理的難度加大，甚至項目失敗。4.7.2軟件需求分析技巧在實際應用中，進行需求分析需要一些技巧，主要包括如下幾項：(1)需求分析是分析師與用戶雙方進行配合的項目，需要密切交流合作。(2)在微觀上/宏觀上都應以流程為主。(3)注重事實，堅持客觀調研及主見，不應偏聽偏信。(4)構建需求金字塔。決策層提出宏觀上的統計、查詢、決策需求，管理層提出業務管理和作業控制需求，操作層提出錄入、修改、提交、處理、打印、界面、傳輸、通信、時間、速度等方面的操作需求。(5)注重主動征求各層次的意見和建議，一般需求分析過程需要集中匯報征求意見2次或3次。4.8需求分析的方法4.8.1結構化分析方法結構化分析(StructuredAnalysis，SA)是面向數據流進行需求分析的方法。結構化分析方法適合于數據處理類型軟件的需求分析。由于結構化分析方法利用圖形來表達需求，因此顯得清晰、簡明，易于學習和掌握。具體來說，結構化分析方法就是用抽象模型的概念，按照軟件內部數據傳遞、變換的關系，自頂向下逐層分解，直到找到滿足功能要求的所有可實現的軟件為止。在問題域中，一個龐大而又復雜的問題在整體上往往很難被完全理解，為此，人們常常把一個復雜問題分解成若干個子問題，如果問題被分解后，還不足以被理解，則又把子問題再進一步分解，直到問題能被完全理解為止。在軟件工程中，大型軟件往往非常復雜，控制軟件復雜性的基本手段是“分解”。SA方法正是把軟件系統自上向下逐層分解、逐步細化的一種方法，它能較好地控制系統的復雜性，按照這種方法，無論系統有多么大，總可以有計劃地把它分解為足夠小的子問題。即隨著系統的增大，分析工作的復雜程度并不會增大，只是工作量增大而已。簡單地說，復雜性不會隨系統的增大而增大。結構化分析方法主要使用以下幾種工具：數據流圖、數據詞典、結構化英語、判定表和判定樹。1.數據流圖SA方法使用數據流圖從數據傳遞和加工的角度，以圖形的方式刻畫數據流從輸入到輸出的傳輸變換過程。數據流圖是結構化系統分析的主要工具，它表示了系統內部信息的流向，并表示了系統的邏輯處理的功能，是一種功能模型。數據流圖(DataFlowDiagram，DFD)的基本圖形元素有4種，如圖4.8所示。在數據流圖中，如果有兩個以上的數據流指向一個加工，或是從一個加工中引出兩個以上的數據流，則這些數據流之間往往存在一定的關系。為表達這些關系，可以在這些數據流的加工處標上不同的標記符號。所用符號及其含意在圖4.9中給出。為了表達數據處理過程的數據加工情況，用一個數據流圖是不夠的。稍微復雜的實際問題，在數據流圖上常常出現十幾個甚至幾十個加工。這樣的數據流圖看起來很不清楚。層次結構的數據流圖能很好地解決這一問題。按照系統的層次結構進行逐步分解，并以分層的數據流圖反映這種結構關系，能清楚地表達和容易理解整個系統。(1)分層的數據流圖。先把整個數據處理過程暫且看成一個加工，它的輸入數據和輸出數據實際上反映了系統與外界環境的接口。這就是分層數據流圖的頂層。但僅此一圖并未表明數據的加工要求，需要進一步細化。圖4.10給出分層數據流圖的示例。畫數據流圖的基本步驟概括地說，就是自外向內，自頂向下，逐層細化，完善求精。檢查和修改的原則如下：①數據流圖上所有圖形符號只限于前述四種基本圖形元素。②頂層數據流圖必須包括前述四種基本元素，缺一不可。③頂層數據流圖上的數據流必須封閉在外部實體之間。④每個加工至少有一個輸入數據流和一個輸出數據流。⑤在數據流圖中，需按層給加工框編號。編號表明該加工處在哪一層，以及上下層的父圖與子圖的對應關系。⑥規定任何一個數據流子圖必須與它上一層的一個加工對應，兩者的輸入數據流和輸出數據流必須一致。此即父圖與子圖的平衡。⑦可以在數據流圖中加入物質流，以幫助用戶理解數據流圖。⑧圖上每個元素都必須有名字。數據流和數據文件的名字應當是“名詞”或“名詞性短語”，表明流動的數據是什么。加工的名字應當是“名詞?+?賓語”，表明做什么事情。⑨數據流圖中不可夾帶控制流。⑩初畫時可以忽略瑣碎的細節，以集中精力于主要數據流。(2)加工規格說明。加工規格說明用來說明DFD中的數據加工的加工細節。加工規格說明描述了數據加工的輸入，實現加工的算法以及產生的輸出。另外，加工規格說明指明了加工(功能)的約束和限制，與加工相關的性能要求，以及影響加工的實現方式的設計約束。必須注意，書寫加工規格說明的主要目的是要表達“做什么”，而不是“怎樣做”。因此它應描述數據加工實現加工的策略而不是實現加工的細節。2.數據詞典分析模型中包含了對數據對象、功能和控制的表示。在每一種表示中，數據對象和控制項都扮演一定的角色。為表示每個數據對象和控制項的特性，建立了數據詞典。數據詞典精確地、嚴格地定義了每一個與系統相關的數據元素，并以字典式順序將它們組織起來，使得用戶和分析員對所有的輸入、輸出、存儲成分和中間計算有共同的理解。詞條描述及內容描述方法如下所述：(1)詞條描述。在數據詞典的每一個詞條中應包含以下信息：①名稱：數據對象或控制項、數據存儲或外部實體的名字。②別名或編號。③分類：包括數據對象、加工、數據流、數據文件、外部實體、控制項(事件∕狀態)。④描述：描述內容或數據結構等。⑤何處使用：使用該詞條(數據或控制項)的加工。(2)內容描述。在數據詞典的編制中，分析員最常用的描述內容或數據結構的符號如表4.4所示。數據流及數據存儲的表示方法如下：①數據流表示。采用自上而下、逐層分解的方式對每一條數據流進行定義。在數據流的定義式中，通常采用下述符號(以大學教務管理中的成績管理子系統問題數據流圖中的數據流的定義為例)：(D01)學號?=?入學年份?+?專業編號?+?班級編號?+?序號(D02)成績單編號?=?學年?+?課程編號?+?班級編號(d01.1)學號?=?"00000001".."99999999"(d01.2)密碼?=?"000001".."999999"(d02.2)課程號?=?1{"英文字母"}4?+?"0001".."9999"②數據存儲表示。有兩種類型的數據存儲，一種是文件形式，另一種是數據庫形式。對于文件形式，其定義包括定義文件的組成數據項和文件的組織方式兩項內容，其中文件組成數據項的定義方式與數據流的定義方式相同。3.結構化語言結構化語言是一種介于自然語言和形式化語言之間的半形式化語言，它是在自然語言的基礎上加入了一定的限制，通過使用有限的詞匯和有限的語句來較為嚴格地描述加工邏輯。描述加工邏輯時可以使用的詞匯包括：數據字典中定義的名字、基本控制結構中的關鍵詞、自然語言中具有明確意義的動詞、少量的自定義詞匯等。盡量不使用形容詞或副詞，可以使用一些簡單的算術或邏輯運算符。結構化語言中的三種基本結構的描述方法如下：(1)順序結構：由自然語言中的簡單祈使語句序列構成。(2)選擇結構：?通常采用IF…THEN…ELSE…ENDIF和CASE…OF…ENDCASE結構。(3)循環結構：通常采用DOWHILE…ENDDO和REPEAT…UNTIL結構。4.判定表判定表用于描述一些結構化語言不易表達清楚的加工邏輯，這種表達方式簡單明了，如圖4.14所示。5.判定樹判定樹以圖形的方式描述加工邏輯，它結構簡單，易讀易懂。加工邏輯可以用結構化語言、判定表、判定樹等多種形式表示，也可將它們結合起來表示。4.8.2原型分析方法傳統的軟件工程方法強調自頂向下分階段開發，要求在進入實際開發期之前必須預先對需求嚴格定義。但實踐表明，在系統建立起來之前很難僅僅依靠分析就確定出一套完整、一致、有效的應用需求，并且這種預先定義的策略更不能適應用戶需求不斷變化的情況。由此，原型分析法應運而生，它一反傳統的自頂向下的開發模式，是目前較流行的開發模式。1.原型的概念原型最早使用在制造業和機械產品設計中，先做出產品的基本模型，然后進行完善和改進，最后得到符合要求的產品。在軟件工程中，原型是指要開發的軟件系統的原始模型，是一個軟件早期的可運行的版本，它反映最終系統的某些重要特性(如軟件界面與布局、功能等)。在獲得一組最基本的需求說明后，通過分析構造出一個小型的簡約軟件系統，滿足用戶的基本要求，然后不斷演化得到較高質量的產品。原型法克服了傳統軟件生命周期法的一些弊端，具有快速靈活、交互式等特點，方法的核心是用交互、快速建立起來的原型取代了不太明確的需求規格說明，用戶通過在計算機上實際運行和試用原型系統得到親身感受并受到啟發，通過反應和評價向開發者提供真實的反饋意見。然后開發者根據用戶的意見對原型加以改進，通過“原型構造—試用運行—評價反饋—分析修改”的多次反復，從而提高最終產品的質量。圖4.16是原型生存期的圖示。原型分析方法的具體實現步驟如下：(1)快速分析：在分析者和用戶的緊密配合下，快速確定軟件系統的基本要求。(2)構造原型：在快速分析基礎上，根據基本需求，盡快實現一個可運行的系統。(3)運行和評價原型：用戶在開發者指導下試用原型，在試用的過程中考核評價原型的特性，分析其運行結果是否滿足規格說明的要求，以及規格說明描述是否滿足用戶愿望。(4)修正和改進：根據修改意見進行修改。如果用修改原型的過程代替快速分析，就形成了原型開發的迭代過程。開發者和用戶在一次次的迭代過程中不斷將原型完善，以接近系統的最終要求。(5)判定原型完成：如果經過修改或改進的原型，得到參與者一致的認可，則原型開發的迭代過程可以結束。為此，應判斷是否已經掌握有關應用的實質，是否可以結束迭代周期等。判定的結果有兩個不同的轉向，一是繼續迭代驗證，二是進行詳細說明。(6)判斷原型細部是否說明：判斷組成原型的細部是否需要嚴格地加以說明。原型化方法允許對系統必要成分或不能通過模型進行說明的成分進行嚴格的詳細的說明。(7)原型細部的說明：對于那些不能通過原型說明的項目，仍需通過文件加以說明。嚴格說明的成分要作為原型化方法的模型編入詞典。(8)判定原型效果：考察用戶新加入的需求信息和細部說明信息，看其對模型效果有什么影響?是否會影響模塊的有效性?如果模型效果受到影響，甚至導致模型失效，則要進行修正和改進。(9)整理原型和提供文檔。總之，利用原型化技術，可為軟件的開發提供一種完整的、靈活的、近似動態的規格說明方法。2.原型的類型由于建立原型的目的不同，因此實現原型的途徑也有所不同，通常有以下三種類型：(1)探索型。這種原型目的是要弄清客戶對目標系統的要求，確定所希望的特性，并探討多種方案的可行性。(2)實驗型。這種原型用于大規模開發和實現之前，考核方案是否合適，規格說明是否可靠。(3)進化型。這種原型的目的不在于改進規格說明，而是將系統建造得容易處理變化，在改進原型的過程中，逐步將原型進化成最終系統。它將原型方法的思想擴展到軟件開發的全過程，適于滿足需求的變動。由于運用原型的目的和方式不同，因此在使用原型時可采取以下兩種不同的策略：(1)廢棄策略。先構造一個功能簡單而且質量要求不高的模型系統，針對這個模型系統反復進行分析修改，形成比較好的設計思想，據此設計出較完整、準確、一致、可靠的最終系統。系統構造完成后，原來的模型系統就被廢棄。探索型和實驗型屬于這種策略。(2)追加策略。先構造一個功能簡單而且質量要求不高的模型系統，并將其作為最終系統的核心，然后通過不斷地擴充修改，逐步追加新要求，最后發展成為最終系統。進化型屬于這種策略。采用什么形式、什么策略主要取決于軟件項目的特點和開發者的素質，以及支持原型開發的工具和技術。要根據實際情況的特點加以決策。3.原型分析方法的優點原型分析方法有以下優點：(1)增進軟件開發者和用戶對需求的理解，使比較含糊的具有不確定性的軟件需求(主要的功能性的需求)明確化。(2)軟件原型化方法提供了一種有力的學習手段。(3)使用原型化方法，可以容易地確定系統的性能，確認系統主要服務的可應用性，確認系統設計的可行性，確認系統最終作為產品。(4)軟件原型的最終版本，有的可以原封不動地稱為產品，有的略加修改就可以成為最終系統的一個組成部分，這樣有利于建成最終系統。4.原型建立技術原型建立技術有以下幾種：(1)可執行規格說明。它是基于需求規格說明的一種自動化技術，使用這種方法，人們可以直接觀察用語言規定的任何系統的功能和行為。(2)基于腳本的設計。腳本是用戶界面的原型。一個腳本用來模擬在系統運行期間用戶經歷的事件。它提供了輸入—處理—輸出的屏幕格式和有關對話的模型。因此，軟件開發者能夠給用戶顯示系統的逼真的視圖，使用戶得以判斷是否符合他的意圖。(3)自動程序設計在程序自動生成環境的支持下，利用計算機實現軟件的開發。它可以自動地或半自動地把用戶的非過程式問題規格說明轉換為某種高級語言程序。(4)專用語言。它是應用領域的模型化語言。在原型開發中使用專用語言，可方便用戶和軟件開發者對系統特性進行交流。(5)可復用的軟件。它是利用可復用的模塊，通過適當的組合，構造的原型系統。為了快速地構造原型，這些模塊首先必須有簡單而清晰的界面；其次它們應當盡量不依賴其他的模塊或數據結構；最后，它們應具有一些通用的功能。(6)簡化假設。它使設計者迅速得到一個簡化的系統。盡管這些假設可能實際上并不能成立，但它們可以使開發者的注意力集中在一些主要的方面。在修改一個文件時，可以假設這個文件確實存在。在存取文件時，待存取的記錄總是存在。一旦計劃中的系統滿足用戶所有的要求，就可以撤消這些假設，并追加一些細節。4.9軟件需求分析文檔4.9.1軟件需求規格說明和需求評審1.制定軟件需求規格說明的原則1979年由Balzer和Goldman提出了做出良好規格說明的8條原則。原則1：功能與實現分離，即描述要“做什么”而不是“怎樣實現”。原則?2：要求使用面向處理的規格說明語言，討論來自環境的各種刺激可能導致系統做出什么樣的功能性反應，來定義一個行為模型，從而得到“做什么”的規格說明。原則?3：如果目標軟件只是一個大系統中的一個元素，那么整個大系統也包括在規格說明的描述之中，描述該目標軟件與系統的其他系統元素交互的方式。原則4：規格說明必須包括系統運行的環境。原則5：系統規格說明必須是一個認識的模型，而不是設計或實現的模型。原則?6：規格說明必須是可操作的。規格說明必須是充分完