2026年需求分析考试题及答案

2026年需求分析考试题及答案一、单项选择题（每题2分，共20分）1.在需求获取阶段，下列哪项活动最能有效降低需求变更的概率？A.频繁召开评审会议B.采用原型法快速确认用户意图C.要求用户一次性签署完整需求文档D.将需求全部转化为用例图答案：B解析：原型法通过可执行模型让用户提前“体验”系统，可尽早暴露理解偏差，减少后期变更。A项评审会议虽重要，但属于验证手段而非获取手段；C项一次性签署违背迭代思想；D项用例图只是表达方式，不直接降低变更概率。2.某项目采用MoSCoW法则进行优先级划分，其中“Couldhave”需求在迭代计划中的典型处理策略是：A.必须在本轮迭代完成B.本轮迭代若资源剩余则考虑C.直接移入Backlog最底部D.转作二期需求永不实施答案：B解析：MoSCoW中Couldhave属于“锦上添花”类，仅当Must、Should均已满足且团队仍有裕量时才实施，故选B。3.下列关于用户故事“INVEST”原则的描述，错误的是：A.Negotiable强调故事细节可协商B.Valuable要求故事对终端用户或采购方有价值C.Small指故事越大越好，可减少管理开销D.Testable要求故事有明确验收标准答案：C解析：Small强调故事粒度适中，能在一次迭代内完成；过大反而增加风险与管理复杂度，故C错误。4.在质量功能展开(QFD)中，用于量化顾客需求与技术特性相关程度的工具是：A.亲和图B.矩阵图C.屋脊矩阵D.关系矩阵答案：D解析：QFD核心为“质量屋”，其中左墙为顾客需求，天花板为技术特性，两者交叉处为关系矩阵，用符号或数值表示相关程度。5.某金融系统要求“交易响应时间≤300ms，P99≤500ms”，该需求属于：A.功能需求B.业务规则C.非功能需求—性能D.设计约束答案：C解析：响应时间属于典型性能指标，归为非功能需求。6.在需求跟踪矩阵中，RTM的“双向跟踪”是指：A.需求可跟踪到代码，代码可回溯到需求B.用户需求可跟踪到系统需求，系统需求可跟踪到测试用例C.需求可向前跟踪到业务目标，向后跟踪到交付物D.高层需求与低层需求可互相追溯答案：C解析：双向=前向（需求→设计→代码→测试）与后向（交付物→需求）均可追溯，确保范围不漂移。7.下列关于UML用例描述的写法，符合规范的是：A.用户输入密码，系统验证通过B.系统查询数据库返回结果C.用户选择“导出报表”，系统生成Excel并弹出下载框D.ATM吐钞，用户拿钱离开答案：C解析：用例描述应采用“主语-谓语-宾语”视角，主语多为参与者，C项完整描述参与者动作与系统响应；A、B主语混乱；D缺少价值闭环。8.在需求优先级谈判中，若多方对“Must”级需求存在冲突，需求分析师首先应：A.直接上报项目发起人裁决B.采用多标准决策分析（如AHP）量化权重C.要求各方自行协商直到统一D.将冲突需求全部标为Must以规避风险答案：B解析：结构化方法可减少拍脑袋决策，AHP通过成对比较把主观判断量化，为后续决策提供依据。9.下列哪项最符合“需求可验证性”原则？A.系统应易于使用B.系统界面应美观大方C.系统应支持1000并发用户，且CPU利用率≤70%D.系统代码应具备可读性答案：C解析：可验证=可测量或可观察；C项给出明确量化指标，可通过性能测试验证。10.在需求管理工具中，以下哪项功能对“版本基线”支持最关键？A.富文本编辑器B.权限管理C.快照(Snapshot)与对比(Diff)D.看板视图答案：C解析：快照可在任意时刻冻结需求状态，Diff可查看变更细节，是基线管理的核心。二、多项选择题（每题3分，共15分）11.下列属于需求获取“情境调查”(ContextualInquiry)核心原则的有：A.主人-客人关系B.合作伙伴关系C.解释与验证D.焦点小组E.被动观察答案：B、C解析：情境调查四原则：Context、Partnership、Interpretation、Focus；B对应Partnership，C对应Interpretation；A、E为干扰项；D为另一种获取技术。12.以下关于“需求变更影响分析”的描述，正确的有：A.只需评估对代码的影响B.应重新评估项目风险C.需更新需求跟踪矩阵D.必须重新进行全部回归测试E.应评估对业务目标的影响答案：B、C、E解析：影响分析需全方位，A过于片面；D“全部回归”通常不现实，采用风险驱动测试策略。13.在敏捷项目中，可用来度量“需求交付速率”的指标有：A.故事点完成速率B.需求响应时间C.迭代燃尽图斜率D.需求缺陷密度E.累计流图(CFD)答案：A、C、E解析：A、C直接反映交付速率；E通过WIP与周期时间间接反映；B为运维指标；D为质量指标。14.下列属于“需求建模”活动产出物的有：A.数据流图(DFD)B.用户故事地图C.软件测试报告D.状态机图E.系统愿景声明答案：A、B、D解析：C为测试阶段产出；E为项目启动阶段产出，不属于建模活动。15.在需求文档评审中，使用“走查”(Walkthrough)方式的特点有：A.作者主导，逐步讲解B.以发现缺陷为主要目的C.评审员需提前阅读材料D.可现场达成共识并记录问题E.需正式记录缺陷清单并跟踪关闭答案：A、D解析：走查以学习、沟通为主，作者主导；B、E为“审查”(Inspection)特点；C为审查前提，走查可不提前阅读。三、判断题（每题1分，共10分）16.需求分析师只需关注用户需求，无需理解业务战略。答案：错解析：需求必须对齐业务目标，否则易陷入“做得快但做得错”。17.在需求优先级谈判中，Kano模型将需求分为基本型、期望型、魅力型。答案：对18.采用用户故事时，验收标准(AC)必须在故事创建阶段一次性写全，迭代中不可再改。答案：错解析：AC可随细节澄清而演进，但应在开发前稳定。19.需求跟踪矩阵只能用于瀑布模型，敏捷项目无需维护。答案：错解析：敏捷虽轻量，但仍需最小可行追溯，如用户故事-测试用例对应。20.若需求描述中出现“etc.”、“and/or”等模糊词，则违反“明确性”原则。答案：对21.系统“可扩展性”属于设计约束，而非功能需求。答案：错解析：可扩展性是非功能需求，不是约束；约束通常指必须使用的技术、标准。22.采用UseCase2.0时，“用例切片”(Use-CaseSlice)可用于敏捷迭代计划。答案：对23.需求验证与需求确认是同一活动的不同翻译。答案：错解析：验证(Verification)检查“做得对不对”，确认(Validation)检查“做的是否是用户所需”。24.在需求风险分类中，“用户代表不稳定”属于项目风险而非需求风险。答案：错解析：用户代表变动会导致需求漂移，归为需求风险。25.需求文档通过评审后，任何变更都必须走CCB流程。答案：对四、简答题（每题10分，共30分）26.某B2B电商平台提出“供应商可在24小时内完成商品上架审批流程”。请将该需求改写为符合SMART原则的用户故事，并给出3条可执行的验收标准。答案示例：用户故事：作为“已通过资质审核的供应商”，我希望“在提交商品资料后24小时内获得上架审批结果”，以便于“及时铺货并响应市场变化”。验收标准(AC)：1.供应商在北京时间10:00提交商品，系统在次日10:00前返回“通过”或“驳回”结果；2.若审批驳回，系统需在结果中返回≥1条驳回理由，且理由可导出为PDF；3.从提交到结果返回的时长以系统时间戳计算，24小时=86400秒，允许偏差+0/-300秒。27.解释“需求镀金”(GoldPlating)与“需求蔓延”(ScopeCreep)的区别，并各举一例说明其对项目的负面影响。答案：需求镀金：开发方主动增加超出需求说明的功能，以为“给用户惊喜”。例如：合同要求“报表导出为Excel”，开发方额外实现PPT导出，导致测试工作量增加20%，最终交付延期两周。需求蔓延：需求方在基线后不断提出新需求或变更原需求。例如：电商系统在Beta阶段，销售部门要求新增“直播带货”模块，未调整进度与预算，导致团队加班、质量下降，上线后缺陷率上升35%。核心区别：镀金是“开发方自愿”，蔓延是“需求方提出”；两者均造成成本、进度超支，但治理策略不同：镀金需加强团队范围意识，蔓延需强化变更控制。28.简述“业务规则”与“功能需求”的区别，并给出“信用卡计息”场景下的各一条示例。答案：业务规则：组织为达成业务目标而制定的策略、法规或算法，具有跨系统、跨流程的稳定性。功能需求：系统为支持业务规则而必须具备的具体行为或能力。示例：业务规则：信用卡账单日后未全额还款，按日息0.05%计息，复利按月计算。功能需求：系统每日02:30批处理，对未还清金额计算当日利息并更新账户余额，计算结果保留两位小数。五、综合分析题（25分）29.背景：某市“智慧停车”项目计划建设路侧泊位诱导系统，涉及市政、交警、平台运营商、车主四类干系人。项目采用“政府监管、企业运营”模式，政府要求数据实时接入市大数据中心，企业追求盈利，车主关注体验。需求获取阶段，团队通过问卷、访谈、影子观察收集到以下原始陈述：R1：车主A说“我找车位绕了三圈，油费都够交停车费了。”R2：市政管理处文件要求“泊位数据上传延迟≤60秒”。R3：运营商技术总监说“我们已有App，最好复用，别再开发新入口。”R4：交警代表强调“违停自动识别必须联动处罚，否则诱导等于白做。”R5：车主B说“要是能预约车位，提前10分钟锁定就好了。”R6：市政信息办规定“所有前端设备必须支持国密算法SM4加密。”任务：(1)请使用Volere需求模板，为R2、R5分别写出一条“正式需求描述”（含需求编号、需求类型、描述、验收标准）。（10分）(2)识别并列出三条“非功能需求”，注明所属类别（性能/安全/兼容性…）。（6分）(3)针对“预约车位”功能，画出简化用例图，需包含参与者、用例及<<include>>/<<extend>>关系。（5分）(4)项目进入第3个迭代时，市政新增要求“新能源车牌必须免费停车1小时”，该变更可能影响哪些已定义需求？请给出变更影响分析步骤及输出物。（4分）答案：(1)正式需求描述：需求编号：PR-007需求类型：非功能需求—性能描述：系统应将路侧泊位占用状态变化信息实时同步至市大数据中心。验收标准：a.状态变化指车辆驶入或驶离被检测设备识别后生成事件；b.从事件生成到市大数据中心收到该条数据的时间≤60秒；c.以大数据中心服务器时间戳为准，随机抽样7天，每天100条，合格率≥99%。需求编号：UR-012需求类型：功能需求描述：系统应为车主提供泊位预约服务，允许车主在到达前提前锁定泊位。验收标准：a.车主通过App选择目标区域泊位，点击“预约”后，系统立即返回预约成功或失败；b.预约锁定时长为10分钟±30秒，超时自动释放；c.同一车牌在同一时刻只能有1个有效预约；d.预约成功率≥95%（以一周实测数据为准）。(2)非功能需求：NF-001性能：泊位状态查询接口平均响应时间≤300ms，P99≤800ms。NF-002安全：前端设备与平台通信采用SM4加密，密钥管理符合国密标准。NF-003可用性：App服务可用性≥99.9%（年停机时间≤8.76小时）。(3)用例图（文字描述）：参与者：车主、支付系统、泊位检测器用例：预约车位（车主）支付预约费用（include）释放预约车位（extend：超时自动释放）查询泊位状态（车主）关系：“预约车位”include“支付预约费用”“释放预约车位”extend“预约车位”（条件：超时）(4)变更影响分析步骤：Step1接收变更申请，记录编号CR-2026-03-01；Step2评估业务价值：新能源推广政策，政府补贴潜在成本；Step3追溯RTM，识别受影响需求：UR-015“计费规则引擎”需新增免费时长判断；UR-008“车牌识别”需区分新能源车牌；NF-001性能：免费逻辑增加识别耗时，需重新测试；Step4评估工作量：开发4人日、测试3人日；Step5CCB评审：同意纳入第4迭代，范围顺延1周；输出物：《变更影响分析报告》《更新后的需求跟踪矩阵v3.2》《迭代计划调整表》。六、计算题（10分）30.某停车诱导系统