需求工程的定义

需求工程的动因与必要性

在复杂系统开发中，约40%的项目失败直接源于需求缺陷（Kassab et al., 2014）。需求工程（Requirements Engineering, RE）的缺失或不足导致两大核心问题：

1. 返工成本激增
   研究证实，系统性需求工程可将后期返工量降低30%-50%，并显著提升系统质量（DoD, 1991）。若跳过需求分析直接编码（常见于软件项目），将因需求误解引发架构重构、接口冲突等连锁问题。

2. 系统质量失控
   在嵌入式系统领域，37%的工程师指出其公司需求实践“不达标”，主因是现有方法无法处理复杂系统的需求网络（Sikora et al., 2012）。当需求与验证脱节时，系统往往偏离真实用户需求。

更深层动因在于系统复杂性升级：

• 简单系统（如桥梁）可通过简明需求锁定设计模式（如“悬臂钢桥承载双向四车道”）；

• 复杂系统（如生物机械装置）需处理多层级约束与动态演化需求；

• 超复杂系统（如操作系统）面临数千功能点的行为规范挑战（Zave, 1997）。
  这种复杂性要求需求工程必须成为系统设计的“锚点”，而非事后补丁。

需求工程的定义演进与核心内涵

1. 早期定义：生命周期视角（DoD, 1991）

美国国防部首次提出完整框架：

“需求工程涵盖识别用户需求、分析衍生需求、文档化规约、验证需求符合性的全生命周期活动，以及支持这些活动的过程。”
此定义强调需求开发流程，但未明确需求在方案验证中的作用（如验收测试的缺失）。

2. 目标导向扩展（Zave, 1997）

Zave从软件工程视角重构定义：

“需求工程是软件工程的分支，关注软件系统的现实目标、功能及约束，研究这些要素与软件行为规约的关联，及其在时间和产品族中的演化。”
突破性贡献在于提出目标-规约-演化三维模型，但局限在软件领域（未覆盖硬件/混合系统）。

3. 系统工程的集成定义（本书定义）

为弥合上述缺陷，现代定义扩展为：

“需求工程是系统工程的子领域，致力于在逐级抽象层次上，通过发现、开发、追溯、分析、质量确认、沟通及管理需求来定义系统。”
此定义通过六项核心活动与三层突破实现范式升级：

需求工程的含义解构

（1）六大活动的实践内涵

• 发现（Discovering）：融合需求捕获（Capture）与 elicitation（引出），穿透用户表象需求获取本质目标。

• 追溯（Tracing）：建立需求与设计、测试用例的多对多关联，确保需求落地可验证（如通过需求矩阵追踪覆盖率）。

• 质量确认（Qualifying）：统一“验证（Verification）”与“确认（Validation）”争议：

  • 需求确认：检查形式化需求与非形式化利益相关者需求的匹配度；

  • 需求验证：确保需求在抽象层级内/间的逻辑一致性（如冲突检测）。

• 沟通（Communicating）：需求作为多方契约，协调客户、开发方、监管机构的认知对齐（Wnuk et al., 2011）。

（2）抽象层级的核心价值

需求工程通过分层管理化解复杂性：

plaintext

复制

下载

┌───────────────┐     ┌───────────────┐     ┌───────────────┐
│   问题域需求  │◀───▶│   方案域需求  │◀───▶│   实现域需求  │
│ (用户目标层)  │     │ (系统架构层)  │     │ (组件设计层)  │
└───────────────┘     └───────────────┘     └───────────────┘
      ▲                      ▲                      ▲      
      │ 满足关系             │ 满足关系             │      
      │ (多对多追溯)         │ (多对多追溯)         │      
┌─────┴─────┐         ┌─────┴─────┐         ┌─────┴─────┐
│ 利益相关者 │         │ 系统工程师 │         │ 开发团队  │
│ 真实需求   │         │ 技术方案   │         │ 详细设计  │
└───────────┘         └───────────┘         └───────────┘

每一层需求既是上一层的“解决方案”，又是下一层的“问题定义”，形成闭环逻辑链（Sikora et al., 2012）。

（3）与系统工程的关系

需求工程并非孤立活动：

• 向上衔接：承接利益相关者的业务目标与运营场景；

• 向下驱动：为架构设计、模块开发、测试验证提供输入准则；

• 横向协同：通过需求变更管理（Requirements Management）响应系统演化。

总结：需求工程的范式跃迁

需求工程已从传统的“文档编写术”进化为系统工程的中枢神经：

1. 定位升级：从软件工程子域（Zave, 1997）到系统工程核心子集，适应软硬融合趋势；

2. 方法革新：通过抽象层级管理复杂系统需求网络，破解“需求膨胀”难题；

3. 价值重构：需求不仅是规约文本，更是多方共识载体与系统演化基线。

当前挑战在于规模化实践：企业需建立需求与系统架构的动态联动机制（Sikora et al., 2012），并开发支持多层级追溯的工具链。未来研究应聚焦需求智能分析（如AI辅助冲突检测）与跨生命周期演化模型，使需求工程真正成为复杂系统的“稳定器”。