导论

发表于 更新于 Waline： 阅读次数： 本文字数： 2.5k 阅读时长 ≈ 9 分钟

软件开发的核心挑战：从「写得对」到「写对的」

软件开发的核心挑战，并不仅仅在于编写出没有 bug 的代码（即「把代码写对」），而在于准确地理解并实现用户真正需要的功能（即「写对的代码」）。正如 Fred Brooks 在其经典论文《没有银弹》中所指出的：

No Silver Bullet

开发软件系统最为困难的部分就是准确说明开发什么。最为困难的概念性工作便是编写出详细的技术需求，这包括所有面向用户、面向机器和面向其他软件系统的接口。同时这也是一旦做错，将最终会给系统带来极大损害的部分，并且以后再对它进行修改也极为困难。

这揭示了需求工程（Requirements Engineering）的本质重要性：软件项目的成败，首先取决于我们是否正确定义了待解决的问题和要构建的系统。

理解世界：问题域与解系统

为了系统性地解决问题，我们需要区分现实世界和我们构建的软件世界。

问题域

问题域（Problem Domain）是指问题产生和存在的环境，是现实世界的一部分。它包含了与问题相关的所有实体、状态、规则和背景信息。

  • 特点：问题域是客观存在的，有其自身的运行规律，不因软件的引入而改变。
  • 例子：在开发一个共享单车 App 时，问题域包括了城市交通状况、用户的出行习惯、单车的物理状态（位置、是否损坏）、支付渠道规则等。

解系统

解系统（Solution System）是我们为了解决问题域中的特定问题而构建的系统，通常指的就是软件本身。

  • 特点：解系统是人造物，其目标是与问题域交互，并对其产生积极影响，从而解决问题。
  • 例子：共享单车 App 本身就是解系统，它提供了扫码开锁、计费、定位等功能。

从问题域背景出发，结合各方涉众（stakeholder）的主观意愿，我们设定系统目标，制定开发任务，并细化系统交互，这构成了从问题到解决方案的基本路径。

桥梁：模拟与共享

解系统之所以能影响问题域，是因为它在内部模拟（Simulate）了问题域的一部分。

  • 模拟：软件通过数据模型、对象模型等方式，对问题域中的实体和规则进行抽象和建模。例如，用数据库表模拟单车库存，用状态机模拟订单状态。
  • 共享现象：模型中的信息与问题域中的信息能够建立映射关系，这种模型与现实之间的重叠部分，被称为共享现象（Shared Phenomenon）。

共享单车中的模拟与共享

  • 模拟：App 的地图上用一个图标表示一辆单车，数据库里有一条记录存储它的 ID 和 GPS 坐标。这便是对现实世界中单车的模拟。
  • 共享：当用户在现实中骑走一辆车，App 通过 GPS 更新这辆车的位置，并将其状态标记为「使用中」。此时，App 内部的数据状态与现实世界的物理状态保持了一致。这种一致性就是共享现象。

正是通过操纵这些内部模型并与现实世界同步，软件才得以解决现实问题。

需求的核心概念与层次

需求的定义

需求（Requirement）

根据 IEEE 的定义，需求是：

  1. 用户为了解决问题或达到某个目标所需要的条件或能力。
  2. 系统或系统部件为了满足合同、标准、规范或其他正式文档所规定的要求而需要具备的条件或能力。
  3. 对上述条件或能力的一种文档化表述。

简单来说，需求描述了我们期望软件「做什么」和「做得怎么样」。

基本概念

需求工程的工作围绕以下四个核心概念展开，它们清晰地描绘了从现实到软件的转化过程。

graph LR
    subgraph 现实世界
        direction LR
        A(问题域) -- 描述 --> B(问题域描述)
        B -- 期望 --> C(需求)
    end

    subgraph 计算机世界
        direction LR
        D(需求规格说明) -- 实现 --> E(解系统)
    end

    C -- 映射为 --> D

    style A fill:#2E8B57,color:#fff
    style B fill:#87CEEB,color:#000
    style C fill:#FFD700,color:#000
    style D fill:#FF6347,color:#000
    style E fill:#D2B48C,color:#000
  1. 问题域（Problem Domain）：待解决问题所处的环境。
  2. 需求（Requirement）：用户对问题域的期望和目标，通常用自然语言描述。
  3. 解系统（Solution System）：为满足需求而构建的软件系统。
  4. 需求规格说明（Requirement Specification）：对解系统行为的精确描述，是连接需求与实现的桥梁，是开发、测试和验收的依据。

需求的两个维度：

  • 需求（Requirements）：面向问题域，表达的是用户的期望、目标和约束，是「为什么做」和「做什么」的源头。
  • 需求规格说明（Specifications）：面向解系统，是对软件外部行为的精确定义，描述了系统如何响应外部输入，是「怎么做」的蓝图。

需求为何至关重要

忽视需求的代价是巨大的，这一点在软件行业的发展历程中得到了反复验证。

需求错误的高昂代价

软件开发中，一个错误发现得越晚，修复它的成本就越高。

一个在需求阶段就能发现并纠正的错误，如果遗漏到运行维护阶段才被发现，其修复成本可能会增加上百倍。这不仅是金钱和时间的浪费，更可能导致项目失败。

来自业界的警示：Standish Group 报告

自 20 世纪 90 年代以来，Standish Group 发布的 CHAOS 报告持续揭示了软件项目的严峻现实：

  • 成功率低：在早期的报告中，成功项目（按时、按预算、功能完整）的比例仅为 16%。尽管情况有所改善，但「问题项目」（超期、超预算或功能缩减）和「失败项目」仍占大多数。
  • 失败的根源：在导致项目失败或出现问题的因素中，与需求相关的因素常年高居榜首。

影响项目成败的关键因素（综合多年数据）：

  1. 用户参与（User Involvement）
  2. 高层管理支持（Executive Support）
  3. 清晰的业务目标（Clear Business Objectives）
  4. 情感成熟度（Emotional Maturity）
  5. 敏捷过程（Agile Process）

综合来看，需求因素对成功项目的影响指数超过 53%，对失败项目的影响指数更是高达 60.9%。这雄辩地证明了，管好需求是软件项目成功的基石。

需求工程：一门专业的学科

为了系统性地应对需求的挑战，需求工程（Requirements Engineering, RE）应运而生。

什么是需求工程？

需求工程是软件工程的一个分支，它关注于：

  • 清晰地定义软件系统要实现的现实世界目标。
  • 明确软件系统的功能和应遵守的约束。
  • 确保这些目标、功能和约束被准确地转化为软件规格说明。

在现代 DevOps 流程下，开发人员需要更全面地掌握待开发的需求，需求工程的重要性不降反升。

需求工程的核心活动

需求工程是一个迭代的过程，主要包括以下基本活动：

flowchart TD
    A(问题域) --> B{锁定问题<br>明确目标}
    B --> C[需求获取]
    B --> D[需求分析]
    B --> E[需求规格说明]
    B --> F[需求验证]
    B --> G((需求管理))

    subgraph 需求开发
        direction LR
        C --> D --> E --> F
    end

    subgraph 目标与任务
        H(目标) <--> I(任务) <--> J(交互)
    end

    A -- 产生 --> H
    H -- 细化 --> I
    I -- 分解 --> J

    style A fill:#2E8B57,color:#fff
    style B fill:#87CEEB,color:#000
    style C fill:#FFD700,color:#000
    style D fill:#FF6347,color:#000
    style E fill:#D2B48C,color:#000
    style F fill:#FFB6C1,color:#000
    style G fill:#20B2AA,color:#000
    style H fill:#8A2BE2,color:#fff
    style I fill:#FF4500,color:#fff
    style J fill:#00CED1,color:#000
  • 需求获取（Elicitation）：从用户、文档、现有系统等来源识别和收集原始需求。
  • 需求分析（Analysis）：理解、分类、协商需求，解决冲突，建立需求模型。
  • 需求规格说明（Specification）：将分析后的需求清晰、无歧义地记录下来，形成文档。
  • 需求验证（Validation）：检查需求文档是否准确反映了用户的真实意图，以及需求本身是否正确、完整、可行。
  • 需求管理（Management）：在整个项目生命周期中跟踪和控制需求变更。

现代需求：融合商业模式创新

在互联网时代，软件产品本身往往就是商业模式的核心载体。单纯的技术视角已不足以构建成功的产品，需求开发必须与商业模式设计深度融合。

为什么需要商业模式？

  • 价值核心：软件的核心价值在于帮助企业解决组织、流程、利益分配等问题，最终实现价值创造与降本增效。
  • 可持续性：一个商业上可行的产品，才具备领域价值和可持续发展的潜力。
  • 应对变革：新技术（如移动互联网、AI）催生了商业模式的快速迭代，软件开发需要从面向确定性业务转向以「人」为核心的新业务。

什么是商业模式？

商业模式（Business Model）

一个商业模式描述了一个组织创造、传递以及获得价值的基本原理，其本质在于价值的流动。

核心工具：商业模式画布

商业模式画布（Business Model Canvas）是一个用于描述、分析和设计商业模式的可视化工具。它将复杂的商业逻辑解构为 9 个基本构造块，帮助我们系统性地思考价值的创造与传递。

理性（成本驱动） 感性（价值驱动）
重要合作（Key Partnerships） 客户关系（Customer Relationships）
关键业务（Key Activities） 客户群体（Customer Segments）
核心资源（Key Resources） 渠道通路（Channels）
成本结构（Cost Structure） 收入来源（Revenue Streams）
价值服务（Value Propositions） 价值服务（Value Propositions）

通过运用商业模式画布等工具，我们可以更全面、系统地刻画问题域，为后续的目标、任务、交互的逐层转化提供坚实的商业逻辑基础。