先看题目问的是“分析”还是“设计”
系统分析师题目经常把业务背景写得比较长。不要一看材料就急着写方案，先看问题问法。它可能让你识别参与者、补充用例、判断数据流、描述业务规则，也可能让你评价方案的合理性。
如果题目问需求分析，你就不要大篇幅写技术架构；如果题目问系统设计，也不能只写用户想要什么。分析和设计有联系，但采分点不一样。
| 问法信号 | 更可能考什么 | 答题抓手 |
|---|---|---|
| 参与者、用例、业务目标 | 用例建模 | 看系统边界和外部角色 |
| 数据流、加工、数据存储 | DFD/数据字典 | 看输入、处理、输出是否平衡 |
| 实体、联系、多重度 | ER模型 | 看业务对象和关系 |
| 性能、安全、可用性 | 非功能需求 | 写可度量指标更稳 |
| 方案优缺点、适用性 | 方案论证 | 结合约束条件分析取舍 |
案例题不要写成“万能建议”
系统分析师案例题里，“加强沟通、完善管理、优化系统”这类话很难拿高分，因为它没有落到具体分析动作。更像答案的写法，是指出材料里的具体问题，再给出对应分析或建模动作。
比如材料里用户频繁变更需求，你可以写：建立需求基线、维护需求跟踪矩阵、通过评审确认需求变更影响、更新需求规格说明书。这样比只写“加强需求管理”更像采分点。
一段更像答案的表达
先识别系统外部参与者和业务目标，明确系统边界。
对核心业务流程建立用例模型或数据流图，检查输入输出是否完整。
对关键实体建立 ER 模型，明确实体属性、联系和多重度。
把性能、安全、可用性等非功能需求写成可验证指标。
复盘时把错因分成四类
系统分析师案例题复盘，不要只看标准答案。你要判断自己错在哪里：是题目问法没看懂，还是模型图不会画，还是业务规则没抽出来，还是答案表达太散。
如果错因是模型图，建议先回到 UML、DFD、ER 这几类图的边界；如果错因是表达，建议训练“问题-原因-措施-结果”这种短句结构。