第 2 周｜主打科目：案例分析 + 综合知识｜对应知识域：软件工程（需求工程）、系统规划与分析｜主打基本问题：Q1 —— 当业务方自己都说不清要什么时，”需求”从哪里来？凭什么说它是对的？｜本阶段产出：需求规格说明书骨架 + 用例清单 + 需求跟踪矩阵
项目宪法与四问表述见 00-课程总纲.md；三科题型与选做策略见 02-考点地图.md。
一、情境开场（Hook）
需求调研第一周，你安排了三场访谈，结果三场都砸了。
生产部长给你画了一张完美的流程图，从投料到入库，十几道工序讲得清清楚楚。你问：”工序之间最长能等多久？”他愣了一下：”看情况。”你追问”看什么情况”，他说：”看夜班还是白班、看前面那台机器堵没堵、看物料齐不齐。”你意识到——他背给你的是制度上墙的那版流程，不是车间里真正发生的事。
第二场，质量部长递过来 47 页 Excel，全是检验项。你问”哪些是客户真正会查的”，她说：”全都重要。”你问”一期只能做 10 个，你选哪 10 个？”她沉默很久，说：”这是你的专业判断，你应该告诉我。”
第三场最麻烦。设备部长根本不谈需求，只谈钱：”你那方案要给每台老设备加装采集模块，一台 8000 块，180 台就是 144 万。这笔钱谁出？”你说可以做抽样采集，他立刻反问：”抽样的追溯链条是断的，出了问题你负责？”——你忽然发现，这句话本该是质量部长问你的，而两位部长现在站在同一条战线上，对着你。
周五复盘，你在本子上写下三行字：① 业务方说的，未必是他们做的；② 业务方要的，未必是他们需要的；③ 业务方列的”全都重要”，等于没列优先级。
于是本周的问题浮出水面：当业务方自己都说不清要什么时，”需求”究竟从哪里来？你凭什么说你写下的那条需求是对的？
二、为什么学这一周（Where & Why）
- 需求的层次与分类：综合知识 2–3 题。它是案例”判断某描述属哪类需求”的直接依据，也是写 SRS 的分节依据。分不清业务需求与用户需求，SRS 就写不成篇。
- 需求获取技术的选型与对比：综合知识 3–4 题，案例高频（”某场景应选哪种获取技术并说明理由”，约 8–12 分）。这是本周最值钱的一块——题干里的场景特征就是答案。
- SRS 的质量特性（七性）：综合知识 2–3 题，且是案例”指出某需求描述存在的问题”的标准答题框架。凡是”系统要快”这类题，扣分点永远落在不可验证。
- 需求优先级方法（MoSCoW / Kano / 价值-风险矩阵）：综合知识 2–4 题，案例常结合”一期范围裁剪”出题。Kano 五类判断是年年考的送分题。
- 需求跟踪矩阵（RTM）与双向追溯：综合知识 1–2 题；它是”变更影响分析”的答案骨架——没有 RTM，你说不出变更波及了谁。
- 需求变更管理与冲突消解：综合知识 2–3 题，案例约 8–10 分，且是论文”信息系统开发及应用”方向最容易写出真实细节的一段。不会写变更流程，论文会显得像没做过项目。
三、核心讲义（Equip）
3.1 需求的层次与分类：先分层，再动手
定义：需求不是平铺的一张清单，而是三层结构。
| 层次 | 含义 | 谁提出 | 本项目例子 |
|---|---|---|---|
| 业务需求（Business Requirement） | 组织为什么要做这个系统 | 高层 / 出资方 | 三年内把客户质量索赔金额降低 30% |
| 用户需求（User Requirement） | 各类用户要借助系统完成什么任务 | 最终用户 / 部门 | 质检员要能按批次号查到该批次的全流程参数 |
| 系统需求（System Requirement） | 系统必须提供的功能与必须满足的约束 | 系统分析师 | 系统应在 3 秒内返回批次追溯链条，覆盖 24 个月历史数据 |
系统需求再分三类：功能需求（系统必须执行的动作）、非功能需求（Non-Functional Requirement, NFR，系统运行表现出的属性：性能、安全性、可用性、可靠性、可修改性、易用性）、设计约束（对实现的硬性限制，不是需求本身，如”必须复用现有 Oracle””18 个月内上线”）。
为什么需要它：分层的目的是让每条需求都能追溯到它的价值来源。追溯不到业务目标的功能需求，就是该被裁掉的需求。
判定步骤：① 这句话说”为什么做””做什么”还是”做得怎样”？② “为什么做”→ 业务需求；”用户要完成什么任务”→ 用户需求；”系统应……”→ 系统需求。③ 系统需求中，描述动作的是功能需求，描述程度的是非功能需求，描述限制的是设计约束。
真题级短例子：”系统应支持 7×24 小时不间断运行”是非功能需求（可用性）；”系统必须在 18 个月内上线”是设计约束（进度约束）；”系统应提供批次追溯查询功能”是功能需求；”降低客户索赔 30%”是业务需求。**”7×24 运行”不是设计约束——它描述运行表现，不是实现限制。**
3.2 需求获取技术：八种武器与选型对照
定义：需求获取（Requirements Elicitation）是通过系统化手段从干系人处获得需求信息的过程。
为什么需要它：答题逻辑只有一条——场景特征决定技术选型。背不如背”哪个技术特征被哪个场景特征激活”。
| 技术 | 适用条件 | 优点 | 缺点 | 本项目落点 |
|---|---|---|---|---|
| 访谈（Interview） | 需深入理解、涉及敏感话题、人数少 | 灵活、可追问、能挖隐性规则 | 耗时、覆盖面小、受主观影响 | 与三位部长深谈，挖真实流程 |
| 问卷调查（Questionnaire） | 用户数量大、分布广，需统计结论 | 成本低、可量化、可匿名 | 无法追问、设计不当易误导、回收率不稳 | 面向 2000 名员工收集痛点 |
| 现场观察 / 民族志（Observation） | 用户说不清自己在做什么，流程性强 | 得到真实行为，能发现制度流程与实际流程的偏差 | 观察者效应、耗时长 | 跟班观察夜班与白班的工序等待 |
| 头脑风暴（Brainstorming） | 需产生大量创意 | 发散、数量多 | 不产生决策，易被强势者主导 | 收集追溯断点的可能成因 |
| 德尔菲法（Delphi） | 专家分歧大，需匿名收敛 | 避免权威影响、可多轮收敛 | 周期长、对专家依赖高 | 估算老设备改造成本区间 |
| JAD 联合应用开发（Joint Application Development） | 多方诉求冲突，需快速达成共识 | 集中决策、周期短、当场解决分歧 | 组织成本高、需专业主持人 | 三方部长 + IT + 高层集中会，定一期范围 |
| 原型法（Prototyping） | 用户看到实物才能表达 | 需求确认快、减少误解 | 见 S01：范围蔓延、架构腐烂 | 报工与追溯查询界面做抛弃型原型 |
| 文档分析（Document Analysis） | 现存系统有完整文档、法规标准明确 | 成本低、可了解历史与合规要求 | 文档常过期，只能反映”应该怎样” | 分析现有 MES 表结构与 47 页检验项 |
判定的五条黄金线索：① “用户多、分布广、要统计“ → 问卷调查；② “用户说不清 / 实际操作与制度不一致“ → 现场观察；③ “多方诉求冲突、需达成共识、时间紧“ → JAD；④ “看到界面才能提意见“ → 原型法；⑤ “专家分歧大、要匿名“ → 德尔菲法。
真题级短例子：”用户分布在 12 个地市共 3000 余人，需了解满意度与改进期望，最经济的获取技术是？” → 问卷调查。若改为”需了解某个关键审批环节的实际判断依据”，则应选访谈。
3.3 需求规格说明书（SRS）：结构与七性
定义：软件需求规格说明书（Software Requirements Specification, SRS）是需求阶段的核心交付物，是开发方与用户方之间的契约性文件，也是验收与测试的依据。
为什么需要它：案例问”验收时用户不认账问题出在哪”，答案几乎永远是”SRS 里没写清”或”需求不可验证”。
SRS 标准结构：1 引言（目的、范围、定义、参考文献）；2 总体描述（产品前景、功能摘要、用户特征、运行环境、设计约束、假设与依赖）；3 具体需求（功能需求、非功能需求、接口需求、数据需求）；4 支持信息（附录、索引、需求跟踪矩阵）。
SRS 的七项质量特性（必背，案例”挑 SRS 毛病”的答题框架）：
| 特性 | 含义 | 违反的典型症状 |
|---|---|---|
| 正确性 Correct | 每条需求真实反映用户意图 | 需求与业务目标相反 |
| 无歧义性 Unambiguous | 每条需求只有一种解释 | “尽快””适当””支持批量”未定义批量大小 |
| 完整性 Complete | 覆盖所有必要需求，含异常与边界 | 只写正常流程，不写异常与失败处理 |
| 一致性 Consistent | 需求之间不冲突 | 一条要求 1 秒响应，另一条要求全量加密留痕 |
| 可验证性 Verifiable | 存在有限、成本可接受的方法判定是否被满足 | “界面美观””操作简便””系统健壮” |
| 可追踪性 Traceable | 可向前追溯到来源、向后追溯到设计/测试 | 出现无人认领的”孤儿需求” |
| 可修改性 Modifiable | 结构良好、冗余少，改动一处不引起连锁修改 | 同一规则在文档里重复出现 7 次 |
判定步骤（案例”指出下列需求描述的问题”）：拿到一句话依次问——有主语吗？有量化指标吗？有前置条件吗？有异常处理吗？与别处冲突吗？有一问答”否”，就是一条不合格需求。
真题级短例子：”系统应具有良好的用户体验。”→ 违反可验证性（无法判定”良好”），且不完整（未定义用户是谁）。改写为：”质检员完成一次批次追溯查询的操作步骤不超过 3 步，从提交到结果展示不超过 3 秒。”
3.4 需求优先级：三种方法的分工
① MoSCoW 方法 —— 按”不做会怎样”分四档：
| 档位 | 含义 | 判定问句 |
|---|---|---|
| M Must have | 必须有，否则一期不能上线 | 不做这条，系统能验收吗？ |
| S Should have | 应该有，不做很难受但可绕过 | 不做能用，但很难用吗？ |
| C Could have | 可以有，有余力就做 | 不做基本没影响吗？ |
| W Won’t have (this time) | 本次不做，明确排除 | —— |
W 的意义常被忽略：把”不做”明确写下来，比写”要做”更能防止范围蔓延。考试问”如何防止范围蔓延”，答”明确 W 清单”是标准得分点。
② Kano 模型 —— 按”满足度—满意度”的非线性关系分五类：
| 类型 | 含义 | 表现 | 本项目例子 |
|---|---|---|---|
| 基本型 Must-be | 没有会极度不满，有了也不加分 | 理所当然 | 报工数据不能丢、批次号不能重复 |
| 期望型 One-dimensional | 做得越好越满意，线性关系 | 竞标比分项 | 查询响应时间（3 秒 → 1 秒 → 0.5 秒） |
| 兴奋型 Attractive | 没有不会不满，有了惊喜 | 差异化 | 自动识别异常工艺参数并提前预警 |
| 无差异 Indifferent | 有没有都一样 | 做了也白做 | 花哨的 3D 车间看板动画 |
| 反向 Reverse | 做了反而不满 | 帮倒忙 | 强制每步操作都弹窗二次确认 |
Kano 四条判定规律：① 基本型优先满足但不必过度投入（超过及格线满意度不再上升）；② 期望型是性价比最高的投入区；③ 兴奋型待基本型与期望型达标后再考虑；④ 无差异需求直接砍掉。
③ 价值—风险矩阵 —— 二维排序，优先级 = 价值 ÷ 风险。四象限执行顺序：高价值低风险（先做）→ 高价值高风险（技术预研/原型验证后再做）→ 低价值低风险（有余力时做）→ 低价值高风险（直接排除）。
三者分工（考试问”用哪个”时的答法）：**Kano 定”值不值得做”，MoSCoW 定”一期做不做”，价值—风险矩阵定”按什么顺序做”**——串联关系，不是三选一。
本项目落点：质量部那 47 个检验项，先用 Kano 分类（破解”全都重要”），再对进入 Must 的项用价值—风险矩阵排序，最后把”兴奋型 + 低价值高风险”的项写进 W 清单并让质量部长签字。让业务方在 W 清单上签字，是范围管理最有效的一招。
3.5 需求验证与需求跟踪矩阵（RTM）
定义：需求验证（Requirements Validation）是确认 SRS 正确、完整地反映用户真实意图的过程——**获取是”得到需求”，验证是”确认需求是对的”**，两者不是一回事。
三种主要验证手段：① 需求评审（Review / Inspection），最正式最常用，分走查（Walkthrough）、审查（Inspection）、技术评审（Technical Review），参与方必须含用户代表、开发方、测试方；② 原型验证，适合界面与流程类需求；③ 测试用例生成——如果一条需求写不出测试用例，它就不合格，这是可验证性的最强检验。
需求跟踪矩阵（Requirements Traceability Matrix, RTM）：
| 需求 ID | 需求描述 | 来源（干系人/业务目标） | 优先级 | 设计元素 | 测试用例 | 变更记录 |
|---|---|---|---|---|---|---|
| BR-01 | 降低客户索赔 30% | 业务需求 / CIO | — | — | — | — |
| UR-03 | 质检员可查批次全链条 | 用户需求 / 质量部 | — | — | — | — |
| SR-12 | 批次追溯查询 ≤ 3 秒 | 系统需求（非功能） | M | 模块 M4 / 索引 IX_BATCH | TC-31, TC-32 | CR-008 |
双向追溯（必考）：前向追溯（需求 → 设计 → 代码 → 测试）用于确认”每条需求都被实现”、防漏做；后向追溯（测试/代码 → 需求）用于确认”每个功能都有需求依据”、防镀金（Gold-plating，做了没人要的功能）。考题问”某功能上线后发现没有需求依据，应通过什么机制发现”→ 后向追溯。
3.6 需求变更管理与冲突消解
定义：需求变更管理（Requirements Change Management）不是阻止变更，而是让变更在受控状态下发生。呼应 EU-5：*”没有变更不代表项目健康，只代表变更被压到了地下。”*
变更控制流程（六步，必背）：① 提出与记录（任何干系人可提出，必须书面申请并登记，口头变更一律不执行）→ ② 变更影响分析（分析对范围、进度、成本、质量、风险及其他需求/工作产品的波及）→ ③ CCB 审批（变更控制委员会 Change Control Board 决策批准/否决/延期，须含用户方与开发方代表）→ ④ 实施变更（更新 SRS、设计、代码、测试，并更新 RTM）→ ⑤ 验证（确认变更正确实施且未引入新问题，回归测试）→ ⑥ 发布与通知（通知全体干系人，更新基线，基线变更必须正式受控）。
变更影响分析应回答的六个问题（案例答案骨架）：① 影响哪些已确定的需求（用 RTM 查）？② 影响哪些设计元素与代码模块？③ 增加多少工作量与成本？④ 如何影响关键路径与总工期？⑤ 是否需追加预算或缩减其他需求（等价交换原则）？⑥ 引入哪些新风险？
冲突消解的五种手法：
| 手法 | 做法 | 本项目例子 |
|---|---|---|
| 协商与妥协 | 双方各让一步 | 实时性从”秒级”降为”关键工序秒级、非关键工序分钟级” |
| 优先级排序 | 用 MoSCoW + 价值风险矩阵定序 | 一期先做追溯，再做实时看板 |
| 原型演示 | 让冲突方看到实际效果再判断 | 用原型让生产部确认”3 秒”可接受 |
| 定量分析 | 用数据把主观争议变客观比较 | 对比”全量加装 144 万/覆盖率 99%”与”关键设备加装 + 其余人工录入 46 万/覆盖率 82%” |
| 高层决策 | 上升到有决策权的层级 | 82% 追溯覆盖率是否可接受，由 CIO 拍板并书面确认 |
关键立场：首选永远是协商 + 定量分析，最后才是高层决策。一上来就上报，等于放弃系统分析师的专业价值；但涉及范围与预算红线，必须及时上升，不能自己扛。
四、典型考法
4.1 综合知识怎么考
题 1：需了解一线工人对现有系统的使用感受，工人分布在 3 个厂区共 2000 余人，且希望得到可统计结论。最适宜的需求获取技术是（ ）。 A. 一对一访谈 B. 问卷调查 C. 现场观察 D. JAD 联合应用开发
答案：B。解析：题干两个关键特征——人数多（2000 余人）、分布广（3 厂区）、要可统计，正是问卷调查的适用条件。A 求深度但覆盖面小；C 适合用户说不清的场景；D 适合多方冲突需快速达成共识。
题 2：下列关于需求层次的说法，正确的是（ ）。 A. “系统应在 3 秒内返回追溯结果”属于业务需求 B. “系统必须在 18 个月内上线”属于设计约束 C. “降低客户索赔 30%”属于系统需求 D. “系统应提供批次追溯查询功能”属于非功能需求
答案：B。解析：工期是典型的设计约束（进度约束）。A 是非功能需求（性能）；C 是业务需求；D 是功能需求。
题 3：根据 Kano 模型，某系统提供了”车间 3D 可视化看板动画”，用户表示”有没有都一样”。该需求属于（ ）。 A. 基本型需求 B. 期望型需求 C. 兴奋型需求 D. 无差异需求
答案：D。解析：无差异需求的特征是具备与否都不影响满意度，应直接砍掉。基本型是”没有极度不满、有了不加分”；期望型是线性；兴奋型是”没有不会不满、有了惊喜”。
题 4：下列关于需求跟踪的说法，错误的是（ ）。 A. 前向追溯用于确认每条需求都被设计与测试覆盖 B. 后向追溯可用于发现”镀金”功能 C. 需求跟踪矩阵只在需求阶段使用，设计完成后即可废弃 D. 变更影响分析需依赖需求跟踪矩阵
答案：C。解析：RTM 是贯穿全生命周期的活文档，需求变更后必须同步更新；设计完成后即废弃会让后续所有变更影响分析失去依据。A、B、D 均正确。
题 5：需求变更控制流程的正确顺序是（ ）。 A. 提出 → CCB 审批 → 影响分析 → 实施 → 验证 → 发布 B. 提出 → 影响分析 → CCB 审批 → 实施 → 验证 → 发布 C. 影响分析 → 提出 → CCB 审批 → 实施 → 发布 → 验证 D. 提出 → 影响分析 → 实施 → CCB 审批 → 验证 → 发布
答案：B。解析：影响分析必须在审批之前——CCB 没有影响分析数据就无法决策，这是最常考的顺序陷阱。D 是”先斩后奏”，违反受控原则。
4.2 案例分析怎么考
【案例题】（共 25 分）
承接本项目情境。调研中出现以下情况：① 生产部坚持所有工位数据必须秒级采集与展示；② 质量部提交 47 项检验项，称”全都重要”，要求全部纳入一期；③ 设备部指出 180 台老设备中部分无标准接口，全部加装采集模块需 144 万元，超出预算；④ 一线工人反映现有系统操作步骤繁琐，但说不清具体应怎么改；⑤ 项目进行到第 4 个月，生产部提出新增”班组长移动端审批”功能，要求 2 个月内上线。
【问题 1】（8 分） 针对情形①—④，分别指出最适宜的需求获取技术并说明理由。 【问题 2】（9 分） 说明应如何对 47 项检验项做优先级排序（方法与步骤），并说明如何处理”全都重要”。 【问题 3】（8 分） 针对第 4 个月提出的”班组长移动端审批”：① 变更控制应遵循的流程（4 分）；② 变更影响分析应包括哪些内容（4 分）。
采分点拆解：问题 1——四种情形各 2 分（技术名 1 + 理由 1），技术名写错则该情形 0 分，理由必须引用题干特征。问题 2——方法选择 2 分（Kano + MoSCoW + 价值风险矩阵，答出 2 个及以上给满），步骤 4 分（每步 1 分），处理”全都重要”2 分，书面确认与 W 清单 1 分。问题 3——① 流程 4 分，六步答全给满，顺序错误扣 2 分；② 影响分析内容 4 分，答出 4 条给满。只写方法名不写思想、三法张冠李戴、选型不写理由，是三种最常见失分。
标准作答范例
【问题 1】 ① 情形①（生产部要求秒级采集）：宜采用现场观察。理由：生产部描述的”秒级”是诉求而非事实，需实地观察各工序实际节拍、采集点与网络条件，才能判断”秒级”在技术与成本上是否必要，避免把主观诉求直接写入 SRS。② 情形②（47 项检验项）：宜采用 JAD 联合应用开发会议（辅以文档分析）。理由：检验项涉及质量部内部及与客户标准的对齐，需召集质量部各岗位、工艺、IT 与高层在主持人引导下集中讨论，一次性达成优先级共识，比分别访谈效率更高、避免反复。③ 情形③（设备改造成本）：宜采用访谈 + 定量分析（成本估算可用德尔菲法）。理由：需向设备部深入了解每台设备的接口类型、改造可行性与费用构成，属需深度挖掘且涉及敏感成本信息的内容。④ 情形④（工人说不清怎么改）：宜采用原型法（探索型）+ 问卷调查。理由：工人说不清但看到实物能指出问题，正是原型法的典型适用条件；同时工人多达 2000 人，用问卷收集痛点可得到可统计结论，二者配合使用。
【问题 2】排序步骤：第一步——用 Kano 分类：请质量部与关键用户对 47 项逐项回答”具备时感受””不具备时感受”，分出基本型、期望型、兴奋型、无差异、反向五类。第二步——剔除与降级：无差异需求直接砍掉，反向需求立即废止，兴奋型本期不纳入、登记入需求池待后续版本。第三步——用 MoSCoW 定档：对剩余项逐项追问”不做能否验收”（M）”可用但很难用”（S）”不做基本无影响”（C），并明确列出 W 清单。第四步——用价值—风险矩阵排序：对 M 档做价值（对追溯完整性的贡献、客户关注度）与风险（技术难度、对工期的影响）二维评估，按高价值低风险 → 高价值高风险 → 低价值低风险 → 低价值高风险安排，其中高价值高风险项先做技术预研或原型验证。第五步——书面确认：把排序结果与 W 清单提交质量部长与 CIO 签字，作为一期范围基线。
如何处理”全都重要”：它等价于没有优先级，成因是把”重要性”与”本期必要性”混为一谈。处理方式有三：① 改变提问方式——不问”重不重要”，而问”不做能否验收””不做能否用其他手段临时替代”；② 强制配额——要求质量部只能选 10 项进入 Must，把排序责任交还业务方，系统分析师只提供方法与后果分析；③ 量化后果——用数据说明”47 项全做”对工期与预算的影响（如需延长 5 个月、追加 80 万），让业务方在等价交换前提下做选择。
【问题 3】① 变更控制流程（六步）：提出与记录——要求生产部提交书面变更申请并登记，口头提出的一律不执行；变更影响分析——由系统分析师会同架构师、项目经理分析波及范围；CCB 审批——变更控制委员会决策批准/否决/延期；实施变更——更新 SRS、设计、代码与测试用例，并同步更新 RTM；验证——执行测试（含回归测试）确认变更正确实现且未引入新问题；发布与通知——通知全体干系人，更新项目基线并正式发布。
② 变更影响分析内容：需求波及——通过 RTM 前向追溯，查明新增需求与哪些已有需求存在依赖或冲突（如与”质检结果不可篡改”的安全要求是否冲突）；设计与代码影响——涉及哪些模块（用户与权限、工作流引擎、消息推送）、是否需新增移动端技术栈；进度影响——是否改变关键路径，对 18 个月总工期与里程碑的影响，是否需顺延或增加人力；成本影响——新增工作量、人力成本与第三方组件费用，是否需追加预算；质量与风险影响——移动端带来的新安全风险（终端丢失、数据泄露、越权审批）与新增测试工作量；范围取舍建议——按等价交换原则提出备选方案（如本期先做移动只读查询、审批延至二期），供 CCB 决策。
五、易错点（Rethink）
| 错误认知 | 为什么错 | 正确理解 |
|---|---|---|
| “用户需求就是用户说出来的需求” | 用户说的是诉求，未必是真需求 | 需求是被构造出来的（EU-1）；用户说的流程常是”制度流程”，需现场观察校验 |
| “头脑风暴可以用来做决策” | 头脑风暴只做发散、不做收敛，且开大会不等于 JAD（JAD 需主持人、议程、会前材料、当场决策机制） | 收敛靠 JAD / 德尔菲 / 优先级矩阵 |
| “Kano 里基本型需求做得越多越好” | 基本型过线后满意度不再上升 | 基本型达标即可；期望型才是性价比最高的投入区 |
| “MoSCoW 的 W 指’以后也不做’” | 忽略 (this time) | W = 本次不做，须登记入需求池并明确触发条件 |
| “优先级用一个方法就够了” | 三法回答不同问题 | Kano 定值不值得做，MoSCoW 定本期做不做，价值风险矩阵定顺序——串联 |
| “RTM 是需求阶段的一次性文档” | 变更后不更新等于废纸 | RTM 是活文档，贯穿全生命周期 |
| “变更影响分析放在 CCB 审批之后” | CCB 无数据无法决策 | 影响分析 → 审批 → 实施是铁序，先斩后奏是典型失分项 |
| “变更越少说明项目管得越好” | 变更被压到地下 | 变更不可避免，受控的变更是健康的（EU-5），口头变更才致命 |
| “‘要快、要易用’可以直接写进 SRS” | 违反可验证性 | 必须改写为带量化指标与条件的场景 |
六、GRASPS 推进（Experience）
本周五前，往交付物「业务需求规格说明书」里加三块内容，总计 1500–2000 字：
- SRS 骨架（约 500 字）：按 3.3 四段结构搭出目录（引言、总体描述、具体需求、支持信息）；在”设计约束”节填入本项目 4 条硬约束：18 个月工期、预算上限、必须兼容现有 Oracle、部分老设备无标准接口。
- 用例清单（约 600 字，不少于 15 条）：表格列出用例编号、用例名、参与者、优先级（MoSCoW 档）、来源（哪个干系人）、备注。必须含至少 3 条 Won’t have 用例，备注写清”为什么本期不做、什么条件下会做”。编号规则与 S04 保持一致。
- RTM 初版（约 400 字，不少于 20 行）：至少建立”业务需求 → 用户需求 → 系统需求”纵向链条 3 组，每组 3–5 行；”设计元素”与”测试用例”两列暂时留空，标注”S04/S05 回填”。
验收标准：SRS 骨架目录能直接对应 3.3 的四段结构，且”设计约束”的 4 条硬约束一字不差地来自情境；用例清单覆盖生产、质量、设备三个部门，且三者数量分布反映其诉求强度；每条 Must 用例都能说出一句话的”不做会怎样”；RTM 中没有任何孤儿需求（每条系统需求都能向上追溯）；至少有一处你能指着说：”这条是我用 Kano 判为无差异、建议砍掉的。”
七、自测
下列属于业务需求的是（ ）。 A. 系统应支持质检员录入检验结果 B. 三年内将客户质量索赔金额降低 30% C. 系统应在 3 秒内返回追溯结果 D. 系统必须兼容现有 Oracle 数据库
适用于”用户说不清自己要什么，但看到实物能指出问题”的获取技术是（ ）。 A. 问卷调查 B. 原型法 C. 文档分析 D. 德尔菲法
需面向 2000 名分布广泛的员工收集痛点并得出可统计结论，宜采用（ ）。 A. 一对一访谈 B. 问卷调查 C. JAD D. 头脑风暴
某需求描述为”系统应具有良好的用户体验”，主要违反 SRS 的哪项特性？（ ） A. 一致性 B. 无歧义性 C. 可验证性 D. 可修改性
根据 Kano 模型，”没有会极度不满，有了也不会更满意”的需求属于（ ）。 A. 基本型 B. 期望型 C. 兴奋型 D. 无差异
MoSCoW 中 W 的正确含义是（ ）。 A. 完全没有价值的需求 B. 本次不做，但明确登记待后续版本 C. 由开发方自行决定是否实现的需求 D. 需求待定，尚未分析
通过从测试用例反向追溯到需求，主要用于发现（ ）。 A. 需求未被实现 B. 镀金功能 C. 需求描述有歧义 D. 需求优先级错误
需求变更流程中，紧接”变更影响分析”之后的步骤是（ ）。 A. 提出变更 B. CCB 审批 C. 实施变更 D. 验证变更
关于需求评审，正确的是（ ）。 A. 只需开发方内部参与 B. 属需求验证活动，目的是确认需求正确完整反映用户意图 C. 有了原型就不需要评审 D. 应在编码完成后进行
多部门诉求冲突且需快速达成共识时，最适宜采用（ ）。 A. JAD 联合应用开发 B. 问卷调查 C. 现场观察 D. 文档分析
| 题号 | 1 | 2 | 3 | 4 | 5 |
|---|---|---|---|---|---|
| 答案 | B | B | B | C | A |
| 一句话解析 | 业务需求回答”组织为什么做”；A 功能需求、C 非功能需求、D 设计约束 | 看到实物才能表达 → 原型法（探索型） | 人多、分布广、要可统计 → 问卷调查 | “良好”无法判定，违反可验证性，同时也违反完整性 | 基本型 = 没有极度不满、有了不加分，达标即可 |
| 题号 | 6 | 7 | 8 | 9 | 10 |
|---|---|---|---|---|---|
| 答案 | B | B | B | B | A |
| 一句话解析 | W = Won’t have (this time)，须登记入需求池并明确触发条件 | 后向追溯找”无需求依据的功能”即镀金；前向追溯找”未实现的需求” | 铁序：提出 → 影响分析 → CCB 审批 → 实施 → 验证 → 发布 | 需求验证 ≠ 需求获取；评审须有用户代表、开发方、测试方参与 | JAD 通过集中会议在主持人引导下一次性解决多方分歧 |
八、分档任务（Tailor）
- 保底 45：背熟 3.1 三层分类的判定问句、3.2 五条黄金线索、3.3 七性表、3.4 Kano 五类、3.6 变更六步；完成 4.1 五题与自测十题，错题回到讲义定位。
- 冲 60：加做 GRASPS 三块产出（SRS 骨架 + 15 条用例清单 + 20 行 RTM）；案例 4.2 的【问题 2】手写完整作答并对照采分点自评；把”全都重要”的处理话术背到能脱口而出。
- 冲 70：把本项目换为医疗场景（医生/护士/医保办三方冲突）重做问题 1 的技术选型；为本项目写一份两页纸变更管理规程（含变更申请单字段、CCB 组成与决策规则、紧急变更绿色通道与事后补审机制）；自命题 3 道案例子问题并写出采分点。
九、本阶段回答基本问题
Q1：当业务方自己都说不清要什么时，”需求”从哪里来？凭什么说它是对的？
第一，需求不是”收集”来的，是”构造”出来的。 业务方说不清不是失职，是常态——生产部长背给你的是上墙的制度流程，不是车间里真正发生的事。系统分析师的价值就在于有一套可复现的构造方法：访谈挖隐性规则、现场观察校验真实行为、问卷拿统计结论、原型激发被压抑的表达、JAD 把冲突摆到桌面上当场收敛。这些技术不是可选项，它们分别对应不同的”说不清”病因。
第二，需求”对不对”不靠业务方认可，靠三重检验。 ① 可验证性——写不出验收测试用例的需求，本身就不合格；② 可追溯性——追溯不到任何业务目标或用户任务的需求，就是该被裁掉的孤儿需求；③ 冲突检验——把需求放进质量属性场景里跑一遍，”1 秒响应”与”全量加密留痕”是否冲突，一跑就现形。业务方的签字是必要的，但不充分：签字只代表认可，不代表正确。
第三，需求正确性的最终保障是”把冲突显式化”。 生产部要实时、质量部要追溯、设备部要低成本，三者冲突不靠技术解决，靠权衡并被书面记录。”全都重要”必须被翻译成一份有 M/S/C/W 的清单并让业务方签字——尤其是 W 清单。这正是 EU-1 的落点：让”验收”这件事在写第一行代码之前就已经定义好。至于这条需求后来变了怎么办，那是 S03（模型层一致性）与 S09（变更控制 + 挣值）要回答的。
