2025年需求分析师试题及答案

2025年需求分析师试题及答案一、单项选择题（每题2分，共20分）1.以下哪项不属于需求工程中的“需求分类”维度？A.业务需求B.用户需求C.技术需求D.系统需求答案：C解析：需求工程中通常将需求分为业务需求（组织层面目标）、用户需求（用户具体任务）、系统需求（系统功能/非功能要求），技术需求属于系统需求的子项，非独立分类维度。2.某医疗系统需满足“患者电子病历存储时间不低于30年”，这属于：A.功能需求B.性能需求C.安全需求D.合规性需求答案：D解析：合规性需求指系统需符合法律法规或行业标准（如《医疗机构病历管理规定》要求病历保存年限），题干强调存储时间的强制性要求，属于合规性需求。3.以下需求描述中，符合“清晰性”原则的是：A.“系统应快速响应用户操作”B.“用户登录时，系统需在2秒内返回验证结果”C.“系统应具备高可用性”D.“后台管理界面要友好”答案：B解析：清晰性要求需求可量化、无歧义。选项B明确了“2秒内”的时间阈值，符合可验证性；其他选项存在“快速”“高可用性”“友好”等模糊表述。4.采用用户故事（UserStory）描述需求时，核心三要素是：A.角色、功能、验收标准B.角色、活动、价值C.场景、目标、约束D.输入、处理、输出答案：B解析：用户故事的标准模板为“作为[角色]，我想要[活动]，以便[价值]”，三要素为角色（Who）、活动（What）、价值（Why）。5.需求评审时发现“用户下单后，系统需发送短信通知”与“用户可关闭短信通知功能”存在冲突，这属于需求的：A.不一致性B.不完整性C.不可验证性D.冗余性答案：A解析：不一致性指需求间逻辑矛盾（如强制通知与可关闭功能冲突）；不完整性指缺少必要信息；不可验证性指无法测试；冗余性指重复描述。6.某银行核心系统升级项目中，“支持单日10万笔交易处理”属于：A.功能需求B.性能需求C.安全需求D.扩展性需求答案：B解析：性能需求描述系统在容量、速度、吞吐量等方面的能力，题干“单日10万笔交易”是吞吐量指标，属于性能需求。7.需求跟踪矩阵（RTM）的核心作用是：A.记录需求变更历史B.确保需求与测试用例一一对应C.展示需求与业务目标的关联D.以上都是答案：D解析：需求跟踪矩阵需覆盖需求来源（业务目标）、需求描述、设计文档、测试用例、验收标准等维度，同时记录变更历史，确保需求全生命周期可追溯。8.采用Kano模型对需求优先级排序时，“用户未明确提出但实现后能大幅提升满意度”的需求属于：A.基本型需求B.期望型需求C.兴奋型需求D.无差异型需求答案：C解析：Kano模型中，兴奋型需求（Delighter）是用户未预期的功能，实现后能显著提升用户体验；基本型需求是必须满足的“门槛”；期望型需求是用户明确要求的；无差异型需求对用户满意度无影响。9.以下工具中，最适合用于分析用户任务流程的是：A.用例图（UseCaseDiagram）B.流程图（Flowchart）C.实体关系图（ERDiagram）D.状态图（StateDiagram）答案：B解析：流程图通过步骤、分支、循环等元素直观展示用户完成任务的操作路径，是分析任务流程的核心工具；用例图侧重系统功能边界；ER图用于数据建模；状态图描述对象状态变化。10.需求变更管理中，“变更影响分析”的关键输出是：A.变更请求表（CR）B.变更成本评估报告C.需求跟踪矩阵更新D.以上都是答案：D解析：变更影响分析需输出变更请求表（记录变更内容）、成本评估（时间、资源、风险）、需求跟踪矩阵更新（确保关联需求同步调整），三者缺一不可。二、简答题（每题8分，共40分）1.简述需求验证（RequirementValidation）与需求确认（RequirementVerification）的区别，并说明常用方法。答案：需求验证（Validation）关注“是否做了正确的事”，即需求是否符合业务目标和用户真实需求；需求确认（Verification）关注“是否正确地做事”，即需求描述是否清晰、完整、一致、可测试。常用方法：-验证方法：用户原型测试（让真实用户操作原型并反馈）、业务场景模拟（通过角色扮演验证需求覆盖业务流程）、需求-目标追溯（检查需求是否支撑顶层业务目标）。-确认方法：需求评审（组织跨部门专家逐条审查）、需求测试（编写测试用例验证需求可实现性）、形式化验证（用数学模型检查需求逻辑一致性）。2.列举需求优先级排序的三种方法，并说明各自适用场景。答案：（1）MoSCoW法：将需求分为“必须有（Must）”“应该有（Should）”“可以有（Could）”“不会有（Won’t）”四类。适用于敏捷开发或资源受限场景，快速划分核心与非核心需求。（2）商业价值-实现成本矩阵：横轴为实现成本（低-高），纵轴为商业价值（低-高），将需求分为“高价值低成（优先）”“高价值高成本（规划）”“低价值低成本（可选）”“低价值高成本（排除）”。适用于需要平衡业务收益与资源投入的中大型项目。（3）Kano模型：根据需求对用户满意度的影响分为基本型、期望型、兴奋型等。适用于用户体验导向的产品（如C端应用），帮助识别“用户未明说但能带来惊喜”的需求。3.说明用户故事的“INVEST”原则，并举例说明。答案：“INVEST”原则是用户故事的质量标准：-独立（Independent）：故事间无依赖，可独立开发测试。例如“用户查看订单详情”与“用户修改收货地址”应是独立故事，而非绑定为一个。-可协商（Negotiable）：故事是沟通起点而非合同，允许开发团队与用户协商细节。例如“用户导出订单报表”的格式（Excel/CSV）可在开发中根据技术可行性调整。-有价值（Valuable）：故事对用户或业务有明确价值。例如“客服快速查询用户历史咨询记录”比“系统日志格式优化”更具用户价值。-可估算（Estimable）：故事大小适中，可估算开发时间。避免“系统性能优化”这类模糊故事，应拆分为“订单查询响应时间优化至2秒内”。-小（Small）：故事需在1-3个迭代内完成。例如将“实现会员体系”拆分为“会员等级规则配置”“积分计算逻辑”等小任务。-可测试（Testable）：故事需有明确验收标准。例如“用户登录失败时，提示‘账号或密码错误’”比“登录失败有提示”更易测试。4.需求分析师在敏捷开发中需承担哪些关键职责？答案：（1）需求拆分与用户故事编写：将模糊的高层需求拆分为符合“INVEST”原则的用户故事，确保每个迭代的需求颗粒度适中。（2）参与每日站会（DailyScrum）：同步需求进展，解答开发团队对需求的疑问，调整故事细节以适应开发实际。（3）组织迭代评审（SprintReview）：与用户验收团队一起验证迭代交付的功能是否满足需求，收集反馈并更新需求列表（ProductBacklog）。（4）需求优先级调整：根据用户反馈、市场变化或技术风险，动态调整ProductBacklog的优先级，确保开发资源投入到高价值需求。（5）需求文档轻量化维护：在敏捷“文档够用即可”原则下，维护用户故事、验收标准等核心文档，避免过度文档化影响效率。5.分析“需求镀金（GoldPlating）”的危害，并提出预防措施。答案：危害：-资源浪费：开发团队超出需求范围添加“额外功能”（如未要求的界面美化），占用本可用于核心需求的时间与人力。-增加复杂度：冗余功能可能引入新的bug或与现有功能冲突，提高系统维护成本。-用户困惑：非必要功能可能干扰用户核心任务流程（如购物车页面添加无关营销弹窗），降低用户体验。预防措施：-严格需求边界管理：在需求文档中明确“范围外”内容，开发前与团队对齐需求边界。-强化验收标准：每个用户故事需定义清晰的验收条件（如“仅支持微信、支付宝两种支付方式”），避免开发团队自行扩展。-敏捷迭代验证：每个迭代交付后，由用户直接验收，确保功能符合原始需求，及时纠正“镀金”倾向。-团队培训：强调“满足需求即可”的理念，避免开发人员因“展示技术能力”而过度设计。三、案例分析题（30分）背景：某电商公司计划在2025年Q4推出“双11全球购”活动，需求团队收集到以下需求：1.运营部：活动期间需支持“跨店铺满减”（如满500减80），并在商品详情页、购物车、结算页显示优惠金额，要求10月15日前完成开发。2.技术部：当前促销系统架构仅支持“单店铺满减”，扩展跨店铺逻辑需重构优惠引擎，预计开发周期60天（10月1日-11月29日），可能影响现有单店铺活动的稳定性。3.用户调研：82%的用户希望“优惠规则简单易懂”，75%的用户表示“复杂优惠会放弃参与”。4.数据部：去年双11因优惠计算错误导致客诉率上升15%，要求新系统需100%准确计算优惠，且故障恢复时间≤10分钟。问题：（1）分析当前需求的主要冲突点，并说明原因（8分）。（2）提出协调运营部与技术部需求的具体方案（10分）。（3）设计“跨店铺满减”需求的验收测试策略（12分）。答案：（1）主要冲突点及原因：-时间冲突：运营部要求10月15日前完成开发（剩余35天），但技术部评估需60天，时间缺口25天。-复杂度与用户体验冲突：跨店铺满减规则本身复杂（涉及多店铺商品组合），与用户“规则简单易懂”的需求矛盾，可能导致参与率下降。-稳定性与新功能冲突：技术部指出扩展逻辑可能影响现有单店铺活动稳定性，而数据部要求“100%准确”“故障恢复≤10分钟”，对系统可靠性提出高要求。（2）协调运营部与技术部的方案：①分阶段上线：-第一阶段（10月1日-10月30日）：完成核心功能开发（跨店铺满减计算引擎、购物车/结算页显示），优先保障基础逻辑正确性，暂不开放商品详情页显示（可通过“活动规则说明”替代）。-第二阶段（11月1日-11月10日）：优化商品详情页显示、增加规则提示（如“点击查看跨店满减组合”），同步修复第一阶段测试中发现的bug。②降低技术风险：-采用“灰度发布”：上线前在5%的用户中测试跨店铺满减功能，收集性能数据（如计算耗时、前端渲染速度），若出现超预期延迟则回滚至单店铺模式。-预留“开关”功能：在系统中增加“跨店铺满减”启用/关闭按钮，若活动期间出现大面积故障，可快速切换至单店铺满减，保障活动整体可用。③用户体验优化：-简化规则表述：在页面顶部用“主标题+副标题”形式展示（如“跨店满500减80”→“凑满500，立省80！支持任意3家全球购店铺组合”）。-增加“智能凑单”工具：开发小工具自动计算用户当前购物车中可参与跨店满减的商品组合（如“再选1件XX商品，可再减80元”），降低用户理解成本。（3）验收测试策略：①功能测试：-正常流程：选择3家不同店铺的商品组合（总金额≥500元），验证购物车/结算页显示的优惠金额是否正确（如500元减80元后应付420元）。-边界情况：测试499元（不满500元无优惠）、500元（减80元）、1000元（减160元）等金额，确认计算逻辑无误差。-异常场景：测试部分商品不参与活动（如某店铺标记“不参与跨店满减”），验证系统是否自动排除该商品金额（如总金额=400元（可参与）+100元（不可参与）=400元，不满500元无优惠）。②性能测试：-压力测试：模拟10万用户同时添加跨店铺商品到购物车，验证优惠计算引擎的响应时间（目标≤1秒）、数据库QPS（查询每秒请求数）是否达标。-容量测试：测试系统支持的最大跨店铺组合数（如同时选择20家店铺的商品），确认无内存溢出或卡顿现象。③稳定性测试：-故障注入：模拟优惠引擎服务器宕机，验证系统是否自动切换至备用服务器，并在10分钟内恢复（通过监控工具记录故障恢复时间）。-长时间运行测试：持续48小时运行跨店铺满减功能，检查是否存在内存泄漏、连接池耗尽等潜在问题。④用户体验测试：-可用性测试：让100名真实用户（覆盖老用户、新用户、不同年龄层）模拟凑单过程，收集“规则是否易懂”“凑单工具是否有用”等反馈，要求至少90%用户表示“操作无困难”。-文案准确性测试：检查商品详情页、购物车、结算页的所有优惠提示文案（如“已优惠80元”）是否与实际计算一致，避免误导用户。四、论述题（10分）结合当前数字化转型趋势（如大数据、AI、低代码），论述需求分析师应具备的核心能力升级方向。答案：在企业数字化转型加速的背景下，需求分析师的角色从“需求翻译员”升级为“业务-技术桥梁”，需重点提升以下能力：1.业务建模与战略对齐能力：数字化转型要求需求不仅满足当前业务，更需支撑企业长期战略（如从“卖产品”转向“卖服务”）。需求分析师需掌握业务流程建模（BPM）、价值流分析（VSM）等工具，能将顶层战略（如“客户体验优先”）拆解为可落地的系统需求（如“全渠道客户数据统一视图”）。例如，某制造企业转型为“设备+运维服务”模式，需求分析师需识别“设备运行数据实时采集”“故障预测模型接口”等需求，而非仅关注传统销售流程。2.数据驱动需求挖掘能力：大数据与AI技术使企业从“经验决策”转向“数据决策”。需求分析师需具备数据敏感度，能通过用户行为数据（如APP点击路径）、业务运营数据（如订单转化率）挖掘隐性需求。例如，某零售企业发现“用户浏览商品后30分钟内未下单”的比例高达40%，需求分析师需进一步分析：是否因支付流程复杂？是否缺少“一键收藏-稍后购买”功能？并将数据结论转化为具体需求（如“添加收藏后自动推送限时优惠通知”）。3.低代码/无代码平台适配能力：低代码平台（如微软PowerApps、腾讯轻联）加速了需求