信息系統(tǒng)項目管理師-需求管理

1、信息系統(tǒng)項目管理師-需求管理（總分：6.00，做題時間：90分鐘）一、（總題數(shù)：1,分數(shù)：6.00）信息系統(tǒng)需求分析的任務(wù)不應(yīng)包括U U 6 /U /U。進行需求分析可使用多種工具，但U U 7 /U /U是不適用的。 （分數(shù)：6.00）（1）.« A.問題分解« B.可靠性與安全性要求« C.結(jié)構(gòu)化程序設(shè)計« D.確定邏輯模型（分數(shù)：1.00 ）A.B.C. VD.解析：.« A.數(shù)據(jù)流圖（DFD）* B.判定表« C.PAD 圖* D.數(shù)據(jù)詞典（分數(shù)：1.00 ）A.B.C. VD.解析：解析信息系統(tǒng)需求分析的目標是深入描述系統(tǒng)的

2、功能和性能，確定系統(tǒng)設(shè)計的約束和信息系統(tǒng)同 其他系統(tǒng)元素的接口，定義系統(tǒng)的其他有效性需求。也就是說，信息系統(tǒng)需求分析的任務(wù)是要解決“信息 系統(tǒng)做什么”的問題，而不是解決“如何做”的問題，因此不包括程序設(shè)計。在需求分析中，可使用的工 具主要有數(shù)據(jù)流圖（DFD）、數(shù)據(jù)詞典（DD）、結(jié)構(gòu)化語言、判定表及判定樹等。PAD圖（問題分析圖）主要用在信息系統(tǒng)設(shè)計過程中。（3）.以下關(guān)于需求管理的描述中，不正確的是 U U /U /U。* A.在獲取用戶需求完畢后，才能分析用戶需求* B.通過原型向用戶提供可視化的界面，用戶可以對需求做出自己的評價* C.需求驗證是為了確保需求說明書準確、完整地表達必要的質(zhì)量

3、特點D.當(dāng)完成需求說明書后，需求的變更是不可避免的（分數(shù)：1.00 ）A. VB.C.D.解析：解析在很多情形下，分析用戶需求是與獲取用戶需求并行的，主要通過建立模型的方式來描述用 戶的需求，為客戶、用戶、開發(fā)方等不同參與方提供一個交流的渠道。這些模型是對需求的抽象，以可視 化的方式提供一個易于溝通的橋梁。用戶需求的分析與獲取用戶需求有著相似的步驟，區(qū)別在于分析用戶 需求時使用模型來描述，以獲取用戶更明確的需求。分析用戶需求需要執(zhí)行下列活動：（1）以圖形表示的方式描述系統(tǒng)的整體結(jié)構(gòu)，包括系統(tǒng)的邊界與接口：（2）通過原型、頁面流或其他方式向用戶提供可視化的界面，用戶可以對需求做岀自己的評價：（3

4、）系統(tǒng)可行性分析，需求實現(xiàn)的技術(shù)可行性、環(huán)境分析、費用分析、時間分析等：（4）以模型描述系統(tǒng)的功能項、數(shù)據(jù)實體、外部實體、實體之間的關(guān)系、實體之間 的狀態(tài)轉(zhuǎn)換等方面的內(nèi)容。需求驗證是為了確保需求說明書準確、完整地表達必要的質(zhì)量特點。這里需要 強調(diào)的是，在需求驗證過程和評審過程中，客戶的參與是非常重要的。對需求文檔進行正式審查是保證產(chǎn) 品質(zhì)量的有效方法，組織一個由分析人員、客戶、設(shè)計人員、測試人員等組成的小組，對其進行仔細的檢 查和評審。如果有必要的話，還可以組織公司外的、行業(yè)內(nèi)的專家評審。一般的評審分為用戶評審和同行評審兩類。用戶和開發(fā)方對于項目內(nèi)容的描述，是以需求規(guī)格說明書作為基礎(chǔ)的：用戶驗

5、收的標準則是依 據(jù)需求規(guī)格說明書中的內(nèi)容來制定，可見，評審需求文檔時用戶的意見是第一位的。而同行評審的目的， 是在項目初期發(fā)現(xiàn)那些潛在的缺陷或錯誤，避免這些錯誤和缺陷遺漏到項目的后續(xù)階段。當(dāng)完成需求說明書后，需求的變更是不可避免的，如何以可控的方式管理信息系統(tǒng)的需求，對項目的順利進行有著重要的 意義。對于需求變更的管理，則主要使用需求變更流程和變更控制委員會兩個手段來實現(xiàn)。如果需要對每 項變更帶來的潛在影響及可能的成本費用、進度質(zhì)量進行評估，變更控制委員會應(yīng)與項目風(fēng)險承擔(dān)者進行 協(xié)商，以確定哪些需求可以變更。同時無論在開發(fā)階段還是測試階段，每項變更和需求都是可跟蹤的。（4）.下面關(guān)于需求變更的

6、敘述，不正確的是U U /U /U。« A.控制需求變更就是要拒絕用戶提岀的需求，以保證工程實現(xiàn)核心目標* B.只有建立了基線才能很好地實施變更«C.需求變更應(yīng)以規(guī)定格式提岀，并統(tǒng)一提交到變更控制委員會* D.應(yīng)定期評估需求變更對項目進度、成本、質(zhì)量等績效的影響（分數(shù)：1.00 ）A. VB.C.D.解析：解析需求變更應(yīng)以其可行性為基礎(chǔ)，對其有效控制非常重要，否則將會導(dǎo)致工期、成本、質(zhì)量不 斷擴大，對工程的成功影響較大。作為項目管理師要充分認識到這點，而且要將其重要性不斷灌輸給工程 的客戶、各施工方等所有干系人，特別是讓客戶認識到，有時控制需求變更不是拒絕用戶，而是為了保證

7、 工程實現(xiàn)核心目標，達到預(yù)期的成功目標，當(dāng)然控制需求變更也不是一味拒絕用戶提岀的需求。（5）.在各種不同的信息系統(tǒng)需求中，U U /U /U描述了用戶使用產(chǎn)品必須要完成的任務(wù)，可以在用例模型中予以說明。* A.業(yè)務(wù)需求* B.非功能需求* C.用戶需求* D.功能需求（分數(shù)：1.00 ）A.B.C. VD.解析：解析開發(fā)信息系統(tǒng)最為困難的部分就是準確說明開發(fā)什么。最為困難的概念性工作便是編寫出詳 細的技術(shù)需求，這包括所有面向用戶、面向機器和其他系統(tǒng)的接口。同時，這也是一旦岀錯，將最終會給 系統(tǒng)帶來極大困難的部分，并且以后再對它進行修改也極為困難。信息系統(tǒng)需求可以分為幾個層次，分別如下。業(yè)務(wù)需求

8、（Business Requirements）。反映組織結(jié)構(gòu)或客戶對系統(tǒng)、產(chǎn)品高層次的目標要求，它 們在項目視圖與范圍文檔中予以說明。（2）用戶需求（User Requirements）。描述用戶使用產(chǎn)品必須完成的任務(wù)，在用例文檔或方案場景 （scenario）說明中予以說明。（3）功能需求（Functional Requirements）。定 義開發(fā)人員必須實現(xiàn)的信息系統(tǒng)功能，使得用戶能完成他們的任務(wù)，從而滿足業(yè)務(wù)需求。（4）非功能需求（None-Functional Requirements）。描述系統(tǒng)展現(xiàn)給用戶的行為和執(zhí)行的操作等。包括：產(chǎn)品必須遵循的標準、規(guī)范和合約：外部界面的具體細節(jié)

9、；性能要求；設(shè)計或?qū)崿F(xiàn)的約束條件；質(zhì)量屬性。（6）.信息系統(tǒng)需求說明書是需求分析階段的成果，U U /U /U不是其應(yīng)包含的內(nèi)容。«A.數(shù)據(jù)描述«B.功能描述C.系統(tǒng)結(jié)構(gòu)描述D.性能描述（分數(shù)：1.00）A.B.C. VD.解析：解析信息系統(tǒng)需求說明書是需求分析階段的成果，不僅是系統(tǒng)測試和用戶文檔的基礎(chǔ)，也是所有 子系列項目規(guī)劃、設(shè)計和編碼的基礎(chǔ)。它應(yīng)該盡可能完整地描述系統(tǒng)預(yù)期的外部行為和用戶可視化行為。 除了設(shè)計和實現(xiàn)上的限制，信息系統(tǒng)需求規(guī)格說明不應(yīng)該包括設(shè)計、構(gòu)造、測試或工程管理的細節(jié)。可以 使用以下3種方法編寫信息系統(tǒng)需求規(guī)格說明。（1）用好的結(jié)構(gòu)化和自然語言編寫文本型文檔。（2）建立圖形化模型，這些模型可以描繪轉(zhuǎn)換過程、系統(tǒng)狀態(tài)和它們之間的變化、數(shù)據(jù)關(guān)系、邏輯流或?qū)ο箢惡退?們的關(guān)系。（3）編寫形式化規(guī)格說明，這可以通過使用數(shù)學(xué)上精確的形式化邏輯語言來定義需求。由于形式化規(guī)格說明具有很強的嚴密性和精確度，因此，所使用