需求分析考点归类：数据流图、判定表与需求工程六阶段详解

简介面向软件工程及相关专业备考者的需求分析考试题归类PDF文档将分散在教材中的核心概念、常考问答与易混知识点整理为可快速查阅的电子版复习资料。内容覆盖需求分类与相互关系、软件过程分类、需求工程六阶段、软件体系结构、用户界面设计、需求规格说明文档、数据库设计等高频考点并以问答形式给出名词解释与简答题要点适合期末复习、考研专业课巩固或面试前突击。资源为单文件PDF格式共1个文件文件大小约222KB结构紧凑便于PC端或移动端随时翻阅。已有213人下载学习说明其对同类学习者具备实用参考价值。文档后半部分还针对结构化分析方法、数据流图基本符号与绘制要点、数据字典作用等易混淆知识点作了系统梳理可帮助读者快速建立需求分析知识框架减少四处翻教材整理笔记的时间。1. 需求分析考试题归类考题背后都是项目踩坑现场“需求分析”这四个字在软件工程课表里通常不是最难的却是最容易让人翻车的。这份《需求分析考试题归类.pdf》把散落在各章的概念、工具和典型应用题按考点归了类我通读之后最大的感受是它表面上是应付考试的题目集内核却是一套需求分析能力的自查清单。适合三类人准备期末或考研复试的软工专业学生、需要快速补上需求分析概念的转岗开发以及我这种常年被需求变更折腾的一线工程师。因为很多题里的“标准答案”换个场景就是真实项目里踩过的坑。下面我按这份 PDF 的知识组织方式把它拆开讲清楚。2. 先搭概念骨架三类需求、五个过程与需求工程六阶段很多人拿到这类归类资料就直接背名词背完合上 PDF 发现连一个完整问题都答不利索问题就出在概念之间是孤立的。这份 PDF 的高明之处在于它把第一组考点放在“需求分类及其相互关系”上也就是先回答“需求从哪来、分层放哪、最终由谁实现”这其实对应真实项目里 PRD、用例文档和技术方案的三层拆解。2.1 业务需求、用户需求、系统需求三层怎么区分又怎么对上先把定义说准。业务需求反映的是组织机构或客户对系统、产品的高层次目标要求落点文档是项目视图与范围文档用户需求描述用户使用产品必须完成的任务落点文档是用例文档或方案脚本说明系统需求定义开发人员必须实现的软件功能使得用户能完成任务从而满足业务需求。三层是逐级细化和承接的关系不是平级并列的关系。我做过的项目里最容易犯的错是把用户需求直接当成业务需求写到项目章程里。老板说“今年要上一个能提升客户转化率的系统”这是业务需求销售说“我希望能一键生成客户跟进记录”这是用户需求而“系统在录入页面提供跟进记录模板自动关联客户编号与时间戳”才是系统需求。考试题里如果问“某句话属于哪类需求”先用载体判断看它出现在项目视图与范围文档、用例文档还是技术规格说明中。需求类型提问角度常见文档载体验收侧重点业务需求组织为什么要做这个系统项目视图与范围文档是否达成高层业务目标用户需求用户能用它完成什么任务用例文档、方案脚本任务能否被完整执行系统需求开发人员要实现什么功能软件需求规格说明功能实现是否符合约束2.2 五个基本过程软件过程是责任链不是流水账软件过程这一考点PDF 里给了一个必须记住的框架软件过程也称软件生存周期过程是软件生存周期中一系列相关过程过程是活动的集合活动是任务的集合。活动执行方式可以是顺序、迭代、并行、嵌套或有条件引发的。软件过程分三类基本过程、支持过程和组织过程。其中基本过程包含五个获取、供应、开发、运行和维护。把这五个过程放到真实语境里本质上是一条责任链。获取过程是项目委托方做的事确定需求、招标、签订合同、监督供应方、验收完成供应过程是项目承包方做的事理解需求、投标、签订合同、计划、实施、控制、评审评价、交付开发过程是软件开发人员的动作从系统需求分析一路走到系统合格测试和安装运行过程在用户侧包括运行准备、运行测试、产品转移、运行支持和运行评价维护过程解决的是上线之后的问题分析和修改实施以及软件退役。考试答题时注意每个过程的动作列表不需要一字不差背但“哪个角色对应哪个过程”必须分清。比如问到“招标属于什么过程”答案是获取过程而不是供应过程因为招标是委托方动作。实际沟通中我常把“交付”和“验收”连在一起说但在这套标准里交付属于供应过程验收完成属于获取过程这是两个责任主体的动作外包项目里扯皮经常就扯在这两个词上。2.3 需求工程六阶段需求获取到需求管理是一条完整链路需求工程细分为六个阶段需求获取、需求分析与协商、系统建模、需求规约、需求验证和需求管理。这里要特别看清需求获取和需求规约的差异因为不少人在考试和实践中都会把二者混为一谈。需求获取是分析人员通过与用户交流、观察现有系统、分析任务确定系统范围的限制性描述、人员及特征列表、技术环境描述、功能列表、领域限制、应用场景以及为更好定义需求而开发的原型。它的产出物是后面分析的输入。需求规约则是分析任务的最终产物要建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束说明、合适的验收标准最终给出目标软件的各种需求。一句话需求获取是在收集素材需求规约是在形成协议。从项目管理视角看需求规约就是用户和开发者之间的一份契约文档后期的设计、测试、评价全都要参考它。我习惯把需求规约完成当成“需求冻结”的起点而不是项目开工的起点。再看需求工程的另外几个阶段需求分析与协商解决冲突系统建模把需求图形化需求验证确认需求正确完整需求管理则覆盖变更控制——考试如果问你“需求变更应该在哪一阶段处理”答需求管理不是需求获取。3. 结构化分析考点从DFD符号到储蓄系统应用题结构化分析是这份 PDF 分量最重的一块也是实际考试中的大题的集中区域。结构化分析方法本质上是面向数据的分析方法描述工具有四件套数据流图 DFD、数据字典 DD、结构化语言以及判定表、判定树。下面按“工具本身→工具边界→应用题”的顺序拆这也是我建议你的复习顺序。3.1 数据流图的四个基本符号与命名、编号纪律数据流图简称 DFD是 SA 方法中用于表示系统逻辑模型的工具属于功能模型。它用图形方式描绘数据在系统中流动和处理的过程反映系统必须完成的逻辑功能。四个基本符号必须闭眼能画出来符号名称含义→箭头数据流○圆或椭圆加工双杠数据存储□方框数据的源点或终点符号好记真正容易失分的是绘图纪律。PDF 里列了八条注意事项我挑三条最影响得分的说。第一条画数据流而不是控制流。DFD 里箭头表达的是数据从哪来到哪去的流转不是“先做什么后做什么”的时序。第二条每个加工至少有一个输入数据流和一个输出数据流。如果某个加工只有输入没有输出说明它的结果没被表达。第三条父图与子图必须平衡。父图中一个加工被分解成子图时子图的输入输出数据流必须与父图该加工的输入输出一致。编号规则也在这条纪律里。父图的加工编号是 1、2、3子图加工编号是 1.1、1.2、2.1逐层展开。我还见过不少人在图上用中文长句命名数据流比如“经过加工后的数据结果”这既不规范也不利于检查。命名要用名词性短语动词留给加工名。画完图自查一遍每个加工有进有出、每条数据流有名字、每对父子图数据流对得上。注意局部数据存储不用在父图中体现。某些只在子图内部使用的临时存储属于局部数据存储画在子图里即可不必上升到父图否则父图会被数据存储塞满失去层次感。3.2 数据字典四个条目的作用与构建方式数据字典简称 DD用来精确定义数据流图中的各个成分以准确、无二义性的方式为分析、设计、维护提供一致的定义和详细描述。它与 DFD 共同构成系统的逻辑模型是需求规格说明书的主要组成部分。这份 PDF 里明确给出了四个条目数据流、数据项、数据存储、基本加工。数据流条目描述一条数据流内容包括名称、别名、简述、来源、去向、数据流量和组成。数据存储条目描述存储结构内容包括名称、别名、简述、组成和组织方式。数据项条目是组成数据流和数据存储的最小单位。基本加工条目描述加工逻辑包括加工名、编号、激发条件、优先级、输入、输出和加工逻辑。考试里经常给一个“银行储蓄系统”场景要求建立数据字典其实就是按这四个条目把关键对象各写一遍。我在项目里对数据字典的态度是“该较真时必须较真”。需求评审会上产品说“统计报表”开发说“我要知道统计口径”如果数据字典里没有对“余额”的定义两边就吵起来了。考试题里的数据字典看似琐碎但它训练的是同一个习惯把每个数据元素的语义钉死不给歧义留空间。看到这类题目时先列数据流再列数据存储最后补数据项和加工顺序别乱。3.3 描述加工逻辑的三件套结构化语言、判定表、判定树DFD 只能表示系统“做什么”加工内部“怎么做”要靠加工逻辑描述工具结构化语言、判定表和判定树。三者的适用场景不同。结构化语言适合描述顺序和循环逻辑接近伪码但更简洁判定树适合条件分支不多、逻辑关系直观的场景判定表适合条件多、组合多的场景能覆盖所有条件组合不容易漏分支。PDF 里的职工分配工作题是判定表的经典案例。题目给出按年龄、文化程度、性别三个条件组合确定岗位的规则年龄 20 岁及以下且初中文化脱产学习、高中文化当电工20 岁到 40 岁之间且中学文化男性当钳工、女性当车工大学文化当技术员40 岁以上中学文化当材料员、大学文化当技术员。这类题用结构化语言写容易漏掉边界用判定表则一目了然条件/动作1234567891011年龄20√√√————————20年龄40———√√√√√———年龄40————————√√√文化程度中学√——√√———√——文化程度高中—√———√√————文化程度大学——√————√—√—性别男———√—√—————性别女————√—√————脱产学习√当电工√当钳工√√当车工√√当技术员√√√当材料员√填判定表时先列条件取值表把每个条件的取值符号定好再列所有组合最后填动作。这工程看似机械但能逼你把“20 到 40 之间是否包含端点”这种模糊语义暴露出来。考试中我推荐优先用判定表因为阅卷能直观看到你的条件覆盖是否完整代码评审里这也是排查漏判最快的手段。3.4 SA 方法优缺点与 IDEF0为什么实时系统不适合用 DFDSA 方法的优缺点这个考点容易被跳过但我建议当成“工具边界”来记。优点是公认的、有成效的、技术成熟、使用广泛适合数据处理类型软件的需求分析而且用图形等半形式化工具表达需求简明易读为后续设计、测试、评价提供了有利条件。缺点必须记牢传统 SA 主要用于数据处理问题DFD 体现的是功能模型即“做什么”它是静态模型没有反映处理顺序即控制流程所以不适合描述实时控制系统DFD 在分析与描述数据要求方面也有局限它同样不适合描述人机界面系统的要求。为了提升可靠性、安全性、可自动化程度SA 需要与形式化方法结合。IDEF 是美国空军在 1981 年针对集成化计算机辅助制造工程提出的方法基于结构化分析与设计技术发展而来IDEF 是 ICAM Definition 的缩写。IDEF0 的特点有两条一是用方框和箭头等简单图形符号描述系统活动和数据流同时描述活动所受约束及实现机制二是采用严格的自顶向下、逐层分解方式建立系统功能模型。考试问“IDEF0 与 DFD 的区别”你就抓住“约束和机制”这两个关键词。DFD 里没有专门的约束箭头IDEF0 把它显式画出来了这也是我后来做业务流程梳理时更愿意用 IDEF0 的原因DFD 回答数据怎么走IDEF0 回答活动凭什么约束执行。3.5 两道应用大题的解题示范储蓄系统与图书管理系统第三部分末尾是两个完整的应用题适合用来做整章自测。银行储蓄系统要求用 DFD 和 IDEF0 描绘存、取款功能并建立数据字典PDF 中给出了完整的数据字典条目。数据流“存款单”的组成是姓名住址存款类型存款日期利率来源是储户去向是记账数据流“取款单”组成是姓名住址取款类型取款日期利率数据流“清单”组成是姓名住址取款类型取款日期利率余额。数据存储“账单”组成是姓名住址余额存款类型最后修改日期利率。加工条目里有“分类检查”“统计”“记录”三个加工其中统计加工的加工逻辑用结构化语言可以这样表达加工名统计 激发条件接收到取款单 输入取款单 输出清单 加工逻辑 IF 账单中查不到该储户 THEN 输出错误清单 ELSE IF 取款数 余额 THEN 余额 余额 - 取款数 输出清单给储户 输出现金给储户 ELSE 输出错误清单 ENDIF这段结构化语言里输入是取款单输出是清单加工过程中访问数据存储账单。关键参数是“余额”它同时是数据存储字段和取款比较的基准。写这类加工逻辑时注意分支的先后顺序先查储户是否存在再判断余额是否充足顺序反了就会出现“查无此人却提示余额不足”的荒谬结果。图书管理系统则练的是分层 DFD。顶层图是读者、图书管理员与系统的交互系统中的加工可先归纳为借书、还书、查询三个。借书加工展开成子图后要包含检查借书证有效性、查验借书数量是否超过 10 本、检查库存、修改库存目录、登记借书文件这几个子加工。还书加工展开后要包含读取借书记录、判断是否超期 3 个月、罚款处理、修改库存与借书文件。查询加工则要打通借书文件、库存目录文件的读取。画分层图时每个父图加工展开成子图后子图的输入输出要和父图一致否则就违反了父图与子图平衡原则。建议自己先在草稿纸上画一遍再对照 PDF 中的题目描述逐项检查重点看 10 本上限、3 个月超期这两个判定条件落在哪一个加工里。4. 界面、架构与数据库四个容易当成“背题”的考点这一章在考试里通常以简答题出现看起来像是在考记忆实际上每个考点背后都对应一个设计决策。把它们当成背题就亏了因为它们恰好是需求分析阶段就要定的方向。4.1 软件体系结构与 B/S 三层构件视角下的职责划分软件体系结构的定义要抓三个关键词构件、连接、结构。体系结构是具有一定形式的结构化元素的集合包括处理构件、数据构件和连接构件。处理构件负责对数据做加工数据构件是被加工的信息连接构件把体系结构的不同部分组合连接起来。B/S 结构是考试常考的实现方式它的链路是浏览器客户机—WEB 服务器—数据库服务器。B/S 的考点在于三层各自的职责。客户机只需安装浏览器软件无须开发前端应用程序这是 B/S 与 C/S 最大的差异中间层的 Web 应用服务器承担主要的数据计算和应用逻辑所以对中间层服务器的性能要求较高后台数据库服务器主要完成数据的管理。我在实际部署中判断瓶颈也是按这个思路来用户反馈慢先看是浏览器端渲染慢、中间层服务耗时长还是数据库查询慢三层各看各的指标。答这题如果你能补一句“中间层的计算压力是关键约束”会比只罗列结构多得一分。4.2 用户界面设计三部分结构、交互、视觉的递进关系用户界面设计在工作流程上分为结构设计、交互设计、视觉设计三个部分。结构设计也叫概念设计是界面设计的骨架通过对用户研究和任务分析制定产品整体架构常用纸质低保真原型做用户测试并完善其中目录体系的逻辑分类和语词定义是用户能否理解和操作的重要前提。交互设计的目的是让产品能被用户简单使用任何产品功能都是通过人机交互完成的所以人的因素要作为设计核心。视觉设计则是参照目标群体的心理模型和任务达成来设计包括色彩、字体、页面目标是让用户愉悦使用。这三个部分不是并列的三个工种而是先后递进的三个阶段。评审时顺序也固定先确认信息架构对不对再确认操作路径顺不顺最后才聊颜色和字体。有人一上来就让 UI 出高保真图信息架构还没定返工是必然。考试里如果给一个登录页面让你分析设计任务就按“结构上入口是否清晰、交互上操作步骤是否最短、视觉上是否匹配用户心理模型”三层回答。4.3 数据库设计的内容与常用方法静态模型与动态模型的分界数据库设计包含结构设计和行为设计。结构设计指根据给定应用环境进行数据库模式或子模式的设计包括概念设计、逻辑设计和物理设计。数据库模式是各应用程序共享的结构是静态的、稳定的一旦形成通常不容易改变所以结构设计又称静态模型设计。行为设计指确定数据库用户的行为和动作即用户对数据库的操作这些通过应用程序实现用户行为会使数据库内容发生变化所以行为设计是动态的又称动态模型设计。这里理解的关键是“动静之分”。结构设计回答表怎么建、关系怎么定、索引怎么设行为设计回答业务操作怎么通过 SQL 和事务改变数据。考试问“数据库设计的内容”只答“建表”是拿不全分的必须同时写结构设计和行为设计两条线。常用设计方法有直观设计法、规范设计法、计算机辅助设计法和自动化设计法看到选项能对应上即可。项目实践中我习惯先做概念模型即 ER 图再做逻辑模型转成表结构最后在物理设计阶段考虑索引和存储参数行为设计部分则跟着用例走一个用例对应一组数据操作。4.4 需求规格说明的表现手段从自然语言到 BNF需求规格说明文档的作者是涉众用户他们是验证人。表现手段分成两档半形式化用结构化文本也就是伪码或结构化英语形式化用形式化语言即 BNF 这类数学语言。考试常问“形式化方法和半形式化方法各有什么优缺点”答案的关键是精确性与可读性的权衡。半形式化的结构化英语接近自然语言用户容易参与验证但存在一定的歧义空间。BNF 语法精确、无二义性适合描述语言类或协议类需求但用户读不懂。需求分析里我一般这样取舍业务规则用结构化英语写让产品和用户能评审凡是涉及报文格式、配置文件的语法定义用 BNF 写死防止前后端对字段格式理解不一致。如果你能在答题时提到“涉众是验证人而不是作者”这题的分数基本稳了因为这句话点出了需求规格说明的验证关系写出来的文档最终要由涉众来确认它是否反映了真实需求。5. 避坑注意五类翻车现场与对应的排查方法这章的每条坑要么来自考试现场的高频失分点要么来自我接手过的真实项目里的血泪经验。建议你把这五条当成自检清单每完成一版 DFD、每答一道大题都拿它过一遍。5.1 边界条件写漏年龄判断少了等于号现象做职工分配题时把条件写成“20年龄40”输出结果里 20 岁和 40 岁的人落到了错误的岗位分支真实项目里则表现为“3 个月内免罚”的界限日期算错超期一天没罚款。原因口语里说“20 到 40 之间”语义上不明确是否包含端点直接翻译成伪码就产生开闭区间歧义。解决写任何区间条件前先列条件取值表把“20、20 且 40、40”这种边界显式写出来。PDF 里的条件取值表就是标准做法年龄取值明确为 C、D、E 三档再据此填判定表就不会漏。5.2 把 DFD 画成了流程图现象给储蓄系统画 DFD 时把“先收到存款单、再判断类型、然后记账、最后打印”画成一条顺序箭头还在加工之间加了 IF 分支图里出现了“存款单已打印”这种描述动作完成状态的数据流。原因DFD 是数据流图不是控制流图。箭头只表达数据流动方向加工只表达数据处理位置不表达时间先后和条件分支。解决把控制逻辑从图中剥离放到加工逻辑描述里。DFD 中只保留“存款单从储户流向分类检查加工再从分类检查流向记账加工”这类数据流动关系“如果是存款单则做什么”的控制逻辑用结构化语言或判定表写在加工内部。5.3 父图与子图不平衡导致评审对不上现象顶层 DFD 里“借书”是一个加工展开子图后出现了“检查证号、检查数量、修改库存、登记借书文件”四个子加工但子图的输入输出和父图的输入输出对不上顶层的借书加工没有独立的“拒绝借书”输出子图却多出几条。原因画子图时只想着往下拆功能忘了父图与子图平衡原则。子图是父图加工的细化输入输出必须一致多一条少一条都是错的。解决拆子图前先写父图加工的数据流清单展开后逐个核对。子图新增的加工编号按父图编号扩展父图加工 1 的子加工就是 1.1、1.2。检查顺序固定为先核对输入数据流再核对输出数据流最后看存储是否有局部存储误提升到父图。5.4 IDEF0 和 DFD 的建模视角混用现象答题时把 IDEF0 画成了 DFD只有数据流箭头和数据存储没有约束和机制箭头或者在描述 IDEF0 时说“它和图 DFD 一样都是画数据流动的”把两者的核心差异丢了。原因两种图形符号部分相似但 IDEF0 的关键特征是显式表达活动所受的约束及实现机制以及严格的自顶向下逐层分解。DFD 强调数据流动IDEF0 强调活动在约束下如何执行。解决看到“约束、机制、自顶向下逐层分解”这些关键词就答 IDEF0。IDEF0 图中活动框上方的箭头是约束下方的箭头是机制左侧是输入右侧是输出。画完检查是否每个活动框都有约束是否写清了输入、输出、约束、机制四个方向的箭头如果没有说明没真正用 IDEF0。5.5 把需求规约当成需求获取现象问“需求规约的任务是什么”答“和用户沟通、访谈、了解用户想要什么”把两个阶段的功能搞混。原因六个阶段名称相近“获取”和“规约”在字面上都像收集需求实际上一前一后一个是采集素材一个是产出协议。解决需求获取的产出物是范围描述、人员列表、技术环境描述、功能列表、应用场景等素材需求规约的产出物是完整的信息描述、功能行为描述、性能需求、设计约束和验收标准它是用户和开发者之间的协议。答题时只要看到“最终产物”“协议”“验收标准”这些词就应该定位到需求规约而不是需求获取。6. 把归类 PDF 变成考点索引判定表法与分层 DFD 练习顺序拿到这份归类 PDF最忌讳的是当成“考前背诵小抄”一页一页翻完就放着了。我建议你第一遍先按它的顺序读建立知识框架第二遍按“概念—工具—场景”做一张自己的映射表第三遍只练应用题把储蓄系统和图书管理系统各画三遍每次画完对照避坑清单检查。三遍走完这份资料才算真正变成你的能力索引。我最想让你练透两个具体技巧。第一个是判定表解题法。凡遇到“不同条件组合产生不同结果”的题目不管它是分配工作、计算折扣还是设置权限都先在草稿上写条件取值表再列组合最后填动作。这样能保证条件覆盖完整边界不漏。第二个是分层 DFD 练习顺序。先画顶层上下文图只画一个系统框和外部实体再画 0 层图把顶层系统框展开为主加工然后逐层往下展开。每层展开后立刻核对父图子图平衡不要等整张图画完再检查否则返工成本高。我自己的教训是有个项目上线前才发现“删除”和“归档”被当成同一个需求写进了系统需求导致数据不可恢复。从那以后我每次拿到需求文档都强制走一遍“需求分类—数据流建模—数据字典定义—规约评审”的检查顺序把这份 PDF 里的题目当成每周一次的自测工具。希望帮到你。本文还有配套的精品资源点击获取