S01 · 系统分析师交付什么

第 1 周｜主打科目：综合知识｜对应知识域：系统规划与分析、软件工程、计算机系统基础｜主打基本问题：Q1–Q4 全部提出（本阶段只提问，不作答）｜本阶段产出：项目情境卡 + 干系人清单 + 初步问题清单

项目宪法（四问、五条持久理解、GRASPS 任务、评分量规）见 00-课程总纲.md，本文件不再复述。

一、情境开场（Hook）

周一上午九点，你被叫进 CIO 的会议室。桌上摊着三份文件：一份是生产部报上来的”系统响应太慢，工位扫码要等三四秒”的投诉记录；一份是质量部刚出的客户索赔通报——某批次轴承被客户查出热处理参数异常，追溯时才发现那套运行 12 年的 C/S 架构 MES 只存了结果值、没存过程参数，追不回是哪台炉、哪一班、哪个工艺版本；还有一份是设备部长的手写便签，上面只有一句话：”要我给 2000 人换设备，先给我 2000 万。”

CIO 问你的第一句话不是”你打算怎么设计”，而是：**”18 个月，一期上线，你说这个项目到底该做什么？”**

你说要先做可行性研究。生产部长立刻插话：”可研我们三年前做过一次，结论是’可行’，然后就没有然后了。”质量部长不关心技术，只问一句：”你能保证出了事我追得到人吗？”设备部长更直接：”我那批 2008 年的老机床没有标准接口，你打算怎么办？”

你忽然意识到，这三个人说的根本不是同一件事——生产部要实时性、质量部要完整追溯、设备部要低改造成本，而这三者叠加预算受限与 18 个月死线，不可能同时满分。散会前 CIO 留了一句话：”下周一，我要看到你说的’系统分析师’到底交付什么。”

于是本周的问题只有一个：在这个局里，你交付的到底是什么？是需求文档，是一串没人看的图，还是一个能被论证、被推翻、被追责的判断？

二、为什么学这一周（Where & Why）

1. 系统分析师的角色定位与边界：综合知识每年 2–4 题。它更决定你后面 11 周”用谁的视角看问题”——用架构师视角答题会丢需求分，用 PM 视角答题会丢设计分。
2. 三科结构与连考机制：本身不出题，但决定 240 分钟怎么花。每年都有人综合知识做满 140 分钟，案例只剩 80 分钟，第 1 题白丢 20 分。不知道时间规则，是在用策略失误伪装成知识不足。
3. 生命周期与阶段产出：综合知识 2–3 题，且是案例”某阶段该产出什么文档”的直接依据（约 5–8 分）。
4. 开发方法对比（结构化 / 面向对象 / 原型 / 敏捷）：综合知识 3–5 题，案例”应选哪种开发方法”约 8–10 分，论文也常要求说明选型理由。
5. 系统规划三法（BSP / CSF / SST）与可行性研究：综合知识稳定 2–4 题，几乎是纯记忆送分，属第一梯队里最不该丢的一块。
6. 非功能需求 / 质量属性：综合知识 2–3 题，并在 S06（ATAM）、S08（SQA）两次加深。本周只要求说出名字与判定场景，但案例里凡”响应慢””改造贵”的问题，本质都是质量属性问题。

三、核心讲义（Equip）

3.1 系统分析师是谁：角色定位与四条边界

定义：系统分析师（System Analyst, SA）是在需求与实现之间做翻译和决策的人——把模糊的业务诉求转译成可验证的系统规格，并在成本、进度、质量约束下论证它可行。

为什么需要它：业务方说”要快”，工程师听到”加缓存”；业务方说”要能追溯”，工程师听到”建日志表”。两句话之间隔着一整个专业，这段距离就是 SA 的岗位。

怎么用：考试里区分四个角色，抓住交付物与关注点这一条主线。

角色	核心关注	主要交付物	一句话区别
系统分析师 SA	做什么、为什么做、做到什么程度算对	需求规格说明书、分析模型（DFD/用例/类图）	定义问题域与验收标准
系统架构师	用什么结构满足质量属性	架构设计说明书、ADR	定义解空间与技术权衡
项目经理 PM	范围、进度、成本、风险	WBS、进度计划、风险登记册	保证在约束内交付
产品经理	用户价值、商业成功、版本节奏	产品路线图、PRD	对市场负责，不必然对技术可行性负责

真题级短例子：问”系统上线后查询慢，需分析瓶颈在 SQL、网络还是应用服务器，属于谁的职责”→ 系统架构师（性能是质量属性，属解空间）；问”查询结果不符合预期，需确认业务规则”→ 系统分析师（需求正确性）。看病灶在问题域还是解空间，是这类题唯一的钥匙。

3.2 三科结构与连考时间机制（2026）

定义：系统分析师考试分三科，三科必须在同一次考试中全部达到 45 分，无成绩滚动、无单科保留。

科目	题型	分值 / 合格	时长	关键机制
① 综合知识	75 道单选	75 / 45	150 分钟	与②连考，总计 240 分钟
② 案例分析	5 道主观大题，选做 3 道（第 1 题必做，其余 4 选 2）	75 / 45	90 分钟	与①连考，中途不休息、不收卷
③ 论文	1 篇，约 2500 字	75 / 45	120 分钟	单独时段

为什么需要它：连考机制意味着时间可以在科目间转移。综合知识省下的每一分钟，都能变成案例第 1 题的检查时间。全程机考也意味着画图题靠文字描述或选择，不能靠”画得像”。

240 分钟分配战术：

阶段	建议用时	纪律
综合知识	70–80 分钟	75 题，平均每题 60 秒；超 90 秒无思路立刻凭第一感选并标记
交卷切换 + 审题	5 分钟	案例先扫全卷，按”会做的确定性”给 5 题排序，不按题号做
案例第 1 题（必做）	25–30 分钟	建模题，全卷性价比最高，优先啃下
案例选做 ×2	各 25 分钟	严格计时，卡住就写要点留空
机动 / 检查	20–25 分钟	回填空，检查第 1 题的数据守恒与平衡

真题级短例子：案例作答固定四段结构——问题定位 → 理论依据 → 解决方案 → 效果分析，分点作答、用专业术语。同样一个答案，分点写与写成一段，实务中相差 3–5 分。

3.3 信息系统生命周期与阶段产出

定义：信息系统生命周期（System Development Life Cycle, SDLC）通常划分为系统规划 → 系统分析 → 系统设计 → 系统实施 → 系统运行与维护五阶段，可行性研究作为系统规划阶段的核心活动。

为什么需要它：案例与论文都爱问”某阶段该产出什么””上一阶段没做完就跳下一阶段会出什么问题”。背出阶段—产出对应表就能白拿分。

阶段	核心问题	主要产出	本项目对应物
系统规划	要不要做、能不能做	可行性研究报告、系统规划报告	一期可行性研究报告
系统分析	做什么	需求规格说明书（SRS）、DFD、数据字典、用例模型	业务需求规格说明书
系统设计	怎么做	概要设计说明书（架构、模块结构）、详细设计说明书	架构设计说明书 + ADR
系统实施	做出来	源程序、测试报告、用户手册	编码、单元测试、集成测试
运行与维护	用得住	维护记录、变更记录、版本说明	运维手册、变更台账

注意：分析阶段产出的是逻辑模型（做什么，与实现技术无关）；设计阶段产出的是物理模型（怎么做，与具体技术绑定）。考题常把”数据库表结构设计””选 Java 还是 Go”放到需求阶段迷惑你——这些属设计阶段。

3.4 四大开发方法：选型就是选失败方式

方法	核心思想	适用场景	主要风险
结构化方法（Structured Analysis and Design, SA/SD）	自顶向下、逐层分解，用 DFD + 数据字典描述	需求明确、稳定的大型系统；数据处理密集	需求一变，模型大面积返工
面向对象方法（Object-Oriented, OOA/OOD）	对象、类、继承、多态；用例驱动	需求复杂、易变；需长期演进	建模门槛高，团队能力不齐易失控
原型法（Prototyping）	先做可运行样品，反复确认	需求不明确、用户说不清	演化型原型被当成最终系统，架构腐烂
敏捷方法（Agile）	短迭代、拥抱变化、可工作软件优先	需求变化快、规模适中、团队小而专、客户可全程参与	文档不足；大团队/强合规场景难落地

判定步骤（考试里套这个）：① 需求明确吗？不明确 → 原型法或敏捷；明确 → 结构化或面向对象。② 规模大、需求稳定、以数据处理为主 → 结构化。③ 需长期维护、复用、领域模型复杂 → 面向对象。④ 需求变化频繁、交付周期紧、团队 5–9 人且客户能持续参与 → 敏捷。⑤ 硬实时、强安全、强合规（航天、医疗、金融核心）→ 不选敏捷。

原型法三类型：探索型（弄清需求）、实验型（验证技术方案可行性）、演化型（逐步演化为最终系统）。风险最高的是演化型——“原型未经重构直接上线导致后期维护成本剧增”就是它的典型症状；与之相对的是抛弃型原型。

真题级短例子：”车间工人无法完整描述操作流程，但看到界面就能指出哪里不对”→ 原型法（探索型）；”需求明确、技术成熟、工期固定的财务核算系统”→ 结构化方法 / 瀑布模型。

3.5 系统规划三法：CSF / SST / BSP 必须分清

方法	全称	核心思想	起点	适用场景	局限
CSF	关键成功因素法（Critical Success Factors）	抓少数几个决定组织成败的关键因素，再导出信息需求	高层管理者的目标	高层战略规划、需突出重点、资源有限	因素易受个人主观影响
SST	战略目标集转化法（Strategy Set Transformation）	把组织的战略目标集（使命、目标、战略、组织属性）转化为信息系统战略目标集	组织已有的战略文档	组织战略清晰、需保证 IS 战略与组织战略一致	战略本身模糊则无从转化
BSP	企业系统规划法（Business System Planning）	自上而下规划、自下而上实现；识别业务过程与数据类，用 U/C 矩阵划分子系统	业务过程与数据类	大型组织、需从数据角度整合孤岛、做总体数据规划	方法重、周期长

判定的三条线索：出现”高层“”少数关键因素“”突出重点“ → CSF；出现”组织战略“”使命/目标/战略转化“”保持一致“ → SST；出现”U/C 矩阵“”数据类“”子系统划分“”自上而下规划、自下而上实现“”数据孤岛“ → BSP。

BSP 的 U/C 矩阵怎么用：行是数据类、列是业务过程；U 表示使用（Use），C 表示创建（Create）。正确性检验三条：① 每个数据类有且仅有一个 C（唯一数据源）；② 每个数据类至少有一个 U（否则是死数据）；③ 每个业务过程至少有一个 C 或 U（否则该过程无效）。调换行列让 C 尽量集中在对角线上，对角线附近的方块即子系统。

本项目落点：本项目”数据孤岛严重、3 厂区、要打通生产与质量数据”→ 总体规划用 BSP（用 U/C 矩阵划分子系统、确定数据类）；向 CIO 汇报投入产出时辅以 CSF（收敛为”一次合格率””追溯响应时间””设备改造投入”三项）。二者是协作关系，不是二选一。

3.6 可行性研究与非功能需求的初次引入

定义：可行性研究（Feasibility Study）在立项前论证项目是否值得做、是否做得到，通常含四类。

类型	回答的问题	本项目要查什么
技术可行性	现有技术能不能实现	老设备无标准接口 → 边缘网关 / OPC 转换 / 人工录入兜底是否可行
经济可行性	投入产出划不划算	成本效益分析、投资回收期、净现值、ROI
操作（运行）可行性	组织与人能不能用得起来	2000 名员工的操作习惯、班次、培训成本、岗位抵触
社会可行性	法律、政策、道德允许吗	数据合规、安全生产与环保监管报送、劳工影响

经济可行性三个公式：① 净现值 NPV = Σ(CI_t − CO_t)/(1+i)^t，NPV ≥ 0 可行，多方案取最大；② 静态投资回收期 = 累计净现金流量首次为正的年份数 − 1 + |上年累计净现金流量| / 当年净现金流量；③ ROI = 年平均利润总额 / 总投资额 × 100%。

非功能需求 / 质量属性：功能需求说”做什么”，非功能需求（Non-Functional Requirement, NFR）说”做到多好”。常考六类：性能、安全性、可用性、可修改性、可靠性、易用性。质量属性必须写成可度量场景才有意义：

坏例子：”系统要快。”（不可验证，SRS 里这是废话）
好例子：”工位终端提交报工数据后，系统1 秒内返回结果；峰值并发 300 个工位、网络正常条件下，99% 的请求满足该指标。”

本项目四个落点：生产部的”实时”= 性能；质量部的”完整追溯”= 可靠性 + 安全性（防篡改）；设备部的”低改造成本”= 可修改性 + 互操作性；18 个月上线 = 进度约束（不是质量属性，但会挤压所有质量属性）。

四、典型考法

4.1 综合知识怎么考

题 1：某企业进行信息系统总体规划，需先识别组织的使命、目标与战略，并将其转化为信息系统的目标与战略，确保二者一致。最适合采用的方法是（　　）。　A. 关键成功因素法　B. 战略目标集转化法　C. 企业系统规划法　D. 价值链分析法

答案：B。解析：题干关键词”组织战略目标 → 信息系统战略目标””保持一致”，正是 SST 定义。CSF 抓少数关键因素，BSP 从业务过程与数据类出发用 U/C 矩阵划分子系统，D 为干扰项。

题 2：关于原型法，下列说法错误的是（　　）。　A. 原型法适用于用户需求不明确、难以准确描述的场景　B. 演化型原型经不断完善，最终可能演化为交付的系统　C. 原型法可以完全取代结构化分析与设计方法　D. 抛弃型原型主要用于确认需求，需求确认后即不再使用

答案：C。解析：原型法是需求获取的辅助手段，不能取代系统化的分析与设计。演化型原型若不重构直接上线会带来严重维护问题。A、B、D 均为教材原意。

题 3：某项目初始投资 200 万元，第 1 至第 3 年末净现金流量分别为 80、90、100 万元。不考虑贴现，静态投资回收期约为（　　）。　A. 2.00 年　B. 2.30 年　C. 2.67 年　D. 3.00 年

答案：B。解析：累计净现金流：第 1 年末 −120，第 2 年末 −30，第 3 年末 +70。首次为正发生在第 3 年，回收期 = 3 − 1 + 30/100 = 2.30 年。要点是”年份数 − 1 + 上年累计绝对值 / 当年净现金流”。

题 4：结构化设计中，模块间耦合类型按由低到高排列，正确的是（　　）。　A. 数据耦合 → 标记耦合 → 控制耦合 → 公共耦合 → 内容耦合　B. 标记耦合 → 数据耦合 → 控制耦合 → 公共耦合 → 内容耦合　C. 数据耦合 → 控制耦合 → 标记耦合 → 公共耦合 → 内容耦合　D. 控制耦合 → 数据耦合 → 标记耦合 → 外部耦合 → 内容耦合

答案：A。解析：由低到高为非直接耦合 → 数据耦合 → 标记耦合 → 控制耦合 → 外部耦合 → 公共耦合 → 内容耦合。A 相对顺序正确（S03 完整展开，本周先记住”数据 < 标记 < 控制 < 公共 < 内容”这条主轴）。

题 5：系统分析师与系统架构师的主要区别在于（　　）。　A. 系统分析师负责编码实现，系统架构师负责测试　B. 系统分析师定义问题域与验收标准，系统架构师定义解空间与技术权衡　C. 系统分析师只对项目经理负责，系统架构师只对客户负责　D. 两者职责完全重合，仅是称谓不同

答案：B。解析：这是本阶段最核心的一条边界。A 混淆实现与测试职责，C、D 明显错误。

4.2 案例分析怎么考

【案例题】（共 25 分）

某中型制造企业 3 个厂区、约 2000 名员工，现有一套运行 12 年的 C/S 架构 MES，数据孤岛严重。企业决定建设”生产执行 + 质量追溯一体化”系统，要求 18 个月内完成一期上线，预算受限。调研发现：生产部要求数据实时采集与展示；质量部要求从成品到原材料、到设备参数、到班组的全程追溯；设备部指出部分 2008 年购置的设备无标准接口，改造费用高；企业高层尚未就一期范围达成一致。

【问题 1】（8 分） 分别说明 CSF、SST、BSP 的核心思想与适用场景，并结合本项目特点指出总体规划阶段应优先采用哪一种，说明理由。
【问题 2】（9 分） 从技术、经济、操作、社会四方面列出本项目可行性研究应分析的主要内容（每方面不少于 3 条）。
【问题 3】（8 分） 项目组拟采用”原型 + 增量”混合方式：① 为何纯瀑布模型不适合本项目（4 分）；② 采用原型法可能存在哪些风险，应如何控制（4 分）。

采分点拆解：问题 1——三种方法各 2 分（思想 1 + 场景 1），选型 1 分，结合本项目的理由 1 分；必须出现 CSF”少数关键因素/高层视角”、SST”战略转化/保持一致”、BSP”业务过程+数据类+U/C 矩阵+自上而下规划自下而上实现”。问题 2——四个方面各 2 分（列 3 条且合理即满），条理性 1 分，缺一方面扣 2 分。问题 3——① 每点 2 分最多 4 分；② 风险每点 1 分（最多 2 分）、控制措施每点 1 分（最多 2 分）。只写方法名不写思想、三种方法张冠李戴、选型不写理由，是最常见的三种失分。

标准作答范例

【问题 1】 ① CSF：识别少数几个决定组织成败的关键因素，再由其导出信息需求与性能指标；适用于高层战略规划、需突出重点且资源受限的场景；局限是易受个人主观影响。② SST：把组织战略目标集（使命、目标、战略及其他战略性组织属性）转化为信息系统战略目标集，保证二者一致；适用于组织战略已清晰的场景。③ BSP：自上而下规划、自下而上实现，通过识别企业业务过程与数据类构造 U/C 矩阵，调整行列使 C 集中于对角线，从而划分子系统、确定数据共享关系；适用于大型组织的总体数据规划。④ 选型与理由：总体规划阶段应优先采用 BSP。理由：题干明确指出”数据孤岛严重”，BSP 以数据类为核心，可从数据角度统一规划、消除孤岛；3 个厂区、生产/质量/设备三部门诉求冲突，需 BSP 的业务过程—数据类矩阵客观划分子系统边界，避免按部门割裂建系统；向高层论证投入产出时可辅以 CSF，把关键因素收敛为”一次合格率””追溯响应时间””设备改造投入”三项。

【问题 2】 ① 技术可行性：无标准接口老设备的数据采集方案是否成熟（边缘网关/OPC 转换/人工录入兜底）；实时采集的数据量与现有网络、存储承载力是否匹配；与现有 C/S 架构 MES 的集成与数据迁移是否可行；技术团队是否具备相应能力。② 经济可行性：投资估算（硬件改造、软件研发、实施、培训）与成本效益分析；计算投资回收期、净现值（NPV）、投资回报率（ROI）；分期投入与一期资金约束（题干”预算受限”）；直接效益（报废率下降）与间接效益（客户索赔减少）的量化。③ 操作可行性：2000 名员工跨 3 厂区的培训成本与班次安排；一线工人对新系统的接受度与操作习惯改变；现有业务流程是否需要调整（BPR）及组织阻力；运维团队能否承接。④ 社会可行性：是否满足数据安全与个人信息保护相关法规；是否满足行业监管及安全生产、环保数据报送要求；对员工岗位的影响与劳动关系风险；是否符合产业政策与企业社会责任方向。

【问题 3】 ① 纯瀑布模型不适合的原因：瀑布要求需求在前期完全确定并冻结，而本项目高层尚未就一期范围达成一致、三部门诉求冲突，需求必然演进；瀑布到项目后期才交付可运行软件，风险暴露太晚，18 个月工期下方向错了无法回头；瀑布难以响应变更，而设备改造方案不确定、业务理解逐步深入，变更不可避免。② 风险与控制：风险一——演化型原型被直接当作最终系统上线，架构不清、维护成本高。控制：明确区分抛弃型原型与演化型原型；采用演化型时，需求确认后必须做一次架构重构与重新设计并纳入评审与配置管理。风险二——用户过度关注界面细节，忽视业务流程与数据模型等本质问题。控制：原型只做关键流程与核心交互，每次演示围绕业务规则确认清单展开。风险三——反复修改导致范围蔓延、工期失控。控制：为原型迭代设固定迭代次数与截止时间，超出即冻结；变更走变更控制流程，由变更控制委员会（CCB）审批。

五、易错点（Rethink）

错误认知	为什么错	正确理解
“系统分析师就是高级程序员/需求分析员”	把角色等同于某个职级或某份文档	SA 对问题域与验收标准负责；写文档只是载体，判断与论证才是交付物
“三科只要有一科过了就行，下次补另一科”	软考没有成绩滚动	三科必须同次全部达 45 分，任一科不过全部作废
“综合知识 150 分钟，我就用满 150 分钟”	忽略连考机制	①②连考共 240 分钟，综合知识应压缩到 70–80 分钟，把时间转移给案例第 1 题
“案例第 1 题必做，所以我按顺序先做它”	必做 ≠ 先做	应先扫全卷 3 分钟排序；卡壳果断跳，最后回填
“原型法就是先做个界面给用户看”	缩小了原型的用途	原型分探索型/实验型/演化型，实验型验证技术方案可行性，不一定有界面
“敏捷最先进，所以任何项目都该选敏捷”	选型看匹配度不是先进度	硬实时、强合规、大团队、文档密集型场景（航天、金融核心）不适合敏捷
“U/C 矩阵里一个数据类可以有多个 C”	违背唯一数据源原则	每个数据类有且仅有一个 C，多个 C 说明冗余与职责不清，必须归并
“技术上做不到就一票否决”	混淆四类可行性	可行性是四维综合；技术做不到可缩小范围或换方案，经济不划算才是硬否决
“非功能需求写成’要快、要安全、要易用’”	不可验证的需求等于没有需求	质量属性必须写成可度量场景：有指标、有条件、有比例

六、GRASPS 推进（Experience）

本周五前，在交付物根目录新增三块内容，总计 800–1200 字：

1. 项目情境卡（约 300 字）：把 Hook 压缩成可复用背景——3 厂区、2000 员工、12 年 C/S 架构 MES、数据孤岛、18 个月一期、预算受限、老设备无标准接口、三部门冲突诉求。这段会在论文里一字不改地用 4 次，现在就打磨好。
2. 干系人清单（表格，约 300 字）：不少于 6 个干系人（CIO、生产部长、质量部长、设备部长、一线操作工、IT 运维、客户/监管方），每人标注角色、核心诉求、态度（支持/中立/抵制）、影响程度（高/中/低）、沟通策略。必须包含至少一个”抵制”者，否则清单是假的。
3. 初步问题清单（约 400 字）：列出 12–15 个调研阶段必须问清的问题，例如”追溯粒度到批次还是到件””无接口设备人工录入能否接受””一期是否覆盖 3 个厂区””历史 12 年数据是否迁移”，每条注明问谁。

验收标准：情境卡让人 30 秒内听懂项目且不堆技术术语；干系人清单有明确的冲突对（生产部 vs 设备部）和至少一个抵制者；问题清单中至少 3 条是”没人能立刻回答”的尖锐问题（如”一期不上线，哪个部门最先出问题”）；三部分都能直接粘进后续 SRS 与论文正文，无需重写。

七、自测

1. 属于系统分析师职责的是（　　）。
   A. 确定技术栈与中间件选型　B. 编写需求规格说明书并建立需求跟踪矩阵
   C. 制定 WBS 与挣值基线　D. 决定项目是否立项

2. 关于三科考试，正确的是（　　）。
   A. 综合知识与案例连考总时长 240 分钟，论文单独 120 分钟　B. 综合知识 150 分钟，案例 150 分钟
   C. 三科成绩可保留两年，分次通过即可　D. 案例 5 题全部必做

3. 系统分析阶段的主要产出是（　　）。
   A. 源程序与测试报告　B. 概要设计与详细设计说明书
   C. 需求规格说明书与逻辑模型　D. 可行性研究报告

4. 要从”使命—目标—战略”出发保证 IS 战略与组织战略一致，宜采用（　　）。
   A. CSF　B. SST　C. BSP　D. 关键路径法

5. BSP 的 U/C 矩阵正确性检验不包括（　　）。
   A. 每个数据类有且仅有一个 C　B. 每个数据类至少有一个 U
   C. 每个业务过程至少有一个 C 或 U　D. 每个业务过程有且仅有一个 U

6. 关于结构化与面向对象方法，错误的是（　　）。
   A. 结构化方法自顶向下、逐层分解　B. 面向对象更适合需求易变、需长期演进的系统
   C. 结构化方法的核心模型是 DFD 与数据字典　D. 面向对象方法不能用于数据处理密集型系统

7. 下列属于可验证的非功能需求的是（　　）。
   A. 系统界面应简洁美观　B. 系统应具备良好的可扩展性
   C. 报工提交后 1 秒内返回结果，峰值 300 并发下 99% 请求满足　D. 系统应易于使用

8. 某项目 NPV 为负，说明（　　）。
   A. 项目在经济上不可行　B. 项目技术上不可行　C. 项目操作上不可行　D. 项目社会影响不佳

9. 敏捷方法不适用于（　　）。
   A. 需求变化快、客户可全程参与的互联网产品　B. 5–9 人的小型专职团队
   C. 强合规、需完整文档与审计追溯的金融核心系统　D. 需快速验证市场假设的创新项目

10. 最适合”用户说不清需求，但看到实物就能指出问题”的是（　　）。
    A. 结构化方法　B. 原型法　C. 瀑布模型　D. 形式化方法

题号	1	2	3	4	5
答案	B	A	C	B	D
一句话解析	需求规格与可追溯性是 SA 核心交付；A 属架构师，C 属 PM，D 属决策层	①②连考共 240 分钟，③单独 120 分钟；三科须同次全达 45 分，案例 5 选 3	分析阶段产逻辑模型；设计产物理模型，立项产可研，实施产程序	SST = 把组织战略目标集转化为 IS 战略目标集，强调二者一致	业务过程只需”有 C 或 U”；唯一性约束只针对 C

题号	6	7	8	9	10
答案	D	C	A	C	B
一句话解析	OO 完全可用于数据处理密集系统，只是未必最优，”不能”是绝对化错误	可验证 = 有量化指标与条件；A/B/D 均为主观形容词，无法验收	NPV < 0 表示收益折现后低于投入，属经济可行性结论	强合规、重文档、需审计与敏捷价值观冲突，优先计划驱动方法	用户说不清但看得懂 → 用可运行样品激发需求，即原型法（探索型）

八、分档任务（Tailor）

• 保底 45：背熟 3.3 阶段—产出表、3.4 方法对比表、3.5 三法辨析的判定关键词；完成 4.1 全部 5 题与自测 10 题；把 240 分钟分配战术抄在草稿纸上，做真题时强制按表执行。
• 冲 60：加做 GRASPS 三份产出；案例 4.2 的【问题 1】【问题 2】手写完整作答并对照采分点自评、算出自己拿了几分；记忆三个经济公式并各做一道计算题。
• 冲 70：把本项目换成政务或医疗场景重做一次开发方法选型论证（跑一遍 3.4 判定步骤）；用 CSF 为本项目收敛出 3 个关键成功因素及其信息需求，写成一页纸；自命题 3 道综合知识题（含一个错误项陷阱）并写出解析。

九、本阶段回答基本问题

本阶段的主打任务不是回答，而是提出四个贯穿 12 周、且能同时在三科考到的问题（照录总纲表述）：

• Q1（需求） —— 当业务方自己都说不清要什么时，”需求”从哪里来？凭什么说它是对的？
• Q2（架构） —— 在没有唯一最优解的世界里，怎么证明一个架构是”好的”？决策如何被论证？
• Q3（数据） —— 什么时候该严格遵守规范，什么时候该为性能主动打破规范？谁来承担代价？
• Q4（演化） —— 系统上线是终点还是起点？”可维护性”在什么时候买最便宜？

本阶段自身要回答的是：系统分析师到底交付什么？ 立场明确——交付的不是文档，是”可被推翻的判断”。SRS、DFD、用例图只是载体，真正交付三样东西：① 把”实时””能追溯””少花钱”翻译成可度量的质量属性场景；② 在冲突诉求之间做出有理由的选择，并把理由写下来让 CIO 与评审专家能够推翻它；③ 让”验收”这件事在写第一行代码之前就定义好。生产部要实时、质量部要追溯、设备部要低成本——这三者的冲突不靠技术解决，靠权衡并被显式记录。这正是最终交付物里必须有 6 份 ADR 的原因：如果没人说清”为什么否决了方案 B”，那这个架构只是碰巧被选中，不是被论证过。四问的首次正式回答分别在 S02（Q1）、S06（Q2）、S05（Q3）、S08（Q4）。