需求分析方法

发表于 2025-04-29 Waline：阅读次数：本文字数： 7.5k 阅读时长 ≈ 27 分钟

AI WARNING

未进行对照审核。

需求分析基础

为什么要进行需求分析？

需求分析是软件开发过程中的关键环节，它架起了用户需求与软件系统解决方案之间的桥梁。

需求分析的目标

需求分析旨在将模糊、不完整甚至可能相互矛盾的用户期望，转化为清晰、一致、可验证的系统需求规格。

获取结果：通常是用户对问题的理解和描述，往往是初步的、非结构化的。
需求分析过程：
- 建立分析模型：通过系统化的方法和工具，对获取的需求信息进行整理、抽象和建模。
- 创建解决方案：基于模型，发挥创造性，设计出满足需求的软件系统方案。
需求开发目标：达成开发者与用户之间的共同理解，并对解决方案形成精确的描述。

简单来说，需求分析帮助我们弄清楚「要做什么」以及「为什么要做」，是后续设计与实现的基础。

需求分析的任务

需求分析的核心任务有两个：

建立分析模型：通过建模活动，将复杂的需求信息结构化、可视化，消除歧义，确保开发者和用户对需求的理解达成一致。
创建软件系统解决方案：在共同理解的基础上，利用专业知识和创造性思维，提出满足需求的、可行的软件系统初步方案。

模型与建模

模型（Model）：是对现实世界事物或系统的抽象。它简化复杂性，帮助我们在构建实际事物之前更好地理解它。例如，建筑图纸是建筑物的模型。
建模（Modeling）：是建立模型的过程。它是一种系统化的思考和推理方式，旨在创建精确、一致的系统表示，使系统更易于理解和使用。

建模常用的基本手段：

抽象（Abstraction）：忽略与当前目标无关的细节，关注事物的本质特征。
分解（Decomposition/Partitioning）：将复杂系统划分为更小、更易于管理的部分，分别进行分析和理解。

需求分析模型

需求分析模型是需求分析阶段的主要产出物，它以图形或文本的形式描述了待开发系统的需求。常见的分析模型根据其侧重点不同，可以分为两大类：

结构化分析方法（Structured Analysis, SA）
- 数据流图（Data Flow Diagram, DFD）：描述数据在系统中如何传递和加工，强调系统的功能和数据流动。适用于从数据处理角度理解系统。
- 实体关系图（Entity Relationship Diagram, ERD）：描述系统中的数据对象及其关系，侧重于系统的静态数据结构。
面向对象分析方法（Object-Oriented Analysis, OOA）
- 用例图（Use-Case Diagram）：从用户角度描述系统的功能需求，定义系统的边界和外部交互者。
- 类图（Class Diagram）：描述系统中的概念（类）及其静态关系（关联、继承等），捕捉系统的静态结构和领域知识。在分析阶段通常指概念类图。
- 交互图（Interaction Diagram），主要是顺序图（Sequence Diagram）：描述对象之间为完成特定任务而进行的消息传递和交互顺序，展示系统的动态行为。
- 状态图（State Diagram）：描述单个对象或系统在其生命周期内可能经历的状态以及状态之间的转换，刻画对象或系统的状态变迁行为。

这些模型并非相互排斥，常常结合使用，从不同侧面完整地描述系统需求。

面向对象分析（OOA）

面向对象分析是一种主流的需求分析方法，它使用面向对象的概念（如对象、类、继承、封装、多态）来理解和建模问题域。其核心思想是将系统视为由相互协作的对象组成的集合。

面向对象分析的简单过程

面向对象分析通常从用户需求出发，逐步构建分析模型：

细化系统与外界的交互：通过用例图和用例描述明确系统的功能范围和使用者。
明确用例中的协作对象：通过分析用例描述，识别出问题域中的核心概念，建立概念类图/领域模型。
明确用例中的协作行为：通过交互图（顺序图）和状态图来详细描述对象间如何交互以及对象自身状态如何变化，以实现用例功能。

用例图与用例描述

用例（Use Case）

用例

用例（Use Case）描述了系统为响应某个参与者（Actor）的请求而执行的一系列动作，这些动作能够为参与者提供有价值的结果。

起源：由 Ivar Jacobson 在 1992 年提出，作为 Objectory 方法的一部分。
核心思想：从用户（或其他外部系统）与系统交互的角度来捕获需求。
场景（Scenario）：一个用例通常包含多个场景。每个场景描述了在特定条件下（如正常流程、异常情况）系统与参与者交互的一条具体路径或行为序列。一个用例是多个场景的集合。

用例图基本元素

用例图以图形化的方式展示系统功能、参与者以及它们之间的关系。

参与者（Actor）
- 表示与系统交互的角色，可以是人、外部系统或设备。
- 注意：参与者代表的是角色，而非特定的个体。一个用户可能扮演多个角色，一个角色也可能对应多个用户。
- 参与者总是位于系统边界之外。
- 图标：小人形状。
用例（Use Case）
- 表示系统提供的一个完整且有意义的功能单元，通常能为参与者带来价值。
- 用例总是位于系统边界之内。
- 图标：椭圆形。
关系（Relationship）
- 关联（Association）：连接参与者和用例，表示参与者参与执行该用例。用直线表示。
- 包含（Include）：表示一个用例（基础用例）的行为包含了另一个用例（被包含用例）的行为。被包含用例是基础用例执行的必要部分。用带箭头的虚线表示，指向被包含用例，并标有 <<include>>。
- 扩展（Extend）：表示一个用例（扩展用例）在特定条件下可以扩展另一个用例（基础用例）的行为。扩展用例是可选的，基础用例无需知道扩展用例的存在。用带箭头的虚线表示，指向基础用例，并标有 <<extend>>。
- 泛化（Generalization）：表示参与者或用例之间的一般与特殊关系（类似继承）。用带空心三角箭头的实线表示，指向更一般的元素。
系统边界（System Boundary）
- 通常用一个矩形框表示，框内是用例，框外是参与者。
- 明确定义了正在建模的系统范围，区分系统内部功能和外部交互。

error code: 520

建立用例图的过程

目标分析与解决方案确定：明确系统要解决的核心问题和业务目标。
- 案例（超市）：解决手工销售慢、库存不准、竞争力下降的问题。目标是提高效率、准确管理库存、降低成本、增强竞争力。
寻找参与者：识别与系统交互的所有角色（人或外部系统）。
- 案例（超市）：总经理、客户经理、收银员、管理员。（顾客虽然是最终用户，但不直接操作此后台管理系统，而是通过收银员间接交互，因此在此例中不作为参与者）。
寻找用例：确定每个参与者使用系统的主要任务（目标）。每个任务通常对应一个用例。
- 案例（超市）：
  - 总经理：产品调整、特价策略制定、赠送策略制定、库存分析、库存管理。
  - 客户经理：会员管理、库存管理。
  - 收银员：销售处理、退货。
  - 管理员：用户管理。
细化用例：调整用例粒度，合并或拆分用例，识别 include 和 extend 关系。
- 判断标准：一个合适的用例通常描述为应对一个业务事件，由一个参与者发起，在一个连续时间段内完成，并能增加业务价值的任务。
- 案例（超市）细化：
  - 合并：「特价策略制定」和「赠送策略制定」目标和过程类似，合并为「销售策略制定」。
  - 细化：「会员管理」包含不同业务事件，细化为「发展会员」和「礼品赠送」。
  - 细化：「库存管理」包含不同目标，细化为「商品出库」「商品入库」和「库存分析」。
  - 复用：「库存分析」用例对总经理和客户经理都适用。

用例细化常见错误

粒度过细：将用例细化为单个操作（如增、删、改）。这些操作通常应聚合在一个更有业务价值的用例中（如「用户管理」）。
目标混淆：将同一个业务目标拆分成不同用例（如将「特价策略制定」和「赠送策略制定」分开，如果它们本质上是相似的策略管理任务）。
包含无业务价值的内容：将非功能性需求（如「登录」「数据验证」）或内部实现细节（如「连接数据库」）作为用例。这些应作为约束或在用例描述的特殊需求中体现。

用例描述（用例模板）

用例图提供了系统功能的概览，但需要详细的用例描述来补充细节。常用模板包含以下要素：

项目	内容描述
ID	用例的唯一标识符。
名称	简洁、精确地描述用例任务，通常是动宾短语（如：「销售处理」）。
参与者	涉及的主要参与者及其目标。
触发条件	启动该用例的事件（外部或内部）。
前置条件	用例启动前必须满足的系统状态。
后置条件	用例成功执行后系统达到的状态。
正常流程	（主成功场景）描述最常见、无异常情况下的参与者与系统交互步骤序列。
扩展流程	（替代路径/异常场景）描述各种偏离正常流程的情况及其处理步骤（如错误处理、可选路径）。
特殊需求	与该用例相关的非功能性需求（性能、安全、可靠性等）或其他约束。

示例：可见 Tomato-Bookstore。

概念类图（Conceptual Class Diagram/Domain Model）

概念类图

概念类图，也称为领域模型（Domain Model），是面向对象分析的核心，用于识别和描述问题域中重要的概念（类）、它们的属性以及它们之间的关系。它关注的是现实世界的业务概念，而不是软件实现细节。

与设计类图的区别：

关注点：概念类图关注问题域的理解和表达（系统与外界交互的概念）；设计类图关注解决方案域的软件构造（系统内部实现机制）。
细节：概念类图通常不包含或很少包含方法、具体数据类型、可见性（public/private）等软件实现细节。

基本元素

类（Class）：对具有相同属性、行为和关系的一组对象的抽象。表示问题域中的一个重要概念。
- 属性（Attribute）：描述类的特征或状态的数据项。在概念类图中，通常只列出重要的、领域相关的属性。
关联（Association）：表示类之间存在的某种结构化或业务联系。
- 角色（Role）：关联端点可以有名称，说明该类在关联中扮演的角色。
- 多重性（Multiplicity）：表示一个类的实例可以与另一个类的多少个实例相关联（如 1, 0…1, *, 1…*, 0…*）。
依赖（Dependency）：表示一个类（客户端）的改变可能会影响到另一个类（供应端），但这种关系通常比较弱，不是结构化的关联。对象间的临时协作（链接 link）是依赖在实例层面的体现。
聚合（Aggregation）：一种特殊的关联，表示整体与部分的关系（has-a），部分可以独立于整体存在。用带空心菱形的线表示，菱形指向整体。
组合（Composition）：一种更强的聚合，表示整体与部分的关系，部分不能脱离整体存在（生命周期绑定）。用带实心菱形的线表示，菱形指向整体。
继承/泛化（Inheritance/Generalization）：表示一般与特殊的关系（is-a），子类继承父类的属性和行为，并可以有自己的特性。用带空心三角箭头的线表示，箭头指向父类。

建立概念类图的过程

识别候选类：分析用例描述（尤其是场景描述），找出其中可能代表领域概念的名词或名词短语。常用的方法有：
- 名词分析法：找出文本中的所有名词，作为候选类。
- 行为分析、CRC 卡片等方法也可使用。
- 案例（UC1 销售处理名词）：收银员、销售、VIP 顾客、客户编号、商品标识、商品、赠品信息、商品信息、描述、数量、价格、特价、总价、商品清单、赠品清单、余额、抵价券、积分、收据、库存…
筛选候选类，确定概念类：根据以下准则判断候选类是否应成为最终的概念类：
- 系统需求：该概念是否是系统需要了解和处理的核心业务元素？
- 状态与行为：该类的实例是否需要维持状态（有属性）并且需要根据状态表现行为（有操作，即使在概念类图中不显式画出）？
  - 有状态有行为 $\to$ 概念类。
  - 仅有状态无行为 $\to$ 可能是其他类的属性。
  - 仅有行为无状态 $\to$ 重新审视需求（行为通常需要状态支持），或将行为职责分配给其他有状态的类。
  - 无状态无行为 $\to$ 剔除。
- 案例（筛选）：
  - 顾客：在此系统中不直接交互，信息通过 VIP 顾客 体现，可舍弃或合并。
  - 收据：通常是销售过程的结果，其信息包含在 销售 或 账单 中，本身可能不需要独立状态和行为，可考虑舍弃或作为属性集合。
  - 商品标识、价格、数量 等：明显是 商品 或 商品清单 的属性。
  - 会员、销售、商品、库存、策略（特价/赠送）等是核心概念，保留为类。
识别关联：分析用例描述和领域知识，找出概念类之间的协作关系和结构联系。
- 协作驱动：用例中描述的类之间的交互通常意味着关联（如：收银员 执行 销售）。
- 领域知识补充：补充问题域中固有的关系（如：商品清单 包含 商品，整体部分关系）。
- 去除冗余/导出关联：避免不必要或可以通过其他关联推导出的关联。
- 确定关联的多重性。
识别重要属性：为每个概念类添加关键的、领域相关的属性。这些属性通常是用例执行所需的信息（条件、输入、输出、记录）。
- 案例：为 商品 添加 标识、描述、价格；为 销售 添加 时间、总额；为 VIP 顾客 添加 编号、积分、级别。
合并与整体化：将从各个用例分析得到的局部概念类图进行合并，消除重复，解决冲突，形成系统整体的概念类图。

超市销售系统概念类图示例：

顺序图（Sequence Diagram）

顺序图

顺序图（Sequence Diagram）是交互图的一种，用于展示对象之间如何通过消息传递进行协作以完成特定任务（通常是一个用例或场景）。它强调交互的时间顺序。

在分析阶段，主要使用系统顺序图（System Sequence Diagram, SSD）。

系统顺序图（SSD）

SSD 将整个系统视为一个黑盒子，只显示外部参与者与系统之间的交互事件（系统事件），而不展示系统内部对象的交互细节。它有助于明确系统需要响应哪些外部输入以及产生哪些输出。

基本元素

参与者（Actor）：发起交互或接收系统响应的外部角色。
系统（System）：通常用一个带有 :System 标签的对象框表示，代表整个被测系统。
生命线（Lifeline）：从参与者或系统框向下延伸的垂直虚线，表示对象存在的时间。
激活/执行规格（Activation/Execution Specification）：生命线上的矩形条，表示对象正在执行操作或处理消息的时间段。
消息（Message）：表示对象间的通信。用带箭头的线表示。
- 同步消息（Synchronous Message）：发送者发送消息后必须等待接收者返回结果。用实心箭头表示。
- 异步消息（Asynchronous Message）：发送者发送消息后无需等待，可继续执行。用开放箭头表示。
- 返回消息（Return Message）：表示操作执行完毕后返回结果或控制权。用虚线箭头表示（有时可省略）。
组合片段（Combined Fragment）：用带标签的框包围部分交互，表示特殊的控制逻辑。常用类型：
- opt (Optional)：片段中的交互是可选的。
- alt (Alternative)：表示多个互斥的交互选择（类似 if-else）。
- loop (Loop)：表示片段中的交互会重复执行。

系统顺序图示例（销售处理 - 简化）：

sequenceDiagram
    actor 收银员
    participant 系统 as 系统

    收银员 ->> 系统: 开始新销售
    activate 系统
    系统 -->> 收银员: （系统准备就绪）

    opt 会员
        收银员 ->> 系统: 输入会员号（id）
        系统 -->> 收银员: 显示会员信息
    end

    loop 还有下一项商品
        收银员 -) 系统: 输入商品标识（code）
        系统 -) 收银员: 显示商品信息（price, desc）
    end

    收银员 ->> 系统: 结束输入
    系统 -->> 收银员: 显示总价（total）

    收银员 ->> 系统: 输入收款金额（amount）
    系统 -->> 收银员: 计算找零（change）

    收银员 ->> 系统: 确认完成
    系统 -->> 收银员: 打印收据

    deactivate 系统

状态图（State Diagram/State Machine Diagram）

状态图

状态图（State Diagram），也称为状态机图，用于描述一个对象或系统在其生命周期中响应事件所经历的状态序列以及状态之间的转换。

它特别适用于对具有明确、离散状态且行为受状态影响的对象或系统进行建模（事件驱动系统）。

基本概念

状态（State）：对象或系统在其生命周期中的一种可观察到的、稳定的状况或条件。通常用圆角矩形表示。
- 初始状态（Initial State）：状态机开始时的状态。用实心圆表示。
- 最终状态（Final State）：状态机结束时的状态。用带圆圈的实心圆表示。
转换（Transition）：从一个状态到另一个状态的迁移。由特定事件触发。用带箭头的线表示。
事件（Event）：导致状态发生转换的外部或内部发生的事情（如用户输入、时间到达、条件满足）。通常标记在转换线上。
动作（Action）：在转换过程中或进入/退出某个状态时执行的原子性操作（如调用方法、发送信号）。通常标记在转换线上，跟在事件后面，用 / 分隔。
监护条件（Guard Condition）：一个布尔表达式，只有当其值为真时，相应的转换才能发生。用方括号 [] 括起来，标记在转换线上。

转换标签格式：事件 [监护条件]/动作 (各部分都可选)

建立状态图的过程

确定上下文环境：明确状态图描述的主体是谁？（一个类、一个用例、整个系统等）。
- 案例：主体是用例 UC1「销售处理」。
识别状态：找出主体在其生命周期中可能存在的、有意义的稳定状态。
- 案例（UC1 销售处理状态）：空闲、销售开始、VIP 顾客信息显示、商品信息显示、列表显示、错误提示、账单处理、销售结束。
建立状态转换：根据需求描述的系统行为，确定哪些事件会触发从一个状态到另一个状态的转换。
- 案例：从「空闲」状态，收到「开始新销售」事件，转换到「销售开始」状态。从「列表显示」状态，收到「结束输入」事件，转换到「账单处理」状态。
补充详细信息，完善状态图：为转换添加触发事件、监护条件和动作。

销售处理用例状态图示例：

---
title: 销售状态图
---
stateDiagram-v2
    [*] --> 空闲 : 登录/授权

    state 空闲
    state 销售开始
    state VIP 顾客信息显示
    state 商品信息显示
    state 列表显示
    state 错误提示
    state 账单处理
    state 销售结束

    空闲 --> 销售开始 : 开始新销售
    销售开始 --> VIP 顾客信息显示 : 输入 VIP 顾客号 [合法]/显示信息
    销售开始 --> 商品信息显示 : 输入商品标识 [合法]/显示信息
    VIP顾客信息显示 --> 商品信息显示 : 输入商品标识 [合法]/显示信息

    商品信息显示 --> 列表显示 : 输入下一商品标识 [合法]/更新列表
    商品信息显示 --> 错误提示 : 输入商品标识 [非法]/提示错误
    列表显示 --> 列表显示 : 输入下一商品标识 [合法]/更新列表
    列表显示 --> 错误提示 : 输入商品标识 [非法]/提示错误
    列表显示 --> 账单处理 : 结束输入/计算总价并显示

    错误提示 --> 商品信息显示 : 重新输入 [商品标识合法]/显示信息
    错误提示 --> 列表显示 : 重新输入 [商品标识合法]/更新列表

    账单处理 --> 销售结束 : 支付完成/更新库存, 打印收据
    销售结束 --> 空闲 : 完成

    销售开始 --> 空闲 : 取消销售
    VIP顾客信息显示 --> 空闲 : 取消销售
    商品信息显示 --> 空闲 : 取消销售
    列表显示 --> 空闲 : 取消销售
    账单处理 --> 空闲 : 取消销售

    销售结束 --> [*] : 退出/完成

结构化分析（SA）

结构化分析是早期的系统分析方法，强调自顶向下分解和使用图形工具来描述系统。虽然面向对象分析更为现代，但结构化分析中的某些思想和工具（如 DFD、ERD）仍然有其价值，尤其是在理解数据处理流程和数据结构方面。

结构化分析思想

自顶向下分解：将复杂的系统或问题，从整体入手，逐层分解为更小、更具体的子系统或子问题，直至容易理解和处理。
图形化表示：使用标准化的图形符号来建模。主要工具包括：
- 数据流图（DFD）：侧重功能和数据流动。
- 实体关系图（ERD）：侧重数据结构。
- 状态转移图（STD）：侧重系统状态变化（类似 UML 状态图）。

结构化分析的简单过程

结构化分析通常也涉及发现业务事件、描述业务逻辑、建立模型等步骤，但其模型体系与 OOA 不同。

graph LR
    A[发现业务「事件」] --> B(需求分析模型);
    C[描述业务「事件」] --> B;
    D[发现业务「事物」] --> E(需求分析模型);
    F[描述业务「事物」] --> E;

    subgraph B[需求分析模型 - 功能/流程]
        B1[上下文图]
        B2[事件列表/功能列表]
        B3[数据流图/状态转移图]
    end

    subgraph E[需求分析模型 - 数据]
        E1[概念列表]
        E2[实体关系图]
    end

    A --> B1;
    C --> B2;
    C --> B3;
    D --> E1;
    F --> E2;

    style A fill:#f9f,stroke:#333,stroke-width:2px
    style C fill:#f9f,stroke:#333,stroke-width:2px
    style D fill:#ccf,stroke:#333,stroke-width:2px
    style F fill:#ccf,stroke:#333,stroke-width:2px

数据流图（Data Flow Diagram, DFD）

数据流图（DFD）

数据流图（DFD）是一种图形化技术，用于描绘信息（数据）在系统中的流动和处理过程。它将系统视为一系列相互连接的处理（功能），这些处理接收输入数据，进行转换，并产生输出数据。

DFD 关注的是数据如何从输入流动到输出，以及在此过程中经历了哪些处理步骤，而不关心处理的具体实现细节或控制流程。

基本元素

DFD 有两种常见的表示法：DeMarco-Yourdon 和 Gane-Sarson。

元素	DeMarco-Yourdon 图标	Gane-Sarson 图标	描述
外部实体	方框	方框	系统之外的、与系统交互的人、组织或系统（数据的源或宿）。
处理/过程	圆圈	圆角矩形（带编号区）	对数据进行转换或操作的功能单元。
数据流	带箭头的线	带箭头的线	在处理、数据存储和外部实体之间流动的数据。线上标明数据名称。
数据存储	两条平行线	开口矩形（带标识区）	存储数据供以后使用的地方（如文件、数据库表）。

DFD 分层结构

为了管理复杂性，DFD 通常采用自顶向下的分层结构：

上下文图（Context Diagram）：顶层图（0 层图的上层），将整个系统视为一个处理，只显示系统与外部实体的交互数据流。用于明确系统边界和主要输入输出。
0 层图（Level 0 Diagram）：上下文图中那个代表整个系统的处理被分解为系统主要的子功能（处理）。显示主要的数据流和数据存储。
N 层图（Level N Diagram）：0 层图或其他下层图中的某个处理可以进一步分解为更详细的子处理，形成下一层 DFD。分解持续进行，直至每个处理足够简单。

重要原则：父图与子图平衡。即，分解一个处理得到的子图，其输入输出数据流必须与父图中流入流出该处理的数据流保持一致。

DFD 语法规则（部分）

处理至少要有一个输入数据流和一个输出数据流（黑洞和奇迹不允许）。
数据流必须连接到至少一个处理。
数据不能直接从外部实体流向数据存储，反之亦然（必须经过处理）。
数据不能直接在两个外部实体之间流动，也不能直接在两个数据存储之间流动。

实体关系图（Entity Relationship Diagram, ERD）

实体关系图（ERD）

实体关系图（ERD）是一种用于数据建模的图形工具，它描述了系统需要存储和管理的数据对象（实体）以及它们之间的关系。

ERD 独立于处理逻辑，专注于数据的静态结构。

基本概念

实体（Entity）/数据对象（Data Object）：系统中需要存储信息的一个独立事物，通常对应现实世界中的对象或概念（如：顾客、订单、产品）。每个实体实例可以唯一标识。用矩形表示。
属性（Attribute）：描述实体特征的数据项（如：顾客实体的 姓名、地址 属性）。用椭圆（早期表示法）或在实体矩形框内列出（常用表示法）。
- 键（Key）：能够唯一标识实体实例的一个或一组属性（主键）。通常会加下划线或特殊标记（如 # 或 PK）。
关系（Relationship）：实体之间存在的业务联系（如：顾客 下达 订单）。用菱形（早期表示法）或连接实体的线（常用表示法）表示。关系也可以有属性。
基数/多重性（Cardinality/Multiplicity）：表示一个实体实例能与另一个实体实例相关联的数量。常见的表示法包括：
- 一对一（1:1）
- 一对多（1:N）
- 多对多（M:N）
- 标注方式多样，如 Crow's Foot (鸟足) 标记、数字标记等。

建立 ERD 的过程（分层）

Level 1：识别所有核心数据对象（实体）以及它们之间的基本连接。
Level 2：明确实体之间的具体关系类型和基数。
Level 3：为每个实体和关系添加详细的属性，特别是标识符（键）。

超市销售系统 ERD 示例：

erDiagram
    CUSTOMER ||--o{ SALE : "一个顾客可下多个订单"
    SALE ||--|{ SALE_ITEM : "一个订单包含多个商品项"
    PRODUCT ||--|{ SALE_ITEM : "一个商品可出现在多个订单项中"
    SALE ||--o{ PAYMENT : "一个订单可有多种支付方式"
    CASHIER ||--o{ SALE : "一个收银员处理多个订单"
    SALE }o--|| VIP_CUSTOMER : "identifies (optional)"

    CUSTOMER {
        string customerId PK "客户 ID"
        string name "姓名"
        string phone "电话"
    }

    VIP_CUSTOMER {
        string customerId PK,FK "客户 ID"
        string level "级别"
        int points "积分"
    }

    SALE {
        string saleId PK "销售单号"
        datetime timestamp "时间"
        string cashierId FK "收银员 ID"
        string customerId FK "客户 ID（Nullable）"
        decimal totalAmount "总金额"
    }

    SALE_ITEM {
        string saleId PK,FK "销售单号"
        string productId PK,FK "商品 ID"
        int quantity "数量"
        decimal price "单价"
        decimal discount "折扣（Nullable）"
    }

    PRODUCT {
        string productId PK "商品 ID"
        string description "描述"
        decimal listPrice "标价"
        int stockLevel "库存水平"
    }

    PAYMENT {
        string paymentId PK "支付 ID"
        string saleId FK "销售单号"
        string method "支付方式"
        decimal amount "支付金额"
    }

    CASHIER {
        string cashierId PK "收银员 ID"
        string name "姓名"
    }

使用需求分析方法细化和明确需求

为什么要细化和明确需求？

用户提出的原始需求往往存在模糊性、不完整性、甚至矛盾。而后续的系统设计和实现需要严谨、精确、无歧义的需求规格说明。需求分析建模的过程，正是为了弥补用户需求描述与系统设计要求之间的鸿沟。

如何细化和明确需求？

细化和明确需求是一个迭代的过程，通过运用前面介绍的各种分析模型（用例图、类图、顺序图、状态图、DFD、ERD 等）来：

系统化地审视需求：将需求从不同角度进行建模。
发现问题：在建模过程中，更容易发现原始需求中的遗漏、冲突、冗余和错误。
与用户沟通：将模型作为与用户沟通的工具，澄清疑问，确认理解。
迭代完善：根据发现的问题和沟通结果，返回需求获取阶段补充信息，然后重新分析和调整模型，如此反复，直至需求清晰、完整、一致。

各模型如何帮助发现问题？

系统顺序图（SSD）：有助于发现系统与外部交互的缺失。通过模拟交互流程，可以检查是否遗漏了必要的系统事件（输入）或系统响应（输出）。
- 案例：绘制销售处理的 SSD 时，可能会发现忘记处理顾客取消交易的请求，或者系统没有在特定步骤给出必要的状态反馈。
概念类图（ERD）：有助于发现信息使用不准确、信息不明确以及遗漏重要内容。
- 信息不准确：如用例描述中说输入「商品」，但类图分析发现应该是输入「商品标识」。
- 信息不明确：如用例提到「会员信息」，但类图需要明确包含哪些具体属性（编号、姓名、积分、级别等）。
- 遗漏重要内容：如用例描述了总价计算，但类图分析发现缺少必要的「商品特价策略」「总额特价策略」等概念及其关联。
状态图：有助于发现用户界面（UI）跳转逻辑的问题或遗漏。通过模拟对象或用例的状态变迁，可以检查是否存在无法到达的状态、非预期的状态转换、或缺少处理特定事件的转换路径，这直接关系到 UI 的流程设计。
- 案例：绘制销售处理状态图时，可能会发现从「错误提示」状态返回正常流程的路径不完整，或者没有处理用户在「账单处理」状态下突然取消的情况。

建立系统需求

经过细化和明确后，需求分析的结果最终需要文档化，形成系统需求规格说明书（Software Requirements Specification, SRS）。SRS 是开发团队进行设计、实现、测试以及项目管理的重要依据。

SRS 的内容组织方式有多种标准模板，可以根据项目特点选择合适的结构，例如：

按系统模式（Mode）组织
按用户类别（User Class）组织
按对象/类（Object/Class）组织
按特性/功能（Feature）组织
按外部激励（Stimulus）组织
按功能层次（Functional Hierarchy）组织
混合组织（Multiple Organization）

选择哪种组织方式取决于哪种结构能最清晰、最有效地传达系统需求。无论采用哪种方式，一份好的 SRS 都应具备完整性、一致性、无歧义性、可验证性等质量属性。