2025年需求分析測試題及答案一、單項選擇題（每題2分，共20分）1.以下哪項屬于非功能性需求？A.用戶登錄時需驗證手機號和驗證碼B.系統(tǒng)需支持1000并發(fā)用戶同時訪問C.訂單詳情頁需顯示商品名稱、價格、數(shù)量D.管理員可批量導入會員信息2.需求獲取過程中，用于快速驗證用戶對界面交互理解的常用方法是？A.問卷調(diào)查法B.原型法C.頭腦風暴法D.觀察法3.某金融系統(tǒng)要求"交易數(shù)據(jù)存儲需滿足GDPR合規(guī)性"，這屬于哪種需求類型？A.功能需求B.性能需求C.安全需求D.可維護性需求4.需求規(guī)格說明書（SRS）中，"當用戶連續(xù)3次輸入錯誤密碼時，賬戶鎖定15分鐘"屬于？A.業(yè)務規(guī)則B.數(shù)據(jù)需求C.接口需求D.約束條件5.進行需求優(yōu)先級排序時，使用KANO模型劃分的"魅力型需求"指的是？A.用戶未明確提出，但實現(xiàn)后能顯著提升滿意度的需求B.用戶認為必須滿足的基本需求C.滿足后用戶滿意度提升，不滿足則滿意度下降的需求D.無論是否滿足對用戶滿意度影響較小的需求6.需求驗證的關鍵目標是？A.確保需求符合項目進度計劃B.確認需求描述清晰、無歧義且可測試C.評估需求實現(xiàn)的技術可行性D.統(tǒng)計需求數(shù)量以計算工作量7.某教育類APP需求文檔中描述"教師端需支持作業(yè)批改"，此描述的主要問題是？A.未明確作業(yè)類型（如文字、視頻、圖片）B.未說明批改后的通知方式C.未限定教師角色權限（如主科/副科教師）D.以上都是8.需求跟蹤矩陣（RTM）的核心作用是？A.記錄需求變更歷史B.確保每個需求都有對應的測試用例C.建立需求與設計、開發(fā)、測試階段的雙向追溯關系D.統(tǒng)計需求覆蓋度9.以下哪種場景最適合使用用例（UseCase）進行需求建模？A.描述系統(tǒng)與外部支付網(wǎng)關的交互流程B.定義數(shù)據(jù)庫表結構的字段約束C.說明系統(tǒng)性能指標（如響應時間≤2秒）D.記錄用戶對界面配色的偏好10.需求變更管理中，"變更影響分析"的重點不包括？A.評估變更對現(xiàn)有功能的影響B(tài).計算變更所需的開發(fā)工時C.分析變更對用戶體驗的影響D.確認變更提出者的職位層級二、簡答題（每題8分，共40分）1.簡述用戶故事（UserStory）的三要素及其在需求分析中的作用。2.列舉至少4種需求獲取方法，并說明每種方法的適用場景。3.說明功能需求與非功能需求的主要區(qū)別，各舉2個典型例子。4.需求規(guī)格說明書應包含哪些核心內(nèi)容？請列出5個以上關鍵章節(jié)。5.當業(yè)務方提出"系統(tǒng)需支持未來3年用戶量增長5倍"的需求時，需求分析師應從哪些維度進行深入挖掘？三、案例分析題（每題20分，共40分）案例一：某生鮮電商平臺擬開發(fā)"社區(qū)團購"模塊，需求團隊收集到以下原始需求：①團長需通過微信小程序發(fā)起團購，可設置商品庫存、截單時間②系統(tǒng)需在截單后30分鐘內(nèi)自動提供采購單③用戶下單時需選擇自提點（社區(qū)內(nèi)500米范圍內(nèi)的便利店/快遞柜）④商品詳情頁需展示生產(chǎn)日期、保質(zhì)期、冷鏈運輸溫度⑤團長可查看團員的下單明細，但無法修改訂單⑥系統(tǒng)在用戶付款成功后發(fā)送短信通知（包含訂單號、自提時間）⑦大促期間（如周末）系統(tǒng)需支持5萬并發(fā)下單⑧老年用戶反饋商品名稱字體太小，建議調(diào)整為16號以上問題：（1）將上述需求按功能需求（FR）與非功能需求（NFR）分類，寫出對應序號；（2）從需求描述質(zhì)量角度，指出需求①存在的問題并提出修改建議；（3）針對需求⑧，說明應補充哪些細節(jié)以提升需求可測試性。案例二：某企業(yè)擬開發(fā)智能會議室預約系統(tǒng)，需求評審會上出現(xiàn)以下爭議：行政部："系統(tǒng)必須支持手機端、PC端、會議室觸控屏三端預約"IT部："三端同步可能增加開發(fā)復雜度，建議優(yōu)先開發(fā)PC端"研發(fā)部："需要記錄每次會議的實際使用時長，用于統(tǒng)計會議室利用率"財務部："超2小時的會議需部門負責人審批，否則無法預約"用戶代表（普通員工）："希望能快速找到最近3天有空的小會議室（≤10人）"問題：（1）使用MoSCoW方法對上述需求進行優(yōu)先級排序（分為Must-have、Should-have、Could-have、Won't-have）；（2）說明需求分析師在處理部門爭議時應采取的關鍵措施；（3）提出驗證"快速查找最近3天有空小會議室"需求是否滿足的測試場景。答案一、單項選擇題1.B（非功能需求關注系統(tǒng)屬性，如性能、可靠性；A/C/D為具體功能實現(xiàn)）2.B（原型法通過可視化界面快速驗證交互需求）3.C（GDPR涉及數(shù)據(jù)隱私保護，屬于安全合規(guī)需求）4.A（業(yè)務規(guī)則定義系統(tǒng)運行的邏輯約束）5.A（KANO模型中魅力型需求是用戶未預期但能提升滿意度的需求）6.B（需求驗證核心是確保需求質(zhì)量，包括清晰性、完整性、可測試性）7.D（需求描述需明確主體、行為、對象、約束條件，原描述缺少多維度細節(jié)）8.C（RTM核心是建立需求與各開發(fā)階段的雙向追溯，確保需求不遺漏）9.A（用例適合描述系統(tǒng)與參與者的交互流程）10.D（變更影響分析關注技術、業(yè)務、用戶影響，與提出者職位無關）二、簡答題1.用戶故事三要素：角色（Who）、目標（What）、收益（Why）。作用：以用戶視角描述需求，促進開發(fā)團隊與用戶的共同理解；支持敏捷開發(fā)中的需求拆分和優(yōu)先級排序；通過"驗收標準"明確完成條件，提升需求可測試性。2.需求獲取方法及適用場景：訪談法：適用于關鍵用戶（如業(yè)務負責人），深入挖掘復雜業(yè)務流程；問卷調(diào)查法：適用于大范圍用戶（如終端消費者），收集定量數(shù)據(jù)；觀察法：適用于了解用戶實際操作行為（如超市收銀員使用系統(tǒng)的真實場景）；原型法：適用于交互需求不明確時，通過可視化原型快速驗證；頭腦風暴法：適用于跨部門需求討論，激發(fā)創(chuàng)新想法。3.區(qū)別：功能需求描述系統(tǒng)"做什么"（具體功能），非功能需求描述"做得如何"（系統(tǒng)屬性）。功能需求例子：用戶可修改個人收貨地址；管理員可導出月度銷售報表。非功能需求例子：APP啟動時間≤1.5秒；用戶信息存儲需加密（加密算法≥AES-256）。4.核心內(nèi)容：概述（系統(tǒng)目標、范圍）；參考文檔；總體約束（如技術選型、合規(guī)要求）；功能需求（用例/用戶故事）；非功能需求（性能、安全、易用性等）；數(shù)據(jù)需求（數(shù)據(jù)模型、數(shù)據(jù)流程）；接口需求（與外部系統(tǒng)交互）；驗收標準；附錄（術語表、版本歷史）。5.挖掘維度：當前用戶基數(shù)及增長預測（如現(xiàn)有10萬用戶，3年目標50萬）；關鍵業(yè)務場景（如峰值下單、數(shù)據(jù)查詢）的性能瓶頸；系統(tǒng)架構擴展性（如是否支持分布式部署、數(shù)據(jù)庫分片）；硬件/云資源預算（服務器擴容、帶寬升級）；第三方服務依賴（如支付接口、物流API的并發(fā)支持）；用戶行為變化（如移動端占比是否會提升）。三、案例分析題案例一：（1）功能需求（FR）：①③⑤⑥；非功能需求（NFR）：②④⑦⑧（注：④涉及商品信息展示的詳細程度，屬于數(shù)據(jù)需求中的內(nèi)容完整性要求，可歸類為非功能；②為時間約束，屬于性能需求）（2）問題：未明確團長的權限邊界（如是否可修改已發(fā)起的團購信息）、商品庫存的類型（實物庫存/虛擬庫存）、截單時間的設置范圍（如最小/最大可設置時長）。修改建議："團長通過微信小程序發(fā)起團購時，可設置商品實物庫存數(shù)量（≥10件）、截單時間（需在發(fā)起時間后≥2小時且≤72小時），發(fā)起后30分鐘內(nèi)可修改團購信息，超時后僅可查看不可修改"。（3）補充細節(jié)：目標用戶群體（60歲以上老年用戶）；測試環(huán)境（微信小程序默認字體設置，不使用用戶自定義字體）；驗證方式（隨機抽取20名目標用戶，使用視力≤0.8的設備，在自然光/弱光環(huán)境下識別商品名稱的準確率≥90%）；字體具體要求（16號宋體，行間距≥1.5倍）。案例二：（1）優(yōu)先級排序：Must-have（必須實現(xiàn)）：用戶快速查找最近3天有空小會議室（基礎功能）；手機端/PC端預約（覆蓋主要使用場景）；Should-have（應該實現(xiàn)）：記錄會議實際使用時長（管理需求）；超2小時需負責人審批（財務控制）；Could-have（可以實現(xiàn)）：會議室觸控屏預約（提升體驗但非必需）；Won't-have（本次不實現(xiàn)）：無（所有需求均有價值，可調(diào)整為迭代計劃）。（2）關鍵措施：①明確系統(tǒng)核心目標（提升會議室使用效率，減少資源浪費）；②收集各部門需求背后的真實訴求（如IT部擔心復雜度可討論分階段實施）；③量化需求影響（如三端開發(fā)需增加2人月，觸控屏后續(xù)迭代）；④建立需求優(yōu)先級決策標準（如用戶覆蓋度、業(yè)務價值、技術風險）；⑤形成會議紀要并確認各方責任。（3）測試場景：正常場景：用戶選擇"小會議室（≤1