ELEC5620 Stage 1 评分标准拆解 + Lab 3 需求建模三方法

Posted on Edited on In , Word count in article: 2.5k Reading time ≈ 9 mins.
ELEC5620 Project Stage 1 官方评分标准的完整拆解：报告 15 分逐项权重、个人任务与小组任务的划分、必须遵守的溯源链（ad hoc 需求 → use case → 三张行为图），以及「提交越早面试越晚」的排期规则。附 Lab 3 三种需求建模方法及其与评分表的对应关系。

ELEC5620 Stage 1 评分标准拆解 + Lab 3

来源：ELEC5620_Project_Stage_1_Marking_Criteria.pdf（2 页）+ ELEC5620-Lab-Note-3.pdf（Week 4） 相关：项目指南｜需求范例拆解

⭐ 这就是 Week 1 老师说「往年的已过时、会重发」的那份评分文档。里面有两条之前完全不知道的规则，都会实际影响你怎么安排工作。

一、Stage 1 的 30 分怎么来的

Project Description 只说 Stage 1 是 30 分、其中「15 分报告 + 15 分 presentation 和 interview」。现在细化了：

组成 分数 形式
Report Submission 15 各类模型图与文档
Video Presentation 5 ⭐ 8 分钟以内的视频
Interview 10 ⭐ Week 11 / Week 12 的 practical session
合计 30

几个要点：

  • ⭐ 视频严格限时 8 分钟——超时要扣分，讲稿必须提前掐时间
  • 视频上传 Canvas，并建议同时附一个 YouTube 链接
  • 视频内容要覆盖：项目介绍 + 关键 agent 角色 + 功能 + use cases + 设计模型
  • ⭐ 面试在 Week 11–12，比报告提交晚不少——每组按所属 practical session 分配时段，会逐个成员提问

二、⭐ 报告 15 分的逐项拆解

模型 要求 分数 类型
Ad hoc diagram 描述整体软件设计的非正式图 Optional 组
Ad hoc requirements ***** 每人至少贡献 1 条，用非正式描述表达 0.5 👤 个人
Feature diagram(s) 全组一张综合图；⭐ 鼓励尽可能标出非功能需求 1 组
Use case overall diagram 一张涵盖所有架构与利益相关者的综合图 1 组
Use case specification(s) ***** 每人至少 1 份，⭐ 全组共 5–10 个 use case 2 👤 个人
Architecture Analysis and Design 基于恰当 viewpoint 选择的一份分析 + 设计 Optional 组
⭐ Elementary Structure Modelling 类图，正确使用 generalization、composition、aggregation、interface、multiplicity 等关联 3 组
⭐ Complex Structure Modelling 基于类的运行时模型：object diagram、collaboration、structured class 3 组
Activity diagram(s) ***** 每人至少 1 张，建模特定行为 1.5 👤 个人
Interaction diagram(s) ***** 每人至少 1 张，建模特定行为 1.5 👤 个人
State machine diagram(s) ***** 每人至少 1 张，建模特定行为 1.5 👤 个人
Package diagram 一张总体图 Optional 组
Deployment diagram 一张总体图 Optional 组

分数分布（合计正好 15 分）：

维度 分数 占比
⭐⭐ 结构建模（类图 + 运行时模型） 6 40%
行为图（活动 + 交互 + 状态机） 4.5 30%
Use case（总图 + 规格说明） 3 20%
Feature diagram 1 7%
Ad hoc requirements 0.5 3%
—
👤 个人任务（带 *） 7 47%
👥 小组任务 8 53%

⭐⭐ 最该投入精力的是结构建模：类图 3 分 + 运行时模型 3 分 = 6 分，占报告的 40%，是单项最大的一块。 但它同时也是唯一没有"每人至少一张"要求的重头戏——意味着很容易变成少数人扛。必须提前分工，并按第 3 条注意事项标明每人做了哪部分。

💡 四个 Optional 项（ad hoc diagram、architecture analysis、package diagram、deployment diagram）虽然不计分，但 Project Description 的报告要求里明确点名了 package diagram。建议至少把 package diagram 画上——不做不扣分，做了能体现完整性，面试时也好讲。

三、⭐⭐ 五条 Important Notes（比评分表还关键）

1. 需求文档必须随 Stage 1 一起交

所有后续的设计和建模都必须基于你的项目需求文档，以保证全程一致性。

📌 也就是说 Lab 1 写的那份项目文档不是一次性作业，它是整个 Stage 1 的地基。

2. 带星号（*）的是个人任务，必须独立完成

对应五项：ad hoc requirement、use case specification、activity diagram、interaction diagram、state machine diagram。

3. 小组任务也要标明每人贡献

需要说明每位组员在小组任务中的具体贡献，例如：明确指出图中的哪一部分由谁完成，或者每人的贡献百分比。

⚠️ 这条直接针对类图和运行时模型这种"容易一个人画完"的产出。建议在图旁边直接标注区块归属，或附一张贡献矩阵表。

4. ⭐⭐ 溯源链：三张行为图必须来自你自己的需求

在所有个人任务中，你创建的 activity diagram、interaction diagram、state machine diagram 必须基于你自己的 ad hoc requirement 分析和对应的 use case specification。

这意味着每个人要拉通一条完整的纵向切片：

你的 ad hoc requirement (0.5)
        ↓ 细化
你的 use case specification (2)
        ↓ 分别建模三种行为
   ┌────────┼────────┐
Activity  Interaction  State machine
 (1.5)      (1.5)       (1.5)

⭐ 规划含义：你选的那条需求，必须同时撑得起活动图、交互图和状态机三种视角。

  • ❌ 选一条太简单的需求（比如"用户可以修改昵称"）→ 状态机没东西可画
  • ✅ 选一条有多步流程、有多方参与、有明确状态迁移的需求

💡 放到 trip planning 项目里，好的个人需求切片长这样： 「预算超支时的协商与升级」——活动图画协商流程、交互图画 Planner ↔︎ Budget Advisor 的来回、状态机画行程从 Draft → OverBudget → Revised → PendingApproval → Approved 的迁移。一条需求三张图全有戏。

5. ⭐⭐ 面试排期：交得越早，面试越晚

关于面试顺序，我们会看 Assignment 1 的提交时间，并按倒序分配时段——你交得越早，面试时段就越靠后。

这是一条可以主动利用的规则：

策略 结果
⭐ 早交 面试排在后面（Week 12）→ 多出一两周准备面试
晚交（卡 deadline） 面试排在前面（Week 11）→ 交完没几天就要面

⭐ 结论：尽早提交是双赢的——既避开 Canvas 截止前的拥堵，又给自己争取到最多的面试准备时间。这条规则显然就是为了鼓励早交而设计的，别浪费。

四、Lab 3（Week 4）：三种需求建模方法

Lab 3 要求用三种互补的方法，基于你们已选的项目题目和需求做建模。

方法 特点 定位
① Ad-Hoc Approach 非正式、灵活，不依赖预定义结构或标准，按项目具体情境调整 初始的、灵活的需求定义
② Feature-Oriented Approach 识别并描述系统的关键特性与属性，强调系统应具备的具体功能 系统性地把需求细化成具体特性
③ Use Case Approach 用 use case 说明系统如何与用户或其他系统交互，特别适合捕捉和理解用户需求 确保特性符合用户预期与交互

官方原话的三者关系：

Ad-Hoc 提供初始的、灵活的需求定义 → Feature-Oriented 系统性地将其细化为具体特性 → Use Case 确保这些特性满足用户预期和交互。

⭐ Lab 3 就是 Stage 1 的前四行

把 Lab 3 的三种方法和评分表对一下，会发现是一一对应的：

Lab 3 的方法 评分表对应项 分数
① Ad-Hoc Ad hoc diagram（Optional）+ Ad hoc requirements * 0.5
② Feature-Oriented Feature diagram(s) 1
③ Use Case Use case overall diagram + Use case specification(s) * 3

⭐ 所以 Lab 3 不是练习，是 Stage 1 的第一批交付物（合计 4.5 分，且其中 2.5 分是个人任务）。当堂就该按最终要交的质量来做。

Feature diagram 的加分提示：评分表写了 "You are encouraged to specify non-functional requirements for the features where possible" ——记得标非功能需求（响应时间、准确率、隐私、可用性）。这是免费的加分点，很多组会漏。

五、5 人组的工作量分配

每人的个人任务（固定 5 项）

交付物 数量 分数
Ad hoc requirement ≥1 条 0.5
Use case specification ≥1 份 2
Activity diagram ≥1 张 1.5
Interaction diagram ≥1 张 1.5
State machine diagram ≥1 张 1.5

⚠️ 必须是同一条需求贯穿下来（Note 4）。

Use case 总数控制：全组要 5–10 个。5 人组 → 每人 1 个（共 5）到每人 2 个（共 10）都合规。建议每人 2 个，一个作为个人 spec 的主线，另一个补充覆盖面。

小组任务分工建议

交付物 分数 建议
Feature diagram 1 1 人主笔 + 全组评审；记得标非功能需求
Use case overall diagram 1 1 人整合全组的 use case
⭐ 类图 3 ⭐ 按 agent 切分：每人负责自己主责 agent 的类，再由 Integration Owner 合并
⭐ 运行时模型 3 ⭐ 挑 2–3 个关键场景画 object/collaboration，每人认领一个场景
Package diagram Optional 建议做，Integration Owner 出

⭐ 类图和运行时模型按 agent / 场景切分，天生就满足了 Note 3「标明每人贡献」的要求——在图上直接标出每个区块的负责人即可。

六、行动清单

Week 4（Lab 3）当堂完成：

之后：

七、和之前笔记的差异

项 之前的理解 ⭐ 现在的准确信息
Stage 1 内部构成 报告 15 + presentation & interview 15 报告 15 + 视频 5 + 面试 10
Presentation 形式 只知道要 slides ⭐ 8 分钟视频，传 Canvas + 建议附 YouTube
面试时间 不明确 ⭐ Week 11 / Week 12 的 practical session
面试排期 不知道 ⭐⭐ 按提交时间倒序——交得越早面试越晚
各图权重 不知道 ⭐ 结构建模占 40%，是最大头
行为图的约束 不知道 ⭐⭐ 必须溯源到自己的 ad hoc requirement 和 use case