系统分析师考点整理：从需求分析到架构设计的备考路径

简介：这份资源面向具备一定信息技术基础、从事系统分析与设计、数据库管理、Web开发及大数据处理的研发人员与架构师，尤其适合备考系统分析师或需要系统梳理知识体系的1至3年从业者。内容围绕需求工程、系统运行维护、数据库设计、Web与架构模式、大数据处理等核心考点展开，涵盖系统规划步骤、需求获取与验证、软件维护类型、负载均衡与容错、数据库锁协议与反规范化、MVC/MVP/MVVM、微服务与云原生、Lambda/Kappa/IOTA架构等具体知识点，并配有案例与记忆逻辑辅助理解。资源包为1个docx文档，大小约4.55MB，结构清晰，便于按章节检索与复习。目前已有165人学习。读者可借助它快速建立系统分析师知识框架，掌握可行性分析、净现值与回收期计算等案例解题思路，同时获取架构选型与数据库优化的参考依据，适合作为备考笔记与日常查阅资料。

1. 系统分析师考点整理：从零散知识点到可复现的备考路径

很多人第一次翻系统分析师的大纲，都会有一种“什么都考、什么都不会”的错觉。系统分析、系统设计、数据库、Web 开发、架构模式、大数据处理，这几块单拎出来每一块都能写一本书，合在一起却只给你一张卷子。真正的问题不是知识点太多，而是它们之间没有串成一条线。我见过不少同行，工作五六年，项目做了不少，但一上考场就翻车，原因往往不是不会，而是不知道考的是“哪一层”的决策。这篇笔记不打算给你一份背诵清单，而是把系统分析师考点整理这件事，拆成一条能自己走一遍的路径：先搞清楚每块知识在考什么决策，再落到能动手验证的最小操作，最后把容易踩的坑标出来。适合正在备考、或者想用考试大纲反向梳理自己技术体系的人。

2. 系统分析到底在考什么：从需求到模型的四步拆解

系统分析这块，很多人背了一堆“结构化分析”“面向对象分析”的名词，真到做题还是分不清该用数据流图还是用例图。核心原因是没搞明白：系统分析考的不是画图，而是“把模糊需求转成可验证模型”的能力。考试里出现的每一张图、每一个模型，背后都对应一个具体决策——边界在哪、数据怎么流、状态怎么变、对象怎么协作。

2.1 需求工程的三层过滤：原始诉求、功能需求、非功能需求

需求工程最常见的失分点是把“用户说想要一个报表”直接当成功能需求写进答案。实际考试中，你需要先做一层过滤：原始诉求是用户嘴里的那句话，功能需求是系统必须提供的动作，非功能需求是动作执行时的约束。这三层混在一起写，阅卷时基本拿不到分。

我一般用下面这个判断顺序来拆：

1. 这句话描述的是“谁做什么”，还是“做得怎么样”？
2. 如果是“谁做什么”，继续问：触发条件是什么、输入是什么、输出是什么、异常分支是什么。
3. 如果是“做得怎么样”，归到非功能需求，再细分性能、安全、可用性、可维护性。

举个具体例子。某模拟项目里，业务方说“希望订单查询快一点”。这句话不能直接写。拆完应该是：功能需求——系统提供按订单号查询订单详情的接口；非功能需求——在 500 并发下，95 分位响应时间不超过 800 毫秒。考试答题时，功能需求写清楚输入输出，非功能需求写清楚指标和测量条件，这两条分开写，分数就稳了。

提示：非功能需求一定要带数字和条件，没有数字的非功能需求在阅卷里等同于没写。

2.2 数据流图与用例图的选择：看边界还是看交互

数据流图和用例图是系统分析里最容易选错的两种图。选错的代价是整道题的方向偏掉。判断标准其实很简单：如果题目强调的是“数据在系统内部怎么加工、存储、流出”，选数据流图；如果强调的是“外部角色和系统之间有什么交互”，选用例图。

数据流图分顶层图和逐层分解。顶层图只画一个加工，把外部实体和系统之间的数据流标清楚。逐层分解时，注意平衡原则：父图里出现的输入输出流，子图里必须对应出现，不能凭空多也不能凭空少。这个平衡检查是考试里高频的扣分点，很多人图画得漂亮，一查平衡就漏了一条流。

用例图的关键是找对参与者。参与者不一定是人，外部系统、定时任务都可以是参与者。用例的粒度也要控制：一个用例应该是一个对参与者有价值的完整目标，不要把“输入用户名”“输入密码”拆成两个用例。我一般会问自己：这个用例结束后，参与者有没有拿到一个可感知的结果？有就是用例，没有就是步骤。

2.3 结构化分析与面向对象分析的切换时机

结构化分析适合数据加工流程清晰、业务规则相对稳定的场景，输出的是数据流图和数据字典。面向对象分析适合实体关系复杂、状态变化多的场景，输出的是类图、状态图、序列图。考试里经常给你一段描述，让你判断该用哪种方法。

我的判断习惯是看两个信号：第一，描述里有没有大量“状态流转”的词，比如“待审核→已审核→已发布”，有就偏向面向对象；第二，描述里有没有明显的“输入→加工→输出”链条，有就偏向结构化。两者不是互斥的，实际答题时可以主用一种，另一种作为补充说明。

2.4 用最小案例跑一遍分析流程

下面用一个虚构的“设备报修管理”场景，把分析流程走一遍。注意这里不追求完整，只追求每一步都有可验证的输出。

场景描述： 某实验室有多台设备，使用人发现故障后提交报修单。 维修人员接单后上门维修，维修完成后填写维修结果。 管理员可以查看所有报修单的状态统计。 第一步：识别参与者 - 使用人 - 维修人员 - 管理员 第二步：识别用例 - 提交报修单（使用人） - 接单（维修人员） - 填写维修结果（维修人员） - 查看状态统计（管理员） 第三步：识别关键实体 - 报修单：单号、设备编号、故障描述、提交时间、状态 - 维修记录：报修单号、维修人、维修时间、结果说明 第四步：状态流转 待提交 -> 待接单 -> 维修中 -> 已完成

这段文本可以直接作为答题草稿。考试时不需要画得多漂亮，但参与者、用例、实体、状态这四样必须齐全。缺任何一样，后面的设计题就容易断链。

3. 系统设计与架构模式：从分层到微服务的决策链

系统设计这块，考试喜欢考“为什么这么分”而不是“怎么画”。分层架构、客户端服务器、微服务、事件驱动，这些模式本身不难背，难的是在具体约束下选对。选型的依据永远是质量属性：性能、可用性、可修改性、安全性、可测试性。脱离质量属性谈架构，就是玄学。

3.1 分层架构的边界划分：什么时候该加一层

分层架构最常见的是表现层、业务逻辑层、数据访问层。很多人做设计时习惯性加一层“服务层”，但说不清这一层到底解决什么问题。加层的唯一理由是：某一类变化被隔离了。比如业务逻辑层里既有纯计算规则，又有跨表的事务编排，那可以把事务编排抽到应用层，让业务逻辑层只保留规则。这样改规则不影响事务，改事务不影响规则。

考试里如果题目强调“业务规则经常变”，你就应该把规则集中到一层，并说明这一层不依赖具体存储和界面。如果题目强调“多种客户端接入”，你就应该在表现层和业务层之间加一层适配，隔离不同客户端的协议差异。

3.2 微服务拆分的三个硬指标：数据、团队、发布节奏

微服务不是越细越好。拆分时我一般看三个硬指标：第一，数据能不能独立，如果两个服务必须共享同一张表写事务，拆了就是分布式事务的坑；第二，团队边界清不清楚，一个服务最好由一个小组端到端负责；第三，发布节奏是否不同，如果两个模块总是一起改一起发，拆开只会增加联调成本。

考试答题时，如果题目给的是“某公司业务快速扩张，多个团队并行开发”，你可以往微服务方向写，但一定要补一句“按业务能力拆分，每个服务独立数据库”。如果题目给的是“业务稳定、团队规模小”，写微服务反而会被扣分，因为过度设计。

3.3 用配置表对比四种架构模式的适用场景

下面这张表是我自己整理用的，考试时可以在草稿纸上快速列出来帮助判断。

这张表不用背，理解每一行的“代价”比记住“适合场景”更重要。考试里问“为什么不选某个模式”，答代价往往比答优点更得分。

3.4 设计题的最小验证：用质量属性场景检查方案

设计题写完不要急着交，用质量属性场景过一遍。一个完整的质量属性场景包含六要素：刺激源、刺激、环境、制品、响应、响应度量。比如“在高峰期，用户发起查询，系统应在 1 秒内返回结果”。如果你的设计里没有任何机制对应这个度量，说明设计不完整。

我一般会挑两到三个关键场景，逐个问：这个场景下，我的分层/服务/缓存/队列分别起什么作用？如果某个组件在这个场景里没有角色，要么删掉，要么说明它是为别的场景服务的。这样检查一遍，设计题的逻辑会紧很多。

4. 数据库与 Web 开发考点：从范式到接口的落地细节

数据库和 Web 开发是系统分析师考试里最容易“看起来会、做起来错”的部分。范式、索引、事务、接口设计，这些概念大家都听过，但一到具体题目，细节上翻车的人特别多。这一章把高频考点拆成可操作的检查项。

4.1 范式判断的快速方法：看函数依赖而不是背定义

范式题不用背 1NF、2NF、3NF 的定义，直接找函数依赖。步骤是：先找候选键，再看非主属性对候选键的依赖关系。如果存在部分依赖，就是 1NF 问题；存在传递依赖，就是 2NF 问题；存在非平凡的多值依赖，才考虑 4NF。

具体操作：拿到一个关系模式，先标出所有函数依赖，然后问三个问题。第一，有没有非主属性只依赖候选键的一部分？有就拆。第二，有没有非主属性依赖另一个非主属性？有就拆。第三，拆完之后有没有丢失原有的函数依赖？如果丢了，说明拆过头了，需要保留一个关联关系。

考试里经常让你判断“是否满足 3NF”，你不需要写完整证明，只要指出哪条依赖违反了哪条规则，然后给出拆分方案即可。

4.2 索引设计的取舍：选择性、覆盖、写入代价

索引不是越多越好。判断一个索引该不该建，看三个数：选择性、覆盖能力、写入代价。选择性是不同值的比例，比例越高越适合建索引。覆盖能力是指查询需要的列是否都在索引里，如果在，可以避免回表。写入代价是指每次插入更新都要维护索引，索引越多写越慢。

我一般用下面这个顺序决定：

1. 找出 where 条件里出现频率最高的列。
2. 看这些列的选择性，低于 10% 的单独建索引意义不大，可以考虑组合索引。
3. 看查询是否需要回表，如果需要的列少，做成覆盖索引。
4. 统计这张表的读写比，读多写少可以多建，写多读少要克制。

注意：组合索引的列顺序很关键，等值条件在前，范围条件在后。顺序反了，索引可能只用上前缀列。

4.3 事务隔离级别的选择：从脏读到幻读的对应关系

事务隔离级别是必考点，但很多人只背了四个级别和三个现象，不知道怎么选。实际判断时，先看业务能不能容忍哪种异常。如果绝对不能出现脏读，至少用读已提交。如果同一事务内多次读同一范围，结果必须一致，就要可重复读或串行化。

下面这张表把现象和级别对应清楚：

考试答题时，如果题目说“某系统要求同一事务内多次查询结果一致”，你写可重复读并说明它通过快照实现即可。如果要求“统计结果绝对准确”，写串行化，但要补一句性能代价。

4.4 接口设计的三个检查项：幂等、超时、错误码

Web 开发部分，接口设计是高频考点。我一般用三个检查项过一遍。第一，幂等：这个接口重复调用会不会产生副作用？如果会，需要幂等键或去重表。第二，超时：调用方等多久？服务端处理多久？两个时间要匹配，调用方超时时间必须大于服务端处理时间。第三，错误码：业务错误和系统错误有没有分开？业务错误用明确码值，系统错误用统一码值加日志追踪。

{ "code": "ORDER_NOT_FOUND", "message": "订单不存在", "traceId": "abc-123" }

上面这个结构里，code 是业务错误码，message 给人看，traceId 给排查用。考试里如果让你设计接口返回，把这三样写全，基本不会丢分。

5. 大数据处理与架构模式：批流选择与考点排查

大数据处理这块，系统分析师考试不会考你写 MapReduce，但会考你选批处理还是流处理，以及架构模式怎么配合。判断依据是延迟要求和数据完整性要求。延迟要求低、允许近似结果，选流处理；延迟要求高、要求精确结果，选批处理。两者结合就是 Lambda 架构，但考试里写 Lambda 要说明批层和流层各自负责什么。

5.1 批处理与流处理的判断树

我一般用三个问题做判断。第一，数据要不要全量重算？要就偏批。第二，结果能不能接受分钟级延迟？能就偏批，不能就偏流。第三，有没有乱序数据？有就偏流，因为批处理对乱序不敏感但流处理需要水位线机制。

考试里如果题目说“实时监控设备状态并告警”，写流处理，补一句“使用窗口聚合和状态存储”。如果说“每天生成经营报表”，写批处理，补一句“按天分区，全量计算”。

5.2 大数据架构的考点分布：存储、计算、调度

大数据架构题一般考三层：存储层、计算层、调度层。存储层考选型，比如按列存储适合分析、按行存储适合事务。计算层考批流和引擎选择。调度层考依赖管理和失败重试。

答题时不要只写“用某某组件”，要写清楚每一层解决什么问题。比如“存储层使用分布式文件系统保存原始数据，计算层使用批处理引擎做全量聚合，调度层按依赖关系触发任务并记录执行状态”。这样写，层次清楚，得分点全。

5.3 避坑与常见问题排查

这一节列几个我在整理考点和实际做题时反复踩的坑，每条按现象、原因、解决写。

现象一：数据流图逐层分解后，父图和子图数据流对不上。原因：画子图时凭感觉加了新的输入输出，没有回头核对父图。 解决：每画完一层，把父图的所有流列出来，逐条在子图里找对应，找不到就补，多出来就删。

现象二：范式判断时把候选键找错，导致后续依赖全错。原因：只看了明显的唯一列，忽略了组合候选键。 解决：先把所有函数依赖写出来，再从中推导候选键，不要凭直觉指认。

现象三：索引建了但查询没走，性能没提升。原因：查询条件里对索引列做了函数运算或类型转换。 解决：检查 where 条件，确保索引列以裸列形式出现，必要时改写查询或建函数索引。

现象四：事务隔离级别选了可重复读，但统计结果还是不对。原因：可重复读防不住幻读，统计范围变了。 解决：对统计类查询使用串行化，或者在应用层加锁，并说明代价。

现象五：微服务拆分后，两个服务频繁联调，发布反而更慢。原因：拆分时没有按发布节奏切，把总是一起改的模块拆开了。 解决：重新按业务能力聚合，把同步修改的模块合并回一个服务，或者改用模块化单体。

6. 把考点变成可验证的复习动作：我的错题复盘习惯

复习到后期，最大的问题不是不会，而是“以为自己会”。我自己的做法是，每整理完一个考点，不写总结，而是写一个可验证的动作。比如整理完索引设计，动作是“给一张虚构的订单表，写出三个查询和对应索引，并说明每个索引的选择性”。整理完事务隔离，动作是“写出两个并发事务，分别在不同隔离级别下执行，标出可能出现的异常”。这样做的目的是把知识点变成可检查的输出，而不是停留在“看过”。

具体操作上，我一般用下面这个模板来复盘错题：

错题来源：某次模拟练习 考点：数据流图平衡 我的答案：子图少了一条输入流 正确答案：父图的“设备信息”流必须出现在子图 错因：画图时只关注了加工逻辑，忘了外部实体输入 修正动作：以后每画完子图，先列父图流清单，再逐条核对

这个模板的关键是最后一行“修正动作”，必须是一个下次可以执行的具体行为，不能写“下次注意”。写“下次注意”等于没写。

另外，我会把每个考点的“最小验证”记在一个单独的文件里，考前只看这个文件。比如数据库部分的最小验证是“给一个关系模式，判断范式并拆分”；架构部分的最小验证是“给三个质量属性场景，检查设计是否覆盖”。这样考前不用翻厚书，直接跑一遍验证动作，心里就有底。

最后一个习惯：遇到不确定的题，不要猜，先标记，回头用“如果我是出题人，我想考哪个决策”来反推。系统分析师考试考的是决策能力，不是记忆能力。把每个考点还原成一个决策场景，比背十遍定义都管用。希望帮到你。

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