需求的分层

目录

在面试的时候，CEO问你，我要把ERP和OA打通，你评估下需要多少人才能满足。
我蒙了，，但是老板不懂技术，我难以解释，，，
最终找到问题根因，是因为我软件工程的功底不够扎实。。。我不懂需求分析的层次。

你直觉是对的：
之所以回答乏力，根本原因是：你缺乏一套“结构化的软件需求评估模型”，无法在当场用专业框架把老板说的“概念”转译成“可评估的需求”。

这不是技术问题，是“需求工程 + 技术管理沟通模型”的问题。

【摘自 需求分析】
Contoso 制药公司的高级管理长官Gerhard ,会见C o n t o s o公司的信息系统开发小组
的新管理员 C y n t h i a。“我们需要建立一套化学制品跟踪信息系统”，G e r h a r d说道。
“该系统可以记录库房或某个实验室中已有的化学药品，这样，化学专家可以直接从
楼下的某人那里拿到所需的药品，而不必再买一瓶新的。另外，卫生保健部门也得为
联邦政府写些关于化学药品的使用报告。你们小组能在五个月内开发出该系统吗？”
“我已经明白这个项目的重要性了， G e r h a r d”C y n t h i a说，“但在我制定计划前，
我们必须收集一些系统的需求。”
G e r h a r d觉得很奇怪“你的意思是什么？我不是刚告诉你我的需求了吗？”
“实际上，你只说明了整个项目的概念与目标，”C y n t h i a解释道，“这些高层次的
业务需求并不能为我们提供足够的详细信息以确定究竟要开发什么样的软件，以及
需要多长时间。我需要一些分析人员与一些知道系统使用要求的化学专家进行讨论，
然后才能真正明白达到业务目标所需的各种功能和用户的要求。我们甚至并不需要
开发一个新的软件系统，这样可节省许多钱。”
G e r h a r d此前还从未遇到过与这位系统开发人员类似的看法。“那些化学专家都非
常忙”他坚持道，“他们没有时间与你们详细讨论各种细节，你不能让你的手下的人
说明要做的系统吗？”
C y n t h i a尽力解释从使用新系统的用户处收集需求的合理性。“如果我们只是凭空
猜想用户要求，结果不会令人满意。我们只是软件开发人员，而并非化学专家。我
们并不能真正明白化学专家们需要这个化学制品跟踪系统做些什么。我曾经尝试过，
未真正明白这些问题就匆忙开始编码，结果没有人对产品满意。”
“行了，行了，我们没有那么多时间” Ger h a r d坚持道。“我来告诉你需求，请马
上开始开发系统。随时将你们的进展情况告诉我。”
像这样的对话经常出现在软件开发过程中。要求开发一个新信息系统的客户通常并不懂
得从系统的实际用户处得到信息的重要性。市场人员在有了一个很不错的新产品想法后，也
就自认为能充分代表产品用户的兴趣要求。然而，直接从产品的实际用户处收集需求有着不
可替代的必要性。通过对 8 3 8 0个项目的调查发现，导致项目失败的最主要的两个原因是缺乏
用户参与和不完整的需求以及不完整的规格说明 (Standish 1995)。
引起需求问题的一部分原因是对不同层次需求（业务、用户、功能）的混淆所致。
G e r h a r d说明了一些业务需求，但他并不能描述用户需求，因为他并不是“化学制品跟踪系统”
的实际使用者。只有实际用户才能描述他们要用此系统必须完成的任务。但他们又不能指出
完成这些任务所有具体的功能需求。

一、最核心的：什么是“概念”，什么是“需求”

你老板说“ERP、OA、CRM 要打通”，这属于：

概念 / 方向（Concept）

  • 战略目标
  • 业务愿景
  • 抽象的意图
  • 高层期望
  • 没有边界、没有范围、没有输入输出定义
  • 无法估算时间和人力

因此你无法给出“多少人多少天”完全是合理的。

而需求（Requirement）必须满足三件事：

1. 有清晰边界（Scope）

例如：
ERP 的采购订单要同步到 OA 的审批流，并回写审批状态。

2. 有可验证条件（Acceptance Criteria）

例如：
同步失败必须在 5 秒内重试三次。

3. 有系统间的规范定义（Contract）

字段映射、数据源、触发条件、任务频率、异常处理、权限控制等。

在没有这些条件之前，不存在“需求”，只有“目标”。

二、软件需求评估模型：你可以立刻掌握的一套框架

这是全球项目方法论（PMI、BABOK、Scrum、ITIL）共同的评估框架。

1. 需求五层模型（非常实用）

用于区分概念、需求和实现：

五层快速对照总结

层级 内容性质 示例 是否能估期 准确度
1. 业务愿景 战略目标 把系统打通 完全不行 0
2. 业务需求 痛点问题 三系统共享客户数据 仍然不行 0–10%
3. 用户需求 用户想做什么。用户+场景 销售查看 ERP 信用额度 可粗估 30–50%
4. 功能需求 功能点、流程、字段范围 字段同步、审批流配置 能估算 60–80%
5. 技术规格 接口、架构、数据表等 API 协议、数据源等 最终估算 80–95%

客户是指直接或间接从产品中获得利益的个人或组织。软件客户包括提出
要求、支付款项、选择、具体说明或使用软件产品的项目风险承担者 ( s t a k e h o l d e r )或是获得产
品所产生的结果的人。

用户需求—必须从使用产品的用户处收集。因此这些用户（通常称作最
终用户），构成了另一种软件客户。他们能说清楚要使用该产品完成什么任务和一些非功能性
的特性，而这些特性会对使用户很好接收具有该特点的产品是重要的。

说明业务需求的客户有时将试图替代用户说话，但通常他们根本无法准确说明用户需求。

业务需求（或产品视图和范围）不应包括用户需求（或使用实例），而所有的功能需求都应该源于用户需求。

老板给你的只到第 1 层。
你需要带他往第 3-5 层落地，才能估时。

下面提供一个清晰、业务化、可在企业内部培训中直接使用的解释，帮助你快速区分：

一句话总结

客户需求 = 商业目标需求（Business Needs）
用户需求 = 用户任务与行为需求（User Tasks & Goals）

两者关注点完全不同：
客户关心“业务成功”，用户关心“任务完成”。

客户需求 vs. 用户需求（精确定义）

项目 客户需求 Customer Needs 用户需求 User Needs
关注焦点 业务成功、成本、收益、战略目标、效率提升 真实用户在使用系统时的任务、痛点、操作流程
提需求的人 付费方、决策者、管理层、业务 owner 实际使用系统的终端用户
属于谁的视角 组织视角（公司/部门的利益） 使用者视角（个人完成任务）
描述方式 高层业务需求、KPI、项目目标 用户任务、使用场景、用例、行为
典型输出物 商业需求文档（BRD）、项目范围、成功标准 用户故事、用例模型、任务流程、原型
表达形式 “我们需要减少成本、提高效率、提升收入” “我需要快速录入订单”、“我需要查看库存”
错误风险 与用户实际工作脱节，系统上线后不被使用 解决的只是局部痛点，不一定提升整体业务收益

用简单例子区分（最容易理解）

以“仓库管理系统”为例：

客户需求（老板想要的）

  • 降低库存成本 20%
  • 提高发货效率
  • 减少人工录入错误
  • 满足审计与合规要求

这些是“业务目标”，不是用户能直接操作的功能。

用户需求（仓库管理员真正要做的）

  • 快速扫描商品入库
  • 一次性打印多张配送单
  • 当库存不足时系统自动提醒
  • 批量导入 Excel 不出错
  • 能使用条码枪提高速度

这些才是用户在系统中要完成的任务。

为什么必须区分？

如果混为一谈，会出现经典问题：

  • 老板说“要提高效率”，开发团队却不知如何实现。
  • 用户说“我要一个按钮”，但这个按钮不一定实现客户的业务目标。

正确做法：

  1. 客户需求 给出的是业务目标 → 为什么做
  2. 用户需求 给出的是任务行为 → 要做什么、怎么做
  3. 系统需求 才是最终开发的功能 → 功能/逻辑/规则

三层需求金字塔（《需求分析》中的结构）

  1. 客户需求（Business Needs）
    为什么做？业务目标是什么？

  2. 用户需求（User Needs）
    用户要完成什么任务？使用场景是什么？

  3. 功能需求（Functional Requirements）
    系统必须具备哪些功能以支撑用户任务？

如果你需要，我可以继续提供：

  • 将客户→用户→系统需求转化的步骤

2. 评估模型：3W+3D 框架（现场可用）

这是你在面试被问“多少天”时最该说的话：

3W：需要先定的三件事

  • What：打通哪些场景
  • Who：哪些用户参与，谁主谁从
  • When：实时性要求

3D：周期相关的三件事

  • Data：字段和数据量
  • Definition：接口规范、边界、异常处理
  • Dependencies：第三方依赖、权限体系

掌握这个，你以后不会被“拍脑袋估工期”的问题卡住。

5层需求层次说明

一、业务愿景（Vision）

核心定位：方向、目标、愿望，不是需求。
它表达了企业“想成为什么样子”，但不告诉你“要做什么功能”。

1. 是什么

  • 企业高层的战略目标
  • 抽象、模糊、非结构化
  • 不包含任何能直接开发的细节

2. 为什么不能用于估工期

  • 没有范围
  • 没有功能
  • 没有数据实体

示例

愿景：

  • “让 ERP、OA、CRM 彻底打通，形成统一数字化平台。”
  • “消除信息孤岛，提高组织运行效率 30%。”

这句话并没有说：

  • 哪些数据要打通？
  • 谁使用？怎么使用？
  • 哪个系统主动？哪个系统被动？
  • 是实时同步还是定时同步？

愿景是公司层面的战略，技术团队无法据此做任何开发排期。

二、业务需求（Business Requirements）

业务需求是客户提出的，客户是指直接或间接从产品中获得利益的个人或组织。软件客户包括提出
要求、支付款项、选择、具体说明或使用软件产品的项目风险承担者 ( s t a k e h o l d e r )或是获得产
品所产生的结果的人。

核心定位：企业“为什么需要”这个项目。
它说明要解决什么业务问题、提升什么流程。

1. 是什么

  • 来自业务部门（销售/财务/人力等）的“问题陈述”
  • 仍然是“业务层语言”，没有技术细节
  • 比愿景更具体，但仍然不能直接开发

2. 为什么仍无法估工期

  • 描述的是“问题”，不是“解决方案”
  • 未明确用户角色、数据范围、流程步骤

示例

业务需求：

  • “ERP、CRM、OA 需要共享客户数据。”
  • “销售提交的审批要能在 OA 流转，但审批通过后结果要回写 ERP。”
  • “希望减少手工 Excel 对账。”

这些只是说明痛点，没有说明具体要做哪些功能和接口。

三、用户需求（User Requirements）

用户需求—必须从使用产品的用户处收集。因此这些用户（通常称作最
终用户），构成了另一种软件客户。他们能说清楚要使用该产品完成什么任务和一些非功能性
的特性，而这些特性会对使用户很好接收具有该特点的产品是重要的。

核心定位：用户“想要做什么”。
这是第一次出现可以做“初步估算”的内容。

1. 是什么

  • 针对具体用户角色（如销售、财务、客服）
  • 以“我需要……因为……”的形式表达
  • 描述用户操作场景与目标

2. 为什么可以“初步估计”

  • 用户目标清晰
  • 可以判断系统边界、参与系统数量、流程的大概复杂度

但仍然没有明确字段、规则、数据格式，因此只能进行粗估，准确度低（50%级别）。

示例

用户需求：

  • “销售需要在 CRM 中查看 ERP 的客户信用额度。”
  • “客服需要能在 OA 中查看订单在 ERP 的拣货状态。”
  • “财务需要月度对账支持 OA → ERP 的数据追踪。”

你开始知道——

  • 哪些系统参与、
  • 哪些用户角色、
  • 系统之间哪些场景需要联动。

这比“共享客户数据”具体得多，但你仍不知道“字段是什么”“接口怎么设计”。

四、功能需求（Functional Requirements）

核心定位：列出系统要实现的功能与规则。
这是第一次可以做“可估算”的需求层。

1. 是什么

  • 具体功能点
  • 具体流程
  • 具体字段
  • 错误处理逻辑
  • 角色与权限
  • 接口触发场景与方向

2. 为什么可以进行可量化估算

因为①功能数量、②系统逻辑分支、③接口方向已经基本清晰。

示例

功能需求：

  • “CRM → ERP：客户新增时触发接口，字段包括 A/B/C，失败时记录日志。”
  • “OA → ERP：审批通过后，每 5 分钟同步一次，字段包括 x/y/z。”
  • “ERP → CRM：每日同步库存，可分页，每次拉取 500 条。”

这一层可用于：

  • 罗列任务点
  • 分配资源
  • 做 WBS（工作分解结构）
  • 估算开发、测试、联调工作量

五、技术规格（Technical Specs / Technical Requirements）

核心定位：可开发、可测试、可上线的最终实现定义。
这是最终准确估算工期的唯一基础。

1. 是什么

  • API 文档（字段、类型、错误码）
  • 数据源列表
  • 数据映射表（mapping）
  • 表结构/索引设计
  • 缓存策略、幂等策略
  • 部署架构
  • 安全与权限方案

2. 为什么到这一层才能“准确估期”

这是你第一次知道——

  • 开发要写多少代码
  • 压力测试要做哪些内容
  • 是否涉及网络、VPN、防火墙
  • 是否需要变更现有系统
  • 是否需要数据清洗
  • 是否需要上线窗口

只有这层才能产生准确度 80~90% 的估期。

需求转化过程

下面给出一个 企业可直接采用、清晰可执行的“客户 → 用户 → 系统需求转化步骤”。该流程是《需求分析》《软件需求》《需求工程》等方法论的共识型流程，适合在需求评审、项目启动、外包交付中作为统一标准。

客户 → 用户 → 系统需求 的转换步骤

（共 8 步）

步骤 1：识别客户（Business Stakeholders）

明确“谁是客户”，他们通常是：

  • 付费方
  • 决策者
  • 部门领导
  • 业务 owner

目的：厘清项目必须满足的业务目标是谁提出的。

步骤 2：收集客户需求（Business Needs）

把客户想要的业务价值写清楚，常见形式包括：

  • 降本（降低 20% 人力成本）
  • 增效（提升订单处理速度）
  • 合规（满足审计要求）
  • 风险降低（减少人工错误）

输出文档：
客户需求说明（Business Requirement Statement）

步骤 3：拆解为业务流程（Business Process）

将客户的高层需求落地为：

  • 关键业务流程
  • 必须支持的业务活动
  • 量化目标（如 SLA、处理时间）

目的：从“老板视角”变为“业务运作视角”。

步骤 4：识别系统的所有用户类型（User Roles）

识别真正使用系统的人，包括：

  • 一线操作人员
  • 管理人员
  • 审计员
  • 偶发用户（如客服、财务）
  • 外部用户（客户、供应商）

输出：用户角色模型（User Role Model）

步骤 5：定义用户需求（User Needs）

对于每类用户，明确：

  • 用户的任务（Task）
  • 工作流程（Workflow）
  • 痛点（Pain Points）
  • 场景（Scenario）
  • 使用背景（Context）

输出：用户故事或任务描述，如：

“仓库管理员需要在 30 秒内完成入库登记。”

这一步是 客户需要 → 用户如何实现 → 系统必须支持什么 的关键纽带。

步骤 6：转化为系统需求（System Requirements）

将用户任务转化为可开发的功能需求。

三类内容必须包括：

1. 功能需求（Functional Requirements）

系统必须具备的功能，包括：

  • 输入 / 输出
  • 业务规则
  • 数据结构与处理流程

例如：

  • 系统必须支持扫描条码并自动拉取商品信息。

2. 非功能需求（Non-Functional Requirements）

如：

  • 性能（2 秒内返回结果）
  • 安全性
  • 可用性（99.9%）
  • 兼容性
  • 易用性

3. 约束（Constraints）

如：

  • 必须接入既有 ERP
  • 必须用公司现有 SSO

输出：
SRS（软件需求规格说明）

步骤 7：验证需求链条（Traceability）

确保每条系统需求都能溯源至：

  • 某个用户需求
  • 某个客户需求

建立需求可追踪矩阵（RTM）

目的：
避免功能与业务目标脱节；避免遗漏关键需求。

步骤 8：与客户和用户共同验证（Validation）

最后要求：

  • 客户确认：系统是否满足业务价值？
  • 用户确认：系统是否满足日常任务？

方式包括：

  • 原型评审
  • 需求评审
  • 用例走查
  • 低保真或高保真 Demo

输出：
需求基线（Demand Baseline）

流程示意图（文字版）

客户需求（Why）
→ 业务流程（What for）
→ 用户角色（Who）
→ 用户需求（What）
→ 系统需求（How）
→ 非功能需求（How well）
→ 需求基线

posted @ 2025-12-06 20:21  向着朝阳  阅读(6)  评论(0)    收藏  举报