軟件需求參考答案

1、軟件需求工程隨堂測試參考答案1.（15分）為什么在軟件開發(fā)項目中維護階段發(fā)現錯誤的修復成本是需求階段發(fā)現錯誤修復成本的100倍到200倍（3-5）？詳細說明這些成本的主要構成（10-12）？答：1、因為維護是建立在需求、設計、編碼等的基礎之上的，如果在維護階段發(fā)現錯誤，那么要修復，或許就要從編碼、設計、需求等階段開始修復，隨之伴隨而來的，可能就是要重新進行規(guī)格說明，重新進行設計，重新進行編碼等，這就成倍的增加了修復的成本。如下圖所示，該圖是許多公司項目生命周期各階段修復成本的度量和計算，由圖可得，如果把編碼階段發(fā)現和修復一個錯誤所需要的努力用“1”個成本單元表示的話，那么，需求階段的錯誤修復成

2、本是它的510，而在維護階段發(fā)現和修復一個錯誤的成本超過20倍，因此，軟件開發(fā)項目中維護階段發(fā)現錯誤的修復成本是需求階段發(fā)現錯誤修復成本的100倍到200倍。2、 這些成本由以下方面構成：（1）重新進行規(guī)格說明:（2）重新設計；（3）重新編碼；（4）重新測試；（5）版本升級：用一個修正后的版本來替代有缺陷的版本；（6）糾正活動：消除由于不正確的系統(tǒng)錯誤造成的一切危害，這可能涉及到償還不滿用戶的經濟損失，以及重新運行系統(tǒng)所付出的代價等；（7）報廢：包括以最好的意圖完成的代碼、設計和測試用例，當發(fā)現它們是依據于不正確的需求時則不得不全部丟棄?。?）收回有缺陷的軟件版本以及相關的用戶手冊。有時軟件可

3、能會已經嵌入到數字手表、微波爐或汽車等產品中，這時所收回的內容也包括有形的產品和嵌入該系統(tǒng)的軟件；（9）保修成本；（10）產品賠償：客戶可能要求對有缺陷軟件造成的損害進行賠償；（11）公司代表到客戶那里重新安裝軟件所必須支付的服務成本；（12）建檔成本。2.（12分）什么是軟件需求（5）？說明軟件需求的層次并描述其相互關系（7）。答：1、IEEE軟件工程標準詞匯表(1997年)中定義需求為：（1）用戶解決問題或達到目標所需的條件或權能(Capability)。（2）系統(tǒng)或系統(tǒng)部件要滿足合同、標準、規(guī)范或其它正式規(guī)定文檔所需具有的條件或權能。（3）一種反映上面(1)或(2)所描述的條件或權能的文

4、檔說明。或答： 軟件需求是指用戶對目標軟件系統(tǒng)在功能、行為、性能、設計約束等方面的期望。通過對問題及其環(huán)境的理解與分析，為問題涉及的信息、功能及系統(tǒng)行為建立模型，將用戶需求精確化、完全化，最終形成需求規(guī)格說明，這一系列的活動即構成軟件開發(fā)生命周期的需求分析階段。2、 軟件需求的三個不同層次之間的關系可用下圖表示（圖正確得4分）： 軟件需求包括三個不同的層次:（1） 業(yè)務需求 (business requirement)：反映了組織機構或客戶對系統(tǒng)、產品高層次的目標要求，它們在項目視圖與范圍文檔中予以說明。（2） 用戶需求(user requirement)：文檔描述了用戶使用產品必須要完成的任

5、務，這在使用實例(use case，簡稱用例)文檔或方案腳本(scenario)說明中予以說明。（3） 功能需求(functional requirement)：定義了開發(fā)人員必須實現的軟件功能，使得用戶能完成他們的任務，從而滿足了業(yè)務需求。 此外，還包括系統(tǒng)需求和其他需求，其他需求分為質量屬性或其他非功能需求和設計約束等。3.（15分）選定一不少于四種用戶類的簡單項目，論述該項目的視圖陳述（4），確定并分析項目的用戶類及特征（4），給出系統(tǒng)用例模型（4），并繪制系統(tǒng)關聯圖（3）。答：新聞發(fā)布系統(tǒng)1、項目陳述如下：“新聞發(fā)布系統(tǒng)”可使任何人方便的對新聞內容進行瀏覽，任何人可以通過注冊成為會員，

6、會員可以享有對新聞和評論進行評論的權限，同時會員也可以對自己的個人信息進行修改，管理員登錄系統(tǒng)后，可以在后臺發(fā)布并管理新聞，后臺的系統(tǒng)管理員可以管理新聞、評論和會員信息。系統(tǒng)可以對新聞進行有效的管理，包括新聞的各種內容、屬性還有評論和會員信息等，通過不同用戶所擁有的管理權限，方便對新聞等信息進行刪除更改，同時用戶通過登錄功能可以幫助用戶隨時了解新聞狀態(tài)，保持新聞的時效性和正確性，同時擴大新聞的閱讀量和傳播率，避免新聞發(fā)布可能產生的管理混亂，嚴格用戶職責，做到責任追溯，評論追溯等科學化管理。2、用戶類及特征分析（略） 3、用例模型（參考）： 4、系統(tǒng)關聯圖：4（12）什么是軟件原型（3）？使用原

7、型的目的有哪些（3）？說明軟件原型的種類和使用原型技術應遵守的主要原則（6）。軟件原型是一種技術，可以利用這種技術減少客戶對產品不滿意的風險。一個軟件原型是所提出的新產品的部分實現，通過使用原型可以使開發(fā)小組正確理解需求，發(fā)現和解決在產品開發(fā)的早期階段不確定的問題以及需求中的二義性和不完整性問題，最終明確如何最好地實現這些需求并最終明確并完善需求、探索設計選擇方案、發(fā)展為最終的產品。同時用戶、經理和其他非技術項目風險承擔者發(fā)現在確定和開發(fā)產品時，原型可以使他們的想象更具體化。使用原型有三個主要目的： 明確并完善需求: 原型作為一種需求工具，它是對部分系統(tǒng)的初步實現。用戶對原型的評價可以指出需求

8、中存在的問題，在開發(fā)真正產品之前，可以最低的費用來解決這些問題。 探索設計選擇方案: 原型作為一種設計工具，用它可以探索不同的用戶界面技術，使系統(tǒng)達到最佳的易用性，并且可以評價可能的技術方案。 發(fā)展為最終的產品原型: 作為一種構造工具，是產品最初子集的完整功能實現，通過一系列小規(guī)模的開發(fā)循環(huán)，你可以完成整個產品的開發(fā)。軟件原型的種類：水平原型和垂直原型、拋棄型原型和進化型原型、電子原型和書面原型。通過水平和垂直原型讓用戶體驗或者驗證需求實現的具體行為（或操作）以及部分確定性的功能，而拋棄型和進化型原型則針對不確定性的問題通過原型進行探討和研究最終剔除掉需求的不確定性。為了幫助開發(fā)者在需求開發(fā)過

9、程中建立有效的原型，請遵循如下原則：l 項目計劃中應包括原型風險。安排好開發(fā)、評價和可能的修改原型的時間。l 計劃開發(fā)多個原型。因為很少能一次成功。l 盡快并且廉價地建立拋棄型原型。用最少的投資開發(fā)那些用于回答問題和解決需求的不確定性的原型。不要努力去完善一個拋棄型原型的用戶界面。l 在拋棄型原型中不應含有代碼注釋、輸入數據有效性檢查、保護性編碼技術，或者錯誤處理的代碼。 l 對于已經理解的需求不要建立原型。l 不能隨意地增加功能。當一個簡單的拋棄型原型達到原型目的時，就不應該隨便擴充它的功能。l 不要從水平原型的性能推測最終產品的性能。原型可能沒有運行在最終產品所處的特定環(huán)境中，并且你開發(fā)原

10、型的工具與開發(fā)產品的工具在效率上是存在差異的。l 在原型屏幕顯示和報表中使用合理的模擬數據。那些評價原型的用戶會受不現實數據的影響而不能把原型看成真正產品的模型。l 不要期望原型可以代替需求文檔。原型只是暗示了許多后臺功能，因此必須把這些功能寫入軟件需求規(guī)格說明，使之完善、詳細并且可以有案可稽。 5.（12）簡述軟件需求的幾種典型來源。典型的軟件需求來源:l 與潛在用戶進行交談和討論l 描述現有產品或競爭產品的文檔l 系統(tǒng)需求規(guī)格說明l 現有系統(tǒng)的問題報告和改進要求l 市場調查和用戶問卷調查l 觀察用戶如何工作l 用戶工作的情景分析l 事件和響應并做適當的解釋。6 （12分）本課程中涉及的主要

11、圖形化分析方法有哪些（5）？繪制系統(tǒng)數據流圖應遵循哪些原則（7）?答：1、本課程中涉及的主要的圖形化分析方法有：用例圖，數據流圖，實體聯系圖，狀態(tài)轉換圖，對話圖，類圖。2、 繪制系統(tǒng)數據流程圖應遵循的原則有：（1） 把數據存儲放在0層數據流圖或更低層子圖上，不要放在關聯圖上；（2） 過程是通過數據存儲進行通訊，而不是從一個過程直接流到另一過程。類似地，數據不能直接由一個數據存儲直接流到另一個數據存儲，它必須通過一個過程圓圈；（3） 使用數據流圖時，不要試圖讓數據流圖反映處理的順序；（4） 用一個簡明的動作命名過程：動詞+對象。數據流圖中所用的名字應對客戶有意義，并且與業(yè)務或問題域相關；（5）

12、對過程的編號要唯一且具有層次性。在0層圖上，每個過程的編號用整數表示。如果你為過程3創(chuàng)建子圖，則子圖中的過程編號應表示為3.1，3.2等等；（6）不要在一個圖中繪制多達7-10個以上的過程，否則就很難繪制、更改和理解；（6） 不要使某些圓圈只有輸入或只有輸出。數據流圖中圓圈所代表的處理過程通常要求既有輸入又有輸出。7.（12分）優(yōu)秀需求及需求規(guī)格說明應具有哪些主要特性（5）？圖示并論述需求審查的過程(4)，并說明需求規(guī)格說明書進入和退出審查的標準（3）。答：主要特性:完整性，正確性，可行性，必要性，劃分優(yōu)先級，無二義性，可驗證性，一致性，可修改性，可跟蹤性。需求評審要經歷如下過程：（1） 規(guī)劃

13、。作者和調解者協同對審查進行規(guī)劃，以決定誰該參加審查，審查員在召開審查會之前應收到什么材料并且需要召開幾次審查會。（2） 總體會議?？傮w會議可以為審查員提供了解會議的信息，包括他們要審查的材料的背景，作者所作的假設和作者的特定審查目標。如果所有的審查員對要審查的項目都很熟悉，那么就可以省略本次總體會議。（3） 準備。在正式審查的準備階段，每個審查員以典型缺陷清單為指導，檢查產品可能出現的錯誤，并提出問題。（4） 審查會議。在審查會進行過程中，讀者通過軟件需求規(guī)格說明指導審查小組，一次解釋一個需求。當審查員提出可能的錯誤或其它問題時，記錄員就記錄這些內容，其形式可以成為需求作者的工作項列表。會議

14、的目的是盡可能多地發(fā)現需求規(guī)格說明中的重大缺陷。另外，審查會不應該超過兩個小時，如果需要更多的時間，就另外再安排一次會議。（5） 重寫。幾乎每一個質量控制活動都可能發(fā)現一些需求缺陷。因此，作者必須在審查會之后，安排一段時間用于重寫文檔，解決需求中的二義性、消除模糊性，并且為成功開發(fā)一個項目打下堅實的基礎。（6） 重審。這是審查工作的最后一步，調解者或指派人單獨重審由作者重寫的需求規(guī)格說明。重審確保了所有提出的問題都能得到解決，并且正確修改了需求的錯誤。重審結束了審查的全過程并且可以使調解者做出判斷：是否已滿足審查的退出標準。具體流程如下圖：需求規(guī)格說明書進入審查的標準：（1） 文檔符合標準模板

15、；（2） 文檔已經做過拼寫檢查和語法檢查；（3） 作者已經檢查了文檔在版面安排上所存在的錯誤；（4） 已經獲得了審查員所需要的先前或參考文檔，例如系統(tǒng)需求規(guī)格說明；（5） 在文檔中打印了行序號以方便在審查中對特定位置的查閱；（6） 所有未解決的問題都被標記為TBD(待確定)；（7） 包括了文檔中使用到的術語詞匯表。需求規(guī)格說明書退出審查的標準：（1） 已經明確闡述了審查員提出的所有問題；（2） 已經正確修改了文檔；（3） 修訂過的文檔已經進行了拼寫檢查和語法檢查；（4） 所有TBD的問題已經全部解決，或者已經記錄下每個待確定問題的解決過程，目標日期和提出問題的人；（5） 文檔已經登記入項目的配置管理系統(tǒng)；（6） 檢查是否已將審查過的資料送到有關收集處。8.（10）需求管理的主要活動有哪些（6），給出需求變更控制過程描述（4）。答: 需求管理包括在工程進展過程中維持需求約定集成性和精確性的所有活動如下:變更控制l 建議變更l 分析影響l 決定變更l 更新需求文檔l 變更計劃l 測量需求的穩(wěn)定性版本控制l 定義版本標識方法l