2025年需求分析測(cè)試試題及答案一、單項(xiàng)選擇題（每題2分，共20分）1.以下哪項(xiàng)屬于需求分析階段的核心產(chǎn)出物？A.項(xiàng)目進(jìn)度計(jì)劃B.需求跟蹤矩陣C.測(cè)試用例文檔D.代碼評(píng)審記錄答案：B2.在敏捷開(kāi)發(fā)中，用戶故事（UserStory）的驗(yàn)收標(biāo)準(zhǔn)（AcceptanceCriteria）應(yīng)滿足的核心要求是？A.技術(shù)實(shí)現(xiàn)細(xì)節(jié)明確B.可驗(yàn)證且無(wú)歧義C.覆蓋所有可能場(chǎng)景D.包含性能指標(biāo)答案：B3.某企業(yè)開(kāi)發(fā)智能養(yǎng)老監(jiān)護(hù)系統(tǒng)，其中“系統(tǒng)需在老人心率超過(guò)120次/分鐘時(shí)，5秒內(nèi)通過(guò)短信通知緊急聯(lián)系人”屬于？A.功能需求B.非功能需求（性能需求）C.業(yè)務(wù)規(guī)則D.約束條件答案：B4.需求驗(yàn)證（RequirementValidation）與需求確認(rèn)（RequirementVerification）的主要區(qū)別是？A.驗(yàn)證關(guān)注“是否正確實(shí)現(xiàn)需求”，確認(rèn)關(guān)注“需求是否正確”B.驗(yàn)證是開(kāi)發(fā)團(tuán)隊(duì)內(nèi)部活動(dòng)，確認(rèn)需用戶參與C.驗(yàn)證使用測(cè)試用例，確認(rèn)使用原型D.驗(yàn)證在需求階段完成，確認(rèn)在開(kāi)發(fā)階段完成答案：B5.以下哪種需求優(yōu)先級(jí)排序方法最適用于資源有限、需快速交付核心價(jià)值的場(chǎng)景？A.MoSCoW方法（必須有、應(yīng)該有、可以有、不會(huì)有）B.Kano模型（基本型、期望型、興奮型）C.成本效益分析（CBA）D.客戶投票法（DotVoting）答案：A6.某電商平臺(tái)需求文檔中描述“用戶下單后，系統(tǒng)應(yīng)提供多種支付方式”，該描述的主要缺陷是？A.未明確“多種”的具體范圍（如支付寶、微信、信用卡等）B.未說(shuō)明支付方式的切換邏輯C.未提及支付失敗的處理流程D.未定義支付接口的技術(shù)標(biāo)準(zhǔn)答案：A7.在需求跟蹤矩陣（RTM）中，“需求-設(shè)計(jì)-測(cè)試用例”的正向跟蹤主要用于驗(yàn)證？A.所有需求均被實(shí)現(xiàn)且測(cè)試覆蓋B.測(cè)試用例未超出需求范圍C.設(shè)計(jì)文檔符合需求描述D.需求變更的影響范圍答案：A8.針對(duì)“銀行核心交易系統(tǒng)需支持7×24小時(shí)不間斷運(yùn)行”的需求，以下哪項(xiàng)是最合理的驗(yàn)證方法？A.審查需求文檔的完整性B.進(jìn)行壓力測(cè)試（如模擬高并發(fā)交易）C.開(kāi)展用戶訪談確認(rèn)業(yè)務(wù)場(chǎng)景D.分析系統(tǒng)架構(gòu)的冗余設(shè)計(jì)答案：D9.當(dāng)用戶提出“系統(tǒng)要比現(xiàn)有產(chǎn)品更易用”的模糊需求時(shí)，需求分析師的首要任務(wù)是？A.直接拒絕，要求用戶明確量化指標(biāo)B.通過(guò)用戶旅程圖（UserJourneyMap）挖掘具體痛點(diǎn)C.參考行業(yè)標(biāo)準(zhǔn)定義易用性指標(biāo)（如任務(wù)完成時(shí)間、錯(cuò)誤率）D.邀請(qǐng)用戶參與原型設(shè)計(jì)，通過(guò)反饋細(xì)化需求答案：B10.某醫(yī)療軟件需求中規(guī)定“患者電子病歷數(shù)據(jù)存儲(chǔ)需符合《個(gè)人信息保護(hù)法》及HIPAA標(biāo)準(zhǔn)”，這屬于？A.功能需求B.合規(guī)性需求（約束條件）C.性能需求D.可用性需求答案：B二、多項(xiàng)選擇題（每題3分，共15分，少選得1分，錯(cuò)選不得分）1.需求分析階段常見(jiàn)的stakeholders（涉眾）包括？A.最終用戶（EndUser）B.業(yè)務(wù)負(fù)責(zé)人（BusinessOwner）C.開(kāi)發(fā)工程師D.合規(guī)/法務(wù)人員答案：ABCD2.以下哪些方法可用于挖掘用戶的隱性需求？A.觀察法（實(shí)地觀察用戶操作現(xiàn)有系統(tǒng)）B.頭腦風(fēng)暴（Brainstorming）C.角色扮演（RolePlay）D.Kano模型問(wèn)卷調(diào)查答案：ACD3.需求變更管理的關(guān)鍵步驟包括？A.記錄變更請(qǐng)求（CR，ChangeRequest）B.評(píng)估變更對(duì)進(jìn)度、成本、范圍的影響C.未經(jīng)審批直接修改需求文檔D.更新需求跟蹤矩陣并同步相關(guān)方答案：ABD4.非功能需求（NFR）的常見(jiàn)分類包括？A.性能（如響應(yīng)時(shí)間、吞吐量）B.安全性（如數(shù)據(jù)加密、訪問(wèn)控制）C.可維護(hù)性（如代碼模塊化程度）D.可擴(kuò)展性（如支持第三方插件集成）答案：ABCD5.在敏捷需求實(shí)踐中，產(chǎn)品待辦列表（ProductBacklog）的特點(diǎn)包括？A.動(dòng)態(tài)更新，優(yōu)先級(jí)隨業(yè)務(wù)目標(biāo)調(diào)整B.包含詳細(xì)的技術(shù)實(shí)現(xiàn)方案C.條目需足夠小，可在一個(gè)沖刺（Sprint）內(nèi)完成D.由產(chǎn)品負(fù)責(zé)人（ProductOwner）負(fù)責(zé)排序答案：ACD三、簡(jiǎn)答題（每題8分，共40分）1.簡(jiǎn)述需求分析中“用戶需求（UserRequirement）”與“系統(tǒng)需求（SystemRequirement）”的區(qū)別，并舉例說(shuō)明。答案：用戶需求是用戶對(duì)系統(tǒng)的期望和業(yè)務(wù)目標(biāo)的描述，關(guān)注“要做什么”，通常用自然語(yǔ)言表達(dá)（如“患者能在線查看檢驗(yàn)報(bào)告”）；系統(tǒng)需求是對(duì)用戶需求的技術(shù)細(xì)化，明確“如何實(shí)現(xiàn)”，包括功能、性能、約束等（如“檢驗(yàn)報(bào)告查詢接口響應(yīng)時(shí)間≤2秒，支持PDF/圖片格式下載”）。2.說(shuō)明需求評(píng)審（RequirementReview）的主要目的及關(guān)鍵參與人員。答案：目的：確保需求文檔完整、清晰、一致、可驗(yàn)證，減少后期變更成本。關(guān)鍵參與人員：需求分析師、產(chǎn)品經(jīng)理、業(yè)務(wù)代表（用戶）、開(kāi)發(fā)/測(cè)試負(fù)責(zé)人、合規(guī)/法務(wù)人員。3.當(dāng)需求文檔中出現(xiàn)“系統(tǒng)應(yīng)具備高可靠性”的模糊描述時(shí)，需求分析師應(yīng)如何處理？請(qǐng)給出至少3個(gè)具體步驟。答案：（1）與用戶確認(rèn)“高可靠性”的具體場(chǎng)景（如交易成功率、故障恢復(fù)時(shí)間）；（2）參考行業(yè)標(biāo)準(zhǔn)或歷史數(shù)據(jù)量化指標(biāo)（如“交易成功率≥99.99%，故障恢復(fù)時(shí)間≤30分鐘”）；（3）明確可靠性的技術(shù)實(shí)現(xiàn)方式（如冗余部署、自動(dòng)故障轉(zhuǎn)移）；（4）將量化后的需求補(bǔ)充到文檔中，并通過(guò)用戶確認(rèn)。4.解釋需求跟蹤矩陣（RTM）的“雙向跟蹤”（Forward&BackwardTraceability）及其作用。答案：雙向跟蹤指正向跟蹤（需求→設(shè)計(jì)→測(cè)試）和反向跟蹤（測(cè)試→設(shè)計(jì)→需求）。正向跟蹤確保所有需求被實(shí)現(xiàn)并測(cè)試覆蓋；反向跟蹤驗(yàn)證測(cè)試用例、設(shè)計(jì)方案無(wú)超出需求范圍，避免過(guò)度設(shè)計(jì)。作用：降低需求遺漏或鍍金風(fēng)險(xiǎn)，支持需求變更影響分析。5.敏捷開(kāi)發(fā)中，如何通過(guò)“用戶故事拆分（StorySplitting）”提升需求管理效率？請(qǐng)舉例說(shuō)明。答案：拆分原則：按功能模塊（如“用戶登錄”拆分為“普通用戶登錄”“管理員登錄”）、按用戶角色（如“患者端預(yù)約”拆分為“門診預(yù)約”“檢查預(yù)約”）、按業(yè)務(wù)流程（如“訂單支付”拆分為“選擇支付方式”“完成支付”“支付結(jié)果反饋”）。示例：將“用戶能管理收貨地址”拆分為“新增地址”“編輯地址”“刪除地址”“設(shè)為默認(rèn)地址”4個(gè)用戶故事，每個(gè)故事可在1個(gè)Sprint內(nèi)完成，便于迭代開(kāi)發(fā)和測(cè)試。四、案例分析題（共25分）案例背景：某物流企業(yè)計(jì)劃開(kāi)發(fā)“智能配送調(diào)度系統(tǒng)”，目標(biāo)是提升車輛利用率、降低配送成本。需求分析階段收集到以下信息：業(yè)務(wù)部門：希望系統(tǒng)能自動(dòng)分配訂單，減少人工調(diào)度時(shí)間（當(dāng)前人工調(diào)度需2小時(shí)/天）。司機(jī)用戶：希望系統(tǒng)能提供實(shí)時(shí)導(dǎo)航，避開(kāi)擁堵路段，且操作界面簡(jiǎn)單（司機(jī)普遍年齡較大，熟悉基礎(chǔ)手機(jī)操作）。技術(shù)團(tuán)隊(duì)：現(xiàn)有服務(wù)器帶寬為100Mbps，需評(píng)估系統(tǒng)并發(fā)量（預(yù)計(jì)峰值訂單量5000單/小時(shí)）。合規(guī)要求：配送路徑需符合《道路運(yùn)輸車輛動(dòng)態(tài)監(jiān)督管理辦法》，敏感信息（如用戶地址）需加密存儲(chǔ)。問(wèn)題1：請(qǐng)結(jié)合需求分類（功能/非功能/約束），對(duì)上述需求進(jìn)行歸類，并補(bǔ)充至少2項(xiàng)遺漏的關(guān)鍵需求（5分）。答案：功能需求：自動(dòng)分配訂單、實(shí)時(shí)導(dǎo)航、操作界面簡(jiǎn)單（易用性）。非功能需求：人工調(diào)度時(shí)間≤30分鐘/天（效率）、系統(tǒng)并發(fā)支持5000單/小時(shí)（性能）、操作界面符合老年人使用習(xí)慣（可用性）。約束需求：符合《道路運(yùn)輸車輛動(dòng)態(tài)監(jiān)督管理辦法》、敏感信息加密存儲(chǔ)（合規(guī)性）。遺漏需求示例：訂單分配規(guī)則（如按距離/車輛負(fù)載優(yōu)先）、異常處理（如車輛故障時(shí)的重新調(diào)度）。問(wèn)題2：針對(duì)“操作界面簡(jiǎn)單”的需求，需求分析師應(yīng)如何細(xì)化并驗(yàn)證？請(qǐng)給出具體方法（10分）。答案：細(xì)化步驟：（1）通過(guò)用戶訪談（司機(jī)）明確“簡(jiǎn)單”的具體表現(xiàn)（如按鈕數(shù)量≤5個(gè)、字體大小≥18號(hào)、操作步驟≤3步）；（2）參考可用性標(biāo)準(zhǔn)（如ISO9241）定義量化指標(biāo)（如任務(wù)完成時(shí)間≤1分鐘、錯(cuò)誤率≤5%）；（3）設(shè)計(jì)低保真原型（如僅保留“接收訂單”“導(dǎo)航”“異常上報(bào)”功能），邀請(qǐng)司機(jī)進(jìn)行可用性測(cè)試（Think-AloudProtocol），觀察操作過(guò)程并記錄反饋；（4）根據(jù)測(cè)試結(jié)果優(yōu)化界面（如調(diào)整按鈕位置、簡(jiǎn)化術(shù)語(yǔ)），直至滿足司機(jī)的使用習(xí)慣。問(wèn)題3：若開(kāi)發(fā)過(guò)程中，業(yè)務(wù)部門提出“增加跨區(qū)域訂單合并功能”，需求分析師應(yīng)如何處理？請(qǐng)描述完整的變更管理流程（10分）。答案：變更管理流程：（1）記錄變更請(qǐng)求：填寫CR表單，說(shuō)明變更內(nèi)容（跨區(qū)域訂單合并的業(yè)務(wù)場(chǎng)景、預(yù)期收益）、提出方（業(yè)務(wù)部門）、提交時(shí)間。（2）影響分析：聯(lián)合技術(shù)團(tuán)隊(duì)評(píng)估對(duì)系統(tǒng)架構(gòu)（如是否需擴(kuò)展訂單池容量）、開(kāi)發(fā)進(jìn)度（是否影響當(dāng)前Sprint交付）、成本（是否需增加服務(wù)器資源）的影響；聯(lián)合業(yè)務(wù)團(tuán)隊(duì)評(píng)估對(duì)現(xiàn)有流程（如原調(diào)度規(guī)則是否需調(diào)整）的