2025年全國(guó)計(jì)算機(jī)技術(shù)與軟件專業(yè)技術(shù)資格（水平）考試軟件需求工程師試卷考試時(shí)間：______分鐘總分：______分姓名：______一、單項(xiàng)選擇題（共25題，每題2分，共50分。每題只有一個(gè)正確答案，請(qǐng)?jiān)诖痤}卡上涂寫(xiě)相應(yīng)選項(xiàng)字母。）1.在需求獲取過(guò)程中，以下哪種方法最適用于探索用戶潛藏的需求？A.問(wèn)卷調(diào)查B.用戶訪談C.文檔分析D.競(jìng)品分析2.下面哪個(gè)術(shù)語(yǔ)最能描述“用戶通過(guò)點(diǎn)擊按鈕完成某項(xiàng)操作”這類需求？A.功能性需求B.非功能性需求C.業(yè)務(wù)規(guī)則D.數(shù)據(jù)模型3.需求優(yōu)先級(jí)排序時(shí)，MoSCoW方法中“Musthave”代表什么？A.必須實(shí)現(xiàn)的功能B.可以考慮添加的功能C.以后版本再考慮的功能D.可選功能4.繪制用例圖時(shí)，以下哪個(gè)元素代表系統(tǒng)外部參與者？A.用例B.系統(tǒng)C.直線D.矩形邊界5.“系統(tǒng)響應(yīng)時(shí)間不超過(guò)2秒”屬于哪種需求？A.性能需求B.安全需求C.可用性需求D.可靠性需求6.下面哪種文檔最適合記錄業(yè)務(wù)規(guī)則？A.需求規(guī)格說(shuō)明書(shū)B(niǎo).用戶手冊(cè)C.系統(tǒng)設(shè)計(jì)文檔D.測(cè)試計(jì)劃7.需求變更控制流程中，誰(shuí)負(fù)責(zé)評(píng)估變更的可行性？A.項(xiàng)目經(jīng)理B.產(chǎn)品經(jīng)理C.技術(shù)負(fù)責(zé)人D.測(cè)試工程師8.原型法適用于以下哪種類型的需求？A.復(fù)雜系統(tǒng)需求B.簡(jiǎn)單功能需求C.數(shù)據(jù)密集型需求D.標(biāo)準(zhǔn)化需求9.下面哪個(gè)術(shù)語(yǔ)描述“用戶必須通過(guò)驗(yàn)證才能訪問(wèn)敏感數(shù)據(jù)”？A.訪問(wèn)控制B.容錯(cuò)機(jī)制C.數(shù)據(jù)加密D.事務(wù)管理10.需求評(píng)審會(huì)議中，以下哪個(gè)角色最應(yīng)該提出業(yè)務(wù)角度的問(wèn)題？A.開(kāi)發(fā)工程師B.測(cè)試工程師C.產(chǎn)品經(jīng)理D.系統(tǒng)架構(gòu)師11.用例描述中，“參與者：張三”這句話代表什么？A.張三是系統(tǒng)管理員B.張三是用例作者C.張三是系統(tǒng)用戶D.張三是需求分析師12.下面哪種方法最適合驗(yàn)證需求文檔的完整性？A.代碼審查B.用戶驗(yàn)收測(cè)試C.需求確認(rèn)簽字D.復(fù)盤會(huì)議13.“系統(tǒng)支持多語(yǔ)言切換”屬于哪種非功能性需求？A.性能需求B.可用性需求C.可移植性需求D.安全需求14.需求跟蹤矩陣的主要作用是什么？A.管理需求版本B.記錄需求狀態(tài)C.驗(yàn)證需求實(shí)現(xiàn)D.排序需求優(yōu)先級(jí)15.下面哪個(gè)術(shù)語(yǔ)描述“系統(tǒng)必須能在斷電后恢復(fù)數(shù)據(jù)”？A.數(shù)據(jù)備份B.日志記錄C.恢復(fù)能力D.冗余設(shè)計(jì)16.需求沖突時(shí)，以下哪種方法最有效？A.拋棄矛盾需求B.按客戶意愿解決C.協(xié)商折中方案D.報(bào)告給高層決策17.繪制活動(dòng)圖時(shí)，菱形框代表什么？A.初始狀態(tài)B.結(jié)束狀態(tài)C.決策點(diǎn)D.處理過(guò)程18.下面哪種文檔需要包含用例編號(hào)？A.需求規(guī)格說(shuō)明書(shū)B(niǎo).用戶故事卡C.測(cè)試用例D.會(huì)議紀(jì)要19.需求驗(yàn)證過(guò)程中，以下哪個(gè)工具最常用？A.UML工具B.版本控制系統(tǒng)C.需求管理軟件D.文檔編輯器20.“系統(tǒng)必須符合GDPR法規(guī)”屬于哪種需求？A.合規(guī)性需求B.性能需求C.安全需求D.可用性需求21.下面哪個(gè)術(shù)語(yǔ)描述“用戶輸入錯(cuò)誤密碼時(shí)系統(tǒng)會(huì)顯示錯(cuò)誤提示”？A.反饋機(jī)制B.輸入驗(yàn)證C.錯(cuò)誤處理D.認(rèn)證過(guò)程22.需求優(yōu)先級(jí)排序時(shí)，以下哪種方法最客觀？A.MoSCoW法B.Kano模型C.成本效益分析D.業(yè)務(wù)價(jià)值評(píng)估23.繪制數(shù)據(jù)流圖時(shí)，箭頭代表什么？A.數(shù)據(jù)流向B.處理過(guò)程C.數(shù)據(jù)存儲(chǔ)D.系統(tǒng)邊界24.需求變更時(shí)，以下哪個(gè)步驟最關(guān)鍵？A.提交變更請(qǐng)求B.評(píng)估變更影響C.執(zhí)行變更操作D.測(cè)試變更結(jié)果25.下面哪種方法最適合獲取隱性需求？A.文檔分析B.用戶訪談C.觀察法D.競(jìng)品分析二、多項(xiàng)選擇題（共10題，每題2分，共20分。每題有多個(gè)正確答案，請(qǐng)?jiān)诖痤}卡上涂寫(xiě)相應(yīng)選項(xiàng)字母。）1.下面哪些屬于需求獲取方法？A.問(wèn)卷調(diào)查B.用戶訪談C.競(jìng)品分析D.文檔分析E.觀察法2.需求規(guī)格說(shuō)明書(shū)通常包含哪些內(nèi)容？A.功能性需求B.非功能性需求C.業(yè)務(wù)規(guī)則D.數(shù)據(jù)模型E.用例圖3.下面哪些屬于非功能性需求？A.性能需求B.安全需求C.可用性需求D.可靠性需求E.合規(guī)性需求4.需求變更控制流程通常包括哪些步驟？A.提交變更請(qǐng)求B.評(píng)估變更影響C.審批變更請(qǐng)求D.執(zhí)行變更操作E.驗(yàn)證變更結(jié)果5.繪制用例圖時(shí)，哪些元素是必須的？A.系統(tǒng)B.參與者C.用例D.直線E.矩形邊界6.需求驗(yàn)證方法有哪些？A.代碼審查B.用戶驗(yàn)收測(cè)試C.需求確認(rèn)簽字D.復(fù)盤會(huì)議E.需求評(píng)審7.下面哪些屬于需求跟蹤矩陣的列？A.需求編號(hào)B.需求描述C.來(lái)源文檔D.實(shí)現(xiàn)狀態(tài)E.測(cè)試用例8.需求管理工具通常支持哪些功能？A.需求版本控制B.變更跟蹤C(jī).優(yōu)先級(jí)排序D.跟蹤矩陣E.自動(dòng)化測(cè)試9.繪制活動(dòng)圖時(shí)，哪些元素是常見(jiàn)的？A.初始狀態(tài)B.結(jié)束狀態(tài)C.處理過(guò)程D.決策點(diǎn)E.分支/合并10.下面哪些屬于合規(guī)性需求？A.GDPRB.HIPAAC.ISO27001D.PCIDSSE.ADA（注：實(shí)際考試中每題只有一個(gè)正確答案，此處為多項(xiàng)選擇題示例）三、判斷題（共10題，每題1分，共10分。請(qǐng)判斷下列說(shuō)法的正誤，在答題卡上涂寫(xiě)相應(yīng)選項(xiàng)字母。）1.需求規(guī)格說(shuō)明書(shū)一旦確定就不能修改。（×）2.用戶訪談是獲取隱性需求最有效的方法之一。（√）3.非功能性需求比功能性需求更重要。（×）4.用例圖可以完全替代需求規(guī)格說(shuō)明書(shū)。（×）5.需求跟蹤矩陣可以確保所有需求都被實(shí)現(xiàn)。（×）6.需求變更控制流程只需要項(xiàng)目經(jīng)理參與。（×）7.繪制數(shù)據(jù)流圖時(shí)，數(shù)據(jù)存儲(chǔ)用矩形表示。（×）8.需求優(yōu)先級(jí)排序時(shí)，“Couldhave”代表可選功能。（√）9.需求評(píng)審會(huì)議只需要開(kāi)發(fā)人員和測(cè)試人員參加。（×）10.合規(guī)性需求不屬于需求規(guī)格說(shuō)明書(shū)的范疇。（×）四、簡(jiǎn)答題（共5題，每題4分，共20分。請(qǐng)簡(jiǎn)要回答下列問(wèn)題，答案寫(xiě)在答題紙上。）1.簡(jiǎn)述需求獲取的常用方法及其適用場(chǎng)景。答：需求獲取的常用方法包括：-問(wèn)卷調(diào)查：適用于收集大量用戶的普遍性需求，但難以獲取隱性需求。-用戶訪談：適用于探索用戶的真實(shí)需求和痛點(diǎn)，但需要投入較多時(shí)間和精力。-競(jìng)品分析：適用于了解市場(chǎng)現(xiàn)狀和競(jìng)爭(zhēng)對(duì)手的產(chǎn)品特點(diǎn)，但需要結(jié)合自身業(yè)務(wù)進(jìn)行判斷。-文檔分析：適用于已有相關(guān)文檔的情況，但可能存在信息過(guò)時(shí)或不完整的問(wèn)題。-觀察法：適用于了解用戶實(shí)際操作習(xí)慣，但需要確保觀察環(huán)境的真實(shí)性。2.解釋什么是需求規(guī)格說(shuō)明書(shū)，并說(shuō)明其主要內(nèi)容。答：需求規(guī)格說(shuō)明書(shū)是記錄系統(tǒng)需求的正式文檔，用于指導(dǎo)開(kāi)發(fā)、測(cè)試和驗(yàn)收等階段。其主要內(nèi)容包括：-功能性需求：描述系統(tǒng)應(yīng)具備的功能和特性。-非功能性需求：描述系統(tǒng)的性能、安全、可用性等方面的要求。-業(yè)務(wù)規(guī)則：描述系統(tǒng)應(yīng)遵循的業(yè)務(wù)邏輯和規(guī)則。-數(shù)據(jù)模型：描述系統(tǒng)中的數(shù)據(jù)結(jié)構(gòu)和關(guān)系。-用例圖：描述系統(tǒng)與用戶之間的交互過(guò)程。3.簡(jiǎn)述需求變更控制流程的主要步驟。答：需求變更控制流程的主要步驟包括：-提交變更請(qǐng)求：由需求提出者提交變更請(qǐng)求，說(shuō)明變更原因和內(nèi)容。-評(píng)估變更影響：由項(xiàng)目團(tuán)隊(duì)評(píng)估變更對(duì)項(xiàng)目進(jìn)度、成本和風(fēng)險(xiǎn)的影響。-審批變更請(qǐng)求：由項(xiàng)目經(jīng)理或相關(guān)負(fù)責(zé)人審批變更請(qǐng)求，決定是否接受變更。-執(zhí)行變更操作：由開(kāi)發(fā)團(tuán)隊(duì)執(zhí)行變更，確保變更內(nèi)容得到正確實(shí)現(xiàn)。-驗(yàn)證變更結(jié)果：由測(cè)試團(tuán)隊(duì)驗(yàn)證變更結(jié)果，確保變更滿足需求。4.解釋什么是用例圖，并說(shuō)明其主要元素。答：用例圖是描述系統(tǒng)與用戶之間交互過(guò)程的圖形化表示，主要用于展示系統(tǒng)的功能需求和用戶角色。其主要元素包括：-系統(tǒng)：用矩形表示，代表被開(kāi)發(fā)的系統(tǒng)。-參與者：用小人圖標(biāo)表示，代表與系統(tǒng)交互的用戶或外部系統(tǒng)。-用例：用橢圓形表示，代表系統(tǒng)提供的功能或服務(wù)。-直線：用于連接參與者和用例，表示參與者可以執(zhí)行該用例。5.簡(jiǎn)述需求驗(yàn)證的目的和方法。答：需求驗(yàn)證的目的是確保需求文檔的完整性、正確性和一致性，避免開(kāi)發(fā)過(guò)程中出現(xiàn)偏差。常用方法包括：-需求評(píng)審：由項(xiàng)目團(tuán)隊(duì)成員對(duì)需求文檔進(jìn)行評(píng)審，提出改進(jìn)意見(jiàn)。-用戶驗(yàn)收測(cè)試：由用戶代表對(duì)需求進(jìn)行驗(yàn)收測(cè)試，確保需求滿足業(yè)務(wù)需求。-需求確認(rèn)簽字：由需求提出者和實(shí)現(xiàn)者簽字確認(rèn)，表示對(duì)需求的一致性達(dá)成共識(shí)。-復(fù)盤會(huì)議：定期召開(kāi)會(huì)議，回顧需求文檔的執(zhí)行情況，及時(shí)調(diào)整和改進(jìn)。五、論述題（共2題，每題10分，共20分。請(qǐng)結(jié)合實(shí)際案例或場(chǎng)景，詳細(xì)回答下列問(wèn)題，答案寫(xiě)在答題紙上。）1.結(jié)合實(shí)際案例，論述需求獲取過(guò)程中如何處理需求沖突。答：需求沖突是需求獲取過(guò)程中常見(jiàn)的問(wèn)題，需要通過(guò)協(xié)商和折中來(lái)解決。例如，某電商系統(tǒng)在需求獲取過(guò)程中發(fā)現(xiàn)，銷售部門希望系統(tǒng)支持更多促銷活動(dòng)，而財(cái)務(wù)部門希望系統(tǒng)嚴(yán)格控制折扣上限。這種情況下，可以采取以下步驟處理需求沖突：-理解沖突原因：首先需要了解雙方的需求背景和動(dòng)機(jī)，找出沖突的根本原因。-尋求共同點(diǎn)：分析雙方需求的共同點(diǎn)，尋找可以兼顧的解決方案。-協(xié)商折中方案：與雙方溝通，提出折中方案，例如設(shè)置合理的促銷活動(dòng)范圍和折扣上限。-確認(rèn)解決方案：與雙方確認(rèn)最終的解決方案，確保雙方都能接受。-記錄變更：將最終的解決方案記錄在需求文檔中，并更新需求跟蹤矩陣。2.結(jié)合實(shí)際案例，論述需求變更控制的重要性及其帶來(lái)的好處。答：需求變更控制是項(xiàng)目管理中的重要環(huán)節(jié)，可以確保項(xiàng)目在變更中保持穩(wěn)定和可控。例如，某銀行系統(tǒng)在開(kāi)發(fā)過(guò)程中發(fā)現(xiàn)用戶對(duì)原有需求提出了新的變更請(qǐng)求，需要增加在線轉(zhuǎn)賬功能。此時(shí)，可以采取以下步驟進(jìn)行需求變更控制：-提交變更請(qǐng)求：由用戶提交變更請(qǐng)求，說(shuō)明變更原因和具體需求。-評(píng)估變更影響：由項(xiàng)目團(tuán)隊(duì)評(píng)估變更對(duì)項(xiàng)目進(jìn)度、成本和風(fēng)險(xiǎn)的影響，例如需要增加開(kāi)發(fā)時(shí)間和人力投入。-審批變更請(qǐng)求：由項(xiàng)目經(jīng)理或相關(guān)負(fù)責(zé)人審批變更請(qǐng)求，決定是否接受變更，并確定變更的優(yōu)先級(jí)。-執(zhí)行變更操作：由開(kāi)發(fā)團(tuán)隊(duì)執(zhí)行變更，確保變更內(nèi)容得到正確實(shí)現(xiàn)，并進(jìn)行必要的測(cè)試。-驗(yàn)證變更結(jié)果：由測(cè)試團(tuán)隊(duì)驗(yàn)證變更結(jié)果，確保變更滿足需求，并更新相關(guān)文檔。-記錄變更歷史：將變更過(guò)程和結(jié)果記錄在變更日志中，便于后續(xù)跟蹤和回顧。需求變更控制的重要性在于：-確保項(xiàng)目在變更中保持穩(wěn)定：通過(guò)嚴(yán)格的變更控制流程，可以避免無(wú)序的變更導(dǎo)致項(xiàng)目失控。-優(yōu)化資源配置：通過(guò)評(píng)估變更影響，可以合理分配資源，避免浪費(fèi)。-降低項(xiàng)目風(fēng)險(xiǎn)：通過(guò)審批變更請(qǐng)求，可以及時(shí)發(fā)現(xiàn)和解決潛在問(wèn)題，降低項(xiàng)目風(fēng)險(xiǎn)。-提高項(xiàng)目質(zhì)量：通過(guò)驗(yàn)證變更結(jié)果，可以確保變更滿足需求，提高項(xiàng)目質(zhì)量。本次試卷答案如下一、單項(xiàng)選擇題1.B用戶訪談能夠深入挖掘用戶的真實(shí)想法和潛在需求，尤其適用于探索用戶未明確表達(dá)的需求，比問(wèn)卷調(diào)查、文檔分析等方法更能捕捉到隱性需求。2.A功能性需求直接描述系統(tǒng)應(yīng)提供的功能或服務(wù)，"用戶通過(guò)點(diǎn)擊按鈕完成某項(xiàng)操作"正是典型的功能性需求描述。3.A"Musthave"表示必須實(shí)現(xiàn)的功能，是MoSCoW方法中最高優(yōu)先級(jí)的分類，代表系統(tǒng)核心功能。4.B在用例圖中，系統(tǒng)用矩形邊界表示，參與者代表與系統(tǒng)交互的外部實(shí)體，用小人圖標(biāo)表示。5.A性能需求關(guān)注系統(tǒng)的響應(yīng)時(shí)間、吞吐量等性能指標(biāo)，"系統(tǒng)響應(yīng)時(shí)間不超過(guò)2秒"是典型的性能需求描述。6.A需求規(guī)格說(shuō)明書(shū)是記錄業(yè)務(wù)規(guī)則的主要文檔，它詳細(xì)描述系統(tǒng)應(yīng)遵循的規(guī)則和約束。7.C技術(shù)負(fù)責(zé)人通常負(fù)責(zé)評(píng)估技術(shù)實(shí)現(xiàn)的可行性和影響，為變更決策提供技術(shù)角度的支持。8.A原型法特別適用于需求不明確或快速迭代的項(xiàng)目，能夠幫助用戶直觀感受系統(tǒng)功能，適用于探索性需求獲取。9.A訪問(wèn)控制是安全需求的一種，描述系統(tǒng)如何限制用戶對(duì)資源的訪問(wèn)權(quán)限。10.C產(chǎn)品經(jīng)理通常代表業(yè)務(wù)方，最了解業(yè)務(wù)角度的需求和期望，因此更適合提出業(yè)務(wù)相關(guān)的問(wèn)題。11.C參與者表示與系統(tǒng)交互的用戶角色，用例描述中的"參與者：張三"表明張三是系統(tǒng)的一個(gè)用戶角色。12.B用戶驗(yàn)收測(cè)試是驗(yàn)證需求完整性的主要方法，通過(guò)讓用戶實(shí)際操作來(lái)確認(rèn)需求是否被正確實(shí)現(xiàn)。13.C可用性需求關(guān)注系統(tǒng)的易用性，"系統(tǒng)支持多語(yǔ)言切換"是典型的可用性需求。14.B需求跟蹤矩陣的主要作用是建立需求與設(shè)計(jì)、代碼、測(cè)試用例之間的關(guān)聯(lián)，確保需求被完整實(shí)現(xiàn)。15.C恢復(fù)能力是系統(tǒng)在異常情況下恢復(fù)數(shù)據(jù)的能力，"系統(tǒng)必須能在斷電后恢復(fù)數(shù)據(jù)"是典型的恢復(fù)能力需求。16.C協(xié)商折中方案是處理需求沖突的有效方法，能夠在滿足各方基本需求的前提下找到平衡點(diǎn)。17.C菱形框在活動(dòng)圖中表示決策點(diǎn)，用于展示流程中的條件分支。18.A需求規(guī)格說(shuō)明書(shū)需要包含用例編號(hào)，以便于跟蹤和管理需求。19.C需求管理工具如Jira、Confluence等支持需求跟蹤功能，是需求驗(yàn)證過(guò)程中常用的工具。20.A合規(guī)性需求描述系統(tǒng)必須遵守的法律法規(guī)，"系統(tǒng)必須符合GDPR法規(guī)"是典型的合規(guī)性需求。21.A反饋機(jī)制是系統(tǒng)向用戶提供操作結(jié)果的方式，"用戶輸入錯(cuò)誤密碼時(shí)系統(tǒng)會(huì)顯示錯(cuò)誤提示"是典型的反饋機(jī)制。22.C成本效益分析是客觀評(píng)估需求優(yōu)先級(jí)的方法，通過(guò)比較實(shí)現(xiàn)成本和業(yè)務(wù)收益來(lái)確定優(yōu)先級(jí)。23.A數(shù)據(jù)流圖中的箭頭表示數(shù)據(jù)流向，用于展示數(shù)據(jù)在系統(tǒng)中的傳輸路徑。24.B評(píng)估變更影響是需求變更控制流程中最關(guān)鍵的步驟，直接影響變更決策和項(xiàng)目風(fēng)險(xiǎn)。25.B用戶訪談能夠挖掘用戶未意識(shí)到的需求，是獲取隱性需求最有效的方法之一。二、多項(xiàng)選擇題1.ABCE需求獲取方法包括問(wèn)卷調(diào)查、用戶訪談、競(jìng)品分析和觀察法，文檔分析屬于需求整理方法。2.ABDE需求規(guī)格說(shuō)明書(shū)通常包含功能性需求、非功能性需求、業(yè)務(wù)規(guī)則、用例圖和用例描述等內(nèi)容。3.ABCD非功能性需求包括性能需求、安全需求、可用性需求和可靠性需求，合規(guī)性需求有時(shí)單獨(dú)列出。4.ABCE需求變更控制流程包括提交變更請(qǐng)求、評(píng)估變更影響、審批變更請(qǐng)求、執(zhí)行變更操作和驗(yàn)證變更結(jié)果等步驟。5.ABCE用例圖必須包含系統(tǒng)、參與者、用例和矩形邊界等元素，直線是連接元素的工具。6.BCE用戶驗(yàn)收測(cè)試、需求確認(rèn)簽字和需求評(píng)審是常見(jiàn)的需求驗(yàn)證方法，代碼審查屬于開(kāi)發(fā)階段驗(yàn)證。7.ABCD需求跟蹤矩陣的列通常包括需求編號(hào)、需求描述、來(lái)源文檔、實(shí)現(xiàn)狀態(tài)和測(cè)試用例等。8.ABC需求管理工具通常支持需求版本控制、變更跟蹤和優(yōu)先級(jí)排序等功能，測(cè)試用例管理通常由測(cè)試工具實(shí)現(xiàn)。9.ABCD活動(dòng)圖中的常見(jiàn)元素包括初始狀態(tài)、結(jié)束狀態(tài)、處理過(guò)程、決策點(diǎn)和分支/合并等。10.ABCD合規(guī)性需求包括GDPR、HIPAA、ISO27001和PCIDSS等，它們是系統(tǒng)必須遵守的法律法規(guī)。（注：實(shí)際考試中每題只有一個(gè)正確答案，此處為多項(xiàng)選擇題示例）三、判斷題1.×需求規(guī)格說(shuō)明書(shū)是動(dòng)態(tài)文檔，可以根據(jù)實(shí)際情況進(jìn)行修改，但需要遵循變更控制流程。2.√用戶訪談能夠深入挖掘用戶真實(shí)需求，尤其是隱性需求，是獲取需求的常用且有效方法。3.×功能性需求和非功能性需求同等重要，取決于項(xiàng)目目標(biāo)和用戶需求。4.×用例圖展示需求，但無(wú)法完全替代需求規(guī)格說(shuō)明書(shū)，后者需要更詳細(xì)的需求描述。5.×需求跟蹤矩陣確保需求被跟蹤，但不保證所有需求都被實(shí)現(xiàn)，實(shí)現(xiàn)情況需要通過(guò)測(cè)試驗(yàn)證。6.×需求變更控制流程需要所有相關(guān)方參與，包括項(xiàng)目經(jīng)理、開(kāi)發(fā)人員、測(cè)試人員和需求提出者。7.×數(shù)據(jù)存儲(chǔ)在數(shù)據(jù)流圖中用雙橫線矩形表示，不是普通矩形。8.√"Couldhave"是MoSCoW方法中代表"可以考慮"的級(jí)別，屬于可選功能。9.×需求評(píng)審需要所有相關(guān)方參與，包括開(kāi)發(fā)人員、測(cè)試人員、產(chǎn)品經(jīng)理和項(xiàng)目經(jīng)理等。10.×合規(guī)性需求是需求規(guī)格說(shuō)明書(shū)的重要組成部分，需要明確記錄和跟蹤。四、簡(jiǎn)答題1.答：需求獲取的常用方法及其適用場(chǎng)景：-問(wèn)卷調(diào)查：適用于收集大量用戶的普遍性需求，但難以獲取隱性需求。例如，通過(guò)在線問(wèn)卷收集用戶對(duì)某電商平臺(tái)的購(gòu)物體驗(yàn)反饋。-用戶訪談：適用于探索用戶的真實(shí)需求和痛點(diǎn)，但需要投入較多時(shí)間和精力。例如，與銀行客戶進(jìn)行一對(duì)一訪談，了解他們對(duì)移動(dòng)銀行的需求。-競(jìng)品分析：適用于了解市場(chǎng)現(xiàn)狀和競(jìng)爭(zhēng)對(duì)手的產(chǎn)品特點(diǎn)，但需要結(jié)合自身業(yè)務(wù)進(jìn)行判斷。例如，分析競(jìng)爭(zhēng)對(duì)手的社交平臺(tái)功能，為自家產(chǎn)品提供參考。-文檔分析：適用于已有相關(guān)文檔的情況，但可能存在信息過(guò)時(shí)或不完整的問(wèn)題。例如，通過(guò)分析舊系統(tǒng)的需求文檔，了解歷史需求變更。-觀察法：適用于了解用戶實(shí)際操作習(xí)慣，但需要確保觀察環(huán)境的真實(shí)性。例如，觀察用戶在超市使用自助結(jié)賬機(jī)的流程，發(fā)現(xiàn)操作痛點(diǎn)。2.答：需求規(guī)格說(shuō)明書(shū)是記錄系統(tǒng)需求的正式文檔，用于指導(dǎo)開(kāi)發(fā)、測(cè)試和驗(yàn)收等階段。其主要內(nèi)容包括：-功能性需求：描述系統(tǒng)應(yīng)具備的功能和特性。例如，電商系統(tǒng)需要支持用戶注冊(cè)、商品瀏覽、購(gòu)物車和下單等功能。-非功能性需求：描述系統(tǒng)的性能、安全、可用性等方面的要求。例如，系統(tǒng)響應(yīng)時(shí)間不超過(guò)2秒，需要支持至少1000并發(fā)用戶。-業(yè)務(wù)規(guī)則：描述系統(tǒng)應(yīng)遵循的業(yè)務(wù)邏輯和規(guī)則。例如，訂單金額超過(guò)1000元需要提供發(fā)票，促銷活動(dòng)不能疊加使用。-數(shù)據(jù)模型：描述系統(tǒng)中的數(shù)據(jù)結(jié)構(gòu)和關(guān)系。例如，用戶表包含用戶ID、姓名、手機(jī)號(hào)和密碼等字段。-用例圖：描述系統(tǒng)與用戶之間的交互過(guò)程。例如，用例圖展示用戶如何通過(guò)注冊(cè)、登錄、瀏覽商品和下單等操作完成購(gòu)物。3.答：需求變更控制流程的主要步驟包括：-提交變更請(qǐng)求：由需求提出者提交變更請(qǐng)求，說(shuō)明變更原因和內(nèi)容。例如，銷售部門提出增加限時(shí)折扣功能，并說(shuō)明具體需求。-評(píng)估變更影響：由項(xiàng)目團(tuán)隊(duì)評(píng)估變更對(duì)項(xiàng)目進(jìn)度、成本和風(fēng)險(xiǎn)的影響。例如，評(píng)估開(kāi)發(fā)該功能需要增加的時(shí)間和人力投入。-審批變更請(qǐng)求：由項(xiàng)目經(jīng)理或相關(guān)負(fù)責(zé)人審批變更請(qǐng)求，決定是否接受變更，并確定變更的優(yōu)先級(jí)。例如，項(xiàng)目經(jīng)理根據(jù)項(xiàng)目進(jìn)度和資源情況，決定是否批準(zhǔn)該變更。-執(zhí)行變更操作：由開(kāi)發(fā)團(tuán)隊(duì)執(zhí)行變更，確保變更內(nèi)容得到正確實(shí)現(xiàn)。例如，開(kāi)發(fā)人員根據(jù)變更需求，修改代碼并測(cè)試新功能。-驗(yàn)證變更結(jié)果：由測(cè)試團(tuán)隊(duì)驗(yàn)證變更結(jié)果，確保變更滿足需求。例如，測(cè)試人員測(cè)試限時(shí)折扣功能，確認(rèn)其符合業(yè)務(wù)需求。-記錄變更歷史：將變更過(guò)程和結(jié)果記錄在變更日志中，便于后續(xù)跟蹤和回顧。例如，記錄變更請(qǐng)求編號(hào)、變更內(nèi)容、審批人和實(shí)施結(jié)果等信息。4.答：用例圖是描述系統(tǒng)與用戶之間交互過(guò)程的圖形化表示，主要用于展示系統(tǒng)的功能需求和用戶角色。其主要元素包括：-系統(tǒng)：用矩形表示，代表被開(kāi)發(fā)的系統(tǒng)。例如，電商系統(tǒng)用矩形表示，內(nèi)部包含商品管理、訂單處理等功能模塊。-參與者：用小人圖標(biāo)表示，代表與系統(tǒng)交互的用戶或外部系統(tǒng)。例如，電商系統(tǒng)的參與者包括普通用戶、管理員和支付系統(tǒng)。-用例：用橢圓形表示，代表系統(tǒng)提供的功能或服務(wù)。例如，電商系統(tǒng)的用例包括注冊(cè)、登錄、瀏覽商品、下單和支付等。-直線：用于連接參與者和用例，表示參與者可以執(zhí)行該用例。例如，普通用戶可以執(zhí)行注冊(cè)、登錄和瀏覽商品等用例。-矩形邊界：用例圖必須包含系統(tǒng)邊界，表示系統(tǒng)的范圍。例如，電商系統(tǒng)的邊界包括所有用戶界面和后端服務(wù)。5.答：需求驗(yàn)證的目的是確保需求文檔的完整性、正確性和一致性，避免開(kāi)發(fā)過(guò)程中出現(xiàn)偏差。常用方法包括：-需求評(píng)審：由項(xiàng)目團(tuán)隊(duì)成員對(duì)需求文檔進(jìn)行評(píng)審，提出改進(jìn)意見(jiàn)。例如，產(chǎn)品經(jīng)理、開(kāi)發(fā)人員和測(cè)試人員一起評(píng)審需求文檔，確保需求清晰且無(wú)遺漏。-用戶驗(yàn)收測(cè)試：由用戶代表對(duì)需求進(jìn)行驗(yàn)收測(cè)試，確保需求滿足業(yè)務(wù)需求。例如，電商系統(tǒng)的用戶代表測(cè)試注冊(cè)、登錄和購(gòu)物流程，確認(rèn)符合實(shí)際使用需求。-需求確認(rèn)簽字：由需求提出者和實(shí)現(xiàn)者簽字確認(rèn)，表示對(duì)需求的一致性達(dá)成共識(shí)。例如，產(chǎn)品經(jīng)理和開(kāi)發(fā)團(tuán)隊(duì)代表簽字確認(rèn)需求文檔，表示雙方理解一致。-復(fù)盤會(huì)議：定期召開(kāi)會(huì)議，回顧需求文檔的執(zhí)行情況，及時(shí)調(diào)整和改進(jìn)。例如，每周召開(kāi)需求復(fù)盤會(huì)議，討論需求實(shí)現(xiàn)進(jìn)度和遇到的問(wèn)題。五、論述題1.答：需求沖突是需求獲取過(guò)程中常見(jiàn)的問(wèn)題，需要通過(guò)協(xié)商和折中來(lái)解決。例如，某電商系統(tǒng)在需求獲取過(guò)程中發(fā)現(xiàn)，銷售部門希望系統(tǒng)支持更多促銷活動(dòng)，而財(cái)務(wù)部門希望系統(tǒng)嚴(yán)格控制折扣上限。這種情況下，可以采取以下步驟處理需求沖突：-理解沖突原因：首先需要了解雙方的需求背景和動(dòng)機(jī)，找出沖突的根本原因。銷售部門希望促銷活動(dòng)吸引更多用戶，而財(cái)務(wù)部門擔(dān)心折扣過(guò)高影響利潤(rùn)。-尋求共同點(diǎn)：分析雙方需求的共同點(diǎn)，尋找可以兼顧的解決方案。例如，雙方都希望提高銷售額，但需要平衡利潤(rùn)和用戶增長(zhǎng)。-協(xié)商折中方案：與雙方溝通，提出折中方案，例如設(shè)置合理的促銷活動(dòng)范圍和折扣上限。例如，規(guī)定每月只能進(jìn)行一次大型促銷活動(dòng)，且折扣上限為30%。-確認(rèn)解決方案：與雙方確認(rèn)最終的