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审批→基线更新全流程综合应用能对一段案例文字按角色→功能→规则→实体→约束五步拆解我在实际带复习时发现一个规律总成绩高的同学往往不是背得最多的而是自测最勤的。每学完一章就拿思考题检验自己错了就回到模型图重新推一遍这比反复抄定义有效得多。就拿包含与扩展来说你背十遍定义不如亲手画一个下单时包含支付余额不足时扩展充值的例子画完就再也不会混淆了。考前如果时间紧优先盯住这张表里得分低于3的格子。复习思考题的意义本来就不是押题而是帮你确认我会了什么、还差什么。把每个盲区补上考场上无论遇到什么描述你手里那套角色拆解→功能抽取→规则摘录→实体识别→约束显性化的稳定流程就是最可靠的安全网。