企业官网建设流程全解析

考试大纲如下：
EU 5.1 影响因素（L2）
EO 5.1.1 了解影响需求工程的重要因素(L1)
EO 5.1.2 理解这些因素是如何以及为什么会产生影响(L2)
EU 5.2 需求工程过程方面（L2）
EO 5.2.1 理解在配置需求工程过程时要考虑的方面(L2)
EU 5.3 配置需求工程过程（L3）
EO 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）

这张图告诉你，一个配置好的需求工程过程，在实际操作中必须承担起四大核心职责：

1. 塑造信息流和通信模式：明确谁在什么时候、通过什么方式、跟谁说、说什么（例如：是每周开一次正式的评审会，还是随时在群里@对方）。
2. 定义将要使用或生产的制品：明确大家要产出什么（是写厚重的《需求规格说明书》，还是只维护轻量的《用户故事列表》和《原型图》）。
3. 提供获取、记录、确认和管理的框架：明确大家按什么步骤干活（是先访谈再画图，还是先画原型再确认）。
4. 明确参与人员：把客户、用户、需求工程师、开发、测试都拉到这个“局”里，并清晰定义他们在流程中的角色。

二、影响配置的“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 考点。

一、三大“决定性维度”（配置过程的三个旋钮）

二、各维度的“选择标准”拆解（看图 2/3/4）

1. 时间方面：选“线性”还是“迭代”？

• 选线性（一次性完整规格）：
  • 需求很稳定，利益相关者一开始就清楚自己要什么。
  • 项目是计划驱动（如传统瀑布），或者要作为合同/招标的依据。
  • 监管机构要求必须有一套完整、正式的需求规格书（如航空、医疗）。
• 选迭代（分批演进）：
  • 需求一开始不清楚，要在开发过程中逐步浮现。
  • 有短反馈回路，能持续让利益相关者确认（如敏捷开发）。
  • 时间充裕，能做多个迭代；且容易变更需求是核心诉求。

2. 目的方面：选“规范性”还是“探索性”？

• 选规范性（严格锁定）：
  • 需要固定价格的合同（比如外包给乙方）。
  • 功能与范围优先于成本和工期（即不惜代价也要做全，不能随意砍需求）。
• 选探索性（开放演化）：
  • 利益相关者只有模糊的概念（“我想要个像抖音那样的东西”）。
  • 成本和截止日期优先于功能范围（预算和时间定了，能塞多少功能算多少）。
  • 需求的优先级和具体实现顺序一开始完全不确定。

3. 目标方面：选“客户导向”还是“市场导向”？

• 选以客户为中心（特定组织）：
  • 谁掏钱谁用（如定制开发的内部 OA 系统）。
  • 利益相关者主要在客户组织内部，可以一对一识别角色。
  • 客户通常想要一份合同来约束乙方。
• 选以市场为导向（大众产品）：
  • 准备做商业化产品卖到市场去（如手机 App、游戏）。
  • 用户是匿名的，无法逐一访谈（你不可能找到每一个潜在下载者）。
  • 需求工程师必须**“代表”**用户去设计需求（靠市场分析、竞品调研）。
  • 主要利益相关者是产品负责人、市场人员、设计师，而不是单个掏钱的客户。

三、核心考点：组合倾向与反直觉提示（图 5 的精髓）

1. 常见“黄金搭档”（大多数情况下的自然组合）

• 线性 + 规范性：这是合同外包项目的经典配置。需求一次性全定死，合同按规格签。这就是大家常说的“瀑布式合同”。
• 迭代 + 探索性：这是敏捷创新项目的经典配置。需求分批次演进，边做边改。这就是大家常说的“敏捷开发”。

2. 致命的不协调（警告！）

• 市场导向 ≠ 线性 + 规范性：原文明确指出“市场导向方面往往与线性和规范方面不能很好地结合”。为什么？因为做大众产品（如微信），需求是要快速试错、随市场变化的，你不可能把微信第一版的所有功能全部钉死在一份合同里。

3. 反直觉的例外（IREB 常考陷阱）

• 外包也可以是探索性的！原文举例：虽然外包通常选“规范性”（因为有合同），但只要合同谈得好，外包也可以基于探索性过程（比如签一个人月数固定的框架合同，具体做什么功能按迭代不断调整）。

4. 线性的“代价”

• 选线性不代表高枕无忧。因为线性意味着很长的反馈回路（需求写完，过半年才看到系统），为了降低“做错系统”的风险，必须配套极其严格的变更管理流程，且需求确认要做到极致。

总结：一张图看懂如何配置（实战决策流）

当你接到一个新项目时，按以下三步走，就能配置出合适的需求工程过程：

1. 定目标（看谁用）：如果是定制化（大客户），偏向客户导向；如果是产品化（大众），偏向市场导向。
2. 定目的（看合同）：如果是固定总价合同，偏向规范性；如果是人月外包或自研，偏向探索性。
3. 定时间（看需求清晰度）：如果需求极其明确且不变，选线性；如果需求模糊且多变，选迭代。

最终配置的软技能（L2 灵魂）：

“配置过程不是做单选题，而是做组合题。没有最好的过程，只有最合适的搭配。当你把‘市场导向’硬塞进‘线性+规范性’时，项目就会变成一辆在泥地里开不动的豪华轿车。”😊
你发的这组图片，完整覆盖了 IREB 体系中关于“如何量体裁衣，配置需求工程过程”的核心方法论（EU 5.2）。

EU 5.3 配置需求工程过程（L3）

这三张图将之前抽象的“时间、目的、目标”三维旋钮（EU 5.2）直接拧成了三套具体的、可直接落地的“过程配置方案”（EU 5.3），并且给出了配置的标准操作流程（5步法）。

这相当于把“如何配需求工程过程”从“理论题”变成了“应用题”。我帮你把这三张图整合成一个完整的“配置工具箱”：

一、三种典型的“现成配置”（三套标准模板）

根据你的第一、二张图，IREB 总结出了需求工程领域最常见的三套配置。你可以把它们理解为“基础款套餐”：

二、如何从零开始配置过程？—— 官方推荐的“5步法”（第三张图的核心）

这是 IREB 给需求工程师的实操指南。当你接手一个新项目时，按下面这 5 步走，就能定制出最合适的过程：

步骤 1：分析影响因素（EU 5.1）

先看组织级因素。比如：公司文化是瀑布还是敏捷？团队规模多大？有没有历史遗留系统？政策环境稳不稳定？
白话：摸摸家底，看看手上有哪些牌能打。

步骤 2：评估标准方面（EU 5.2）

按我们之前学的三个维度做选择：时间上选线性还是迭代？目的上选规范性还是探索性？目标上选客户导向还是市场导向？
白话：拧动三个旋钮，确定大方向（比如选“迭代+探索性+市场导向”）。

步骤 3：配置过程（EU 5.3）

根据上一步选出的三个属性，匹配合适的过程模板（比如匹配上面说的“产品导向”配置）。定义好阶段划分、里程碑、评审节点和反馈机制。
白话：把“方向”变成“路线图”，明确先做什么后做什么，多久跟客户/市场对一次。

步骤 4：确定制品（EU 3）

基于选定的配置，决定具体要产出哪些制品。如果是“产品导向”，可能只需要轻量的用户故事和原型；如果是“合同化”，就需要详尽的SRS和术语表。
白话：明确最终要交付哪些文档和图，拒绝“无脑堆模板”。

步骤 5：选择合适的实践

最后补上具体落地的“手脚”。比如选了“参与式+迭代”，那具体实践就包含：每周Sprint计划会、每日站会、Sprint评审会等。
白话：确定具体用什么招式把前面规划的东西落到实处。

三、L3 级别的实战应用：选型速查表

如果你是需求工程师，面对简单的系统开发，可以拿这张速查表直接套用：

最后一句“灵魂总结”

“参与式”是“结婚过日子”（一起磨合，一起改），
“合同化”是“签离婚协议”（白纸黑字，事无巨细，一旦定了很难改），
“产品导向”是“追对象”（揣摩对方心思，不断调整自己，推出去试水看反馈）。

配置过程的境界：没经验的需求工程师永远只用一种模板；而 L3 级的高手，会像做“满汉全席”一样，按 5 个步骤，看人下菜碟，为不同项目精准配菜。😊