ELEC5620 Week 03 需求建模讲课总结

Posted on In , Word count in article: 5.4k Reading time ≈ 20 mins.
ELEC5620 Week 03 讲课总结：需求工程五项活动与常见问题；Ad hoc（Secure Room 规格）、Feature-Oriented（FODA、特征图与跨树约束）、Use Case（Cockburn 模板、extend/include）三种建模方法；功能与非功能需求；面向 agentic 软件的有界自治 use case；Tutorial 3 与 Lab 3 解题思路。

ELEC5620 Week 03 讲课总结：Requirements Modelling

课程：ELEC5620 — Model Based Software Engineering，Semester 2 2026 讲师：Dong Yuan 来源：讲义 PDF 3 Requirement Model.pdf（48 页）+ ELEC5620-TUT-03.pdf（30 页）+ ELEC5620-Lab-Note-3.pdf（1 页）。本周无转录稿。

本周覆盖： 1. 需求工程是什么、为什么难、好需求有什么用 2. 三种需求建模方法：Ad hoc → Feature-Oriented → Use Case 3. 功能需求 vs 非功能需求 4. 面向 agentic 软件的 use case 建模（有界自治） 5. Tutorial 3：特征图符号、use case 图组件与关系；Lab 3：三种方法应用到项目

相关笔记：Week 02 MBSE 导论｜Stage 1 评分标准与 Lab 3｜需求范例（Healthcare）

一、需求工程导论

1.1 软件成功的定义

Software success ⇒ 软件满足其预期目的的程度。 需求建模/需求工程 就是发现这个目的的过程： - 识别利益相关者及其需要 - 以便于分析、沟通和实现的形式记录下来

内在困难：

  • 利益相关者的目标可能不明确、难以表达
  • 目标的满足可能受到他们控制之外的因素约束

Scott W. Ambler：“提供需求是项目利益相关者的职责，理解和实现需求是开发者的职责。”

讲义还提到 Human Centered Design（把被设计的人放在过程中心），以及 Canvas 上提供的 domain user simulator（Canvas → Pages → View all pages）可以用来模拟领域用户做需求访谈。

利益相关者关注点图（P. Kruchten）与 Week 1 相同，见 Week 01 4.1。这里的问题是：“Where do we start?” —— 答案就是从需求开始。

1.2 好需求的收益 vs 需求陈述的问题

Benefits of Good Requirement Issues with Requirement Statement
清晰的期望（客户更易接受） Ambiguity（歧义）
消除不必要的开发 Incompleteness（不完整）
降低项目风险 Conflict（冲突）
更早发现真实缺陷 Difference in priority（优先级不同）
更快开发、更好维护 Perceived stakeholders urgency（利益相关者感知的紧迫性）
测试策略更容易制定、设计更健壮
Iron triangle：time、effort (quality)、money

1.3 需求工程的定义与五项活动

(Software) Requirements Engineering：通过识别利益相关者及其需要，并以便于分析、沟通和后续实现的形式记录下来，从而发现软件系统目的的过程。（Nuseibeh & Easterbrook）

活动 关键问题
Eliciting（获取） 要解决什么问题？系统边界在哪里？ 利益相关者是谁、目标是什么？
Modelling and analysing（建模与分析） 用模型表示、检查冲突与遗漏
Communicating（沟通） 让各方理解
Agreeing（达成一致） 验证并确认
Evolving（演化） 需求随时间变化

捕获的东西需要沟通、验证并与利益相关者达成一致；建模是支持这些目标的常用技术（但不是唯一的）。

Henry Ford：“If I had asked people what they wanted, they would have said faster horses.” —— 用户说出的是解决方案，需求工程要挖出背后的目的。

1.4 例子：AI-native healthcare agency

讲义用一个“AI 原生医疗代理”贯穿本讲：

角色 职责
Clinical director（人） 拥有判断、安全和审批
Intake agent 收集症状和上下文
Evidence agent 检索已批准的临床指南
Care agent 起草下一步并准备转诊
Operations agent 更新记录、排期和随访队列

Running goal：分诊患者咨询、协调照护，但不移除临床医生的问责。

Agent 如何选择下一步行动：

  • 模型解读目标和当前状态；工具让它读数据、在外部系统中行动
  • 指令和策略约束它的选择
  • 循环：plan → act → observe → adjust
  • 在条件要求时必须停止、询问或移交

对需求的含义：需求描述的是结果（outcome）；允许的决策权必须显式写出。

二、三种需求规格方法总览

方法 视角 特点
“Ad hoc” analysis 混合视角 混合了 what / how / how well 等各种需求；不系统、非正式、易出错（遗漏、冲突、不一致、歧义）；但通常是最常见的起点
Feature analysis capability-based view（能力视角） 系统被看作一组期望属性（features）
Use case analysis operational view（操作视角） 系统被看作一组实现利益相关者目标的功能能力

三者务实地结合通常是最好的方法。

三、Ad hoc 方法：Secure Access Room 例子

3.1 场景

一个只允许授权人员停留的房间。设备：Fingerprint scanner、Fingerprint database、Access Control Software、Door、Motion detector、Horn、Panic button、Enable button、连接 Police Station 的电话线。

3.2 非正式规格（三段）

  1. 上电即启用。房间内的人任何时候可以按 panic 按钮呼叫警察（如遇抢劫）：通过电话线给警察发消息，不响警报。
  2. 系统启用时有人开门，必须在开门后 30 秒内扫描食指来解除系统。30 秒内无有效指纹 → 警报响 + 给警察发消息，消息包含安装时向警方登记的 8 位系统 ID。
  3. 系统未启用时，最后离开的人按 Enable 按钮，有 45 秒离开后系统启用。启用状态下运动传感器检测到从窗户进入 → 警报响 + 通知警察。

3.3 为什么非正式规格不够（重点）

文本的非正式性使得以下事情很难做到：

  1. 识别需求之间潜在的冲突和不一致
  2. 确定单个需求之间的相互依赖
  3. 确保覆盖所有需求
  4. 准确理解需要实现什么
  5. 把需求追溯到实现（以及反向）
  6. 为全面测试提供基础

因此需要更系统、更精确的规格方法；需求还需要是电子形式的，方便检索、链接和追溯。

练习：在上面的规格里找问题（解答思路）：

类型 例子
不完整 指纹扫描失败几次算失败？30 秒内扫了错误指纹怎么办？Panic 之后系统状态如何恢复？
歧义 “last person leaving the room” 系统怎么知道是最后一个人？“entry through a window” 和 “person inside moving” 如何区分？
潜在冲突 45 秒离开窗口内有人开门进来，是否要求扫描？Panic 不响警报 vs 窗户入侵响警报，同时发生时如何处理？
混合了 how “message is sent over the telephone line” 规定了实现手段

Tutorial 3 补充：Ad hoc 图是临时性的图，主要用于快速表达想法和讨论——灵活、快速、沟通高效，但缺乏结构，不适合正式文档、难以追踪、难以识别冲突与依赖、可能遗漏需求、实现和测试基础不清晰。Tutorial 建议画 Ad hoc 图时按 What / How / How well 三类去标注需求。

四、Feature-Oriented 方法

4.1 FODA

  • Feature-Oriented Domain Analysis，由 SEI 于 1990 年提出，用于分析领域（概念及其关系）
  • 和类建模有些相似，但更一般
  • 需求分析只是领域分析的一种：被构建系统的领域

Feature：软件系统突出的、用户可见的方面、质量或特征。 更严格的定义（Czarnecki & Eisenecker）：领域概念的一个属性，与某些领域利益相关者相关，并用于区分该概念的不同实例。

4.2 特征图符号

关系 含义 常见画法
Mandatory 子特征必须选 实心圆点
Optional 子特征可选可不选 空心圆点
Or 子特征中至少选一个 实心扇形
Alternative (xor) 子特征中恰好选一个 空心扇形
Cross-tree constraint 跨分支的依赖/互斥 requires / excludes 或逻辑式

4.3 Secure Room 的特征图

Secure Room Software
├── ● Security Validation
│     └── ● Fingerprint Identification
├── ● Violation Notification
│     ├── ● Audible Alarm
│     └── ● Police Notification
└── ○ Manual Control
      └── ● Manual Alarm (panic)

（● = mandatory，○ = optional；讲义图中 Manual Control 为可选分支。）

4.4 Agent 配置的特征图（讲义第二个例子）

Agent Product
├── Autonomy configuration   ⟨xor: Draft only | Auto reply⟩
├── Tools                    ⟨Read tools, ○ Write tools⟩
└── Required controls        ⟨or, at least one: Budget cap | Audit log | Approval gate | ...⟩

Constraint: if (Write tools) then Approval gate

这个例子把 agent 的“自治程度”和“控制措施”建成可变点：有写权限的工具，就必须有审批门——这是典型的 cross-tree constraint。

4.5 Tutorial 3 的 E-Shop 例子

  • 根特征 E-Shop 标识一条软件产品线（SPL）
  • 实现 Catalogue、Payment、Security，以及可选的 Search
  • Security：High 或 Standard 二选一（xor）
  • Payment：Bank Transfer、Credit Card 或两者（or）
  • 跨树约束：包含 Credit Card 的系统必须采用 High security
E-Shop
├── ● Catalogue
├── ● Payment      ⟨or⟩ Bank Transfer | Credit Card
├── ● Security     ⟨xor⟩ High | Standard
└── ○ Search
Constraint: Credit Card ⇒ High

可以把合法配置数一下：Payment 有 种，Security 2 种，Search 2 种，共 种；加上约束后，含 Credit Card 的 2 种 Payment 选项只能配 High： 种合法产品。

Feature model 是一条产品线所有产品的紧凑表示，常作为生成文档、schema、代码片段的输入。

4.6 Feature 建模小结

  • 关注期望的产品能力
  • 静态方法：没有说明特征如何被使用/实现 ⇒ 不容易发现特征之间的潜在冲突
  • 特别适合：需求工作的起点；存在大量可变性的情况 ⇒ 产品族，对架构师非常重要

五、功能需求 vs 非功能需求

功能需求（FR） 非功能需求（NFR）
回答 系统做什么（what） 系统做得多好（how well），对“怎么做”加约束
关注 系统功能 性能特征：可访问性、可靠性、延迟等

但对很多系统来说，两者并不总是可分的。 “Compute the optimal route for a data packet” 与 “Compute the optimal route for a data packet in 4 μsec” 可能是两个完全不同的系统——时间约束改变了算法和架构选择。

Agentic 软件的需求例子：

FR NFR
Agent shall check reported symptoms for emergency warning signs Low latency
根据自然语言生成内容 高准确率的 LLM 模型（NLP 与 CV）
与人对话 用户友好的人机交互（CHI）

六、Use Case 方法

6.1 概念框架

Use case：为了达成一个明确定义的目标而与系统进行的交互——这个目标对 actor 有价值。

  • Actor：有目标；与系统交互以达成一个或多个目标的实体（人或系统）
  • System under consideration：有职责支持 actor 的目标；也可能与其他系统交互
  • Use case 处于非正式（用户想要什么）与正式（工程师实现什么）之间的边界上
  • 作用：给出需求的上下文、促进达成一致、是一组可能的场景

UML 的 use case 图只是一个速记表示——重要（也是困难）的部分是把 use case 本身写清楚。讲义里的元模型多重性：Actor 1 — 0..* Use case 0..* — 1..* Other system。

6.2 Cockburn 方法的关键要素

  1. Use case 由 actor 的目标驱动并围绕它定义
  2. Use case 以 actor 的一个动作开始（trigger）
  3. Use case 总是以明确结果结束：目标达成或未达成
    • Success scenarios（通常一个 main success scenario）
    • Failure scenarios（complications）
  4. 每一步都可能成功或失败；导致失败的条件作为对应失败场景的开头；失败场景从失败点分叉
flowchart TD
    P[Precondition] --> S1[STEP 1]
    S1 -- success --> S2[STEP 2]
    S1 -- failure cond 1 --> F11[STEP F1.1] --> F12[STEP F1.2] --> G2[Goal achieved: SUCCESS]
    S2 -- success --> S3[STEP 3] --> G1[Goal achieved: SUCCESS]
    S2 -- failure cond 2 --> F21[STEP F2.1] --> X[Goal not achieved: FAILURE]

注意：失败分支不一定以失败告终——恢复后也可能达成目标。

6.3 Use case 模板（ATM 例子）

Name Goal Level Precondition Success Failure Trigger
Withdraw cash from ATM Obtain cash User（System 层面） User has ATM-readable card Cash dispensed to user Cash not dispensed despite valid request Insertion of card in ATM

Main scenario：1. 登录 ATM → 2. 选择取款 → 3. 指定金额 → 4. ATM 出钞 → 5. 登出

Extension scenario（当某一步失败条件成立时启动）：在第 4 步 {Insufficient cash on hand} → 1. 通知用户 → 2. 用户登出。

6.4 «extend»、«include»、泛化

关系 含义 箭头方向 例子
«extend» 给 use case 加一个可选步骤，且不影响原 use case 的规格；需要 extension point 从扩展用例指向基用例（虚线箭头） Update Branch Balance --«extend»--> Withdraw Cash，扩展点 X1（第 4 步之后），条件 [service successful]
«include» 场景中某一步本身是一个子 use case（有自己的目标、actor）；主用例依赖子用例的功能 从基用例指向被包含用例（虚线箭头） Withdraw Cash --«include»--> Login（Login：询问 PIN → 输入 PIN → 验证 PIN …）
Generalization 父子关系，子用例是父用例的增强 实线 + 空心三角指向父用例 Pay by Card → Pay 
flowchart LR
    W((Withdraw Cash<br/>ext. point: X1))
    L((Login))
    U((Update Branch Balance))
    W -. "«include»" .-> L
    U -. "«extend» [service successful]" .-> W

讲义特别提醒：“Note the direction of the arrow!” —— extend 指向基用例，include 指向被包含用例。 这是考试和作业最常见的错误。

记忆：include 是“我必须用到它”（基用例知道子用例）；extend 是“它可以插进我”（基用例不知道扩展的存在，只暴露扩展点）。

6.5 保持简单和敏捷

  • Use case 应该让利益相关者容易理解，以便他们能推理
  • 避免实现细节、保持非正式（不是所有利益相关者都是技术专家）
  • 用易读的文本形式

6.6 例子一：Patient Consults AI Health Agent

字段 内容
Goal 患者得到症状的解决方案
Level User-goal
Primary Actor Patient
Preconditions 患者可访问 AI Health Agent；Agent 可访问诊所排期系统
Success postcondition 患者获得治疗建议（轻症）或确认的医生预约（严重/不确定）
Failure postcondition Agent 未能给出方案
Trigger 用户启动 AI Agent

Main success scenario：1 发起对话 → 2 Agent 问候并询问症状 → 3 描述症状 → 4 Agent 追问（严重度、持续时间、病史、过敏）→ 5 患者回答 → 6 Agent 对照医学指南分析 → 7 判断 (a) 轻症可居家/自我用药，或 (b) 需专业评估 → 8 若 7a：给出治疗建议 → 9 若 7b：预约医生 → 10 结束对话。

Extensions：

  • 5.a {描述不清或不完整} → 反复澄清直到信息足够
  • 7.c {症状危急} → 立即呼叫急救，而不是预约
  • 8.a {患者不理解建议} → 换种说法并提供教育资源

Nested use case（第 9 步）：查询医生空闲时段 → 患者确认时间 → 预约并提供确认信息。

6.7 面向 agentic 软件的 use case 模型（本讲最新的部分）

对 agentic 软件，use case 模型应该强调“有界自治（bounded autonomy）”和“可观察的结果”——而不只是固定的交互序列。

要素 写法
Actor goal 写业务结果，如 “deliver an evidence-backed weekly brief”，而不是 “run the research agent”
Authority 明确 agent 可以读、写、发送、购买或修改什么。把能力（capability）和权限（permission）分开
Success conditions 定义可观察的成功证据，而不是精确的推理路径
Failure and uncertainty 把缺数据、证据冲突、工具不可用、低置信度结果建模为正常分支
Human checkpoints 标出 agent 何时必须询问、获得批准、移交或停止

6.8 例子二：Assess and coordinate patient care（有界自治版）

字段 内容
Goal 安全的下一步被及时准备好
Level User goal
Primary actor Patient
Preconditions 患者身份与同意已确认；已批准的指南与排期工具可用
Success postcondition 经临床医生批准的指导已发送；记录已更新
Failure postcondition 未发送任何建议；已向临床医生报警并说明原因
Trigger 患者提交新的健康咨询

Main success scenario（bounded autonomy）： 0. 患者确认身份、同意和当前症状 1. Intake agent 检查急症警示信号 2. Agent 结构化症状、病史和上下文 3. Evidence agent 检索已批准的临床指南 4. Care agent 起草分诊摘要和下一步 5. Checker 验证依据（grounding）、隐私和安全约束 6. Agent 准备回复（但不发送） 7. 临床医生审核、修改并批准 8. Agent 发送指导并更新健康记录

显式建模失败与移交：

  • Emergency red flag → 停止自动化，立即通知医生
  • 5.a {指南冲突} → 询问医生
  • Clinical context missing → 请求一次，然后移交
  • 7.a {未获批准} → 保存草稿，不发送建议

对比 6.6 与 6.8：前者 agent 直接给建议、直接预约；后者 agent 只起草，人类审批后才发送，失败后置条件是“什么都没发”。这就是“Requirements describe the outcome; permitted decision-making is explicit”的具体体现，也是项目 Stage 1 写 use case 时应该采用的写法。

6.9 Use case 小结

  • 流行且经过验证的需求规格方法，变体很多；本课采用略作修改的 Cockburn 变体
  • 是一种操作性方法，适合作为设计阶段的前端
  • 通常用 UML 交互建模（如顺序图） 来补充——但两者不同：use case 更抽象

七、需求规格总结

  • 不充分的需求规格可能是软件项目失败的最大来源
  • 正确获取需求很难，最好通过与利益相关者持续互动来完成（敏捷/演化式开发）；架构师在需求获取中起关键作用
  • feature-based + use-case based 结合通常是系统化定义需求的最佳选择
  • 需求建模是需求工程中一小步但关键的一步：使需求与设计等其他制品之间的可追溯性可以被自动支持
  • 前沿：用 LLM 自动生成需求模型（讲义列了三篇论文链接）

八、Tutorial 3 要点与解答思路

8.1 Use case 图组件

组件 规则
Actor 与系统交互的用户：可以是人、组织、外部系统；必须是产生或消费数据的外部对象；用名词命名；是业务中的角色（一个用户可扮演多个角色，如教授既是 instructor 又是 researcher）；actor 触发 use case；对系统有职责（输入）和期望（输出）
Use case 椭圆；系统功能（自动或手工过程）；动词 + 名词命名（Do Something）；每个 actor 必须连到某个 use case，但有些 use case 可以不连 actor（如被 include/extend 的子用例）；可被扩展
Communication link actor 与 use case 之间的实线，表示双方通过消息通信
System boundary 由需求文档定义，代表整个系统范围；大型系统（如 ERP）中每个模块（人事、工资、会计）可以各自是边界，整体边界包含所有模块

8.2 Use case 模板（Tutorial 版）

Name Goal Level Precondition Success Condition Failure Condition Trigger
User Login User successfully logs in User goal level User is registered 登录并跳转主页 密码错误时显示错误信息 用户点击登录按钮

8.3 关系画法速查

关系 线型 箭头指向
«extend» 虚线 + 开放箭头，标 <<extend>> 基用例（扩展用例在箭尾）
«include» 虚线 + 开放箭头，标 <<include>> 子用例（被包含者）
Generalization 实线 + 空心三角 父用例（子用例在箭尾）

Tutorial 给了 E-Shop、Vehicle Sales System 等示例图（PDF 中为图片，文本未提取）。

8.4 解题模板：给定场景写三种需求模型

  1. Ad hoc：先自由列出所有需求，按 What / How / How well 标注；找出歧义、遗漏、冲突
  2. Feature model：把 What 类需求归成能力树，标 mandatory/optional/or/xor；把 How well 中涉及可选配置的写成跨树约束
  3. Use case：从每个 actor 的目标出发画 use case 图；为核心 use case 写模板 + main scenario + extensions；agentic 功能要写 authority 与 human checkpoint
  4. 一致性检查：每个 use case 能映射回某个 feature；每个 mandatory feature 至少被一个 use case 覆盖

九、Lab 3 要点

ELEC5620-Lab-Note-3.pdf（文件头标注 “Week 4: Laboratory 3”）要求把本周三种方法应用到自己的项目：

Part 方法 作用
1 Ad-Hoc 非正式、灵活地描述和分析需求——初始定义
2 Feature-Oriented 把需求系统地精化为具体特征
3 Use Case 确保特征满足用户的期望与交互

三种方法互补：Ad-Hoc 给初步定义，Feature 系统化精化，Use Case 检验用户交互。

它与 Stage 1 评分表的一一对应关系见 Stage 1 评分标准与 Lab 3；三种模型之间的对应检查见 Lab 1–6 总结 第四节。

十、本周考点速记 / 易错点

  1. 需求工程五活动：elicit、model & analyse、communicate、agree、evolve；elicitation 三问：问题、系统边界、利益相关者与目标。
  2. 需求陈述五问题：ambiguity、incompleteness、conflict、priority 差异、感知的紧迫性。
  3. 三种方法的视角：Ad hoc（混合、最常见起点）、Feature（capability view、静态）、Use case（operational view）；结合使用最好。
  4. 非正式规格不够的六个原因：冲突、依赖、覆盖、精确理解、追溯、测试基础。
  5. Feature 定义：突出的、用户可见的特征；用于区分概念实例。特征图四种关系：mandatory、optional、or（≥1）、xor（=1）+ 跨树约束。
  6. Feature 模型缺点：静态，看不出特征如何使用 → 难发现冲突；优点：适合起点和产品族/可变性。
  7. FR vs NFR：what vs how well；并非总可分（4 μs 例子）。
  8. Cockburn：目标驱动、trigger 开始、明确结果结束、失败从失败点分叉。
  9. 箭头方向：«extend» 指向基用例；«include» 指向被包含用例；泛化指向父。
  10. Agentic use case 五要素：业务结果目标、权限（能力 ≠ 许可）、可观察成功证据、失败与不确定性作为正常分支、人工检查点。
  11. 易错：use case 命名用“动词 + 名词”；actor 用名词且是角色；不要把 UI 步骤画成 use case；agent 本身一般在系统内部，不画成外部 actor（除非是外部系统）。