先看题目有没有从业务问题走到模型
一套好的系统分析题，应当让你先识别业务目标和干系人，再定义系统边界，之后才选择用例、DFD、ER或状态机表达。直接问“这个箭头叫什么”可以检查基础，却不能训练为什么选这张图。
例如登录页面、认证流程协调器和用户对象分别对应边界类、控制类和实体类。真正有用的解析会说明三类对象的责任，以及为什么页面不应直接承担全部业务规则。
| 分析任务 | 适合的表达 | 题库应追问 |
|---|---|---|
| 识别外部角色与目标 | 用例图和用例描述 | 参与者是否在系统边界之外？ |
| 描述业务或数据流 | 流程图、DFD | 输入输出和父子图是否平衡？ |
| 描述数据结构 | ER图、关系模式 | 实体、联系和约束是否完整？ |
| 描述对象交互 | 时序图、通信图 | 消息顺序和责任是否合理？ |
| 描述生命周期 | 状态机图 | 事件、守卫和动作是否区分？ |
用同一个订单场景检验五种模型
让题库用一个订单场景分别问：谁是参与者，订单怎样流转，订单和商品是什么关系，支付消息如何交互，取消事件在什么条件下允许转换。模型来自同一业务，答案之间应彼此一致。
系统分析师的难点正在这里：图不是孤立的。用例里承诺的功能应能在交互和状态中找到支撑，数据模型也要保存业务所需信息。如果题库只按图形分类，反而看不到跨模型矛盾。
- 先写一句业务目标，避免一上来画图。
- 圈出系统外部角色和系统边界。
- 选择最能回答当前问题的模型，不追求一张图包办全部。
- 核对模型之间的名称、数据和行为是否一致。
- 最后才检查符号、箭头和多重度等表示细节。
可行性计算与需求建模要交叉训练
系统分析不只有UML。经济可行性中的NPV、成本效益与风险判断，同样决定方案是否值得做。题库应既有建模题，也有能展示现金流折现和决策依据的计算题。
复习时可以用“目标、需求、方案、价值、风险”五个词串起模块：业务目标产生需求，需求约束方案，方案需要验证经济和技术可行性，最终还要管理风险与变更。这样比按章节孤立背诵更接近分析师思维。
| 能力 | 练习重点 | 常见误区 |
|---|---|---|
| 需求分析 | 来源、优先级、验证与追溯 | 把用户愿望直接当批准需求 |
| 过程与数据建模 | 边界、平衡、关系与约束 | 只认符号不看语义 |
| 对象建模 | 责任、交互、状态和一致性 | 所有逻辑都塞进一个类 |
| 可行性分析 | 现金流折现、成本收益和风险 | 直接相加不同时点金额 |
| 方案评价 | 指标、权衡和验证证据 | 把单个优势当成总体最优 |
模型题错了，先查语义，再查画法
很多考生一看到箭头画错就只背符号。老师复盘时会先问：你认为谁依赖谁、谁触发谁、状态为何转换？语义说不清，换一种建模工具仍会错；语义正确但符号错，才是表示法问题。
案例题也一样。答案不应只是“加强需求管理”，而要回到材料写获取、确认、追溯、变更和验证动作，并指出由谁在什么阶段完成。题库能否把宽泛术语改写成可执行动作，是判断质量的重要标准。
状态机中的event、guard、action怎么分
cancel是触发状态转换的事件。
[尚未出库]是守卫条件，只有为真时转换才允许发生。
refund()是转换发生时执行的动作。
把三个角色放回订单取消场景，比只背英文缩写更不容易混。
相关题目解析
下面这些题目和本专题的判断方法关联较强，适合读完概念后回到具体题干里校验理解。
- 支付成功与失败二选一，在 UML 时序图中应使用哪种组合片段？UML时序图 / 组合片段
- 同一个事件发生后，状态转换是否执行由什么条件决定？UML状态机 / Guard
- 登录页面、认证流程协调器和用户对象分别属于哪类分析类？Boundary Control Entity / 分析类
- 项目净现值 NPV 为正，经济可行性怎样判断？净现值 / NPV
- 用例图中的参与者应该怎么识别？用例图 / 参与者
常见问题
系统分析师题库应该重点练哪些内容？
应覆盖需求分析、可行性分析、DFD、ER、UML、数据与对象建模、方案评价和案例表达，不能只集中在图形符号题。
系统分析师模型题怎么复习？
先理解模型要回答的业务问题，再检查系统边界、对象责任和模型间一致性，最后记符号与箭头。推荐用同一业务场景串联多种模型。
系统分析师案例题答案为什么容易空泛？
常见原因是只写管理名词，没有引用材料中的角色、问题和阶段。答题时应把措施写成责任人、动作、产物和验证方式。