实验1：系统需求分析与用例建模 – 技术笔记

📖 知识概览

本实验涵盖了软件工程中需求分析阶段的两种重要建模方法：

面向对象建模：用例图 + 用例规约结构化建模：数据流图（DFD）

通过智能会议室管理系统的实际案例，掌握需求分析的完整流程。

🎯 核心概念解析

1. 需求分析的本质

定义：需求分析是软件开发生命周期的第一步，回答”系统要做什么”的问题。

重要性：

🏗️ 软件开发的基础，决定后续所有工作💰 需求错误的修复成本随开发进度指数增长🎯 直接影响用户满意度和项目成功率

2. 两种分析方法对比

特征	面向对象方法	结构化方法
核心思想	以对象和交互为中心	以数据流转为中心
主要工具	用例图、用例规约	数据流图、数据字典
适用场景	交互复杂的现代系统	业务流程清晰的系统
优势	贴近现实、易维护	逻辑清晰、易理解

🔍 需求诱导十原则详解

核心原则记忆口诀

“听准推面记协聚图进赢”

倾听 👂 – 多听客户说，少打断 有准备的沟通 📋 – 提前准备问题清单 需要有人推动 👨‍💼 – 指定专人负责 最好当面沟通 🤝 – 面对面效果最佳 记录所有决定 📝 – 避免后期争议 保持通力协作 🤝 – 团队合作 聚焦并协调话题 🎯 – 不偏离主题 采用图形表示 📊 – 图比文字更直观 继续前进原则 ⏩ – 不在细节上纠缠 谈判双赢原则 🏆 – 寻找平衡点

实际应用技巧

场景：与客户讨论会议室预订功能

❌ 错误做法：”您需要一个网页版的系统吗？”

✅ 正确做法：”请您描述一下平时是怎么预订会议室的？”

📊 用例建模核心要点

用例图三要素

1. 参与者（Actor）

识别原则：

✅ 直接与系统交互的角色✅ 系统外部的人或系统❌ 不包含系统内部组件

常见错误：

❌ 把”数据库”当作参与者

❌ 把”登录界面”当作参与者

✅ 把”普通用户”当作参与者

✅ 把”邮件系统”当作参与者

2. 用例（Use Case）

命名规范：

格式：动词 + 名词例子：预订会议室、审批申请、管理用户

粒度判断：

❌ 粒度过小：”点击登录按钮”

❌ 粒度过大：”会议室管理”

✅ 粒度适中：”用户登录”、”预订会议室”

3. 关系（Relationship）

三种关系对比：

关系类型	符号	使用场景	示例
Association	实线	参与者与用例	用户 → 登录系统
Include	虚线<<include>>	必须的子功能	预订会议室 → 用户登录
Extend	虚线<<extend>>	可选的扩展	发送通知 ← 预订会议室

关系使用技巧：

Include使用场景：

– 多个用例都需要的公共功能

– 例：登录验证、权限检查

Extend使用场景：

– 可选的附加功能

– 例：发送邮件通知、生成报表

📝 用例规约编写要点

标准模板结构

用例名称：       [动词+名词格式]

用例描述：       [一句话概括功能]

执行者：         [主要参与者]

前置条件：       [执行前必须满足的条件]

后置条件：       [执行后系统状态变化]

主过程描述：     [正常执行流程，步骤编号]

分支过程描述：   [可选路径，使用层次编号]

异常过程描述：   [错误处理流程]

业务规则：       [约束条件]

涉及的业务实体： [相关数据对象]

编写技巧与注意事项

1. 流程描述规范

✅ 好的描述：

1. 用户输入用户名和密码

2. 系统验证用户身份

3. 验证通过，系统显示主界面

❌ 差的描述：

1. 点击登录按钮

2. 进入系统

3. 显示页面

2. 分支编号规范

主流程：     1, 2, 3, 4…

一级分支：   2.1, 2.2, 4.1…

二级分支：   2.1.1, 2.1.2…

三级分支：   2.1.1.1, 2.1.1.2…

3. 异常处理要点

🚨 覆盖所有可能的错误情况📋 提供明确的错误处理流程🔄 指明错误后的系统状态

🌊 数据流图建模要点

DFD四要素详解

1. 外部实体（External Entity）

表示：矩形 □含义：系统外部的数据源或目标示例：用户、管理员、外部系统

2. 处理过程（Process）

表示：圆形 ○含义：数据变换和处理功能编号：层次化编号（P1, P1.1, P1.2…）

3. 数据存储（Data Store）

表示：开口矩形 ⧠含义：数据保存的地方编号：D1, D2, D3…

4. 数据流（Data Flow）

表示：带箭头的直线 →含义：数据的流动命名：使用名词，描述数据内容

分层设计原则

层次结构

顶层图（Context Diagram）

├── 0层图（Level 0）

    ├── 1层图（Level 1）

        └── 2层图（Level 2）…

数据平衡原则

上下层之间的输入输出必须保持一致

❌ 违反平衡：

上层：用户信息 → P1 → 用户状态

下层：P1.1 → 登录结果（缺少用户信息输入）

✅ 满足平衡：

上层：用户信息 → P1 → 用户状态

下层：用户信息 → P1.1 → 验证结果 → P1.2 → 用户状态

🛠️ Draw.io实用技巧

基础操作技巧

快捷键：

Ctrl + C / V    复制粘贴

Ctrl + Z / Y    撤销重做

Ctrl + A        全选

Ctrl + G        组合元素

Ctrl + Shift + G 取消组合

UML元素选择指南

用例图元素：

– Actor：UML库 → Actor

– Use Case：UML库 → Use Case

– Association：UML库 → Association

– Dependency：UML库 → Dependency（用于Include/Extend）

数据流图元素：

– 圆形：Basic Shapes → Ellipse

– 矩形：Basic Shapes → Rectangle

– 箭头：Arrows → 选择合适样式

布局美化技巧

对齐功能：选中多个元素 → 右键 → Align 分布功能：Arrange → Distribute 网格对齐：View → Grid → 勾选 层次管理：Arrange → To Front/Back

⚠️ 常见错误与解决方案

用例建模错误

1. 用例粒度问题

❌ 错误：把UI操作当用例

正确：把业务目标当用例

❌ 错误：用例过于庞大

正确：合理分解用例

2. 参与者识别错误

❌ 错误：系统内部组件作为参与者

正确：只有外部实体才是参与者

❌ 错误：抽象概念作为参与者

正确：具体的角色作为参与者

3. 关系使用错误

❌ 错误：滥用Include/Extend关系

正确：只在必要时使用特殊关系

❌ 错误：Include/Extend方向错误

正确：Include从基用例指向子用例，Extend相反

数据流图错误

1. 数据不平衡

❌ 错误：子图输入输出与父图不匹配

正确：严格保持数据平衡

检查方法：

– 对比上下层图的数据流

– 确保每个输入输出都有对应

2. 命名不规范

❌ 错误：数据流使用动词命名

正确：数据流使用名词命名

❌ 错误：”发送用户信息”

✅ 正确：”用户信息”

🎯 实践应用指南

需求分析流程

1. 需求收集 → 2. 场景分析 → 3. 用例建模 → 4. 规约编写 → 5. 数据流设计

质量检查清单

用例图检查项

☐  所有参与者都在系统边界外

☐  所有用例都在系统边界内

☐  关系使用正确且必要

☐  命名规范且清晰

☐  布局美观易读

用例规约检查项

☐  所有字段都已填写

☐  主流程逻辑完整

☐  异常情况考虑周全

☐  编号规范无误

☐  业务规则明确

数据流图检查项

☐  四要素使用正确

☐  数据平衡满足

☐  分层合理

☐  命名规范

☐  无信息孤岛

🚀 进阶学习方向

深入理解

需求工程：需求获取、分析、规约、验证、管理 UML建模：类图、序列图、活动图等 敏捷需求：用户故事、验收标准、迭代规划

工具拓展

专业UML工具：Visual Paradigm、Enterprise Architect 需求管理工具：Jira、Azure DevOps、Reqtify 原型工具：Axure、Figma、墨刀

实践项目

选择熟悉的业务场景进行建模练习参与开源项目的需求分析阅读优秀的需求文档案例

💡 经验总结

需求分析的核心思维

用户视角：始终从用户角度思考问题 业务导向：关注业务价值而非技术实现 迭代完善：需求分析是一个持续完善的过程 协作沟通：多方参与，充分沟通

成功要素

🎯 明确目标：清楚分析的目的和范围👥 团队协作：发挥集体智慧📋 文档化：及时记录和整理成果🔄 持续改进：根据反馈不断优化

记住：好的需求分析是成功软件的基石！ 🏆