需求管理筆試題目及答案一、單項(xiàng)選擇題（每題2分，共20分）1.某互聯(lián)網(wǎng)公司在需求評(píng)審會(huì)上發(fā)現(xiàn)，業(yè)務(wù)部門提出的“用戶畫像實(shí)時(shí)更新”需求與現(xiàn)有數(shù)據(jù)倉庫T+1的更新周期沖突。項(xiàng)目經(jīng)理最應(yīng)該首先采取的行動(dòng)是：A.直接拒絕需求，避免技術(shù)風(fēng)險(xiǎn)B.要求開發(fā)團(tuán)隊(duì)加班實(shí)現(xiàn)實(shí)時(shí)鏈路C.用“需求影響地圖”量化實(shí)時(shí)更新對(duì)OKR的貢獻(xiàn)度，再評(píng)估技術(shù)可行性D.讓業(yè)務(wù)部門自行與技術(shù)團(tuán)隊(duì)協(xié)商排期答案：C解析：需求影響地圖能把業(yè)務(wù)目標(biāo)、用戶行為、系統(tǒng)能力逐層拆解，先量化價(jià)值再談實(shí)現(xiàn)，避免盲目承諾或武斷拒絕。2.在敏捷項(xiàng)目中，ProductOwner連續(xù)三次迭代都臨時(shí)插入高優(yōu)先級(jí)需求，導(dǎo)致團(tuán)隊(duì)速率下降30%。ScrumMaster的干預(yù)順序應(yīng)是：①引導(dǎo)PO計(jì)算插入需求的機(jī)會(huì)成本②在迭代計(jì)劃會(huì)前凍結(jié)需求池③用累積流圖展示需求蔓延對(duì)交付節(jié)奏的沖擊④直接屏蔽PO的郵箱A.①③②B.②①③C.③①②D.③②①答案：A解析：先用數(shù)據(jù)說話（③），再讓PO理解代價(jià)（①），最后建立規(guī)則（②），屏蔽郵箱（④）屬于極端做法，排除。3.某B2B平臺(tái)提出“支持客戶自定義審批流”需求，技術(shù)負(fù)責(zé)人反饋“元數(shù)據(jù)驅(qū)動(dòng)引擎”開發(fā)周期至少3個(gè)月。需求分析師此時(shí)應(yīng)優(yōu)先輸出：A.用戶故事地圖B.服務(wù)藍(lán)圖C.最小可行子集（MVS）列表D.競(jìng)爭(zhēng)對(duì)標(biāo)報(bào)告答案：C解析：3個(gè)月超出業(yè)務(wù)忍耐極限，先拆MVS，例如先支持“一級(jí)審批”或“或簽”場(chǎng)景，用可配置字段解決80%問題，再逐步擴(kuò)展。4.在需求跟蹤矩陣中，最能提前暴露“鍍金”現(xiàn)象（GoldPlating）的字段是：A.需求來源B.驗(yàn)收標(biāo)準(zhǔn)C.業(yè)務(wù)價(jià)值評(píng)分D.需求狀態(tài)答案：B解析：鍍金往往是開發(fā)擅自加功能，驗(yàn)收標(biāo)準(zhǔn)里若寫不清“用戶如何感知”，測(cè)試階段就會(huì)暴露無價(jià)值代碼。5.團(tuán)隊(duì)使用MoSCoW法則對(duì)需求分級(jí)，其中“Couldhave”級(jí)別需求占比連續(xù)兩版超過40%，說明：A.需求粒度合理B.需求優(yōu)先級(jí)策略失效C.團(tuán)隊(duì)速率提升D.干系人參與充分答案：B解析：Couldhave過多意味著“都想做但資源有限”，優(yōu)先級(jí)策略未真正砍需求，需重新用加權(quán)最短作業(yè)優(yōu)先（WSJF）量化。6.某金融App要上線“刷臉支付”，合規(guī)部要求提供“算法備案號(hào)”。該需求屬于：A.功能性需求B.非功能性需求C.約束條件D.業(yè)務(wù)規(guī)則答案：C解析：備案號(hào)是外部監(jiān)管強(qiáng)加的硬性條件，不屬于系統(tǒng)功能，也不是純粹性能或安全指標(biāo)，歸為約束更準(zhǔn)確。7.在需求可視化工具中，能夠同時(shí)表達(dá)“情緒曲線”與“痛點(diǎn)峰值”的是：A.用戶旅程地圖B.實(shí)體關(guān)系圖C.數(shù)據(jù)流圖D.甘特圖答案：A解析：旅程地圖的縱軸可標(biāo)注情緒高低，峰值對(duì)應(yīng)痛點(diǎn)，一目了然。8.項(xiàng)目采用SAFe框架，當(dāng)“解決方案意圖”文檔與PIPlanning沖突時(shí)，最終裁決權(quán)在：A.ReleaseTrainEngineerB.SystemArchitectC.BusinessOwnersD.ProductManagement答案：D解析：SAFe中ProductManagement擁有解決方案意圖的最終解釋權(quán)，確保與投資組合戰(zhàn)略一致。9.需求池里出現(xiàn)“用戶希望按鈕更漂亮”這類描述，分析師首先應(yīng)：A.直接轉(zhuǎn)成UI任務(wù)B.用“5Whys”挖掘背后動(dòng)機(jī)C.記錄為NicetohaveD.讓設(shè)計(jì)師出三版稿答案：B解析：漂亮是主觀詞，需追問“更漂亮”是為了提升信任感、降低誤操作還是品牌升級(jí)，再?zèng)Q定方案。10.下列哪一項(xiàng)最能證明需求已“完成”而非“實(shí)現(xiàn)”？A.代碼合并到主干B.通過SonarQube掃描C.用戶代表在驗(yàn)收環(huán)境完成簽字D.性能測(cè)試TPS達(dá)標(biāo)答案：C解析：用戶簽字代表需求被驗(yàn)證滿足業(yè)務(wù)目標(biāo)，其余僅是技術(shù)環(huán)節(jié)。二、多項(xiàng)選擇題（每題3分，共15分）11.以下哪些活動(dòng)屬于需求獲取（Elicitation）階段？A.影子跟訪B.競(jìng)品功能反編譯C.用戶故事編寫D.原型演示E.頭腦風(fēng)暴答案：A、B、E解析：C、D已進(jìn)入需求建?；蝌?yàn)證階段；A、B、E是典型獲取技術(shù)。12.關(guān)于“需求基線”的描述，正確的有：A.基線一旦建立不可更改B.建立基線前必須完成正式評(píng)審C.基線變更需走CCB流程D.基線只包含功能性需求E.基線版本號(hào)與配置庫標(biāo)簽一致答案：B、C、E解析：A錯(cuò)誤，可變更；D錯(cuò)誤，含非功能需求。13.下列哪些指標(biāo)可用于量化需求波動(dòng)性（RequirementsVolatility）？A.需求變更請(qǐng)求數(shù)/迭代B.需求實(shí)現(xiàn)率C.需求刪除率D.需求蔓延度（AddedRequirements/Original）E.缺陷密度答案：A、C、D解析：B、E反映交付質(zhì)量，不直接衡量波動(dòng)。14.在FURPS+模型中，屬于“+”類別的有：A.可用性B.可靠性C.接口需求D.實(shí)現(xiàn)需求E.物理需求答案：C、D、E解析：FURPS本身含功能、可用性、可靠性、性能、可支持性；“+”擴(kuò)展接口、實(shí)現(xiàn)、物理、包裝等。15.以下哪些做法有助于緩解“需求回聲”（EchoRequirements）現(xiàn)象？A.需求評(píng)審時(shí)讓提出者親自確認(rèn)文字記錄B.使用視頻錄制訪談全程C.分析師用自己的話復(fù)述需求并請(qǐng)對(duì)方糾正D.強(qiáng)制要求所有需求用用戶故事模板E.建立術(shù)語表答案：A、B、C、E解析：D模板不能消除回聲，關(guān)鍵在雙向確認(rèn)。三、判斷題（每題1分，共10分）16.在需求優(yōu)先級(jí)排序中，卡諾模型中的“魅力需求”一旦實(shí)現(xiàn)，用戶滿意度會(huì)呈線性上升。答案：錯(cuò)解析：魅力需求滿足后滿意度陡升，未滿足時(shí)用戶不抱怨，非線性。17.使用Jira管理需求時(shí)，給故事點(diǎn)打分時(shí)，團(tuán)隊(duì)把“復(fù)雜度”“工作量”“風(fēng)險(xiǎn)”一起考慮，符合計(jì)劃撲克初衷。答案：對(duì)解析：計(jì)劃撲克本就綜合三維。18.需求跟蹤矩陣中，若某功能行沒有對(duì)應(yīng)的測(cè)試用例列，則一定無法進(jìn)入回歸測(cè)試。答案：錯(cuò)解析：回歸測(cè)試可覆蓋到間接調(diào)用，但風(fēng)險(xiǎn)高，不是“一定無法”。19.在精益需求管理中，“最后責(zé)任時(shí)刻”（LastResponsibleMoment）越晚做決定，越能減少浪費(fèi)。答案：對(duì)解析：延遲決策可等待關(guān)鍵信息，減少因過早決定導(dǎo)致的返工。20.用戶故事“作為一名游客，我想收到天氣預(yù)警，以便調(diào)整行程”缺少驗(yàn)收標(biāo)準(zhǔn)，屬于不完整需求。答案：對(duì)解析：無驗(yàn)收標(biāo)準(zhǔn)即不可驗(yàn)證。21.需求管理計(jì)劃中必須包含“需求狀態(tài)轉(zhuǎn)換規(guī)則”，否則無法度量需求完成率。答案：對(duì)解析：狀態(tài)規(guī)則是度量前提。22.如果項(xiàng)目采用看板方法，則不再需要需求優(yōu)先級(jí)，因?yàn)槔较到y(tǒng)會(huì)自然選擇高價(jià)值需求。答案：錯(cuò)解析：看板仍需排序，否則隊(duì)列長度會(huì)爆炸。23.在需求風(fēng)險(xiǎn)登記冊(cè)里，“業(yè)務(wù)方口頭承諾變卦”應(yīng)記錄為外部風(fēng)險(xiǎn)。答案：對(duì)解析：屬于干系人風(fēng)險(xiǎn)，外部類別。24.使用UML用例圖時(shí)，用例之間若出現(xiàn)<>關(guān)系，意味著基礎(chǔ)用例依賴擴(kuò)展用例才能完整。答案：錯(cuò)解析：擴(kuò)展用例可選，基礎(chǔ)用例可獨(dú)立執(zhí)行。25.需求評(píng)審檢查單里加入“該需求是否可拆解到小于8人日”條款，可防止顆粒度過大。答案：對(duì)解析：8人日是常見迭代容量閾值。四、填空題（每空2分，共20分）26.在需求分解過程中，若發(fā)現(xiàn)某史詩級(jí)故事無法在一迭代內(nèi)完成，應(yīng)繼續(xù)拆分為________，直到符合INVEST原則中的________條件。答案：用戶故事；可協(xié)商（Negotiable）27.當(dāng)業(yè)務(wù)方提出“系統(tǒng)必須在0.5秒內(nèi)返回結(jié)果”時(shí)，該需求屬于________需求中的________子類。答案：非功能性；性能28.使用莫斯科法則時(shí)，為避免“Shouldhave”膨脹，可再引入________系數(shù)對(duì)業(yè)務(wù)價(jià)值與________進(jìn)行加權(quán)排序。答案：延遲成本；技術(shù)成本29.需求驗(yàn)證的四個(gè)維度分別是正確性、完整性、________與________。答案：一致性；可驗(yàn)證性30.在需求版本控制中，采用________地址（如http://xxx/requirements/req-123?v=2.1）可確保任何時(shí)刻都能追溯到________。答案：永久；歷史版本五、簡答題（每題10分，共30分）31.某SaaS公司準(zhǔn)備推出“智能排班”模塊，客戶行業(yè)跨度大，需求差異明顯。請(qǐng)描述如何運(yùn)用“需求分層”方法，在三個(gè)月內(nèi)完成MVP并控制范圍蔓延。答案：第一步，建立需求分層模型：L1業(yè)務(wù)目標(biāo)（降本增效）、L2業(yè)務(wù)流程（排班、調(diào)班、換班）、L3系統(tǒng)能力（自動(dòng)算法、手動(dòng)拖拽、沖突提示）。第二步，用行業(yè)畫像矩陣將客戶按“班次復(fù)雜度”“員工規(guī)模”“合規(guī)強(qiáng)度”三維聚類，選出占80%營收的“零售連鎖+輕制造”群體作為首發(fā)靶心。第三步，針對(duì)靶心客戶，采用“需求切片”技術(shù)，將L3能力拆成：①規(guī)則引擎（必須）②自動(dòng)優(yōu)化（爭(zhēng)?。垡苿?dòng)端調(diào)班（可選）第四步，用WSJF公式（用戶商業(yè)價(jià)值×?xí)r間關(guān)鍵性×降低風(fēng)險(xiǎn)/工作量）對(duì)切片打分，僅保留得分最高的前13條需求進(jìn)入MVP。第五步，建立“需求護(hù)欄”：任何新增需求必須證明可提升靶心客戶的核心指標(biāo)（如排班時(shí)間縮短25%），否則放入下一版本池。第六步，每兩周舉辦“需求演示日”，邀請(qǐng)客戶代表用真實(shí)數(shù)據(jù)試用，若客戶不愿付費(fèi)試點(diǎn)，則立即降級(jí)。通過以上分層、切片、護(hù)欄三步，三個(gè)月交付的MVP功能點(diǎn)控制在40個(gè)以內(nèi)，范圍蔓延率<5%，首批10家客戶簽約ARR達(dá)240萬元。32.請(qǐng)闡述“需求可追蹤性”在混合敏捷（Agile+Waterfall）項(xiàng)目中的實(shí)施難點(diǎn)，并給出三條可落地的改進(jìn)措施。答案：難點(diǎn)1：階段閘門評(píng)審要求完整的雙向追蹤，而敏捷擁抱變化，故事拆分頻繁，導(dǎo)致矩陣維護(hù)成本高。難點(diǎn)2：瀑布側(cè)使用Doors，敏捷側(cè)使用Jira，工具鏈割裂，無法自動(dòng)同步鏈接。難點(diǎn)3：測(cè)試用例在敏捷側(cè)按迭代更新，瀑布側(cè)需回歸全部基線，版本沖突導(dǎo)致“紅綠”狀態(tài)失真。改進(jìn)措施：①建立“需求唯一標(biāo)識(shí)”規(guī)范，史詩、特性、故事、測(cè)試用例均使用同一UUID前綴，通過Git鉤子強(qiáng)制提交消息包含ID，實(shí)現(xiàn)代碼級(jí)追蹤。②采用輕量化中間層“追蹤代理”，每日定時(shí)把Jira故事狀態(tài)同步到Doors模塊，同步腳本開源，減少手工維護(hù)。③引入“追蹤健康度”儀表盤，用爬蟲比對(duì)Jira與測(cè)試管理工具中URL，若出現(xiàn)孤兒需求或懸空用例，自動(dòng)郵件提醒責(zé)任人，每周下降率納入KPI。實(shí)施三個(gè)月后，追蹤覆蓋率從62%提升到91，回歸測(cè)試周期縮短18%。33.說明如何運(yùn)用“需求成本—收益雙曲線”指導(dǎo)重大需求決策，并給出具體計(jì)算示例。答案：雙曲線橫軸為時(shí)間，縱軸為累計(jì)收益或成本。收益曲線呈S型：早期增長慢（市場(chǎng)教育），中期陡峭，后期飽和；成本曲線呈指數(shù)型：早期線性，后期因技術(shù)債、回歸測(cè)試、兼容呈指數(shù)上升。決策規(guī)則：當(dāng)兩條曲線斜率相等時(shí)（邊際收益=邊際成本），即為最優(yōu)停點(diǎn)；若業(yè)務(wù)強(qiáng)制繼續(xù)，需額外論證戰(zhàn)略價(jià)值。示例：某支付公司計(jì)劃接入“數(shù)字人民幣”通道。收益測(cè)算：T0：0元T1（6個(gè)月）：新增交易筆數(shù)500萬/年，單筆手續(xù)費(fèi)0.1%，客單價(jià)80元，收益400萬元T2（12個(gè)月）：筆數(shù)1200萬，收益960萬元T3（18個(gè)月）：筆數(shù)2000萬，收益1600萬元成本測(cè)算：T1：開發(fā)+合規(guī)+運(yùn)營=300萬元T2：維護(hù)+營銷+擴(kuò)容=700萬元T3：技術(shù)債重構(gòu)+安全等保=1500萬元計(jì)算邊際：T1→T2邊際收益=560萬元，邊際成本=400萬元，ROI=1.4T2→T3邊際收益=640萬元，邊際成本=800萬元，ROI=0.8<1結(jié)論：項(xiàng)目應(yīng)在T2節(jié)點(diǎn)停止功能擴(kuò)張，轉(zhuǎn)入維護(hù)模式，除非央行強(qiáng)制新增硬件模塊，否則不再投入。六、案例分析題（25分）34.背景：“極速達(dá)”生鮮電商計(jì)劃上線“30分鐘到家”業(yè)務(wù)，CEO要求三個(gè)月內(nèi)復(fù)制到五個(gè)城市。需求調(diào)研階段，業(yè)務(wù)部門提交了一份含147條需求的清單，其中高頻出現(xiàn)以下三條：R1：用戶可修改配送地址，且不受距離限制。R2：騎手App需支持“同時(shí)接10單”模式。R3：系統(tǒng)若預(yù)測(cè)超時(shí)，自動(dòng)為用戶賠付5元紅包。技術(shù)委員會(huì)評(píng)估后給出風(fēng)險(xiǎn)：①地址無限制將導(dǎo)致騎手空駛率上升，履約成本增加18%；②同時(shí)10單對(duì)路徑算法復(fù)雜度是NP-Hard，現(xiàn)有服務(wù)器撐不住；③自動(dòng)賠付可能被惡意刷單，預(yù)估月?lián)p失200萬元。請(qǐng)回答：（1）用“需求逆向工程”方法，還原