【文章內容簡介】 在不進行直接指導的前提下，讓用戶進行檢查與評價。從而達到需求分析的準確性。分析員通過需求分析，逐步細化對軟件的要求，描述軟件要處理的數(shù)據域，并給軟件開發(fā)提供一種可轉化為數(shù)據設計、結構設計和過程設計的數(shù)據和功能表示。在軟件完成后，制定的軟件規(guī)格說明還要為評價軟件質量提供依據。需求分析的任務開發(fā)軟件系統(tǒng)最為困難的部分就是準確說明開發(fā)什么。最為困難的概念性工作便是編寫出詳細技術需求，這包括所有面向用戶、面向機器和其它軟件系統(tǒng)的接口。同時這也是一旦做錯，將最終會給系統(tǒng)帶來極大損害的部分，并且以后再對它進行修改也極為困難。目前，國內產品的龐雜，一家企業(yè)可能有幾個系統(tǒng)并立運行，它們之間接口是系統(tǒng)開發(fā)人員最頭痛的問題。對于商業(yè)最終用戶應用程序，企業(yè)信息系統(tǒng)和軟件作為一個大系統(tǒng)的一部分的產品是顯而易見的。但是對于我們開發(fā)人員來說，并沒有編寫出客戶認可的需求文檔，我們如何知道項目于何時結束？而如果我們不知道什么對客戶來說是重要的，那我們又如何能使客戶感到滿意呢？然而，即便并非出于商業(yè)目的的軟件需求也是必須的。例如庫、組件和工具這些供開發(fā)小組內部使用的軟件。當然你可能偶爾勿需文檔說明就能與其他人意見較為一致，但更常見的是出現(xiàn)重復返工這種不可避免的后果，而重新編制代碼的代價遠遠超過重寫一份需求文檔的代價，這些血的教訓正在國內的軟件開發(fā)者身上發(fā)生。近來，我遇到一個開發(fā)小組開發(fā)包括代碼編輯器在內的一套內部使用的計算機輔助軟件。不幸的是，當他們開發(fā)完這個工具后，發(fā)現(xiàn)這個工具不能打印出源代碼文件，使用者當然希望有這個功能。結果這個小組只好手工抄寫源代碼文檔以供代碼檢查。這說明那怕需求明確無誤并構思準確，如果我們沒有編寫文檔，軟件達不到期望目標也只能是咎由自取了。相反的情況，我曾見一個要集成到“錯誤跟蹤系統(tǒng)”中的簡單界面寫了一頁需求說明。而操作系統(tǒng)系統(tǒng)管理員在為處理腳本時發(fā)現(xiàn)簡單的一張需求清單竟是如此有用。他們依據需求對系統(tǒng)進行測試時，此系統(tǒng)不僅非常清晰地實現(xiàn)了所有必需功能，而且未發(fā)現(xiàn)任何錯誤。事實上，需求文檔在開發(fā)過程中一直起指導作用。需求的類型下面這些定義是需求工程領域中常見術語的定義。軟件需求包括三個不同的層次：業(yè)務需求、用戶需求和功能需求（也包括非功能需求）。1．業(yè)務需求（business requirement）反映了組織機構或客戶對系統(tǒng)、產品高層次的目標要求，它們在項目視圖與范圍文檔中予以說明。2．用戶需求(user requirement)文檔描述了用戶使用產品必須要完成的任務，這在使用實例（usecase）文檔或方案腳本說明中予以說明。3．功能需求(functional requirement)定義了開發(fā)人員必須實現(xiàn)的軟件功能，使得用戶能完成他們的任務，從而滿足了業(yè)務需求。在軟件需求規(guī)格說明書（SRS）中說明的功能需求充分描述了軟件系統(tǒng)所應具有的外部行為。軟件需求規(guī)格說明在開發(fā)、測試、質量保證、項目管理以及相關項目功能中都起了重要的作用。對一個大型系統(tǒng)來說，軟件功能需求也許只是系統(tǒng)需求的一個子集，因為另外一些可能屬于子系統(tǒng)（或軟件部件）。作為功能需求的補充，軟件需求規(guī)格說明還應包括非功能需求，它描述了系統(tǒng)展現(xiàn)給用戶的行為和執(zhí)行的操作等。它包括產品必須遵從的標準、規(guī)范和合約；外部界面的具體細節(jié)；性能要求；設計或實現(xiàn)的約束條件及質量屬性。所謂約束是指對開發(fā)人員在軟件產品設計和構造上的限制。質量屬性是通過多種角度對產品的特點進行描述，從而反映產品功能。多角度描述產品對用戶和開發(fā)人員都極為重要。下面以一個字處理程序為例來說明需求的不同種類。業(yè)務需求可能是：“用戶能有效地糾正文檔中的拼寫錯誤”，該產品的包裝盒封面上可能會標明這是個滿足業(yè)務需求的拼寫檢查器。而對應的用戶需求可能是“找出文檔中的拼寫錯誤并通過一個提供的替換項列表來供選擇替換拼錯的詞”。同時，該拼寫檢查器還有許多功能需求，如找到并高亮度提示錯詞的操作；顯示提供替換詞的對話框以及實現(xiàn)整個文檔范圍的替換。從以上定義可以發(fā)現(xiàn)，需求并未包括設計細節(jié)、實現(xiàn)細節(jié)、項目計劃信息或測試信息。需求與這些沒有關系，它關注的是充分說明你究竟想開發(fā)什么。項目也有其它方面的需求，如開發(fā)環(huán)境需求或發(fā)布產品及移植到支撐環(huán)境的需求。第四篇：軟件需求分析考試資料需求分析的最終結果是需求規(guī)格說明書。需求分析中開發(fā)人員要從用戶那里解決的最重要的問題是讓軟件做什么。需求規(guī)格說明書中的內容不應該包括對算法的詳細過程的描述。需求規(guī)格說明書的作用不應包括軟件可行性研究的依據。關于面向對象方法中消息的敘述，不正確的是操作系統(tǒng)不斷向應用程序發(fā)送消息，但應用程序不能向操作系統(tǒng)發(fā)送消息。面向對象技術中，對象是類的實例，對象有三種成分標識、屬性、方法（或操作）軟件需求分析階段的工作，可以分成以下四個方面對問題的識別、分析與綜合、制定規(guī)格說明以及需求分析評審。軟件需求規(guī)格說明書的內容不應該包括對算法的詳細過程的描述。產品特性可以稱為質量屬性，在眾多質量屬性，對于開發(fā)人員來說重要的屬性有哪些？可維護性、可移植性、可重用性、可測試性求包括11個方面的內容，其中網絡和操作系統(tǒng)的要求屬于環(huán)境需求，如何隔離用戶之間的數(shù)據屬于安全保密需求，執(zhí)行速度、相應時間及吞吐量屬于性能需求，規(guī)定系統(tǒng)平均出錯時間屬于質量保證。1需求分析過程應該建立3中模型，他們分別是數(shù)據模型、功能模型、行為模型，以下幾種圖形中，數(shù)據流圖（DFD）屬于功能模型，實體聯(lián)系圖（ERD）屬于數(shù)據模型，狀態(tài)轉換圖（STD）屬于行為模型。1常用的需求分析方法有：面向數(shù)據流的結構化分析方法（SA），面向對象的分析的分析方法（OOA），下列(D)不是結構化分析方法的圖形工具。A 決策樹B 數(shù)據流圖C數(shù)據字典D快速原型1軟件開發(fā)中，原型是軟件的一個早期可運行的版本，它反映最終系統(tǒng)的部分重要特性，其中，探索型和實驗型用完可以丟棄，而進化型圍繞原型修改、增加。1數(shù)據流圖用于描述數(shù)據的處理過程。1DFD 的基本符號不包括下列哪種？（A）。A 數(shù)據字典B 加工C 外部實體D 數(shù)據流E 數(shù)據存儲文件1DD的主要字典條目包括以下哪種（E）A 數(shù)據流B文件C 數(shù)據項D加工E以上都是1常用的動態(tài)分析方法不包括以下哪種（B）A 狀態(tài)遷移圖B 層次方框圖C 時序圖D Petri網1需求分析階段的文檔包括以下哪些（E）A 軟件需求規(guī)格說明書B 數(shù)據要求說明書C 初步的用戶手冊D 修改、完善與確定開發(fā)實施計劃E 以上都是1需求驗證應該從下述幾個方面進行驗證：（C）A 可靠性、可用性、易用性、重用性B 可維護性、可移植性、可重用性、可測試性C 一致性、現(xiàn)實性、完整性、有效性 D 功能性、非功能性風險管理的要素包括哪些（D）A 風險評價B 風險避免C 風險控制D 以上都是2下列描述中錯誤的是（D）A 每一個集成的需求變更必須能跟蹤控制到一個經核準的變更請求。B 變更過程應該做