- 识别干系人：客户、系统架构、测试、法规
- 选择 elicitation 技术：访谈、工作坊、文档分析、原型
- 分类与优先级：功能/非功能，MoSCoW 或 Kano
- 输出与确认：形成需求条目，与干系人确认
4. 需求管理与双向追溯面试
第4章 · 需求管理与双向追溯
需求 elicitation · 需求分析 · 追溯矩阵 · 变更控制 · 需求评审
在 ASPICE 的 SYS.2 / SWE.1 等过程域中，需求管理与双向追溯是评估的重中之重。面试官不仅考察你是否理解“追溯矩阵”的格式，更关注你如何从模糊的客户期望中提炼需求、如何应对变更、如何组织评审。本章通过 3 个高频问答与 1 个真实项目模板，帮你建立结构化的回答路径。
面试问答卡片
请描述你如何从客户或系统需求中 elicitation 出软件需求？
回答框架 4步
示例回答 60-100字
我会先识别所有干系人，包括客户、系统工程师和测试代表。然后通过工作坊和文档分析获取原始需求，用用户故事和用例描述功能，同时记录非功能需求。最后与干系人逐条确认，确保需求无歧义、可验证，并录入需求管理工具。
可能追问
如果客户说不清楚需求，你怎么办？
如何区分“需求”和“设计约束”？
elicitation 的输出物有哪些？
避坑提醒：不要只罗列技术名词，要体现“从模糊到清晰”的转化过程，并强调与干系人的持续确认。
你如何建立和维护需求追溯矩阵？变更时如何保证追溯一致性？
回答框架 3层
- 建立追溯：从利益相关者需求→系统需求→软件需求→测试用例，双向链接
- 变更触发：任何需求变更必须更新追溯矩阵，并做影响分析
- 工具与评审：使用 DOORS/Polarion 等工具，定期审计追溯覆盖率
示例回答 60-100字
我使用需求管理工具建立双向追溯，从客户需求到软件需求再到测试用例。变更请求提出后，先做影响分析，识别受影响的需求和测试，更新追溯矩阵，并通知相关干系人。每次基线后都会审计追溯覆盖率，确保没有遗漏。
可能追问
追溯矩阵的粒度应该多细？
如何处理“孤儿需求”？
变更控制委员会（CCB）的职责是什么？
避坑提醒：避免只说“用工具自动生成”，要强调人工评审和影响分析的必要性，以及追溯的“双向”含义。
你如何组织一次有效的需求评审？评审的检查清单有哪些？
回答框架 4要素
- 评审准备：提前分发需求文档，明确评审目标
- 参与者：客户、开发、测试、系统、质量
- 检查清单：正确性、无歧义、可验证、一致性、可追溯
- 输出与跟踪：记录问题，跟踪关闭，更新基线
示例回答 60-100字
我会提前将需求文档发给评审人，并附上检查清单，包括是否可测试、是否与上层需求一致、是否无歧义。评审会上逐条讨论，记录问题并指定责任人。会后跟踪问题关闭，更新需求基线，确保评审闭环。
可能追问
如果评审中客户和开发意见冲突怎么办？
如何衡量需求评审的有效性？
评审和走查、审查的区别？
避坑提醒：不要只描述流程，要突出“检查清单”和“问题跟踪”，体现你对需求质量的把控。
真实项目模板 · 需求管理与双向追溯
车载信息娱乐系统 · 需求管理与追溯落地
项目名称
IVI 平台需求工程与追溯体系搭建
业务背景
为某主机厂开发新一代车载信息娱乐系统，需满足 ASPICE L2 要求，实现需求全生命周期管理。
规模指标
- 需求条目：1200+
- 追溯链接：3500+
- 变更请求：200+
- 团队规模：15人
技术栈 / 工具
- 需求管理：IBM DOORS Next
- 建模：Enterprise Architect
- 测试管理：Jira + Zephyr
- 版本控制：Git + Jenkins
核心难点
- 客户需求模糊，且频繁变更，需快速建立基线并控制变更影响。
- 多供应商协作，追溯链跨组织，需统一需求标识和链接规则。
- ASPICE 评估要求双向追溯覆盖率 100%，且变更后必须更新。
面试高频追问
你们如何保证跨供应商的追溯一致性？
变更影响分析具体怎么做？有没有自动化？
追溯覆盖率如何度量？有没有遇到“孤儿需求”？
需求评审中发现的典型问题有哪些？
可迁移回答话术：“在这个项目中，我主导建立了从客户需求到软件需求再到测试用例的双向追溯矩阵，并制定了变更控制流程。通过定期审计和自动化报告，我们将追溯覆盖率从 70% 提升到 98%，变更影响分析时间缩短了 40%。这套方法可以复用到任何需要 ASPICE 合规的嵌入式项目。”
⚡ 本章重点：需求获取要“从模糊到清晰”，追溯矩阵要“双向且可审计”，变更控制要“影响分析先行”，需求评审要“检查清单+闭环跟踪”。