需求分析与规格说明书是一项十分艰巨复杂的工作。用户与分析员之间需要沟通的内容非常的多，在双方交流信息的过程中很容易出现误解或遗漏，也可能存在二义性。如何才能更加准确的表达双方的意思，且清楚明了，绘制各类图形就显得非常有必要。
前文基础：
1.软件工程学概述：软件工程学概述-CSDN博客
2.软件过程深度解析：软件过程深度解析-CSDN博客
一、实体-联系图
（一）基本思想与定义
实体 - 联系图（Entity-Relationship Diagram，ER 图）是一种用于描述系统数据模型的图形化工具，由 Peter Chen 于 1976 年提出。其核心思想是通过实体、属性和关系三个基本要素，抽象现实世界中的数据对象及其关联，为数据库设计提供概念模型。
定义：ER 图是一种基于实体、属性和关系的建模工具，用于表示系统的数据结构，明确数据对象的静态特征及其相互间的联系，是需求分析阶段的重要成果之一。
（二）表示形式与实现过程
1.表示形式：
实体：用矩形框表示，标注实体名称（如“学生”“课程”）。
属性：用椭圆表示，通过无向边连接到实体（如“学生”实体的属性“学号”“姓名”）。
关系：用菱形表示，标注关系名称（如“选修”），通过无向边连接相关实体，边旁标注关系的基数（如“1:N”“M:N”）。
2.实现过程：
（1）需求分析：通过访谈、问卷等方式获取用户数据需求，识别关键实体（如“用户”“订单”）。
（2）属性定义：确定每个实体的属性，区分主键（唯一标识实体的属性，如“学号”）和非主键属性。
（3）关系建模：分析实体间的关联，确定关系类型（如“学生”与“课程”的“选修”关系为 M:N）。
（4）绘制ER图：使用工具（如PowerDesigner）绘制ER图，标注实体、属性和关系。
验证与优化：与用户确认模型的准确性，消除冗余或歧义。
图1 选课系统的ER图
（三）具体示例：图书馆管理系统
项目背景：某高校图书馆开发管理系统，需实现图书借阅、归还、预约等功能。
流程说明：
1.需求分析：
实体识别：图书、读者、借阅记录、预约记录。
2.属性定义：
图书：ISBN（主键）、书名、作者、出版社、库存数量。
读者：读者 ID（主键）、姓名、学院、借阅上限。
借阅记录：记录 ID（主键）、图书 ISBN（外键）、读者 ID（外键）、借阅日期、归还日期。
3.关系建模：
图书与读者的“借阅”关系为M:N，即一个读者可借阅多本图书，一本图书可被多个读者借阅。
借阅记录与图书、读者的关系为1:1，即一条借阅记录对应唯一的图书和读者。
4.ER 图绘制：
图2 图书馆管理系统 ER 图
5.数据库映射：
图书表（ISBN, 书名，作者，出版社，库存数量）。
读者表（读者 ID, 姓名，学院，借阅上限）。
借阅记录表（记录 ID, ISBN, 读者 ID, 借阅日期，归还日期）。
二、数据规范化
（一）基本思想与定义
数据规范化（Data Normalization）是通过规则将数据库表结构分解，消除数据冗余和异常（插入、更新、删除异常），提升数据一致性和存储效率的过程。其核心思想是遵循范式（Normal Form）逐步优化数据结构。
定义：数据规范化是一种数据库设计技术，通过应用范式规则，将数据表分解为更小、更稳定的表，减少数据冗余，确保数据依赖的合理性。
（二）表示形式与实现过程
1.表示形式：
范式规则：
（1）1NF（第一范式）：每个属性为原子值，无重复组。
（2）2NF（第二范式）：在1NF基础上，非主属性完全依赖于主键。
（3）3NF（第三范式）：在2NF基础上，消除非主属性间的传递依赖。
依赖关系：
（1）函数依赖：X → Y，表示属性 Y 的值由属性 X 唯一确定。
（2）传递依赖：若X → Y且Y → Z，则X → Z（传递依赖）。
2.实现过程：
（1）1NF 处理：
拆分重复属性，确保每个属性为原子值。
示例：将“课程与成绩”列拆分为“课程”和“成绩”两列。
（2）2NF 处理：
消除部分依赖，将部分依赖的属性移至新表。
示例：选课表（学号，课程号，成绩，系别）中，“系别”仅依赖“学号”，拆分为选课表（学号，课程号，成绩）和学生表（学号，系别）。
（3）3NF 处理：
消除传递依赖，将传递依赖的属性移至新表。
示例：学生表（学号，系别，系主任）中，“系主任”依赖“系别”，拆分为学生表（学号，系别）和系表（系别，系主任）。
（三）具体示例：电商订单系统
项目背景：某电商平台优化订单表结构，解决数据冗余和更新异常问题。
流程说明：
1.初始表结构的SQL：
CREATE TABLE orders (
order_id INT PRIMARY KEY,
user_id INT,
username VARCHAR(50),
product_name VARCHAR(100),
price DECIMAL(10,2),
quantity INT,
total DECIMAL(10,2),
address VARCHAR(200));问题：
（1）用户名重复存储（同一用户多次下单）。
（2）产品名称和价格重复存储（同一产品多次被购买）。
（3）地址重复存储（同一用户多次使用同一地址）。
2.1NF 处理：
确保每个属性为原子值（已满足）。
3.2NF 处理：
主键为order_id，非主属性username、product_name、price、address部分依赖于user_id或product_id。
拆分为：
CREATE TABLE users (
user_id INT PRIMARY KEY,
username VARCHAR(50),
address VARCHAR(200));
CREATE TABLE products (
product_id INT PRIMARY KEY,
product_name VARCHAR(100),
price DECIMAL(10,2));
CREATE TABLE order_items (
order_id INT,
product_id INT,
quantity INT,
total DECIMAL(10,2),
PRIMARY KEY (order_id, product_id),
FOREIGN KEY (order_id) REFERENCES orders(order_id),
FOREIGN KEY (product_id) REFERENCES products(product_id));4.3NF 处理：
检查传递依赖：
（1）users.address依赖user_id，无传递依赖。
（2）products.price依赖product_id，无传递依赖。
最终表结构符合 3NF。
5.优化效果：
减少数据冗余：用户名、产品信息、地址仅存储一次。
消除更新异常：修改用户地址只需更新users表。
三、状态转换图
（一）基本思想与定义
状态转换图（State Transition Diagram，STD）是一种行为建模工具，通过描绘系统的状态及触发状态转换的事件，描述系统的动态行为。其核心思想是将系统视为状态机，状态间的转换由事件驱动。
定义：状态转换图是一种图形化工具，用于表示系统在不同状态下的行为，以及事件如何触发状态之间的转换。
（二）表示形式与实现过程
1.表示形式：
（1）状态：用圆角矩形表示，标注状态名称（如“闲置”“复印”）。
（2）转换：用带箭头的直线表示，标注事件名称和动作（如“复印命令 / 开始复印”）。
（3）初始状态：用实心圆表示，系统初始状态。
（4）终止状态：用同心圆表示，系统结束状态。
图3 状态图中使用的主要符号
2.实现过程：
（1）识别状态：分析系统行为，确定所有可能的状态（如电梯控制系统的“待载”“上升”“下降”“楼间停”）。
（2）定义事件：确定触发状态转换的事件（如“进入电梯”“到达目标楼层”）。
（3）绘制转换：使用工具（如PlantUML）绘制状态转换图，标注事件和动作。
（4）验证逻辑：检查状态转换的完整性和合理性，确保无死锁或不可达状态。
图4 全自动洗衣机的状态图
（三）具体示例：电梯控制系统
项目背景：某写字楼电梯控制系统需实现楼层选择、状态监控等功能。
流程说明：
1.状态识别：
（1）待载：电梯空闲，停在某一楼层。
（2）上升：电梯向上运行。
（3）下降：电梯向下运行。
（4）楼间停：电梯到达目标楼层，开门等待乘客进出。
2.事件定义：
（1）进入电梯：乘客进入电梯，选择目标楼层。
（2）到达目标楼层：电梯到达目标楼层，触发开门。
（3）无人：乘客全部离开电梯，触发关门。
3.状态转换图绘制：
plantuml工具代码示例：
@startuml(*) --> 待载
待载 --> 上升 : 进入(目标楼层>当前楼层)/关门上行
待载 --> 下降 : 进入(目标楼层<当前楼层)/关门下行
上升 --> 楼间停 : 到达目标楼层/停机开门
下降 --> 楼间停 : 到达目标楼层/停机开门
楼间停 --> 上升 : 目标楼层>当前楼层/关门上行
楼间停 --> 下降 : 目标楼层<当前楼层/关门下行
楼间停 --> 待载 : 无人/关门@enduml4.逻辑验证：
电梯在“待载”状态时，根据目标楼层选择上升或下降。
到达目标楼层后进入“楼间停”状态，开门等待乘客进出。
乘客全部离开后返回“待载”状态。
四、层次方框图
（一）基本思想与定义
层次方框图（Hierarchical Block Diagram）是一种树形结构的图形工具，用于描述数据或系统的层次分解关系。其核心思想是自顶向下逐步细化，将复杂对象分解为更简单的子对象。
定义：层次方框图是一种用矩形框表示数据或模块，通过连线表示包含关系的图形工具，用于展示系统的层次结构。
（二）表示形式与实现过程
1.表示形式：
（1）顶层矩形：表示整体对象（如“计算机系统”）。
（2）子矩形：表示子对象，通过连线连接到父矩形（如“硬件”“软件”“服务”）。
（3）层次关系：逐层分解，直至最底层的基本元素。
图5 层次方框图示例
2.实现过程：
（1）确定主题：明确要分解的对象（如“企业 ERP 系统”）。
（2）顶层分解：将主题分解为主要子模块（如“采购管理”“生产管理”“销售管理”）。
（3）逐层细化：对每个子模块进一步分解（如“采购管理”分解为“供应商管理”“订单管理”“到货验收”）。
（4）标注说明：在矩形框内标注模块名称或功能描述。
（三）具体示例：企业ERP系统
项目背景：某制造企业开发 ERP 系统，需整合采购、生产、销售等业务模块。
流程说明：
1.顶层分解：
企业ERP系统
├─ 采购管理
├─ 生产管理
└─ 销售管理
2.采购管理细化：
采购管理
├─ 供应商管理
├─ 订单管理
└─ 到货验收
3.生产管理细化：
生产管理
├─ 生产计划排程
├─ 工单下发
└─ 进度跟踪
4.销售管理细化：
销售管理
├─ 客户管理
├─ 订单处理
└─ 物流跟踪
5.层次方框图：
企业ERP系统
├─ 采购管理
│ ├─ 供应商管理
│ ├─ 订单管理
│ └─ 到货验收
├─ 生产管理
│ ├─ 生产计划排程
│ ├─ 工单下发
│ └─ 进度跟踪
└─ 销售管理
├─ 客户管理
├─ 订单处理
└─ 物流跟踪
图6 企业ERP系统中采购管理层次方框图
五、Warnier图
（一）基本思想与定义
Warnier 图（Warnier-Orr Diagram）是一种用于描述数据结构或程序逻辑的层次化图形工具，由Jean-Dominique Warnier提出。其核心思想是通过树形结构表示数据的层次关系，并支持重复项和条件判断的标注。
定义：Warnier图是一种用括号表示层次结构的图形工具，用于清晰展示数据元素的组成、重复次数及条件关系。
（二）表示形式与实现过程
1.表示形式：
（1）层次结构：用括号表示数据元素的嵌套关系（如(A(B,C))表示 A 包含 B 和 C）。
（2）重复项：用数字标注重复次数（如(B{3})表示 B 重复 3 次）。
（3）条件项：用[条件]标注可选元素（如[B]表示 B 可选）。
图7 Warnier图示例
2.实现过程：
（1）数据分解：将复杂数据结构分解为基本元素（如“学生信息”分解为“姓名”“学号”“课程列表”）。
（2）标注重复与条件：确定元素的重复次数和可选性（如“课程列表”可能包含多门课程）。
绘制 Warnier 图：使用工具或文本符号表示层次关系（如(学生信息(姓名, 学号, (课程{3})))）。
（三）具体示例：学生选课系统
项目背景：某高校学生选课系统需记录学生信息及所选课程。
流程说明：
1.数据分解：
学生信息包含姓名、学号和课程列表。
课程列表包含多门课程，每门课程有课程号和成绩。
2.标注重复与条件：
课程列表最多可选 3 门课程（{3}）。
成绩为可选属性（[成绩]）。
3.Warnier 图绘制：
(学生信息
(姓名,
学号,
(课程{3}
(课程号,
[成绩])))) 4.数据库映射：
学生表（学号，姓名）。
课程表（课程号，课程名称）。
选课表（学号，课程号，成绩）。
六、IPO图
（一）基本思想与定义
IPO 图（Input-Process-Output Diagram）是一种用于描述模块输入、处理和输出关系的图形工具，由IBM公司提出。其核心思想是明确模块的功能边界，展示数据流动和处理逻辑。
定义：IPO 图是一种用表格或图形表示模块输入、处理和输出的工具，用于详细设计阶段的功能描述。
（二）表示形式与实现过程
1.表示形式：
（1）输入（Input）：列出模块接收的数据或参数。
（2）处理（Process）：描述模块的处理逻辑或算法。
（3）输出（Output）：列出模块产生的结果或数据。
图8 IPO图示例
改进的IPO图形式，变成IPO表
图9 IPO表示例
2.实现过程：
（1）确定模块：明确要描述的模块（如“用户登录模块”）。
（2）输入分析：识别模块的输入数据（如用户名、密码）。
（3）处理设计：描述处理步骤（如验证用户名密码、查询数据库）。
（4）输出定义：确定输出结果（如登录成功 / 失败）。
（三）具体示例：用户登录模块
项目背景：某电商平台开发用户登录功能，需验证用户名和密码。
流程说明：
1.输入分析：
用户名（字符串）。
密码（字符串）。
2.处理设计：
步骤 1：接收用户名和密码。
步骤 2：对密码进行 MD5 加密。
步骤 3：查询数据库验证用户名和加密后的密码。
步骤 4：返回验证结果。
3.输出定义：
登录成功：返回用户权限信息。
登录失败：返回错误码。
IPO 图：
输入 |
处理 |
输出 |
用户名 |
1. 接收输入数据 |
登录成功：用户权限 |
密码 |
2. 密码MD5加密 |
登录失败：错误码 |
3. 数据库查询验证 |
||
4. 返回验证结果 |
图10 用户登录IPO图
Java代码示例：
public class LoginModule {
public User authenticate(String username, String password) {
// 输入处理
String encryptedPassword = md5Encrypt(password);
// 数据库查询
User user = userDao.findByUsernameAndPassword(username, encryptedPassword);
// 输出结果
if (user != null) {
return user;
} else {
throw new AuthenticationException("Invalid username or password");
}
}}七、验证软件需求
（一）基本思想与定义
验证软件需求是确保需求文档准确、完整、一致且可实现的过程。其核心思想是通过多种方法（如评审、原型、形式化验证）验证需求的正确性和可行性。
定义：验证软件需求是对需求规格说明书进行审查和测试，确保其满足用户需求、技术可行性和项目约束。
（二）表示形式与实现过程
1.表示形式：
（1）需求评审：通过会议形式，由团队成员和用户共同审查需求文档。
（2）原型验证：构建可运行的原型系统，获取用户反馈。
（3）形式化验证：使用数学模型和逻辑推理证明需求的正确性。
2.实现过程：
（1）需求评审：
准备评审材料（需求文档、用例图）。
召开评审会议，记录问题并修改。
（2）原型验证：
开发低保真原型（如线框图）或高保真原型（如可交互界面）。
邀请用户体验并收集反馈，迭代优化。
（3）形式化验证：
使用数学语言（如Z语言）描述需求。
通过模型检查工具（如SPIN）验证需求的一致性。
（三）具体示例：在线支付系统
项目背景：某电商平台开发在线支付功能，需验证支付流程的正确性。
流程说明：
1.需求评审：
评审内容：支付接口定义、异常处理逻辑。
问题记录：未明确“支付超时”的处理流程。
修改方案：增加“支付超时”状态及重试机制。
2.原型验证：
开发支付流程原型，包含“选择支付方式→输入密码→支付成功 / 失败”流程。
用户反馈：密码输入框无遮挡提示，存在安全隐患。
优化方案：增加密码输入时的遮挡掩码。
3.形式化验证：
使用Z语言描述支付状态机：
PaymentSystem = [
state: {idle, processing, success, failed};
amount: ℕ;
timeout: ℕ
]
processPayment(p: Payment) ≡
state = idle ∧
amount = p.amount ∧
(state' = success ∨ state' = failed)使用SPIN工具验证“支付成功后状态不可回退”的性质。
数学模型： 需求覆盖率计算公式：
示例：总需求数50，已验证45，覆盖率为90%。
八、结语
需求分析是软件开发的基石，合理使用图形工具和验证方法可显著提升需求的准确性和可实现性：
- 实体 - 联系图清晰描述数据结构，为数据库设计提供依据。
- 数据规范化消除冗余，提升数据一致性。
- 状态转换图动态展示系统行为，辅助逻辑设计。
- 层次方框图和Warnier 图层次化分解复杂对象，便于理解。
- IPO 图明确模块边界，指导编码实现。
- 需求验证通过多种方法确保需求质量，降低后期变更成本。
实际项目中，需根据需求特点选择合适工具（如ER图 + 状态转换图 + IPO图组合），并结合形式化方法提升验证的严谨性。未来，随着 AI 和低代码技术的发展，需求分析工具将更加智能化，进一步提升软件开发效率。