简介：这份PPT课件围绕软件工程中的需求分析与面向数据流的建模方法展开，适合软件工程专业学生、课程备考者以及需要梳理需求分析流程的初级开发者使用。全包仅含1个ppt文件，体积约1.41MB，轻量易取，可直接用于课堂讲授、复习或自学翻阅。课件以一个小型图书馆管理系统贯穿始终，从借还书、增删图书、按作者或专业领域检索等具体需求出发，讲解现实世界到计算机世界的映射过程，抽象与概念符号模型、当前系统物理模型与逻辑模型的抽取、目标系统逻辑模型的建立及细化验证等步骤均有展开。同时区分功能性需求与非功能性需求，说明需求获取的内容以及性能、环境、界面等约束，并对结构化开发方法与面向对象开发方法、面向信息流向与面向信息内容两类建模思路作了对照。目前已有226人学习，适合用来建立需求分析的整体框架，并对照案例理解建模过程。

1. 从现实世界到计算机世界：面向数据流分析的知识地图

面向数据流的分析方法，是软件工程需求分析阶段最经典的一条路线，核心动作只有两个：先把现实世界抽象成模型，再把模型逐层细化到能指导设计。它看起来像“画图的”，实际上是一套从现场调查、物理模型、逻辑模型一路走到数据流图、数据字典和加工说明的完整流程。适合两类人：正在系统学软件工程、要交需求分析建模作业的；以及复习备考、需要把“需求分析五步”“功能性与非功能性需求”“结构化与面向对象方法”串成一条线的人。下面按知识地图、模块要点、易漏点、复习清单推进。

2. 需求分析的五个台阶：从物理模型到逻辑模型的两级跃迁

需求分析最容易被误解成“找用户聊几次、记几条功能”。真正要建立的是四张模型之间的转换关系：当前系统的物理模型、当前系统的逻辑模型、目标系统的逻辑模型、目标系统的物理模型。中间两步是抽象，后两步是落地。课件给的教材采购例子非常典型：学生交购书申请，教材科汇总成购书单，财务开发票，学生凭领书单领书，这条链路里有人、有科室、有纸质单据，是物理模型；把“谁在哪个办公室”“哪张单子盖什么章”剥掉，只剩下“审查有效性—开发票—开领书单—发书”这几个加工和数据流，就是逻辑模型。这一章把五个台阶逐级拆开，再把图书馆管理系统的功能清单和约束条件挂上去。

2.1 五步流程拆开看：从现场调查到需求验证

课件把需求分析过程写成五步，顺序不能乱，因为每一步的产物都是下一步的输入。

第一步是通过对现实环境的调查，获得当前系统的物理模型。这一步的产物必须“具体到笨拙”：有哪些岗位、哪些单据、单据在谁手里流转、每一步的输入输出是什么。教材采购例子里，购书申请、购书单、发票、领书单构成一条完整的单据链，缺一张，后面就推不出对应的数据流。

第二步是去掉具体模型中的非本质因素，抽取现实系统的实质，抽象出当前系统的逻辑模型。“非本质”这三个字是难点：办公室编号不是本质，审批环节才是本质；单据纸张颜色不是本质，单据承载的数据项才是本质。做完这一步，物理模型里的具体部门和岗位消失，加工和数据存储浮出来。

第三步是分析当前系统与目标系统的差别，建立目标系统的逻辑模型。差别通常来自两类东西：哪些人工加工要被系统替代，哪些新能力是原来没有的。教材采购例子里，“审查并开发票”原来由人完成，目标系统里变成一个系统加工，并且多出一条“无效购书单”的异常分支——异常分支往往是目标系统逻辑模型里最容易漏的部分。

第四步是对目标系统的逻辑模型进行细化、改进与优化。粗粒度的加工要拆成子加工，数据流要补上数据项，数据存储要落到数据字典。这一步决定了模型能不能被评审，而不是只能被“看懂”。

第五步是需求分析的验证。验证的对象不是代码，而是模型本身：每一个数据流是否有来源和去向，每一个数据存储是否既被写又被读，每一条约束是否写成了可判定的句子。

这张表建议默写一遍。考试里“简述需求分析的过程”是高频题，答题时把“物理模型→逻辑模型→目标逻辑模型→细化→验证”这条链写全，比只写“收集需求、分析需求”多拿不少分。

2.2 模型化与抽象化：物理模型和逻辑模型差在哪

课件对抽象的解释写得很“实验科学”：抽象源于实验科学，主要要素是数据采集方法和假设的形式说明、模型的构造与预测、实验结果分析；在为可能的算法、数据结构和系统结构构造模型时使用抽象，抽象的结果是概念符号模型。翻译成复习语言：抽象不是“省略细节”，而是“保留对当前问题有解释力的那一层，把其余层换成符号”。

由此可以整理出四个动词，它们构成需求分析的主干动作：

• 模型化：把现实世界中的流程、单据、角色整理成可描述的模型。
• 抽象化：从物理模型里去掉非本质因素，得到逻辑模型，回答“做什么”。
• 具体化：从逻辑模型走向目标系统的物理模型，回答“怎么做”，落到技术选型、部署、界面。
• 实例化：用具体数据和场景去检验模型，比如拿“读者借走最后一本书”去跑一遍借阅流程。

最容易踩的坑是把“物理模型”理解成“部署架构”。在需求分析语境里，物理模型指的是带具体实现细节的现实系统描述，部署架构属于设计阶段的目标系统物理模型，两者不是一个东西。另一个坑是逻辑模型里残留具体角色名，比如写出“管理员甲审批”，这类信息一旦进模型，评审时就会被追问“甲休假了流程怎么走”。

2.3 图书馆案例：把五步流程走一遍

课件配套的案例是一个小型图书馆管理系统，功能五条、用户两类、约束三条，规模小但要素齐全，非常适合当模板背。

三条约束写得比功能更值钱，因为它们直接决定了系统能不能通过验收：馆中所有未借出的书籍能够供读者随时借阅；同一时刻，一本书不能既被借出又被借阅；一个读者一次借出的书籍数目不能超过预定值。前两条是状态约束，第三条是数量约束，第三条里的“预定值”在需求阶段必须被追成一个明确数字，否则就是一句正确的废话。

把约束写成可执行的形式，是检验需求是否“落地”的好办法。下面这段用最朴素的方式表达三条约束，重点不在代码，而在“每条约束对应一个可判定的判断”。

# 小型图书馆借阅约束的最小表达：把三条业务约束翻译成可判定的检查 MAX_BORROW = 5 # 约束 3 中的“预定值”，需求阶段必须追成具体数字 def can_borrow(reader, book, loans): # 约束 2：同一时刻一本书不能既被借出又被借阅 active = {l["book_id"] for l in loans if l["returned_at"] is None} if book["id"] in active: return False, "该书在借，状态冲突" # 约束 1：未借出的书应可随时借阅，不可借状态要能说清原因 if book["status"] != "available": return False, "该书不在可借状态" # 约束 3：未归还数量不得超过上限 holding = [l for l in loans if l["reader_id"] == reader["id"] and l["returned_at"] is None] if len(holding) >= MAX_BORROW: return False, "已达单次借阅上限" return True, "允许借出"

参数说明：MAX_BORROW是需求阶段就要和用户确认的业务参数，不能留到编码时拍脑袋；reader至少含id和读者类型，book含id与status；loans是借阅记录集合，returned_at为空表示未归还；返回值是“是否允许 + 原因”，原因字段在需求文档里对应异常流，评审时要能逐条对上。

这段代码真正想说明的是：需求分析阶段的模型必须能回答“边界情况怎么办”。读者已借满 5 本还想借第 6 本、一本书刚被借走又被另一个读者点开、图书被标记为“遗失”但仍显示在架上——这些分支在数据流图里就是异常数据流，在数据字典里就是状态字段的取值范围。案例虽小，五脏俱全。

3. 需求获取的四类内容：功能、性能、环境与人的因素

需求分析的五步解决“流程怎么走”，需求获取解决“问什么”。课件把需求分成功能性需求与非功能性需求（技术需求）两大类：功能性需求定义系统做什么，描述系统必须支持的功能和过程；非功能性需求定义系统工作时的特性，描述操作环境和性能目标。这个二分法看起来简单，实际答题时最常见的失分是把权限、并发、数据格式统统塞进“功能需求”。这一章把需求获取的内容拆成四块：功能、性能、环境与界面、用户与人的因素，每块给出可抄的提问清单和图书馆案例里的对应答案。

3.1 功能性与非功能性：先分清“做什么”和“做得怎么样”

功能性需求的判据是“能不能用一个动词短语说清系统替谁完成了什么事”。图书馆案例里，借书、还书、增删图书、按作者或专业领域检索、查某读者借出的书、查某本书最近的借阅人，六条都是功能性需求，因为它们都能对应到一个明确的输入、处理和输出。

非功能性需求（技术需求）的判据是“它约束的是做法和品质，不是业务动作本身”。响应时间、吞吐量、存储容量、操作系统与数据库、接口格式、用户培训成本，都属于这一类。课件列出的需求获取三问——系统做什么、系统何时做什么、系统何时及如何修改或升级——前两问主要落在功能侧，第三问往往被忽略，但它是可维护性需求的源头：图书分类规则变了要不要支持批量调整？读者类型增加一种要不要改代码？

这里有个高频混淆点：功能 4「找出被某位读者借出的一批书」只供普通读者使用，其余功能供图书管理员使用。这属于功能性需求里的角色边界，不是非功能性需求。判断标准很简单：它改变的是“谁能触发哪个加工”，所以进功能模型；如果它改变的是“这个加工必须在 2 秒内返回”，才进非功能清单。

写需求文档时建议强制分成两张表，一张功能清单、一张质量与技术约束清单。混在一张表里，后面做数据流图时就会把“响应时间 2 秒”画成一条数据流，这种图评审时基本一眼被挑出来。

3.2 性能、环境、界面：三个最常被一句“性能良好”糊弄过去的角落

课件把非功能性需求拆得很细，这几组指标值得原样抄进笔记。

性能需求关注存储容量限制、执行速度、响应时间、吞吐量。图书馆案例里可以具体化为：馆藏图书条目上限、借还操作的平均响应时间、开馆高峰时段并发借还的笔数。注意“响应时间”和“吞吐量”是两个方向，前者看单次体验，后者看单位时间处理能力，需求里必须分开写。

环境需求分硬件和软件两路。硬件设备包括机型、外设、接口、地点、分布、温度、湿度、磁场干扰等；软件包括操作系统、网络、数据库等。这些词看着像机房验收清单，实际是需求约束：如果借阅台用的是固定式扫码外设，那“还书”这个加工的输入方式就被限定了；如果部署在多个馆区，那“同一时刻一本书不能既被借出又被借阅”就变成跨节点的状态一致性问题，而不是单机判断。

界面需求问四件事：有来自其它系统的输入吗？有到其它系统的输出吗？对数据格式有规定吗？对数据存储介质有规定吗？图书馆案例里，读者信息可能来自学校的身份系统，图书编目数据可能来自采购系统，这两个接口的格式要求必须在需求阶段写清，否则设计阶段只能返工。

这一块复习时的自检方法是：随便挑一条功能，问自己“它在什么设备上、什么网络下、和谁交换数据、数据长什么样”。四个问题答不上来，说明非功能需求还没写。

3.3 用户与人：两类用户带来的权限与容错需求

课件把“用户或人的因素”单列一类，问的是：用户类型有哪些？各种用户的熟练程度如何？需受何种训练？用户理解、使用系统的难度如何？用户错误操作系统的可能性有多大？这几问在图书馆案例里有非常具体的落点。

用户类型直接决定了权限模型。普通读者只能查自己的借阅记录（功能 4）和检索图书（功能 3），图书管理员才能执行借还、增删图书、查某本书的借阅人（功能 1、2、5）。这意味着同一个“检索”加工在两类用户下的可见字段不同：读者看到的借阅信息只涉及自己，管理员看到的是全量。需求阶段把这条写清，设计阶段才不会出现“读者接口能查到别人借了什么”这种翻车。

熟练程度和训练成本决定交互设计约束。管理员每天高频操作借还，需要快捷键和连续扫码；读者可能一学期用两次，需要更明确的引导和错误提示。课件里“用户错误操作系统的可能性”这一问，在图书馆案例里至少有三个典型场景：管理员误删图书、读者重复点击借书、条码扫错导致借还错位。每一条都应该在需求里对应一个防护措施，比如删除前二次确认、借书操作幂等、借还以图书编号而非书名定位。

把这张表放在需求文档的“用户与权限”一节，评审时能省掉大量口头解释。很多人写需求只写“系统应支持权限管理”，这句话既不能测试也不能设计，等于没写。

4. 面向数据流的建模：数据流图、数据字典与加工说明三件套

课件把需求分析建模方法按信息流向、结构、内容划分：面向信息流向的是结构化分析方法，面向信息内容的是面向对象分析方法；描述系统需求时可以从功能、行为和信息三个方面入手，侧重点可以不同。面向数据流的分析方法就落在“面向信息流向”这一支，配套的开发方法是结构化开发方法（SA/SD、SP），对面是面向对象开发方法（OOA/OOD/OOP）。这一章把这条路线上的三个核心产物讲透：数据流图负责“流”，数据字典负责“定义”，加工说明负责“规则”。

4.1 为什么叫“面向数据流”：与面向对象的分工

“面向数据流”这个名字容易让人以为是“分析数据在网络里怎么传”。它分析的是业务数据在加工之间的流动路径：数据从哪个外部实体进来，经过哪些加工被变换，落到哪个数据存储，最后从哪个出口出去。结构化分析方法的核心就是把系统看成一组加工的集合，加工之间靠数据流连接，数据存储是加工的落脚点。

面向对象分析方法则把系统看成一组对象的协作，强调封装、继承、消息传递，关注的是“信息内容”而不是“信息流向”。两者不是替代关系，是切入角度不同：数据结构稳定、流程清晰的业务系统，面向数据流的分析更直接；实体类型多、状态复杂的系统，面向对象的分析更自然。考试里常考“结构化方法与面向对象方法的区别”，答题要点可以按下面这张表组织。

图书馆案例用结构化方法分析很顺：借书是一条从读者到借阅记录的数据流，还书是反向更新，检索是从图书目录读数据，查借阅人是按读者标识过滤借阅记录。换成面向对象，会先识别读者、图书、借阅记录、管理员几类对象，再定义它们之间的关联。两种建模方式都能描述同一个系统，差别在于你先看到“流”还是先看到“物”。

4.2 数据流图的四要素与分层画法

数据流图有四种基本元素：外部实体、加工、数据流、数据存储。外部实体是系统边界之外的输入来源或输出去向，图书馆案例里是读者和图书管理员；加工是对数据做变换的处理单元，比如“办理借书”；数据流是带着数据内容的箭头，必须有名字；数据存储是数据的静态落脚点，比如图书目录和借阅记录。

分层画法是结构化分析的关键动作。顶层图只画一个加工表示整个系统，标出与外部实体的输入输出；0 层图把系统拆成主要加工；1 层图再把每个主要加工拆成子加工。分层必须满足父子平衡：子图的输入输出数据流要和父图中对应加工的输入输出一致，不能多也不能少。这一条是评审时的硬指标，也是最容易失分的地方。

除了父子平衡，还有几条画图规范值得背下来：数据流不能是控制流，不能画“先判断再走哪条路”的箭头，判断逻辑要放进加工说明；加工不能只有输入没有输出，也不能只有输出没有输入；数据存储必须既有写入流也有读取流，只写不读或只读不写通常意味着模型有冗余；外部实体之间不能直接有数据流，必须经过加工。

图书馆案例里有一条容易画错的地方：借书和还书都是对借阅记录的写操作，但方向相反。有些人会画一条“借阅记录”到“还书”的数据流再画回去，造成同一存储双向流，看着别扭，评审也会问“到底谁写谁读”。更清晰的画法是：借书加工写借阅记录、更新图书状态；还书加工读借阅记录、更新图书状态；两条流各自有明确的名字，比如“借阅记录（新增）”“借阅记录（归还）”。

4.3 数据字典与加工说明：让图能被验证的另一半

只有数据流图，模型是不可验证的：图上写着“借阅记录”，谁也不知道它包含哪些数据项。数据字典就是给每条数据流、每个数据存储、每个数据项下定义的地方。常用记号有几种：=表示定义为，+表示顺序连接，[ | ]表示从中选一，{ }表示重复，( )表示可选。这几组符号必须会写会读。

以图书馆案例为例，可以用字典记号把核心数据写出来：

加工说明（小说明）负责描述每个加工内部的处理规则，常用三种表达：结构化语言、判定表、判定树。当加工内部有多个条件组合时，判定表最不容易漏分支。

下面用判定表把“办理借书”这个加工写清楚，三种条件、两种结果，组合数量一目了然。

-- 借阅记录表：把“一书不可同时被两人持有”的约束落到数据层 CREATE TABLE loan ( loan_id INTEGER PRIMARY KEY, book_id INTEGER NOT NULL, reader_id INTEGER NOT NULL, borrowed_at TEXT NOT NULL, returned_at TEXT -- 为空表示尚未归还 ); -- 部分唯一索引：只对未归还记录生效，保证同一本书只有一条在借记录 CREATE UNIQUE INDEX ux_loan_active_book ON loan (book_id) WHERE returned_at IS NULL;

这段 SQL 不是让需求阶段去建表，而是用建表语句反过来检验需求是否自洽。参数说明：book_id与reader_id是借阅关系的两个主体，returned_at为空代表在借；普通唯一索引会把历史归还记录也算进去，导致同一本书只能被借一次，所以必须用带WHERE returned_at IS NULL的部分唯一索引。写到这里，“同一时刻一本书不能既被借出又被借阅”这条约束就从一个句子变成了一个可以被验证的结构。

判定表的形式可以这样组织：条件包括“图书状态是否可借”“读者是否已达借阅上限”“该书是否在借”，动作包括“允许借出”“提示已达上限”“提示状态冲突”。三条件两两组合共八列，逐列填动作，填完会发现有些列根本不可能出现（比如“该书在借”同时“状态可借”），这些不可能列恰恰是需求里需要澄清的地方——图书状态字段的取值集合到底怎么定义，必须在这一步定死。

5. 易漏点排查：结构化分析里最容易翻车的五处

结构化分析的模型看着规整，实际批改和评审里出错的地方高度集中。下面五条是按“出错频率 × 返工成本”排出来的，每条按“易漏点—为什么漏—怎么补”写，建议对着自己的图逐条核。

5.1 易漏点一：把物理模型当逻辑模型交上去

为什么漏：现场调查拿到的材料天然是物理形态，单据、岗位、办公室、纸质流程，直接誊到图上最省事，看起来还很“详实”。很多人以为细节越多越专业，结果逻辑模型里全是“某科室审核”这类实现细节。

怎么补：交图前做一次“去人名去地点”的替换实验，把模型里所有具体岗位、地点、纸张单据替换成加工和数据存储，如果替换后模型还能讲通业务，说明抽象到位；如果替换后讲不通，说明你把本质环节和非本质因素一起删了，需要回到现场补调查。

5.2 易漏点二：数据流图画成了流程图

为什么漏：日常表达的惯性是把事情讲成“先这样，然后那样，如果……就……”，于是图上出现判断菱形、出现带条件的箭头、出现“若不满足则返回”的控制流。数据流图描述的是数据变换，不是执行顺序。

为什么这很致命：一旦画成流程图，加工说明就没地方放了，因为判断逻辑被画进了图里；父子平衡检查也做不了，因为控制流没有对应的输入输出。怎么补：把所有判断、循环、异常分支从图上摘出来，写进加工说明的判定表或结构化语言；图上只保留“什么数据进、经过什么加工、什么数据出”。

5.3 易漏点三：约束与并发条件写成形容词

为什么漏：需求讨论时大家说的是“借书要快”“不能重复借”“数量要控制”，这些词在会议里能达成共识，写进文档就完全不可判定。图书馆案例的三条约束里，“一个读者一次借出的书籍数目不能超过预定值”如果不把预定值追成数字，开发和测试都无从下手。

怎么补：建立一条硬规则，凡是出现“快速、合理、尽量、适当、不能太多”这类词，必须换成数量、时间、状态集合三选一的表述。数量类追成上限值，时间类追成响应时间或超时时间，状态类追成状态机与非法转移列表。然后把每条约束挂到具体的加工上，看它在哪个加工里被检查、检查失败走哪条异常流。

5.4 易漏点四：数据字典和 DFD 对不上

为什么漏：图先画完，字典后补，补的时候凭印象写，两边各写各的。典型症状是图上有一条叫“借阅信息”的数据流，字典里定义的是“借阅记录”，名字不一致；或者字典里定义了“专业领域”这个数据项，图上根本没有对应的数据流。

怎么补：用双向核对法。正向从图出发，每条数据流、每个数据存储、每个外部实体在字典里都必须有条目；反向从字典出发，每个数据项至少要出现在一条数据流或一个数据存储里，否则就是冗余定义。核对时顺手把命名统一，同一概念全篇只用一个词，别在图上叫“读者”、字典里叫“用户”、说明里叫“借阅人”。

5.5 易漏点五：非功能需求没有度量值

为什么漏：功能性需求有明确的功能点可以数，非功能需求写起来像表态，“系统应具备良好的性能与可靠性”这种句子写起来毫无压力，评审时也不好意思挑刺。结果到了设计阶段，架构选型没有任何约束依据。

怎么补：按课件给的四组问法逐条逼出度量值。性能问容量、速度、响应时间、吞吐量；环境问硬件机型外设接口地点分布与温湿度磁场、软件操作系统网络数据库；界面问外部输入输出、数据格式、存储介质；人的因素问用户类型、熟练程度、训练成本、误操作可能性。四组问完还不能量化的，就明确标注“待确认”并写清确认人和时间点，别用形容词糊过去。

6. 复习清单：把需求分析压成一张可勾选的自查表

复习到这一章，最有效的方式不是再读一遍，而是拿一张表逐项勾。下面这张清单按“模型链—需求内容—建模产物—易错项”四段组织，每一项都能在课件里找到对应出处，勾不上的就是漏洞。

勾完表还有两个动作值得做。一是拿图书馆案例的六条功能，每条各写一句“异常流”：借书时读者已达上限怎么办、还书时记录不存在怎么办、删除图书时该书仍在借怎么办、检索无结果怎么提示、查借阅人时图书不存在怎么办。异常流写得出来，说明加工说明真的写细了，而不是只画了主干数据流。

二是把三条约束各自翻译成一句可验证的话，再翻译成一句可测试的话。比如“同一时刻一本书不能既被借出又被借阅”，可验证的表述是“未归还借阅记录中，同一图书编号至多出现一次”，可测试的表述是“两个会话同时借同一本书，只有一个成功，另一个收到状态冲突提示”。能一路翻译到测试语句，这条约束才算真正进了需求模型。

我当时复习这块栽过一个跟头：图背得滚瓜烂熟，数据字典的重复记号{ }和可选记号( )一直混着用，直到做案例才发现，把一个“可空”的归还日期写成重复项，模型含义完全变了。从那以后我每次画完图，都强制走一遍“图—字典—加工说明”的三向核对：图上每条流去字典里找定义，字典里每个数据项回图里找出处，加工说明里的每个判断回到图上找对应的输入输出。三遍走下来，模型基本没有对不上的地方。希望帮到你。

本文还有配套的精品资源，点击获取