软件工程之需求分析涉及的图与工具

需求分析与规格说明书是一项十分艰巨复杂的工作。用户与分析员之间需要沟通的内容非常的多，在双方交流信息的过程中很容易出现误解或遗漏，也可能存在二义性。如何才能更加准确的表达双方的意思，且清楚明了，绘制各类图形就显得非常有必要。

前文基础：
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(*) --> 待载待载 --> 上升 : 进入(目标楼层>当前楼层)/关门上行待载 --> 下降 : 进入(目标楼层<当前楼层)/关门下行上升 --> 楼间停 : 到达目标楼层/停机开门下降 --> 楼间停 : 到达目标楼层/停机开门楼间停 --> 上升 : 目标楼层>当前楼层/关门上行楼间停 --> 下降 : 目标楼层<当前楼层/关门下行楼间停 --> 待载 : 无人/关门@enduml

4.逻辑验证：

电梯在“待载”状态时，根据目标楼层选择上升或下降。

到达目标楼层后进入“楼间停”状态，开门等待乘客进出。

乘客全部离开后返回“待载”状态。

四、层次方框图

（一）基本思想与定义

层次方框图（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工具验证“支付成功后状态不可回退”的性质。

数学模型：需求覆盖率计算公式：