虽然经常听到“需求定义”这个词，
但很多人可能会觉得“实际上它在做些什么，我并不清楚”。

特别是在刚入职场时，往往更多地参与实现和测试等开发流程，
对需求定义只停留在“好像是最开始的一个流程”的程度。

因此，经常会有“需求定义到底在做什么呢？”这样的疑问出现。

本文将针对需求定义的角色，结合具体示例，进行通俗易懂的整理说明。

需求定义是“明确系统必须满足的条件（需求），并在相关方之间达成共识的流程”。

这里所说的“需求”，指的是“系统应当实现什么”这一条件。

系统开发始于客户的“想做的事情（期望）”。
但是，如果不将这种期望具象化就直接交给开发方，
完成的结果就容易出现“跟想象的不一样”这样的情况。

此外，由于“预算”“人力”“技术限制”等因素，也存在根本上难以实现的情况。

因此，在需求定义阶段会反复进行以下交流：

• 整理客户的期望
• 开发方评估可行性
• 基于实现方法和各种限制提出方案
• 客户确认并调整提案内容

反复进行该流程，
最终定义出“要做什么”的共识内容。

需求定义也可以说是对“期望”与“现实（限制）”进行协调，
并将其落地为可实现形式的过程。

此外，由于客户未必能将所有内容都明确化，
开发方通过提问和提案来具体化需求也很重要。

与需求定义常被混淆的是“设计”。

两者的区别可以整理如下：

• 需求定义：要做什么（What）
• 设计：如何做（How）

示例：用户能够登录的功能。

• 需求定义
  用户可以使用ID和密码登录

• 设计
  认证方式采用JWT
  密码进行哈希后保存

如果在需求定义阶段就开始谈设计内容，
一旦需求变更，就无法灵活应对。

因此，有意识地将“要做什么（What）”和“如何做（How）”区分开来很重要。

需求定义通常按照以下流程进行。

“期望”和“需求”虽相似，但本文中如下定义：

• 期望：客户主观想做的事情
• 需求：已具体化的需求

示例：考勤管理系统。

本节将以具体案例来整理需求定义的流程。

客户的初步期望通常以抽象状态呈现。

(示例)
“想要管理员工的考勤”

※此阶段，业务流程和必要功能尚未明确。

开发方通过访谈，将期望整理为具体的需求。

(示例)

• “想要记录上班和下班时间”
• “想要能在智能手机上打卡”
• “想要汇总每月的工作时间及加班时间”

整理需求后，开发方从以下视角进行评估：

• 作为业务需求是否合理（与业务流程一致性）
• 技术上是否可实现
• 是否能满足成本与进度要求

必要时，还会进行需求的取舍与优先级排序。

基于评估结果，开发方提出具体的实现方案：

(示例)

• “作为Web应用提供”
  → 允许通过PC及智能手机浏览器使用

• “打卡方式采用基于浏览器”
  → 不进行专用应用开发（考虑到开发成本及周期）

• “不与现有的人事系统集成”
  → 初期发布时单独运行，未来考虑扩展

此外，还会根据需要提出以下视角：

• 功能优先级（必需 / 可选）
• 范围（本次涵盖范围）
• 权衡取舍（成本·质量·速度）

客户方对提案内容的合理性进行确认。

• 是否能在业务上正常使用
• 必要功能是否得到满足
• 是否没有缺失或多余的需求

如有必要，再次对期望进行修正或添加。

客户方与开发方达成内容共识，
并确定“要实现什么到何种程度”。

此共识内容将成为后续设计与实现的基准，即“需求”。

• 需求定义是确定“要做什么（What）”的环节
• 协调期望与制约，将其落地为可实现的形式
• 开发方主动将需求具体化至关重要

需求定义不仅是一个简单的前置流程，
还是左右整个项目质量的重要环节。

下次我们将讲解如何实际地梳理并整理需求。