考试大纲如下EU 5.1 影响因素L2EO 5.1.1 了解影响需求工程的重要因素(L1)EO 5.1.2 理解这些因素是如何以及为什么会产生影响(L2)EU 5.2 需求工程过程方面L2EO 5.2.1 理解在配置需求工程过程时要考虑的方面(L2)EU 5.3 配置需求工程过程L3EO 5.3.1 了解典型的需求工程过程配置(L1)EO 5.3.2 理解需求工程过程的配置步骤(L2)EO 5.3.3 对于简单的系统和开发设置选择并应用一个合适的需求工程过程配置(L3)影响因素这两张图分别回答了关于需求工程过程的**“宏观定位”EU 5和“微观输入”EU 5.1**。它们之间的关系可以概括为图2的9个因素是“食材和调料”图1的4个结果是“烹饪出的菜肴”。我帮你把这两张图合并解读并重点剖析这9个因素为什么会产生影响这是 L2 级别的核心考点。一、需求工程过程的“宏观定义”图1这张图告诉你一个配置好的需求工程过程在实际操作中必须承担起四大核心职责塑造信息流和通信模式明确谁在什么时候、通过什么方式、跟谁说、说什么例如是每周开一次正式的评审会还是随时在群里对方。定义将要使用或生产的制品明确大家要产出什么是写厚重的《需求规格说明书》还是只维护轻量的《用户故事列表》和《原型图》。提供获取、记录、确认和管理的框架明确大家按什么步骤干活是先访谈再画图还是先画原型再确认。明确参与人员把客户、用户、需求工程师、开发、测试都拉到这个“局”里并清晰定义他们在流程中的角色。二、影响配置的“9大核心因素”深度拆解图2既然要“量身定制”那裁缝的尺子是什么就是下面这9个因素。为了让你更清楚地记住它们如何以及为什么产生影响我把它们分为四大阵营阵营1外部环境锁项目的基本盘1. 整个过程适合必须匹配系统开发过程如何影响如果公司整体开发流程是严格瀑布你的需求过程就必须是线性规范性先签合同再动工如果整体是敏捷Scrum你的需求过程就必须是迭代探索性边开发边细化。为什么需求过程是开发过程的上游它们必须像齿轮一样咬合否则会出现“需求还在签字开发已经写完了代码”的乱象。2. 开发上下文组织文化、物理环境如何影响团队是集中办公还是跨国远程公司是互联网大厂还是传统国企为什么远程团队需要更严格的文档化和异步沟通工具如Wiki集中办公可以用白板口头沟通。物理距离决定了信息流的密度和频率。6. 约束法规、技术栈、接口限制如何影响如果涉及金融/医疗需求过程必须包含严格的可追溯性和合规确认环节。为什么约束是“不可谈判的红线”它们会强制你在流程中加入额外的审核步骤。阵营2利益相关者因素人的变量3. 利益相关者的能力和可用性如何影响如果业务方很忙一个月只能抽出1小时你就不可能选“参与式”频繁开评审会只能选“合同化”写厚厚一沓文档让他们一次性签字。为什么人的时间就是流程的时间表。流程是为人服务的人没空流程再完美也跑不起来。9. 需求工程师的经验如何影响新手RE需要更结构化、脚本化的流程比如提供访谈提纲模板、用例模板资深RE可以驾驭高度自由、探索性的流程比如开放式引导、即时原型验证。为什么经验决定了流程的容错率。老手能随机应变新手则需要“护栏”防止跑偏。4. 共识如何影响如果项目涉及多个利益相冲突的部门如销售部要低价财务部要收款快共识度低则需求过程必须包含大量的协商、调和与多轮评审环节。为什么流程必须为“吵架”和“达成共识”预留下时间。共识破灭是需求变更的最大来源流程必须对此有抵御能力。阵营3系统本身的复杂度技术的变量5. 被开发系统的复杂性和关键性如何影响做一个小型内部OA流程可以很轻快做一个火箭控制系统或银行核心交易系统流程必须极其严谨、规范强制性完整确认、多重验证。为什么出错的代价决定了流程的严谨度。代价越高流程就越需要增加“冗余检查”来防止风险即细化程度极高。阵营4项目动态性市场的变量7. 可用的时间和预算如何影响时间紧、预算少只能选轻量化流程快速原型极简文档时间充裕、预算充足可以走完整线性流程。为什么这是最现实的“硬约束”。流程的长短与成本直接挂钩你必须在有限资源内做出取舍。8. 波动的需求需求不稳定性如何影响如果市场瞬息万变如互联网App需求波动极大必须选迭代探索性流程如果需求极其稳定如航空雷达选线性规范性。为什么需求变动的频率决定了流程的敏捷度。变脸越快流程的“反馈回路”就必须越短比如两周一个Sprint。最后一句必记口诀帮你应对多选题和场景题“看人利益相关者看货系统复杂度看时间预算/工期看变需求波动看规约束法规看大局开发上下文老手有经验就大胆探索新手没底就严格按步骤9个因素全盘想别拿一个就死扛量身定制才最强”EU 5.2 需求工程过程方面L2你发的这组图片完整覆盖了 IREB 体系中关于“如何量体裁衣配置需求工程过程”的核心方法论EU 5.2。在很多公司需求过程是“万年不变”的——不管做什么项目都用同一套瀑布或同一套敏捷模板。但 IREB 明确指出这是错的配置过程必须从“时间、目的、目标”三个维度进行组合决策。我帮你把这三组图片的精髓提炼成一个“三维决策矩阵”并附上 IREB 官方特别给出的反直觉提示图片5让你彻底吃透这个 L2 考点。一、三大“决定性维度”配置过程的三个旋钮维度两个极端核心区别一句话时间方面线性vs迭代“需求是一口气全写完还是分批次慢慢长出来”目的方面规范性vs探索性“合同/规格是钉死的铁板还是大家商量着来的草稿”目标方面以客户为中心vs以市场为导向“是专门给掏钱的特定大客户做还是给一大群未知的陌生人做”二、各维度的“选择标准”拆解看图 2/3/41. 时间方面选“线性”还是“迭代”选线性一次性完整规格需求很稳定利益相关者一开始就清楚自己要什么。项目是计划驱动如传统瀑布或者要作为合同/招标的依据。监管机构要求必须有一套完整、正式的需求规格书如航空、医疗。选迭代分批演进需求一开始不清楚要在开发过程中逐步浮现。有短反馈回路能持续让利益相关者确认如敏捷开发。时间充裕能做多个迭代且容易变更需求是核心诉求。2. 目的方面选“规范性”还是“探索性”选规范性严格锁定需要固定价格的合同比如外包给乙方。功能与范围优先于成本和工期即不惜代价也要做全不能随意砍需求。选探索性开放演化利益相关者只有模糊的概念“我想要个像抖音那样的东西”。成本和截止日期优先于功能范围预算和时间定了能塞多少功能算多少。需求的优先级和具体实现顺序一开始完全不确定。3. 目标方面选“客户导向”还是“市场导向”选以客户为中心特定组织谁掏钱谁用如定制开发的内部 OA 系统。利益相关者主要在客户组织内部可以一对一识别角色。客户通常想要一份合同来约束乙方。选以市场为导向大众产品准备做商业化产品卖到市场去如手机 App、游戏。用户是匿名的无法逐一访谈你不可能找到每一个潜在下载者。需求工程师必须**“代表”**用户去设计需求靠市场分析、竞品调研。主要利益相关者是产品负责人、市场人员、设计师而不是单个掏钱的客户。三、核心考点组合倾向与反直觉提示图 5 的精髓1. 常见“黄金搭档”大多数情况下的自然组合线性 规范性这是合同外包项目的经典配置。需求一次性全定死合同按规格签。这就是大家常说的“瀑布式合同”。迭代 探索性这是敏捷创新项目的经典配置。需求分批次演进边做边改。这就是大家常说的“敏捷开发”。2. 致命的不协调警告市场导向 ≠ 线性 规范性原文明确指出“市场导向方面往往与线性和规范方面不能很好地结合”。为什么因为做大众产品如微信需求是要快速试错、随市场变化的你不可能把微信第一版的所有功能全部钉死在一份合同里。3. 反直觉的例外IREB 常考陷阱外包也可以是探索性的原文举例虽然外包通常选“规范性”因为有合同但只要合同谈得好外包也可以基于探索性过程比如签一个人月数固定的框架合同具体做什么功能按迭代不断调整。4. 线性的“代价”选线性不代表高枕无忧。因为线性意味着很长的反馈回路需求写完过半年才看到系统为了降低“做错系统”的风险必须配套极其严格的变更管理流程且需求确认要做到极致。总结一张图看懂如何配置实战决策流当你接到一个新项目时按以下三步走就能配置出合适的需求工程过程定目标看谁用如果是定制化大客户偏向客户导向如果是产品化大众偏向市场导向。定目的看合同如果是固定总价合同偏向规范性如果是人月外包或自研偏向探索性。定时间看需求清晰度如果需求极其明确且不变选线性如果需求模糊且多变选迭代。最终配置的软技能L2 灵魂“配置过程不是做单选题而是做组合题。没有最好的过程只有最合适的搭配。当你把‘市场导向’硬塞进‘线性规范性’时项目就会变成一辆在泥地里开不动的豪华轿车。”你发的这组图片完整覆盖了 IREB 体系中关于“如何量体裁衣配置需求工程过程”的核心方法论EU 5.2。EU 5.3 配置需求工程过程L3这三张图将之前抽象的“时间、目的、目标”三维旋钮EU 5.2直接拧成了三套具体的、可直接落地的“过程配置方案”EU 5.3并且给出了配置的标准操作流程5步法。这相当于把“如何配需求工程过程”从“理论题”变成了“应用题”。我帮你把这三张图整合成一个完整的“配置工具箱”一、三种典型的“现成配置”三套标准模板根据你的第一、二张图IREB 总结出了需求工程领域最常见的三套配置。你可以把它们理解为“基础款套餐”配置类型组合维度主要应用案例什么时候用典型制品产出什么典型信息流谁跟谁沟通1. 参与式迭代 探索性 面向客户供应商与客户紧密合作利益相关者深度参与如定制化敏捷开发、内部创新项目。用户故事、任务卡、产品待办列表、低保真原型轻量级适应变化。需求工程师、开发人员、产品负责人持续互动短反馈回路贯穿始终。2. 合同化线性 规范性 面向客户注有时也带一点迭代但核心是线性和规范需求分析后规格书作为合同基础人员不常与利益相关者交互如政府项目、大型外包、固定总价合同。沉重的《系统需求规格说明书SRS》包含大量自然语言和模型如类图、状态图。单向/受限流主要是利益相关者 → 需求工程师写完后基本上就不太改了靠合同锁死。3. 产品导向迭代 探索性 市场导向组织开发软件以作为产品或服务销售如互联网App、通用软件产品。产品待办列表、高保真原型快速验证市场。多角色交叉流产品负责人、市场、设计、开发之间密集交互并**可能** 从用户侧获取快速反馈如A/B测试。二、如何从零开始配置过程—— 官方推荐的“5步法”第三张图的核心这是 IREB 给需求工程师的实操指南。当你接手一个新项目时按下面这 5 步走就能定制出最合适的过程步骤 1分析影响因素EU 5.1先看组织级因素。比如公司文化是瀑布还是敏捷团队规模多大有没有历史遗留系统政策环境稳不稳定白话摸摸家底看看手上有哪些牌能打。步骤 2评估标准方面EU 5.2按我们之前学的三个维度做选择时间上选线性还是迭代目的上选规范性还是探索性目标上选客户导向还是市场导向白话拧动三个旋钮确定大方向比如选“迭代探索性市场导向”。步骤 3配置过程EU 5.3根据上一步选出的三个属性匹配合适的过程模板比如匹配上面说的“产品导向”配置。定义好阶段划分、里程碑、评审节点和反馈机制。白话把“方向”变成“路线图”明确先做什么后做什么多久跟客户/市场对一次。步骤 4确定制品EU 3基于选定的配置决定具体要产出哪些制品。如果是“产品导向”可能只需要轻量的用户故事和原型如果是“合同化”就需要详尽的SRS和术语表。白话明确最终要交付哪些文档和图拒绝“无脑堆模板”。步骤 5选择合适的实践最后补上具体落地的“手脚”。比如选了“参与式迭代”那具体实践就包含每周Sprint计划会、每日站会、Sprint评审会等。白话确定具体用什么招式把前面规划的东西落到实处。三、L3 级别的实战应用选型速查表如果你是需求工程师面对简单的系统开发可以拿这张速查表直接套用项目特征推荐的配置套餐理由老板说我们要做个内部OA流程非常固定必须在3个月内上线合同已经签死合同化需求明确必须严格按合同范围和预算走文档要留底验收。客户说我们有个想法但还不太清楚具体怎么做愿意每周花两天跟我们坐在一起打磨参与式需求模糊探索性强必须依赖利益相关者的高频反馈来纠偏。公司决定我们要做一个面向全国大学生的社交App功能根据市场反馈逐步迭代上线产品导向用户未知匿名的市场需求靠竞品分析和数据驱动必须快速迭代探索。最后一句“灵魂总结”“参与式”是“结婚过日子”一起磨合一起改“合同化”是“签离婚协议”白纸黑字事无巨细一旦定了很难改“产品导向”是“追对象”揣摩对方心思不断调整自己推出去试水看反馈。配置过程的境界没经验的需求工程师永远只用一种模板而 L3 级的高手会像做“满汉全席”一样按 5 个步骤看人下菜碟为不同项目精准配菜。