需求分析复习核心：从用例图到SRS的建模思维与高频考点解析-平芜编程栈

1. 需求分析复习困在哪：从"背概念"到"会建模"的思维转换

每到复习周，我见过太多同学抱着《需求分析》教材从头翻到尾，把术语定义抄了一遍又一遍，结果拿到卷子还是不知道从哪落笔。原因很简单：需求分析这门课，本质上考的不是"记住多少名词"，而是"面对一个模糊的诉求，你有没有能力把它变成清晰、可验证的系统行为描述"。这个能力拆开看，就是需求获取、需求建模、需求规格编写、需求验证与变更管理这几条线。

先说一个反直觉的事实：**考试里丢分最狠的，往往不是最后一道综合分析题，而是第一道填空或名词解释之后的建模小题。**因为大家普遍以为"用例图谁不会画"，但真把一段文字描述扔过来，主语是谁、边界在哪、包含关系和扩展关系怎么区分，全都会露出马脚。这和真实项目里的情形一模一样——客户描述得越口语化，建模时越容易跑偏。

这篇文章不打算给你列一份"背诵版知识点清单"，而是以复习思考题的方式，把需求分析的核心骨架重新串一遍。每一节后面我都会附上典型的思考题、答题框架和易错点，有些地方会直接给出示例答案的思路。我自己当年复习时踩过不少坑，这篇就当是一份带路标的复习地图，适合刚学完课程准备期末考的同学，也适合工作后需要补需求分析基本功的开发者。

复习之前，先给自己做一个定位：你是把"需求分析"当作一项技能在练，还是把它当成一门要应付的课？如果答案是前者，下面这些内容的含金量会高很多；如果是后者，至少也能帮你把高频考点稳妥拿住。接下来我们从需求获取开始，这是整条链路的起点，也是大多数项目栽跟头的地方。

2. 需求获取的工具箱与提问陷阱：访谈提纲怎么写才不会被人带着跑

2.1 五种主流获取方法各自的适用边界

需求获取是整个需求工程的第一阶段，也是决定后续建模质量的上游环节。教材里通常会讲访谈、问卷调查、观察、原型法、文档分析这几种方法，但考试不会只考"有什么方法"，而是考"这个场景该选哪种方法、为什么"。比如下面这道典型的思考题：

某高校要开发一款校园失物招领小程序，目标用户是全校学生和保卫处管理人员。请设计需求获取方案，说明你选择每种方法的理由。

这道题的高分答题逻辑是"分层获取"：先文档分析，把现有的失物招领登记表、校园卡挂失流程、线下招领点的运作规则全部摸清，这属于基线调研；再用问卷面向学生群体做大规模偏好收集，比如"你丢了东西第一时间会去哪里找""你希望收到什么样的推送通知"，问卷适合摸清这类分布型需求；紧接着挑8到10个真实丢过东西的学生做深度访谈，了解他们当时的情绪路径和行为细节，这是问卷拿不到的场景故事；最后快速做一个纸面原型或可点击的低保真原型，找一小批人试用，用于验证需求理解是否到位。

这道题里最容易犯的错误是：只写"用问卷调查"，不写调查谁、问什么、数据怎么用。阅卷老师想看到的是你对每种方法成本和产出有清醒认知。观察法（跟班式观察用户操作）在这道题里可以作为补充手段，用于发现用户自己都没意识到的习惯性行为，比如登记时总要先拍一张照片再写描述；原型法适合需求模糊时快速对齐预期，也适合验证界面层面的交互需求。

再补一个冷门考点：获取方法的组合原则叫"三角验证"——同一个需求点至少用两种独立的方法交叉确认，不能单一信源拍板。复习时可以问自己：三角验证和我在问卷里设置两道重复题有什么本质区别？前者是跨方法的信息比对，后者是同方法内的信度检验，两者层次不一样。

2.2 访谈提纲的三种问题类型与一个反问技巧

访谈是笔试里出现频率最高的需求获取题型，通常以"请你设计一份访谈提纲"的形式出现。很多人把访谈提纲写成了问卷清单，全是封闭式问题："你希望系统支持Android吗？"——这完全是用错了工具。访谈的独特价值在于开放性和追问空间，不是统计选项。

一份合格的访谈提纲应该包含三部分：开场问题（营造氛围、了解背景）、过渡问题（由浅入深引入核心话题）、核心与深层问题（直击痛点和期望）。举个例子，如果访谈对象是教务处的排课管理员，开场可以问"您能先介绍一下一个学期排课大概要经历哪些环节吗"，这是让对方打开话匣子的安全区；过渡问题可以是"上一次排课过程中，您觉得最占精力的是哪一步"；核心问题才是"如果有一套辅助排课系统，您最希望它帮您解决什么、哪些工作您绝对不希望被自动化"。

这里我要特别强调一个容易漏掉的反问技巧：访谈结束前，务必问一句"我理解得对吗"式的确认题。比如"我刚才听下来，排课冲突检查是目前最大的痛点，如果需要系统在检查前先让您确认规则的优先级，这样做OK吗？"这种问题的价值在于，它能把隐藏的误解在第一时间暴露出来。我实际做项目时，好几次都是靠这句话发现用户嘴上说的"冲突"和我理解的"冲突"根本不是一回事——他指的是教师时间冲突，我想的却是教室资源冲突。

复习提示：这道题的答题框架就是"背景了解—流程还原—痛点挖掘—期望确认—优先级排序"五层。每一层给一个示例问题，分数基本就稳了。

2.3 获取过程中的三类"伪需求"识别

复习思考题里经常出现一类案例分析，要求从一段对话中找出"伪需求"。所谓伪需求，不是用户撒谎，而是用户在描述中无意带入了自己的预设方案，掩盖了真实目标。最常见的三类是这样的：

第一类是解决方案型伪需求："我希望有一个按钮，点一下就能自动生成周报。"按钮是方案，自动生成周报也是方案，真正的需求是"我每周要花两小时汇总数据，希望减少这部分工作"。识别的方法是追问一句"你生成周报是为了给谁看、看完要做什么决定"，往回退到目标层。

第二类是惯性型伪需求："我们以前都是月底统一对账，系统也要按这个来。"惯性需求不一定错，但值得验证——如果业务可以用日清日结对账，月底统一是否还必要？这类伪需求要去问"这个规则的业务约束是什么"，不要在系统层面直接复制旧流程。

第三类是少数极端型伪需求："最好支持同时一千人在线抢课。"要考虑的是这个并发峰值是否真实存在、出现频率如何、能否通过排队机制化解，而不是直接照单全收。面对这类需求，正确姿势是给用户展示"支持1000并发"意味着多大的成本，让用户对需求的优先级重新排序。

答题技巧：识别伪需求后，一定要写"如何验证"。比如通过观察法看用户是不是真的每次都需要自动周报，或者用原型让用户在真实数据上走一遍流程，让他自己意识到有些"需求"其实是想象出来的。

3. 需求建模的重灾区：用例图、类图、DFD到底怎么分工

3.1 用例图的三个高频错误：把顺序当关系、把功能当角色、把流程当边界

需求建模是考试的核心区，也是项目实战中最见功力的部分。最常见的建模工具是用例图，但恰恰是它，错误率最高。先说最经典的三个错误，这是我改过不少学生作业和小组成员建模后的总结，每个都是真实踩坑。

**错误一：把系统与用户的交互顺序画进用例图。**用例图表达的是"参与者通过系统达成什么目标"，它不表达步骤先后。我看到有同学把"用户登录—系统验证—进入主页"画成三个用例串起来，这完全错了。登录确实是一个用例，但它背后是"身份认证"这个目标；"进入主页"根本不是一个有效目标，而是系统的导航行为。用例的粒度应该以"参与者可感知的、有完整价值的服务"为准，比如"提交失物招领信息""搜索失物""认领失物"。

错误二：把系统内部功能当成用例。"数据库自动备份""计算推荐权重"这些是系统内部行为，不是用例。判断标准很简单：用例前面能不能加上"作为XX角色，我希望系统支持我……"。比如"作为管理员，我希望系统支持我查看招领率统计"，这个能说通；"作为管理员，我希望系统支持我自动备份数据库"，正常人不会这么说，所以它不是用例。

**错误三：角色的边界画错了。**如果失物招领小程序里保卫处既能审核信息，又能发布公告，那这是不是同一个角色？不能因为"同一个人做两件事"就合并成一个角色，要看他在两个场景中是否扮演不同的系统交互者身份。更规范的做法是引入"actor generalization"（参与者泛化），比如基础用户和高级用户两个角色之间有继承关系，但继承的是权限，不是人物的自然属性。

复习时可以练一道思考题：把"在线考试系统"用一段话描述出来，涵盖学生参加考试、教师出卷、管理员管理题库，然后画出用例图，对照标准答案检查每个用例是否满足"完整目标"标准。这道题练完，法案里最难的用例图基本就拿下了。

3.2 类图不是数据库表结构：从业务概念到数据模型的思维转换

很多有数据库基础的同学画类图时，第一反应是"这个对应一张表，那个对应一张表"，把类图画成了物理表设计。这犯了需求分析阶段的定位错误——类图在分析阶段的价值是表达业务概念及其关系，不是表结构设计。

举个例子，"订单"类里要不要写"order_id BIGINT PRIMARY KEY AUTO_INCREMENT"这个属性？不要。分析阶段的类属性应该写业务属性，比如"订单状态（待支付/已支付/已发货/已完成）""下单时间""实付金额"。主键、外键、索引这些是设计阶段的事。考试里如果给你一段需求文字要求画类图，你需要提取的是：有哪些业务实体（学生、课程、选课记录）、它们之间的关系和多重度（一个学生可以选多门课，一门课可以被多个学生选，多对多）、每个实体的关键业务属性。

还有一个常考的知识点是泛化与组合的区别。"教职工"派生出"教师"和"行政人员"，这是is-a关系，用泛化；"订单"包含"订单明细"，没有明细订单就没有意义，这是has-a中的组合关系（实心菱形），而"订单"关联"客户"则是普通的聚合/关联关系（空心菱形或不加菱形）。这些符号差别，考试时确实是送分题，也是送命题，符号画错一个扣一分，很亏。

实战中我见过最典型的错误，是把"用户—角色"画成组合关系，实际上"用户拥有角色，角色可以独立存在（比如先定义角色再分配给用户)），所以这是普通关联，不是组合。复习时可以画一个"图书馆管理系统"的类图，特别留心图书、读者、借阅记录三者之间的关系多重度，借阅记录要不要作为独立类存在，答案是要——因为借阅行为有"借出时间、应还时间、实际归还时间"这些独立属性。

3.3 DFD的分层原则与平衡规则：为什么说它是必考计算题

数据流图（DFD）在不少学校的考纲里已经弱化了，但它依然是"需求分析"这门课里逻辑最严谨的建模工具，而且特别适合出应用题和判断题。DFD的复习要点有三个：分层原则、图元规则、平衡检查。

分层原则是自顶向下逐层分解：顶层图（上下文图）只有一个加工，代表整个系统，画出所有外部实体与系统的数据流；中层图把顶层加工分解成若干子加工，同时画出内部数据存储；底层图继续分解到"加工不可再分"为止，每一个加工对应一段足够的业务逻辑。判断"是否可以再分"的标准是：加工的描述是否可以用一两句话说清楚，如果说不清就需要分解。

图元规则里最常考的坑是：数据流必须是名词性数据，不能是控制信号。"开始按钮被按下"是控制流，不是数据流；"检查库存状态"是加工动作，也不是数据流。另外，数据存储与外部实体之间不能直接画数据流，必须先经过加工；两个外部实体之间也不能直接画数据流，信息交换必须通过系统。这些"禁画"规则，考试时经常以改错题的形式出现。

平衡规则是DFD的"计算题"：父图中某个加工的生数据流，必须等于子图中对应加工的全部输入输出数据流的并集。比如父图中"处理订单"加工有输入"订单信息"、输出"发货单"和"库存变更"，那子图里分解出的三个子加工，所有输入数据流加起来必须恰好是"订单信息"，所有输出加起来必须恰好是"发货单"和"库存变更"，多一条少一条都叫不平衡。复习时找一张两层的DFD图，自己动手核对一遍平衡，比背十遍定义都管用。

4. 需求规格说明书（SRS）的黄金结构与验收标准：从"写得全"到"写得能测"

4.1 SRS的章节骨架与每个部分的功能定位

需求分析的最后产出物是需求规格说明书（SRS），这也是不少复习思考题大题的命题素材：要么给你一段残缺的SRS让你补全，要么给你一段需求描述让你写出对应章节的内容。很多同学考前背了IEEE 830的目录，但背目录不等于会写内容，关键要理解每个章节在整份文档里承担什么职责。

完整的SRS通常包含这些部分：引言（编写目的、项目范围、定义、参考资料）、总体描述（产品视角、用户特征、运行环境、约束与假设）、功能需求（按功能模块划分，每块列出编号需求条目）、外部接口需求（用户界面、硬件接口、软件接口、通信接口）、非功能需求（性能、安全、可用性、可维护性）、其他需求（数据管理、法律法规等）。考试中如果要求你从零编写目录，你至少要能一层层写到位，不要只写到二级标题就算完。

以"在线考试系统"为例，功能需求部分应该这样组织：考生管理（考生注册、考生登录、参加考试、查看成绩）、试题库管理（试题录入、试题分类、试题审核）、组卷管理（手工组卷、随机组卷、按知识点权重组卷）、考试过程控制（考试计时、自动交卷、防作弊策略）、成绩管理（自动判分、成绩导出、成绩分析报告）。每个功能条目编号，比如FR-1.1、FR-1.2，为后面追溯提供锚点。

非功能需求这块是大题的高发区。性能需求要尽量量化：系统支持同时在线考试人数不少于500人；普通页面响应时间不超过3秒；成绩报表生成时间不超过10秒。安全需求要具体：密码存储必须使用加盐哈希；考生登录连续错误5次后锁定账号15分钟；所有操作日志保留不少于180天。可用性需求可以从学习成本入手：新考生无需培训即可在5分钟内完成首场考试操作。可维护性需求可以写模块化要求：核心业务模块的变更不应影响其他模块，单模块平均故障修复时间不超过2小时。

这些数字不是拍脑袋写出来的，它们的依据来自用户访谈与项目约束。考试答题时如果题目没有给数字，你可以合理假设并说明假设条件，比如"假设并发峰值以课程结束前三天冲刺阶段为准"——写上假设这是一步加分的"显性化思考"，阅卷老师最怕的就是你写"系统性能要好"这种不可验证的废话。

4.2 怎样判断一条需求写得好不好：原子性、可验证性与唯一编号

复习思考题里有一种高频题型：给你一份SRS，让你找出其中的问题需求条目，并说明理由。这种题的得分关键是掌握三条质量标准：原子性、可验证性、无歧义。

原子性指一条需求只表达一个可独立验证的行为。"系统应支持考生考试，并提供试题管理功能"这句话就不是原子需求，它把两个模块的功能揉在一句话里，应该拆成两条。可验证性指需求必须可以被测试确认。"系统应为考生提供良好的界面体验"不可验证，"系统操作页面的常用功能应在2次点击内可达"就可验证。无歧义指不同读者对同一句话的理解应该一致，避免"快速""高效""友好"这类程度形容词，改用可量化的描述。

同时还要注意唯一编号与来源追溯。SRS里每条需求都要有编号，并且最好标注来源（如"来自访谈记录编号IN-2024-03-01"或"来自问卷调查项Q12"）。这对应的是需求追溯矩阵：需求溯源到来源，测试用例溯源到需求。复习时自己动手做一个5行3列的小追溯矩阵，建一个"需求编号｜来源｜测试用例编号"的表，比单纯背概念有用得多。

这里分享一个我实际写SRS时养成的习惯：写完每一条需求，我会在脑子里问自己一句——"如果给我这条需求和一台电脑，我怎么测它到底实现了没有？"想不出测试方法的需求，说明写得还不到位。这个习惯放到考试里同样适用，它几乎可以救治所有"虚胖型需求条目"。

4.3 引用一个经典案例：某在线考试系统SRS片段点评

为了让你更直观地看到"写得全"和"写得能测"之间的差距，我取一个虚构的考试系统SRS片段，做一版现场点评。

原始写法：

系统应保证考试过程中数据不丢失，并确保考生不能作弊。

问题诊断： "数据不丢失"没有定义丢失的尺度，是掉落一条记录不行，还是丢1%也接受？"不能作弊"没有定义防作弊的策略范围，是禁止复制粘贴，还是需要人脸识别？两条都不可验证。

改进写法：

系统应具备考试数据的实时保存能力：考生每答完一道题应立即自动保存答案，单题保存时间不超过500毫秒；若客户端在答题中途异常退出，考生重新进入后可恢复到最近一次已保存的答题进度，恢复误差不超过1题。
系统应具备基本的防作弊机制：考试页面在考试期间禁用右键和文本复制功能；同时系统应记录考生切换出考试页面的时间与次数（离开页面时间累计超过30秒即写入风控记录），供监考教师事后查看。

对比一下就能发现，改进版的每条都可以设计对应的测试用例：模拟异常退出后检查答题进度；尝试复制文本看是否被拦截；切换页面后检查风控记录是否产生。这才是"可验证"的SRS。复习时你可以随手拿一份自己的项目文档做同样手术，练三篇之后写大题的思路会清晰很多。

5. 需求验证与变更管理的情景题：评审、验证方法和变更控制委员会

5.1 需求验证的四种手段，以及它们在考试中的典型问法

需求验证是评审SRS质量的关键环节，教材里常讲的方法有四种：需求评审（同行评审）、原型化（通过演示原型验证需求理解）、测试用例设计（针对每条需求设计验收测试）、仿真或建模验证（用形式化方法或仿真模型验证关键算法/逻辑）。复习思考题通常这样考：给出一段需求描述，问"你会选择哪些验证手段，为什么？"

答题思路要按"验证目标"来匹配。如果是要确认需求是否完整反映了用户意图，首选需求评审加原型演示，尤其原型对非技术背景的用户非常友好；如果是要检查需求内部是否自洽（比如某条规则在A场景和B场景下是否矛盾），适合用建模验证，比如活动图或状态图推演；如果是要在开发前就预估测试工作量，可以提前为每条需求写测试用例，用例写不出来的需求必然有问题。

这里有一个容易忽略的细节：小组评审中常见的"需求走查"和"正式评审"是有区别的。走查是非正式的，通常由作者主讲、组员提问，目的是发现明显缺陷；正式评审有独立的评审组、明确角色分工（作者、评审员、记录员）和决策机制（通过、修改后通过、不通过）。考试时如果问你"评审流程中应该包含哪些角色和环节"，要按正式评审的框架回答，并把每个角色的职责写清楚。

5.2 变更管理全流程：从变更请求到影响分析，再到基线更新

需求变更在考试里多以案例分析题出现。我给你一个非常经典的情景，几乎每届都会考到：

某外卖平台的订单管理系统已通过需求评审进入开发阶段，此时业务方提出新增"订单定时送达"功能，要求用户在下单时可指定未来某个时间点送达。请描述变更管理的完整流程，并分析该变更可能的影响范围。

完整答题框架包括五步。第一步是变更提出与记录：填写变更请求（CR），写明变更内容、提出人、提出时间、业务理由。第二步是变更影响分析（这是最重要的得分点）：影响分析要从功能、数据、接口、进度、成本五个维度展开——功能上要在下单流程增加定时送达选项；数据上订单表需要增加"期望送达时间"字段、商户/骑手侧需要额外的任务调度逻辑；接口上用户端、商户端、骑手端的三端接口都要变更；进度上如果开发已过半，可能影响原定上线时间；成本上需要评估排期和测试资源。第三步是变更决策：提交给变更控制委员会（CCB）审批，决策结果有批准、拒绝、延期三种。第四步是更新文档：如果批准变更，同步更新SRS、需求追溯矩阵、开发计划、测试计划，确保下游拿到的都是最新基线。第五步是变更验证：新增的测试用例覆盖"定时送达"的完整链路，回归测试确保原有下单流程不受影响。

答题时如果写不了这么细，至少要把"影响分析"这一环写透。很多同学回答变更管理时只写"提出变更→领导审批→修改需求"三步，这种答案拿不到高分。一份高质量的答例应该突出：变更为什么不能由需求分析师一个人拍板——因为需求变更的影响可能波及开发、测试、运营多个团队，必须有一个跨职能的决策机制来平衡各方利益。

这里补充一个真实项目的教训：我们做过一个后台系统，曾经收到一个看似很小的变更请求——"把报表导出格式从CSV改成Excel"。开发组评估工作量"只要半天"，就顺手改了，结果没有走变更流程。后来下游的自动化数据流转脚本全部解析失败，才意识到CSV文件是被另一个数据平台自动读取的，"小变更"变成了"大事故"。所以我个人经验是：但凡涉及对外接口或数据格式的变更，无论改变的工作量大小，都必须进入正式的变更评估流程，至少在影响分析里过一遍。

5.3 需求基线：为什么说"冻结需求"是伪命题

需求基线是复习时很容易被一句话带过的概念，但它是变更管理的基石。基线（baseline）指的是某一时点上被正式评审并通过的SRS版本，它是后续开发、测试和变更评估的参照基准。所谓"冻结需求"并不是说需求不能再变，而是说变更必须从基线出发走受控流程。

这个区别写在试卷上就是一道判断题："需求一经评审通过，就应完全冻结，不得再做任何修改。"答案是错。需求冻结的真正含义是"基线的建立"——基线的意义是让所有团队成员对'当前该做什么'有一致理解，而不是封锁一切变化。只要变更走完评估、审批流程，基线就可以更新到新版本。

复习这一节时，最有效的办法是自己画一条"基线演进时间轴"：V1.0评审通过→V1.0.1（小的文字修正，不影响设计）→V1.1（新增定时送达功能，涉及范围调整）→V1.2（删减某个低频功能，风险重新评估），每个版本的变化都对应一次CCB决策。时间轴画完，你对变更管理和基线的理解就不再是名词记忆，而是有了动态的画面。

6. 高频复习思考题自测清单：按题型攻克的实战操练

6.1 概念辨析题——最容易混淆的5组名词对照

这类题通常是填空题、判断题或简答题，考查对核心定义的精确把握。我把历届高频、最容易混淆的5组术语做成了对照表，复习时可以拿来自检。

易混术语	核心区别	一句话记忆法
功能性需求 VS 非功能性需求	功能关注"系统做什么"，非功能关注"做得怎么样"	"登录"是功能，"3秒内完成登录"是非功能
业务需求 VS 用户需求 VS 系统需求	业务需求从组织层面描述为什么做，用户需求从用户视角描述想做什么，系统需求是系统的可实施描述	业务需求回答"为什么"，用户需求回答"要什么"，系统需求回答"怎么做"
用例 VS 用户故事	用例面向完整目标且有前置/后置条件和主成功场景；用户故事是"角色+需求+价值"的简短描述，强调对话启动	用例是"剧本"，用户故事是"便签"
包含关系 VS 扩展关系	包含（include）是被调用的公共步骤，如"在线支付"被多个用例包含；扩展（extend）是特定条件下的可选行为，如"余额不足时转到充值"	包含是"必须的公共步骤"，扩展是"可选的补充"
验证（Verification） VS 确认（Validation）	验证是"做对了没有"（对照规格），确认是"做的是不是想要的"（对照用户预期）	验证是"按图纸造房子"，确认是"房子是不是你想要的那个"

复习建议：不要只背左边一列的定义，要把右边一列自己复述一遍。比如拿"包含关系vs扩展关系"举一个新例子，能做到这个程度，概念题基本就稳了。

6.2 建模应用题——两条必练的综合建模题及参考思路

综合建模题是考试分值的大头，通常给一段业务描述，要求画用例图和类图（有时还有DFD或状态图）。这类题没有唯一的"标准答案"，但有明确的评分点。下面给出两道习题与参考建模思路，你可以先自己画一遍再对照。

**题目一：校园图书共享平台。**描述：学生可以在平台发布自己的闲置图书，也可以浏览其他学生发布的图书并申请借阅；图书所有者收到借阅申请后可以同意或拒绝；如果同意，双方约定线下交接；系统记录借阅状态；学生可以评价借阅经历；管理员负责审核违规内容。

参考用例图思路：参与者包括学生、管理员两个角色。用例可以整理为：发布图书、浏览图书、搜索图书、申请借阅、处理借阅申请（同意/拒绝）、确认借阅完成、评价借阅、管理举报内容。特别注意"申请借阅"和"处理借阅申请"是两个不同参与者的不同用例，不要合并成一个。另外可以把"登录/注册"作为系统用例，但不建议把"线下交接"画成系统用例——它发生在系统外，可以用注释标注。

参考类图思路：实体类包括用户（User）、图书（Book）、借阅记录（BorrowRecord）、评价（Review）、举报（Report）。用户与图书是"发布"关系，一对多；用户与借阅记录有"申请方"与"所有者"两个关联，多重度理解上有难度，建议画两个关联并标注角色名；图书与借阅记录是一对多，借阅记录作为独立类记录借出时间、归还时间、状态；用户对图书可以写多条评价，评价类有评分和内容属性。这个模型能将需求里的主要概念都cover住。

**题目二：某社区团购系统。**描述：团长创建团购活动，设定起购人数和截止时间；用户浏览活动并下单购买，达到起购人数后团购成功，未达到则自动退款；订单支付、配送由第三方物流完成；平台管理员可以查看所有活动的统计报表。

参考建模要点：用例图要区分普通用户与团长，可考虑用参与者泛化；"发起团购""参与团购""查看团购统计"是核心用例。类图重点处理"团购活动（GroupBuyActivity）"与"订单（Order）"的关系，以及"退款"是否建模为独立状态还是订单的一个状态——参考答案是状态，设计成订单状态的合法转换而不是独立类。

6.3 案例改编题——遇到全文字案时按什么顺序拆解

案例题喜欢给一篇长文字描述，要求先用需求获取方法，再建模，再写SRS，甚至再加变更管理。遇到这种全文字案题，我强烈建议按"五步拆解法"进考场：

第一步，标出所有用户角色。把文字中的"学生""教师""教务处""管理员"全圈出来，每个角色对应后续的参与者分析。第二步，用行为动词定位功能需求。圈出"发布""申请""审核""统计"这类动词，每个动词大概率对应一个功能模块或一个用例。第三步，识别业务规则与约束。比如"起购人数必须大于5""申请需在24小时内处理"，这些要单独摘出来，它们是SRS里的约束条款和验收标准。第四步，识别数据实体与关系。把名词实体圈出来，判断彼此关系，为类图做准备。第五步，补非功能需求与技术约束。文字里提到的"并发量""响应速度""数据安全"等暗示都要显性化。

这个拆法看着慢，实际在做题时效率非常高，因为它把"阅读长文"变成"信息抽取"，不容易漏点。我给自己学生做模拟时发现，用这个顺序答题的同学，建模遗漏项明显少于那些读完一遍就上手画图的人。

6.4 辨析纠错题——常见的八种"似是而非"表述

这类题给出一组陈述，让你判断对错并说明理由。我把历届考试和真实评审中出现率最高的八种"似是而非"汇总一下，每条都用一句话给出判断与理由：

"画用例图时，系统与外部系统的交互不算用例。"——错。外部系统可以扮演参与者，与系统交互同样可以构成用例，比如"调用第三方支付接口完成支付"。
"数据流图中的数据流向必须经过加工，不能在两个存储之间直接画。"——对。数据不会自己从一个存储跑到另一个存储，迁移逻辑必须由加工完成。
"用例之间的extend关系表示可选分支，这个分支一定不会影响主流程的成功结果。"——不对。扩展分支可能让主流程以不同结果结束，比如"支付失败转其他支付方式"，最终结果仍是成功支付，但路径不同。
"SRS只需要写开发需要知道的内容，测试人员不需要看。"——错。SRS是开发和测试的共同基准，测试用例的设计依据就是SRS。
"需求获取时，用户说出来的需求一定是真实需求。"——错。用户描述可能混入预设方案、惯性思维或遗忘约束，需要通过三角验证来交叉确认。
"非功能需求优先级一定低于功能需求。"——错。比如金融系统的安全需求优先级远高于部分功能需求，优先级取决于系统性质。
"需求变更越少，项目一定越成功。"——不一定。需求变更数量受业务环境变化影响，关键不是"多少"，而是"是否全部受控、有记录、有影响分析"。
"需求分析阶段结束了，需求管理就可以停止。"——错。需求管理贯穿整个生命周期，开发过程中仍可能出现变更、歧义、新增依赖，需求分析师需要持续参与。

这类题的答题模式是"判断+理由+举例"三段式，判对判错只是第一步，理由要给足，最好补一个具体的例子。比如第4条，举例说"如果测试人员不读SRS，就不知道怎么设计'考试计时'的测试用例，更无法判断实现是否符合预期"，理由一下子就有血有肉了。

6.5 冲刺阶段的复习路线图与一个自我评分表

最后给一份冲刺阶段的自测评分表，适合考前两三天用来查漏补缺。你需要诚实打分：每一项1到5分（5=很熟练，1=完全不会），低于3分的内容就是考前必须补的盲区。

复习维度	自测点	得分（1-5）
需求获取	能根据场景选择合适的需求获取方法并说明理由
需求获取	能设计一份分层的访谈提纲并包含确认性反问
需求建模	能正确区分用例的包含关系与扩展关系
需求建模	能把业务描述转化为类图并正确标注多重度
需求建模	能检查DFD分层图是否满足平衡规则
SRS编写	能写出功能需求与非功能需求的具体条目并保证可验证
需求验证	能解释Verification与Validation的区别并各举一例
变更管理	能完整描述变更请求→影响分析→CCB审批→基线更新全流程
综合应用	能对一段案例文字按"角色→功能→规则→实体→约束"五步拆解