需求工程基础

发表于 Waline： 阅读次数： 本文字数： 5.2k 阅读时长 ≈ 19 分钟

AI WARNING

未进行全面的对照审核。

需求工程概述

软件开发的起点往往是为了解决现实世界中的某个问题或满足某种期望。然而，从模糊的想法到最终交付的软件产品，中间充满了挑战。其中，准确理解和定义「要做什么」以及「为什么要做」是至关重要的第一步。

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

正如著名的「秋千漫画」所揭示的，在客户、项目经理、分析师、程序员等不同角色之间，对需求的理解可能存在巨大的偏差，导致最终产品与客户的真实需求相去甚远。需求工程（Requirements Engineering）正是为了系统化地解决这个问题而产生的学科领域。

什么是需求工程？

需求工程

需求工程（Requirements Engineering）是所有需求处理活动的总和。它涉及系统化地收集信息、分析问题、整合观点、记录需求并验证其正确性，最终目标是清晰地描述软件系统在特定应用环境中，为了达成预定目标所需具备的功能和特性，以及它与环境互动所形成的期望效应。

需求工程的核心任务可以概括为三个方面：

  1. 明确目标与环境（Why & Context）：说明软件系统将被应用的环境及其要达成的目标。
  2. 定义系统功能（What）：说明为了达成目标，软件系统需要提供哪些功能。即明确软件「需要做什么」。
  3. 映射与规格说明（How - Abstractly）：将目标和功能映射为可行的软件系统行为，并对其进行准确的规格说明，为后续设计和实现奠定基础。同时，也要能应对现实世界变化导致的需求演化。

需求工程的活动

需求工程主要包含两大核心活动：需求开发和需求管理。

  • 需求开发（Requirements Development）：专注于需求的产生、分析、定义和确认过程，是处理需求本身的技术活动集合。
  • 需求管理（Requirements Management）：在需求开发活动之后，确保持续、稳定、有效地发挥需求的作用，管理需求的变更，保证后续开发活动与需求保持一致。
graph TD
    RE[需求工程] --> RD(需求开发);
    RE --> RM(需求管理);

    subgraph "需求开发（处理需求的技术）"
        direction LR
        RD_E[需求获取] --> RD_A[需求分析];
        RD_A --> RD_S[需求规格说明];
        RD_S --> RD_V[需求验证];
    end

    subgraph "需求管理（保证需求的有效发挥）"
        direction LR
        RM_BC[需求基线管理]
        RM_CC[变更控制]
    end

    style RE fill:#f9f,stroke:#333,stroke-width:2px
    style RD fill:#ccf,stroke:#333,stroke-width:1px
    style RM fill:#9cf,stroke:#333,stroke-width:1px

需求开发过程

需求开发通常遵循一个迭代的过程模型，各个活动之间可能存在反馈和循环。

graph TB
    %% 定义节点和流程
    A[利害相关人/问题域] --> B(需求获取);
    B --> C(需求分析);
    C --> D(需求规格说明);
    D -- 需求规格说明文档 --> E(需求验证);
    E -- 一致的需求 --> F((结束));
    
    %% 反馈循环
    C -- 分析可能引发进一步获取 --> B;  
    D -- 编写规格时可能发现分析不足 --> C;  
    E -- 验证发现问题返回规格说明修改 --> D;  
    E -- 验证发现问题返回分析修改 --> C;  
    E -- 验证发现问题返回获取修改 --> B;  

    %% 美化样式
    style A fill:#f0f8ff,stroke:#333,stroke-width:2px,color:#333,font-weight:bold
    style B fill:#e6f7ff,stroke:#333,stroke-width:2px,color:#333,font-size:14px
    style C fill:#d9f2e6,stroke:#333,stroke-width:2px,color:#333,font-size:14px
    style D fill:#fff3cd,stroke:#333,stroke-width:2px,color:#333,font-size:14px
    style E fill:#f8d7da,stroke:#333,stroke-width:2px,color:#333,font-size:14px
    style F fill:#d4edda,stroke:#333,stroke-width:2px,color:#333,font-size:14px,font-weight:bold

需求获取（Elicitation）

需求获取是从人、文档或环境中发现、理解并收集需求信息的过程。这不仅仅是简单的记录，更是一个「发现」的过程。

  • 目标：
    • 理解业务目标和用户问题。
    • 识别利害关系人（Stakeholder）及其期望。
    • 发现潜在需求和约束。
  • 目标分析：
    • 从问题出发：分析用户面临的困境或期望改进的方面。
    • 从利害关系人出发：识别所有受系统影响或对系统有影响的个体或组织，理解他们的不同视角和目标冲突。
  • 常用方法：
    • 面谈（Interview）：与用户或利害关系人直接交流，获取深入信息。
    • 问卷（Questionnaire）：向大量用户收集标准化信息。
    • 文档分析（Document Analysis）：研究现有系统文档、业务流程、规章制度等。
    • 头脑风暴（Brainstorming）：激发创意，发现潜在或创新性需求。
    • 专题讨论/研讨会（Workshop/Focus Group）：组织相关人员集中讨论特定主题。
    • 原型法（Prototyping）：创建系统部分模型（如界面草图、Storyboard），让用户体验并反馈，澄清模糊需求。
    • 民族志/观察法（Ethnography/Observation）：观察用户在实际工作环境中的行为。
    • 竞品分析（Competitive Analysis）：研究竞争对手的产品特性。
  • 常见困难与应对：
    • 背景立场不同（如「床边 B 超, 肝胆胰脾」）：需消除默认知识，明确沟通语境。
    • 用户表达能力不足：需求人员需具备专业引导和归纳能力。
    • 用户认知困境（如平板电脑出现前用户难以想象）：原型法有助于具象化。
    • 用户越俎代庖（如指定「双机热备」）：区分「需求」（What）与「解决方案」（How），引导用户关注业务目标而非技术实现，通过协商达成共识。
    • 缺乏用户参与（如医生不愿参与）：强调项目价值，提供便捷参与方式。

需求分析（Analysis）

需求分析的核心是通过建模来整合获取到的信息，深入理解问题，定义出能够有效解决问题的需求集合，并检查、修正其中的错误、遗漏和不一致。

  • 目标：
    • 确保需求的完整性、一致性、无歧义。
    • 建立清晰的系统边界。
    • 构建理解问题域和系统行为的模型。
  • 主要活动：
    • 边界分析（Boundary Analysis）：
      • 定义项目范围（Scope），明确哪些功能属于系统，哪些不属于。
      • 定义系统边界，识别与系统交互的外部实体（用户、其他系统），保证有效互动。常用用例图（Use Case Diagram） 来可视化系统边界和主要交互者。
    • 需求建模（Requirements Modeling）：
      • 使用图形化或形式化方法抽象地描述信息和关系。
      • 常用建模技术包括：
        • 面向对象模型：类图（Class Diagram）、对象图（Object Diagram）、用例图、顺序图（Sequence Diagram）、状态图（State Diagram）、活动图（Activity Diagram） 等 UML 图。
        • 结构化模型：数据流图（DFD）、实体关系图（ERD）、状态转换图（STD） 等。

需求规格说明（Specification）

将经过分析和确认的需求清晰、准确、无歧义地记录下来的过程，产出物是需求规格说明文档（Software Requirements Specification, SRS）。

  • 目的：
    • 作为用户、开发者、测试者等所有利害关系人之间沟通的基础和共识。
    • 作为后续设计、实现、测试和维护的依据。
  • 内容特点：
    • 描述的是软件解决方案，关注系统对外提供的功能和行为，而非内部实现机制。
    • 从软件产品的角度进行描述，而非用户角度（用户需求已在分析阶段转换为系统级描述）。
  • 质量要求：简洁、精确、一致、易于理解、可验证、可修改。
  • 主要工作：
    • 定制文档模板：通常基于标准（如 IEEE 830）或组织内部模板进行定制。
    • 编写文档：使用自然语言、模型图表等方式填充模板内容。

需求验证（Validation）

确保需求规格说明文档准确反映用户意图，并且文档本身满足质量标准的过程。

  • 目标：尽早发现并修复需求错误，降低后期修改成本。
  • 验证标准：
    • 正确性：每条需求都准确反映用户意图。
    • 完整性：包含所有必要的需求，无遗漏。
    • 一致性：需求之间无冲突。
    • 无歧义性：每条需求只有一种解释。
    • 可验证性：能够通过测试或其他方法判断需求是否被满足。
    • 可修改性：易于修改和维护。
    • 可追踪性：需求能与其来源和后续设计、代码、测试用例关联。
  • 验证方法：
    • 同级评审（Peer Review）：组织相关人员（需求分析师、设计师、测试人员、用户代表等）对 SRS 进行审查。最常用且有效。
    • 原型（Prototyping）：通过可交互的原型让用户确认需求。
    • 模拟（Simulation）：对系统行为进行模拟以检查动态特性。
    • 测试用例开发：尝试为需求编写测试用例，难以编写则可能表示需求不清晰或不可验证。

需求管理（Management）

需求不是一成不变的。在整个软件生命周期中，需求可能会因为市场变化、用户理解加深、技术限制等原因发生变更。需求管理旨在控制和维护需求的稳定性与一致性。

  • 目标：保证需求作用的持续、稳定和有效发挥。
  • 主要活动：
    • 需求基线管理：将经过验证和批准的需求集（SRS）作为基线（Baseline），作为后续工作的起点。
    • 变更控制（Change Control）：
      • 建立规范的变更请求流程。
      • 跟踪（Tracking）：记录每项需求的来源、状态和变更历史。
      • 评估（Impact Analysis）：分析变更请求对项目范围、成本、进度、风险及其他需求的影响。
      • 决策：批准或拒绝变更请求。
      • 实施与验证：将批准的变更纳入需求基线，并通知相关人员。

理解需求本身

在进行需求工程活动之前，我们需要对「需求」这个核心概念有更深入的理解。

什么是需求？ (Requirement)

需求（IEEE 610.12-1990 定义）

  1. 用户为了解决问题或达到某个目标所需要的条件或能力。
  2. 系统或系统部件为了满足合同、标准、规范或其他正式文档所规定的要求而需要具备的条件或能力。
  3. 对 1. 或 2. 中的一个条件或一种能力的文档化表述。
  • 本质：需求是一种期望（Expectation），是现实与理想状态之间的差距。它源自现实（问题域），但又高于现实（期望改进）。
  • 特点：需求通常是多变且可调整的，项目需要根据实际情况平衡需求的实现程度。
  • 表述方式：常表述为「系统应该…」「用户可以通过系统…」等形式。例如：「R1: 系统应该允许顾客退回已经购买的产品。」

需求 vs. 问题域 vs. 规格说明

graph LR
    subgraph RealWorld[现实世界]
        ProblemDomain(问题域)
        ProblemDomainDesc(问题域现状描述)
    end

    subgraph Bridge[桥梁]
        Requirement(需求)
        RequirementDesc(用户期望)
    end

    subgraph ComputerWorld[计算世界]
        Specification(规格说明)
        SpecificationDesc(系统如何运作)
        SoftwareSystem(软件系统)
    end

    ProblemDomain -- 产生 --> Requirement;
    Requirement -- 通过分析转化为 --> Specification;
    Specification -- 指导构建 --> SoftwareSystem;
    SoftwareSystem -- 应用于/影响 --> ProblemDomain;

    style ProblemDomain fill:#FFFFCC, stroke:#333
    style Requirement fill:#E6E6FA, stroke:#333
    style Specification fill:#ADD8E6, stroke:#333
    style SoftwareSystem fill:#90EE90, stroke:#333
  • 问题域（Problem Domain）：现实世界中与待开发系统相关的部分，是需求的产生地和解决地。它反映了现实世界的运行规律和约束，软件开发必须尊重问题域。
  • 需求（Requirement）：用户对解决问题或达成目标的期望。它描述了用户「想要什么」，是连接现实世界和计算世界的桥梁。
  • 规格说明（Specification）：对软件系统如何满足需求的解决方案的描述。它定义了软件系统「应该做什么」以及如何与外部交互，是构建软件系统的蓝图。系统级需求实际上是规格说明的主要内容。

混淆的后果

  • 忽视需求：只模拟现实，软件失去价值。
  • 忽视问题域：脱离现实构建，软件无法应用。
  • 混淆需求与规格说明：导致用户期望与系统实现脱节。

需求的层次性

需求并非单一层面的概念，而是存在于不同的抽象层次上。理解需求的层次性有助于系统化地进行需求开发。

graph TD
    B_Req[业务需求（Business Req.）<br/><i>Why? 战略目标, 组织动机</i>] --> U_Req[用户需求（User Req.）<br/><i>What? 用户任务, 期望功能</i>];
    U_Req -- 需求分析转化 --> S_Req[系统需求（System Req.）<br/><i>How? 系统行为, 交互细节, 规格</i>];

    subgraph B_Req_Details [业务需求要素]
        direction LR
        Objective(目标)
        Feature(特性)
        Vision(愿景)
        Scope(范围)
    end

    B_Req --> B_Req_Details;

    style B_Req fill:#f9f,stroke:#333,stroke-width:1px
    style U_Req fill:#ccf,stroke:#333,stroke-width:1px
    style S_Req fill:#9cf,stroke:#333,stroke-width:1px

  1. 业务需求（Business Requirement）：

    • 最高层次，系统建立的战略出发点。
    • 描述组织「为什么」要开发系统，要达到的高层目标（Objective）。
    • 通常也包含系统应具备的高层特性（Feature）、共同愿景（Vision） 和系统范围（Scope）。
    • 例子：
      • R2: 在系统使用 3 个月后，销售额度应该提高 20%。(目标)
      • SF1: 管理 VIP 顾客信息。(特性)
      • SF3: 使用多样化的特价方案，吸引顾客购买，增加销售额。(特性)

  2. 用户需求（User Requirement）：

    • 中间层次，描述执行实际工作的用户对系统完成具体任务的期望。
    • 说明系统能「帮助用户做什么」。
    • 通常从用户视角描述，可能带有一定的模糊性，允许多特性、多逻辑混杂。
    • 需要充分的问题域知识作为背景支持。
    • 例子：
      • R3: 系统要帮助收银员完成销售处理。(任务)
      • UR1.1: 系统应该允许客户经理添加、修改或者删除会员个人信息。(具体功能期望)
      • UR1.3: 系统应该允许客户经理查看会员的个人信息和购买信息。

  3. 系统需求（System Requirement）：

    • 最低层次，最具体，描述开发人员需要实现的系统行为和属性。
    • 反映了外界与系统的一次交互行为或系统的某个实现细节。
    • 是用户需求经过分析、细化和转化为系统视角的结果，构成了需求规格说明的主体。
    • 应尽可能精确、无歧义。
    • 例子：
      • R4: 收银员输入购买的商品时，系统要显示该商品的描述、单价、数量和总价。(交互细节)
      • SR1.3.1: 在接到客户经理的请求后，系统应该为客户经理提供所有会员的个人信息。(系统行为)
      • SR1.3.3: 在客户经理选定一个会员并申请查看购买信息时，系统要提供该会员的历史购买记录。(系统行为)
      • SR1.3.4: 经理可以通过键盘输入客户编号，也可以通过读卡器输入客户编号。(实现细节)

需求的分类

除了按抽象层次划分，需求还可以从不同维度进行分类。

需求谱系

从项目整体角度看，广义的「需求」可能包含以下几类：

graph TD
    Req[需求总集] --> ProjectReq(项目需求);
    Req --> ProcessReq(过程需求);
    Req --> SystemReq(系统需求);
    Req --> Unrealistic(不切实际的期望);

    subgraph SystemReqDetails [系统需求构成]
        direction LR
        SoftwareReq(软件需求)
        HardwareReq(硬件需求)
        OtherReq(其他需求<br/>如人力、协同)
    end

    SystemReq --> SystemReqDetails;

    style Req fill:#f9f,stroke:#333,stroke-width:1px
    style ProjectReq fill:#ccf,stroke:#333,stroke-width:1px
    style ProcessReq fill:#ccf,stroke:#333,stroke-width:1px
    style SystemReq fill:#ccf,stroke:#333,stroke-width:1px
    style Unrealistic fill:#ffcccb,stroke:#333,stroke-width:1px
  • 项目需求（Project Requirement）：关于项目本身的期望，如成本、时间限制。
    • R5: 项目成本控制在 60 万元以下。R6: 项目在 6 个月内完成。
  • 过程需求（Process Requirement）：关于开发过程的期望，如需遵循的标准、方法、交付物。
    • R7: 开发者需提交 SRS、设计文档、测试报告。R8: 项目使用持续集成方法开发。
  • 系统需求（System Requirement）：对最终交付系统的期望，包括软件、硬件及其他相关要素。
    • 软件需求：对软件部分的期望（后续详述）。
    • 硬件需求：对所需硬件设备的期望。
      • R9: 系统需购买专用服务器，规格不低于…。
    • 其他需求：如人力资源、培训、与其他系统协同等。
      • R10: 系统投入使用时，需对用户进行 1 周集中培训。
  • 不切实际的期望（Unrealistic Expectation）：虽然表达了期望，但因技术、资源或问题域限制而无法实现。
    • 例子：
      • R11: 系统分析购买记录，预测未来购买商品。（技术上可能困难或不准确）
      • R13: 收银员必须在 2 小时内完成一个销售处理的所有操作。（软件无法强制人的行为）
    • 正确形式示例 ：R14: 如果一个销售处理任务在 2 小时内没有完成，系统要撤销该任务的所有已执行操作。（将对人的期望转为对系统行为的要求）

软件需求的分类（IEEE 830 标准）

软件需求本身可以进一步细分为功能需求和非功能需求两大类。

graph TD
    SoftReq[软件需求] --> FuncReq(功能需求);
    SoftReq --> NonFuncReq(非功能需求);
    SoftReq --> DataReq(数据需求);

    subgraph NonFuncReqDetails [非功能需求]
        direction TB
        PerfReq(性能需求)
        QualAttr(质量属性)
        ExtInt(对外接口)
        Constr(约束)
    end

    NonFuncReq --> NonFuncReqDetails;

    style FuncReq fill:#90EE90, stroke:#333
    style NonFuncReq fill:#ADD8E6, stroke:#333
    style DataReq fill:#E6E6FA, stroke:#333

功能需求（Functional Requirement）

  • 定义：描述系统应该做什么，即系统需要提供的服务、执行的任务、与环境的行为交互。它们是系统核心价值的基础。
  • 特点：
    • 最常见、最主要、最重要的需求。
    • 通常需要按照业务、用户、系统三个抽象层次进行展开。
    • 直接关系到用户能否使用系统完成工作。
  • 例：前面提到的 R1, R3, R4, UR1.1, UR1.3, SR1.3.1, SR1.3.3 等都是功能需求。

非功能需求（Non-functional Requirement）

  • 定义：描述系统运作时的质量、特性或限制，而不是具体的功能。它们说明了系统应该「如何」工作，或者在什么条件下工作。
  • 类型：
    • 性能需求（Performance Requirement）：系统执行功能的效率和能力。
      • 速度（Speed）：响应时间、处理时间。
        • PR1: 所有用户查询必须在 10 秒内完成。
        • PR6: 98% 的查询不能超过 10 秒。
      • 容量（Capacity）：能存储的数据量。
        • PR2: 系统应能存储至少 100 万个销售信息。
      • 吞吐量（Throughput）：单位时间内处理事务的数量。
        • PR3: 解释器每分钟应至少解析 5000 条无错误语句。
      • 负载（Load）：能同时处理的并发用户数或工作量。
        • PR4: 系统应允许 50 个营业服务器同时上传下载数据。
      • 实时性（Time-Critical）：严格的时间限制。
        • PR5: 监测到病人异常后，监控器必须在 0.5 秒内发出警报。
      • 灵活性：性能需求可以设置不同标准（最低、一般、理想）。
    • 质量属性（Quality Attribute）：系统在特定方面的「好坏」程度，通常是隐式的，但对设计影响巨大。
      • 可靠性（Reliability）：在规定条件下无故障运行的能力。
        • QA1: 数据传输中网络故障，系统不能崩溃。
      • 可用性（Availability）：系统可操作和可访问的程度（通常用百分比表示）。
        • QA2: 系统可用性达到 98%。
      • 安全性（Security）：阻止未授权访问程序和数据的能力。
        • QA3: VIP 顾客只能查看自己的信息；收银员只能查看，不能修改删除 VIP 信息。
      • 可维护性（Maintainability）：修改（修复故障、改进性能、适应环境）的容易程度，包括可修改性（Modifiability） 和可扩展性（Extensibility）。
        • QA4: 增加新特价类型需在 2 人月内完成。
      • 可移植性（Portability）：从一个软硬件环境迁移到另一个环境的能力。
        • QA5: 集中服务器能在 1 人月内从 Windows 7 迁移到 Solaris 10。
      • 易用性（Usability）：用户学习、操作、理解和评价系统的容易程度。
        • QA6: 收银员 1 个月销售处理效率达到 10 件商品/分钟。
      • 开发关注点：用户通常不明确提质量要求，需求工程师需结合功能需求判断可能存在的质量属性（如形容词副词暗示），并在特定场景下识别全局质量属性。
    • 对外接口（External Interface）：系统与外部世界交互的连接点。
      • 用户界面（UI）：人机交互方式。
      • 硬件接口：与物理设备的连接。
      • 软件接口：与其他软件系统（如操作系统、数据库、API）的交互。
      • 通信接口：网络通信协议。
      • 需要定义接口用途、输入输出、数据格式、命令格式、异常处理等。
    • 约束（Constraint）：对开发过程或最终产品施加的限制，限制了设计和实现的选择范围。
      • 开发/运行环境：目标机器、操作系统、网络、编程语言、数据库等。
        • C1: 系统要使用 Java 语言开发。
      • 问题域标准：法律法规、行业协定、企业规章。
      • 商业规则：用户任务执行中的潜在规则。
      • 例子：Google Maps API 使用约束：24 小时内来自同一 IP 的地址解析请求超过 15,000 次或速率过快，将收到 620 错误，持续过多可能被永久阻止。

数据需求（Data Requirement）

  • 定义：作为功能需求的补充，描述需要在数据库、文件或其他介质中存储的数据的特性。
  • 内容：
    • 各功能使用的数据信息。
    • 数据使用频率。
    • 数据可访问性要求（如谁可以访问）。
    • 数据实体及其关系（如数据库模式）。
    • 数据完整性约束（如取值范围、唯一性）。
    • 数据保持要求（如存储期限）。
  • 例子：
    • DR2: 系统需存储 1 年内的销售记录和退货记录。

总结

本章我们学习了软件需求的基础知识，核心要点包括：

  • 需求工程是一个系统化的过程，包含需求开发（获取、分析、规格说明、验证）和需求管理。
  • 需求是用户的期望，连接现实问题域与计算世界的规格说明。
  • 需求具有层次性：业务需求（Why） →\to 用户需求（What users want） →\to 系统需求（How system behaves）。
  • 需求可分为功能需求（做什么）和非功能需求（做得怎么样，有何限制），以及数据需求。非功能需求包括性能、质量属性、接口和约束。
  • 准确理解、定义、记录和管理需求是软件项目成功的关键。