11.需求分析与设计

1. 为什么需要需求分析与设计?

1.1 开发前的思考

常见问题

  • 直接写代码:写着写着发现需求不清楚,要重写
  • 没有规划:功能混乱,用户体验差
  • 沟通不畅:开发者和用户理解不一致

生活类比

  • 没有需求分析:像盖房子不画图纸,盖到一半发现不对
  • 有需求分析:先画图纸,再施工,事半功倍

1.2 需求分析与设计的作用

阶段 作用 实际效果
需求分析 明确"要做什么" 避免返工,节省时间
原型设计 明确"长什么样" 提前发现问题,优化体验
数据模型设计 明确"数据怎么存" 数据结构清晰,易于开发
系统设计 明确"怎么实现" 开发有方向,不混乱

💡 记忆技巧
需求分析 = 盖房子前的"图纸设计",虽然花时间,但能避免很多问题!


2. 用户故事编写

2.1 什么是用户故事?

用户故事 = 从用户角度描述功能需求

格式

1
2
3
作为 [角色]
我想要 [功能]
以便于 [价值]

生活类比

  • 传统需求:"做一个登录功能"(不清晰)
  • 用户故事:"作为用户,我想要登录系统,以便于访问我的个人数据"(清晰)

2.2 用户故事的要素

三个要素

要素 说明 示例
角色 谁要用这个功能 用户、管理员、游客
功能 要做什么 登录、查看订单、发布文章
价值 为什么要做 保护隐私、方便管理、分享信息

实际例子

1
2
3
4
5
6
7
作为 学生
我想要 查看我的成绩
以便于 了解学习情况

作为 管理员
我想要 管理用户信息
以便于 维护系统正常运行

2.3 用户故事的拆分

原则:一个用户故事应该是一个独立、可完成的功能

好的用户故事

  • ✅ 独立:不依赖其他故事
  • ✅ 可完成:能在短时间内完成
  • ✅ 有价值:对用户有意义

不好的用户故事

  • ❌ 太大:"做一个完整的电商系统"
  • ❌ 太模糊:"优化用户体验"
  • ❌ 没有价值:"添加一个按钮"

拆分示例

1
2
3
4
5
6
7
8
❌ 不好的故事:
"做一个待办事项应用"

✅ 拆分后的故事:
1. 作为用户,我想要添加待办事项,以便于记录任务
2. 作为用户,我想要删除待办事项,以便于清理已完成的任务
3. 作为用户,我想要标记任务完成,以便于跟踪进度
4. 作为用户,我想要查看所有待办事项,以便于了解任务列表

2.4 需求文档编写

2.4.1 需求文档的结构

基本结构

  1. 项目概述:项目是什么,解决什么问题
  2. 用户角色:有哪些用户角色
  3. 功能需求:用用户故事描述功能
  4. 非功能需求:性能、安全、兼容性等
  5. 界面要求:基本的界面要求

实际例子

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
# 待办事项应用需求文档

## 1. 项目概述
开发一个待办事项管理应用,帮助用户记录和管理日常任务。

## 2. 用户角色
- 普通用户:使用应用管理自己的待办事项

## 3. 功能需求

### 3.1 添加待办事项
作为用户,我想要添加待办事项,以便于记录任务。

**验收标准**
- 可以输入任务内容
- 点击添加按钮后,任务出现在列表中
- 输入为空时,提示用户输入

### 3.2 删除待办事项
作为用户,我想要删除待办事项,以便于清理已完成的任务。

**验收标准**
- 每个任务旁边有删除按钮
- 点击删除按钮后,任务从列表中移除

## 4. 非功能需求
- 页面加载时间 < 2秒
- 支持现代浏览器(Chrome、Firefox、Safari)
- 数据保存在浏览器本地存储

3. 原型设计工具

3.1 什么是原型?

原型 = 产品的"草图",展示界面布局和交互

生活类比

  • 没有原型:直接盖房子,不知道效果
  • 有原型:先画图纸,看看效果,再决定怎么盖

原型的价值

价值 说明
提前发现问题 在设计阶段发现用户体验问题
统一理解 开发者和用户对界面理解一致
节省成本 修改原型比修改代码便宜得多

3.2 常用原型设计工具

3.2.1 在线工具(推荐)

工具 特点 适用场景
Figma 功能强大,免费版够用 专业设计、团队协作
墨刀 中文界面,上手快 快速原型、移动端
ProcessOn 简单易用,免费 流程图、简单原型

3.2.2 手绘原型(最简单)

优点

  • 快速:几分钟就能画出来
  • 灵活:随时修改
  • 低成本:只需要纸和笔

适用场景

  • 初期想法验证
  • 快速沟通
  • 个人项目

实际例子

1
2
3
4
5
6
7
8
9
10
11
手绘原型示例:
┌─────────────────────────┐
│ 待办事项应用 │
├─────────────────────────┤
│ [输入框] [添加按钮] │
├─────────────────────────┤
│ ☐ 学习Vue │
│ [删除] │
│ ☐ 完成作业 │
│ [删除] │
└─────────────────────────┘

3.2.3 使用Figma快速原型

基本步骤

  1. 创建画板:选择合适的设备尺寸(如网页1920x1080)
  2. 添加元素:拖拽矩形、文本、按钮等
  3. 设置样式:调整颜色、字体、大小
  4. 添加交互:设置点击效果(可选)

实际例子

1
2
3
4
5
Figma原型示例(文字描述):
- 顶部:标题"待办事项"
- 中间:输入框 + "添加"按钮(横向排列)
- 下方:待办事项列表
- 每个事项:复选框 + 文字 + "删除"按钮

💡 建议
初学者可以先用手绘原型,快速验证想法。
需要更专业的原型时,再使用Figma等工具。


3.3 原型设计原则

原则

原则 说明 示例
简洁明了 界面不要太复杂 一个页面一个主要功能
符合习惯 遵循用户使用习惯 登录按钮通常在右上角
突出重点 重要功能要醒目 主要按钮用大号、醒目颜色
一致性 相同功能用相同样式 所有删除按钮样式统一

4. 数据模型设计

4.1 什么是数据模型?

数据模型 = 描述数据结构和数据之间的关系

生活类比

  • 没有数据模型:数据乱放,找不到
  • 有数据模型:数据分类整理,结构清晰

实际例子

1
2
3
4
5
6
7
待办事项应用的数据模型:

待办事项(Todo)
- id: 唯一标识
- text: 任务内容
- completed: 是否完成
- createdAt: 创建时间

4.2 实体关系设计

4.2.1 识别实体

实体 = 系统中需要存储的对象

实际例子

博客系统

  • 用户(User)
  • 文章(Article)
  • 评论(Comment)

待办事项系统

  • 待办事项(Todo)
  • 用户(User)- 如果需要多用户功能

4.2.2 识别属性

属性 = 实体的特征

实际例子

用户(User)实体

属性 类型 说明
id 数字 唯一标识
username 字符串 用户名
email 字符串 邮箱
password 字符串 密码(加密存储)
createdAt 日期 创建时间

待办事项(Todo)实体

属性 类型 说明
id 数字 唯一标识
text 字符串 任务内容
completed 布尔值 是否完成
userId 数字 所属用户ID(关联用户)
createdAt 日期 创建时间

4.2.3 识别关系

关系类型

关系 说明 示例
一对一 一个实体对应一个实体 用户 ↔︎ 用户资料
一对多 一个实体对应多个实体 用户 → 多篇文章
多对多 多个实体对应多个实体 文章 ↔︎ 标签

实际例子

1
2
3
4
5
6
7
8
9
10
11
用户和待办事项的关系:
一个用户可以有多个待办事项(一对多)
一个待办事项只属于一个用户(多对一)

用户和文章的关系:
一个用户可以写多篇文章(一对多)
一篇文章只属于一个用户(多对一)

文章和标签的关系:
一篇文章可以有多个标签(多对多)
一个标签可以属于多篇文章(多对多)

4.3 数据模型示例

4.3.1 简单应用:待办事项

数据模型

1
2
3
4
5
6
7
8
9
10
11
12
13
// 待办事项数据模型(JavaScript对象)
const todoModel = {
id: 1, // 唯一标识
text: '学习Vue', // 任务内容
completed: false, // 是否完成
createdAt: '2024-01-01' // 创建时间
};

// 待办事项列表
const todos = [
{ id: 1, text: '学习Vue', completed: false, createdAt: '2024-01-01' },
{ id: 2, text: '完成作业', completed: true, createdAt: '2024-01-02' }
];

4.3.2 复杂应用:博客系统

数据模型

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
// 用户模型
const userModel = {
id: 1,
username: 'zhangsan',
email: 'zhangsan@example.com',
createdAt: '2024-01-01'
};

// 文章模型
const articleModel = {
id: 1,
title: 'Vue入门教程',
content: '...',
authorId: 1, // 关联用户ID
createdAt: '2024-01-15'
};

// 评论模型
const commentModel = {
id: 1,
content: '写得很好!',
articleId: 1, // 关联文章ID
userId: 2, // 关联用户ID
createdAt: '2024-01-16'
};

关系说明

  • 用户 → 文章(一对多)
  • 文章 → 评论(一对多)
  • 用户 → 评论(一对多)

5. AI实战:使用AI设计数据模型

5.1 任务描述

目标:使用AI工具设计一个博客系统的数据模型

功能要求

  • 用户可以注册、登录
  • 用户可以发布文章
  • 用户可以评论文章
  • 文章可以分类(标签)
  • 需要设计用户、文章、评论、标签的数据模型

5.2 第一步:设计Prompt

Prompt示例

1
2
3
4
5
6
7
8
9
10
11
设计一个博客系统的数据模型,要求:
1. 用户实体:包含id、用户名、邮箱、密码、创建时间
2. 文章实体:包含id、标题、内容、作者ID、创建时间
3. 评论实体:包含id、内容、文章ID、用户ID、创建时间
4. 标签实体:包含id、名称
5. 关系说明:
- 用户和文章:一对多
- 文章和评论:一对多
- 文章和标签:多对多
6. 用JavaScript对象格式展示数据模型
7. 说明每个字段的类型和用途


5.3 AI生成的数据模型(示例)

数据模型设计

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
// 用户模型
const User = {
id: Number, // 用户ID(主键)
username: String, // 用户名(唯一)
email: String, // 邮箱(唯一)
password: String, // 密码(加密存储)
avatar: String, // 头像URL(可选)
createdAt: Date, // 创建时间
updatedAt: Date // 更新时间
};

// 文章模型
const Article = {
id: Number, // 文章ID(主键)
title: String, // 文章标题
content: String, // 文章内容
summary: String, // 文章摘要(可选)
authorId: Number, // 作者ID(外键,关联User)
viewCount: Number, // 浏览量
likeCount: Number, // 点赞数
status: String, // 状态(draft-草稿,published-已发布)
createdAt: Date, // 创建时间
updatedAt: Date // 更新时间
};

// 评论模型
const Comment = {
id: Number, // 评论ID(主键)
content: String, // 评论内容
articleId: Number, // 文章ID(外键,关联Article)
userId: Number, // 用户ID(外键,关联User)
parentId: Number, // 父评论ID(支持回复评论)
createdAt: Date // 创建时间
};

// 标签模型
const Tag = {
id: Number, // 标签ID(主键)
name: String, // 标签名称(唯一)
color: String // 标签颜色(可选)
};

// 文章-标签关联表(多对多关系)
const ArticleTag = {
articleId: Number, // 文章ID(外键)
tagId: Number // 标签ID(外键)
};

关系说明

  • 用户 ↔︎ 文章:一对多(一个用户可以写多篇文章)
  • 文章 ↔︎ 评论:一对多(一篇文章可以有多个评论)
  • 用户 ↔︎ 评论:一对多(一个用户可以写多个评论)
  • 文章 ↔︎ 标签:多对多(一篇文章可以有多个标签,一个标签可以属于多篇文章)

5.4 数据模型验证

检查清单

  • ✅ 每个实体都有唯一标识(id)
  • ✅ 关系字段正确(外键)
  • ✅ 字段类型合理(字符串、数字、日期等)
  • ✅ 必填字段明确(如用户名、邮箱)
  • ✅ 关系设计合理(符合业务逻辑)

6. 选讲:UML与流程图

6.1 UML基础

6.1.1 什么是UML?

UML = Unified Modeling Language(统一建模语言)

作用:用图形化的方式描述系统设计

生活类比

  • UML = 建筑图纸(用标准符号画图,大家都看得懂)
  • 没有UML = 用文字描述(容易理解偏差)

6.1.2 常用UML图

UML图类型 作用 适用场景
用例图 描述系统功能 需求分析阶段
类图 描述数据结构 数据模型设计
时序图 描述交互流程 功能实现设计
活动图 描述业务流程 业务流程设计

6.1.3 类图示例

作用:描述数据模型的结构

实际例子

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
类图示例(文字描述):

┌─────────────┐
│ User │
├─────────────┤
│ +id: int │
│ +username │
│ +email │
│ +password │
└─────────────┘

│ 1

│ *
┌─────────────┐
│ Article │
├─────────────┤
│ +id: int │
│ +title │
│ +content │
│ +authorId │
└─────────────┘

说明

  • + 表示公开属性
  • 1 表示一个
  • * 表示多个
  • 箭头表示关系方向

6.2 流程图

6.2.1 什么是流程图?

流程图 = 用图形描述流程的步骤

作用:清晰展示业务流程或功能流程


6.2.2 流程图符号

符号 含义 说明
圆角矩形 开始/结束 流程的起点和终点
矩形 处理步骤 执行的操作
菱形 判断 条件判断
箭头 流程方向 表示执行顺序

6.2.3 流程图示例

用户登录流程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
流程图示例(文字描述):

开始

显示登录页面

用户输入用户名和密码

验证输入是否为空?
├─ 是 → 提示"请输入用户名和密码" → 返回登录页面
└─ 否 ↓
发送登录请求

验证用户名和密码?
├─ 错误 → 提示"用户名或密码错误" → 返回登录页面
└─ 正确 ↓
保存登录状态

跳转到首页

结束

6.2.4 绘制流程图的工具

工具 特点 适用场景
ProcessOn 在线工具,免费 快速绘制流程图
Draw.io 功能强大,免费 专业流程图绘制
手绘 快速简单 初期设计、快速沟通

6.3 系统设计思维

6.3.1 自顶向下设计

思路:从整体到细节

步骤

  1. 整体规划:系统有哪些模块?

  2. 模块设计:每个模块有哪些功能?

  3. 功能实现:每个功能怎么实现?

实际例子

1
2
3
4
5
6
7
8
9
10
11
12
13
14
博客系统设计:

1. 整体规划:
- 用户模块
- 文章模块
- 评论模块

2. 模块设计:
- 用户模块:注册、登录、个人中心
- 文章模块:发布、编辑、删除、查看
- 评论模块:评论、回复、删除

3. 功能实现:
- 注册:表单验证 → 保存数据 → 返回结果

6.3.2 模块化设计

原则:把系统拆分成独立的模块

优势

优势 说明
易于开发 不同人负责不同模块
易于维护 修改一个模块不影响其他模块
易于测试 可以单独测试每个模块

本章总结

通过本章的学习,你已经掌握了:

用户故事编写

  • 用户故事的格式和要素
  • 如何拆分用户故事
  • 如何编写需求文档

原型设计

  • 原型的作用和价值
  • 常用原型设计工具
  • 原型设计原则

数据模型设计

  • 如何识别实体和属性
  • 如何设计实体关系
  • 数据模型的设计方法

实战技能

  • 使用AI设计数据模型
  • 输出需求文档
  • 绘制界面原型

进阶知识(选讲):

  • UML基础(类图、用例图)
  • 流程图绘制
  • 系统设计思维

🌟 恭喜你!
你已经掌握了需求分析与设计的核心技能!
这些知识将帮助你:

  • 明确项目需求

  • 设计合理的系统结构

  • 提高开发效率

记住:好的设计是成功的一半!
继续练习,继续探索,系统设计的世界等着你! 🚀