软件工程里有一句老话需求阶段犯的错误越到后面修起来越贵。这句话我真正理解是在做课程设计答辩的时候——代码跑通了老师问你这个功能当初是谁提的需求优先级怎么定的我一愣发现自己根本答不上来。因为整个项目我都在赶代码需求分析那一节完全是套模板糊弄过去的。也就是从那时起我才回头把《软件工程——实践者的研究方法》第八章理解需求认真啃了一遍。这一章的特点很反常识概念多、流程多、图也多但偏偏没有一行能跑起来验证的代码。你觉得自己听懂了一到期末卷子或者课设文档上就露馅。作为过来人我强烈建议所有正在复习软工期末、准备课程设计或者毕业设计需求分析部分的同学把这章当成全书的逻辑枢纽来学——后面所有设计、测试、维护内容本质都是围绕需求真正被理解了没有展开的。这篇笔记我不按教材目录平铺只挑重难点讲需求工程七个活动怎么串成一条线、需求分类有哪些坑、分析建模三种视角的区别、用例和行为模型到底怎么用、需求验证与优先级在考试里以什么形式出现最后附上期末和课设里的高频陷阱速查。不管你是哪个学校只要考到软件工程范围基本跑不出这些东西。1. 需求工程七个活动不是流程背诵而是一条问题排查链Pressman把需求工程拆成七个过程活动起始Inception、导出Elicitation、精化Elaboration、协商Negotiation、规格说明Specification、确认Validation、需求管理Requirements Management。这个名单几乎是期末简答题的固定考点但只背名字没意义你必须把它们理解成一条从不知道要做什么 → 搞清楚要做什么 → 把结果锁住的链条。1.1 起始与导出先搞清楚为谁做、值不值得做起始阶段的重点不是收集功能而是回答三个前置问题系统为谁服务业务目标是什么这个项目值不值得启动很多同学一上来就写系统需要登录、需要管理用户顺序就错了。起始阶段要做的是识别涉众Stakeholders——不只是用户还包括客户、领域专家、运营人员、维护人员、甚至法务他们的立场可能完全不同。还要做初步评估项目的范围边界在哪技术上和经济上是否可行。这块在考试里常以选择或简答出现问你需求工程第一步是什么答案是建立项目根基而不是直接问用户要功能。导出才是真正接触用户需求的活动但导出不等于采访。Pressman特别强调多种获取技术配合使用协作式需求收集工作坊、深度访谈、问卷调查、场景分析、原型演示、观察用户真实工作过程等。我当年复习时容易忽略的是观察法——你以为用户会主动说出全部操作流程实际上大量业务知识是隐性的用户自己都说不清楚。所以访谈设计得很关键多用开放式问题引导比如如果这个功能不做你们现在最痛苦的是哪一步少问封闭式问题还要准备顶层问题来控制访谈节奏不要让用户跑题到某个技术实现细节里去。提示期末如果考需求获取方法不要只答访谈一个词尽量答出访谈、问卷、观察、工作坊、原型法等多个方法并用并能说明各适合什么场景。1.2 精化与协商把冲突变成排序精化阶段的目标是把起始和导出阶段收集到的模糊声明逐步转化为可供决策的模型。也就是说从这里开始需求从一句话愿望变成可分析的用例和模型。很多学生在这里又开始着急画图其实精化的核心动作是逐层分解从高层业务目标一层层拆到用户需求、系统需求。每一层的表述都必须可确认、可验证。协商是这七个活动里最容易被低估的一个。现实中需求冲突根本不是例外而是常态业务方要全自动化合规部门坚持保留人工审批产品经理要丰富功能开发评估后表示工期翻倍。所谓协商不是开一次会让大家投票而是基于商业价值、实现成本、技术风险和依赖关系对需求做取舍与排序。Pressman书中给出的协商要点包括识别冲突、达成一致、优先级排序、寻找折中方案。这中间必须有主持人、有记录、有结论输出。考试里常给你一段两个干系人意见相左的场景问你下一步应该怎么做——正确答案不是按领导说的办而是组织需求协商评估冲突项的价值与代价形成优先级共识。1.3 规格说明与管理文档不是终点变更才是规格说明就是把协商后的需求写成正式文档最典型的是软件需求规格说明SRS。要注意需求是有层次的用户需求业务人员能看懂的自然语言描述和系统需求足够详细、能被设计开发直接使用的描述是两个不同粒度。考试里偶尔会专门考系统需求特性比如完整性、一致性、可验证性、无歧义、可追踪性、可行性——这些词也是后续需求验证的基础别只当一套说法背要能拿具体需求例子判断它合不合格。需求管理则是处理变。唯一不变的就是需求一直在变这是软件工程的铁律。管理手段包括建立需求基线Baseline、需求追踪矩阵、变更控制流程、影响分析。在敏捷环境下这个活动落到产品待办列表Product Backlog上其实就是需求优先级排序和持续更新的体现。做课设时很多组第六周就宣布需求分析完成之后数据库字段一改再改本质就是需求管理缺位——没有基线没有变更评估改需求全凭某个人的一时兴起。这部分的简答题常考为什么需求必须管理标准思路是需求变更会影响估算、进度、设计、测试如果没有受控的变更流程项目会越改越乱、成本失控。2. 功能需求、非功能需求与领域需求分类是容易考、也最容易混淆的第一关需求分类是第八章里最基础、但也是最容易丢分的知识点。Pressman体系里常见的分类维度是功能需求、非功能需求和领域需求三类。很多同学觉得这个太简单了结果一考判断题就翻车——因为你以为系统应支持扫码登录是非功能需求实际上它是功能需求而系统应保证用户密码在传输过程中加密反而属于非功能需求。2.1 功能需求的边界该怎么划功能需求描述的是系统做什么给定什么输入产生什么输出执行什么行为。难点在粒度写得太粗变成模块名比如系统应管理订单完全无法指导设计和测试写得太细又变成实现细节比如系统应使用HashMap存储用户数据把设计决策提前塞进了需求层。一个合格的功能需求陈述应该包含行为主体、触发条件、输入、输出和业务规则。举个例子当管理员点击『批量导入』按钮并上传CSV文件时系统应逐行校验数据若某行不合法则跳过该行并在结果报告中记录原因——这才叫一条能指导后续开发的描述。考试常见出题方式是给你一句话让你判断是不是合格的功能需求或者让你把一句模糊描述改写清楚。练习题多做几道手感就出来了。还有一个高频易错点登录认证算不算非功能需求正确答案是要看你怎么描述。功能部分是系统应允许用户通过账号密码登录验证通过后进入主界面而系统应采用加密协议保护登录过程中的口令传输属于安全相关的非功能需求。判断标准很简单这个需求描述的是行为还是约束行为如何表现2.2 非功能需求与FURPS没有量化就没有意义非功能需求描述系统做得怎么样它约束的是性能、安全、可用性、可靠性等一系列质量属性。Pressman里常常提到FURPS这个需求分类框架由五个维度和一组附加约束组成类别含义典型示例FFunctionality功能与特性系统支持在线支付、支持多角色权限UUsability易用性与用户体验新用户能在5分钟内完成首次下单RReliability可靠性与容错系统年可用率不低于99.9%故障恢复不超过30分钟PPerformance性能指标20个并发用户下订单查询响应时间小于3秒SSupportability可维护性与可扩展性系统支持日志采集和远程告警Constraints约束条件必须部署在国产操作系统上必须满足数据合规要求考试里经常给一条需求问它属于FURPS中的哪一类。这里面最经典的陷阱是系统应运行流畅——这不是合格的非功能需求因为它没有量化指标。改写成系统在1000条订单记录范围内查询响应时间不超过2秒才算合格。另外可用性Usability和易用性Ease of Use也容易混可用性更偏用户在多大效率上能完成目标而单纯说界面友好是没有验收标准的考试你要能指出这个描述不可验证。2.3 领域需求最容易被忽略的需求类别领域需求来自应用领域自身的规则往往没有任何用户会专门提出来但系统不满足它就无法在行业里落地。比如银行系统的复式记账规则、电商系统按收货地区计算税率的规则、医疗系统对电子病历保存年限的合规要求。这些规则是领域专家默认你应该知道的知识教科书和通用需求模板里不会写。正因为领域需求隐晦需求导出阶段才必须引入领域专家和真实业务场景。做课程设计和毕业设计时我特别想提醒你选题时选一个自己真的熟悉的领域比选一个听起来高大上的领域重要得多。比如你做过社团管理就做社团活动管理平台你在实验室帮老师管过设备就做设备借用系统。因为你对这个领域的隐性规则天然有感知需求分析才能写出别人抄不出来的内容。反过来一上来就做智能养老平台智慧校园系统领域需求全靠编文档一深问就崩。3. 分析建模三件套数据模型、DFD与类模型的定位区别第八章理解需求里Pressman花了相当篇幅讲构建需求模型虽然完整的模型技术分散在后续章节但期末命题经常把需求分析和需求建模合并考。你要清楚一件事任何单一模型都无法描述一个软件系统完整的需求分析必须同时覆盖数据视角、流程视角和类/对象视角。3.1 数据模型业务视角的实体联系图数据模型描述业务中的核心数据对象及其关系核心概念是实体Entity、属性Attribute、关系Relationship、基数Cardinality和参与性Modality。注意需求阶段画ER图是业务视角不是数据库设计所以别急着标主键、外键和范式这些是实现细节。举个例子图书管理系统的读者借书关系实体是读者和图书关系是借阅一个读者可借多本图书一本图书同一时刻只能被一个读者借出这就是基数。参与性要说清可选的还是强制的读者可以一本书都不借可选参与但一条借阅记录必须关联一个读者和一个图书强制参与。这些在课设答辩时是老师最爱追着问的点特别是基数方向容易画反。还有一个考试爱考的细节递归关系。比如员工–员工一个员工管理多个下属员工一个员工只归属一个上级。这类一元关系很多同学画不出来或者画出来方向错。建议做题时先确定关系两端各是什么角色再填基数。3.2 数据流图DFD从上下文图开始逐层分解数据流图的核心元素只有四种外部实体、加工过程、数据流、数据存储。它的价值在于不依赖任何技术实现方式就能跟业务人员确认数据在系统里是怎么流动的。画DFD必须从上下文图Level 0开始把整个系统画成一个加工外部实体通过数据流与它交互一眼看清系统边界。Level 1 再把这个加工分解成主要子功能Level 2 继续细化。这里有两个高频考点一个是父子图平衡规则——父图中某个加工的所有输入输出流必须在子图中完整保留、不能多也不能少。另一个是命名规范——加工用动词名词验证登录、生成报表数据流和数据存储用名词用户信息、订单记录。有些同学图便宜把加工命名为数据处理等于没命名答辩肯定被追问。DFD和用例图的关系也经常考用例图面向用户视角表达谁能用系统做什么强调场景和目标DFD面向数据视角表达数据经过哪里的处理变成什么强调流动路径。两者互补不是重复。3.3 类模型与CRC卡靠角色扮演找出来的分析类面向类的模型从业务概念出发识别出候选类、属性、操作以及类之间的关系。需求阶段不要求写出完整的方法签名重点是搞清楚哪些名词值得作为类进入后续设计。我特别推荐大家掌握CRC卡类-责任-协作者这个方法因为它是应付课设需求分析时非常好用的头脑风暴工具。操作方式是把课堂或小组会议要讨论的类写在卡片顶部左栏写这个类的责任它知道什么、做什么右栏写为了完成责任需要跟谁协作。然后拿着典型业务场景比如读者借书一步步做场景走查这张卡片的类此时有没有责任如果发现负载过重或完全闲着就说明职责分配有问题。走查几个场景之后缺失的类自然就浮现出来了。类关系的考试重点是关联Association、聚合Aggregation和组合Composition三者区分。简单粗暴的判定口诀组合是同生共死的强归属订单被删除订单明细必须删除聚合是整体与部分但可独立存在班级和学生的生命周期不必一致关联则是普通的认识关系学生使用图书馆。考题常给几个类让你判断关系类型先定是否强归属再定是否共享生命周期基本不会错。4. 用例模型和行为模型一个给业务看一个给设计看如果数据流图和类图是静态视角那动态行为就得靠用例、状态图和顺序图来补。这几种模型在复习时特别容易混我建议用一个简单框架去记用例给业务干系人讲故事逻辑状态图给单个对象秀生命周期顺序图给一场协作画时间线。4.1 用例从业务目标倒推而不是罗列功能用例模型的核心不是画一个椭圆带几条线而是写清楚参与者和系统交互的完整流程。规范用例应包含参与者Actor、前置条件、后置条件、主成功场景、扩展场景备选流和业务规则。写用例最常犯的错有三个一是把参与者写成用户这种泛指没有区分普通用户和管理员导致权限逻辑不清二是把主场景写成二十多步的操作说明书被细节淹没了目标三是把用例名字写成数据管理这种无行为的话。比如管理员登录系统后点击新增图书、填写信息、点保存这不是好用例好用例是管理员新增一本图书系统校验ISBN唯一性成功后库存信息即时可见。前者是操作步骤后者才是业务目标。注意用例的粒度控制在一个参与者通过系统完成一个有价值的业务目标即可登录可能不是独立用例而是其他用例的前置条件。考试若让你给某个系统画用例图先用一句话概括核心目标再倒推出那3~5个最核心的用例别贪多。4.2 状态图单个对象的完整生命周期状态图描述一个对象从创建到销毁经历哪些稳定状态、哪些事件触发状态迁移。关键概念是状态State、事件Event、动作Action和守卫条件Guard Condition。拿订单对象举例稳定的状态可能是待支付、已支付、待发货、已发货、已完成、已取消。这里的坑在于很多人把已支付当成状态——其实支付成功是一个事件事件发生后订单进入的状态才是待发货或已支付取决于你怎么建模。另外状态图上的迁移必须写触发事件和可选守卫条件守卫条件就是布尔表达式比如仅当订单已支付且库存充足时订单才能进入待发货状态。考试里判断状态图还是顺序图最常出错我的判断顺序是题目里只有一个类/对象在变化且关注它处于什么阶段 → 状态图题目里有多个对象在发消息协作关注先后顺序 → 顺序图。4.3 顺序图多个对象在一次交互中的协作顺序顺序图的作用是把用例中的主成功场景从一个抽象目标细化成哪个对象向哪个对象发消息的协作过程。元素包括对象生命线、激活条、消息箭头和返回消息。画顺序图常见的失败姿势是把它画成干巴巴的步骤流程图——竖线不是流程框而是对象生命线箭头不是命令而是消息。你要先确认这个场景里到底有哪些对象参与了再给每个对象画一条生命线。比如新增图书的顺序图可能涉及管理员界面对象、图书管理控制对象、图书数据对象、校验服务对象消息从界面层一路传到数据层再逐层返回结果。在需求分析阶段顺序图最大的作用是帮你检查职责分配是否合理如果某个对象被发了很多消息、承担了所有逻辑说明类的设计有问题如果用例场景里写到了但顺序图里找不到对应消息说明分析漏了需求。把用例和顺序图对照着看很多漏洞一眼就暴露了。5. 需求验证与优先级排序考前必须掌握的评审清单需求分析做完不等于需求正确。Pressman明确把需求确认和后续的开发活动分开强调在动手设计之前必须对需求进行系统化评审。这个环节在考试里通常以判断题或简答题出现在课设答辩里则是老师考察你有没有真思考的切入口。5.1 需求验证要查这六项需求验证的核心检查项是正确性、完整性、一致性、无歧义、可验证性、可追踪性。实际上还要加一个可行性。考试如果给你一条需求让你判断问题出在哪你基本就按这六项去套检查项含义坏例子 → 好例子正确性需求是否反映真实业务目标系统应该让用户点赞 → 系统应允许已登录用户对他人发布的帖子点赞且同一用户对同一帖子只能点赞一次完整性是否遗漏场景或边界只写支持上传图片不写图片大小限制 → 补充单张图片不超过5MB支持jpg/png格式一致性多条需求之间是否冲突一个需求说所有操作在2秒内完成另一个需求说上传视频并转码 → 需拆分场景、设置不同性能指标无歧义每个读者理解是否一致系统应尽快处理数据 → 系统在1000条记录范围内导入时间不超过5秒可验证性有没有办法验收界面要美观 → 系统应通过可用性测试新用户无需培训即可完成下单流程可追踪性能否追溯到来源与后续产物每个需求都有编号、来源、对应的设计模块和测试用例其中无歧义和可验证性最常连在一起考。你只需要记住一句话凡是用了高效友好快速稳定这类形容词却没有任何量化指标的需求在软件工程意义上都是不合格需求。5.2 优先级排序别让所有干系人都全都要需求协商阶段输出的就是一份排好优先级的需求清单。日常项目里最简单实用的排序工具是MoSCoW法则Must必须有、Should应该有、Could可以有、Wont这次不做。考试里会让你对一组需求做MoSCoW划分或者让你从业务价值、实现成本、风险、依赖关系四个维度解释为什么某需求排得靠前。排优先级最难的不是排序这个动作而是顶住全都要的压力。我见过的成功做法是把每个需求做成一张小卡片上面写业务价值高/中/低、实现成本人天估算、技术风险高/中/低、依赖关系被谁依赖、依赖谁开会时所有卡片摆桌上让干系人自己在成本约束下做取舍。一旦把这个功能好不好换成这个功能值不值冲突就好化解了。课设里老师问为什么先做A不做B你就回答因为A是核心业务流程的Must需求B是用户管理里的Should需求且B依赖A的数据库结构所以排后——这个回答本身就体现了需求协商和管理意识。5.3 可追踪矩阵与变更影响分析需求追踪矩阵Requirements Traceability MatrixRTM是需求管理最常用的手段本质是一张需求–来源–设计–测试–状态的对照表。它的意义是出现变更时你知道这条需求动了受影响的代码模块和测试用例是哪几个。需求编号需求描述来源设计模块测试用例状态REQ-001管理员可批量导入图书教务科业务访谈Module: BookImportTC-001, TC-002已实现REQ-002导入数据超过1000条时给出分页预览教务科业务访谈Module: BookImportTC-003待开发变更影响分析就是基于这张表做扩散分析改REQ-001只接口和测试用例要不要跟着改要不要重新估算工作量这个流程看似官僚但在课设和实际项目里都是保命工具。很多小组后期越改越乱就是因为没有一个表能回答这次改动到底影响谁。6. 期末与课设高频陷阱一张速查表治好背了就忘最后这部分是复习冲刺用的。前面讲了原理和流程这里把最容易考、最容易错的点压缩成速查表可以直接用来做考前最后一遍过。6.1 高频混淆概念对照表易混概念判定关键记忆锚点功能需求 vs 非功能需求描述做什么还是做得怎么样登录行为功能密码加密传输非功能用户需求 vs 系统需求能不能被非技术人员读懂业务语言 vs 开发可用的精确描述用例图 vs DFD用户目标视角 vs 数据流动视角用例重角色和目标DFD重加工和数据流状态图 vs 顺序图单个对象的生命周期 vs 多个对象的协作看研究对象数量聚合 vs 组合部分能否脱离整体独立存在组合更强调整体控制部分生命周期需求验证 vs 测试活动验证发生在设计前测试发生在编码后验证的是需求的正确性测试是实现与需求的符合度6.2 课设/毕设场景里最容易被问倒的三句话第一句是你的非功能需求写了什么如果你答系统运行流畅、界面美观基本等于没答。正确做法是把非功能需求写成可验证指标比如系统在20个并发用户操作下核心查询接口的响应时间小于3秒第二句是为什么先做这个模块这说明老师想看你的优先级判断你要能讲清楚这个模块是核心业务流程的Must需求且被其他模块依赖第三句是这个需求从哪来的这是在问需求来源和可追踪性凡是说不出来源的需求都值得怀疑。提示做课设需求分析时建议用一页纸把干系人列表、核心用例清单、需求优先级、追踪矩阵四项列清楚。这张纸在答辩时比几十页复制粘贴的模板更能说明你真的理解了需求。6.3 复习路线建议如果备考时间紧我建议走两轮。第一轮先按需求工程七活动把流程串起来再分别攻需求分类、分析建模、行为建模、需求验证四个知识点块每块画一张概念图不要求背但要求能对着图讲清楚每个概念之间的关系。第二轮专门做需求改写题随便找几条模糊需求比如系统要支持快速查询用参考六项检查项和FURPS框架改写成合格表述。这种题型对口教材考试和软考都非常常见练10条这种题比单纯背概念有用得多。另外提醒一点这一章和后面的需求建模设计工程衔接非常紧复习时顺便把DFD和用例图多画两遍后面课设能省大量时间。我个人做课设栽过跟头也带过几届学弟学妹做毕设发现一个很朴素的规律凡是动手写代码前能花一周时间把需求真正想清楚、写成可验证用例并排好优先级的组后期几乎不会出现推倒重来凡是拿到题目就开数据库建表的组大概率在中后期陷入改字段、改逻辑、加需求的泥潭。关于理解需求这一章我个人操作里最有用的一个小技巧是第一周先别急着画任何正式图只用一句话回答谁在什么场景下要通过系统完成什么目标解决什么痛点。这句话如果写不顺说明你对需求的理解还没到位——后面所有用例、DFD、类图都只是这句话的展开而已。把这个句子磨清楚了第八章你才算真正过关。 软件工程之理解需求：需求工程、用例建模与优先级实战
软件工程里有一句老话需求阶段犯的错误越到后面修起来越贵。这句话我真正理解是在做课程设计答辩的时候——代码跑通了老师问你这个功能当初是谁提的需求优先级怎么定的我一愣发现自己根本答不上来。因为整个项目我都在赶代码需求分析那一节完全是套模板糊弄过去的。也就是从那时起我才回头把《软件工程——实践者的研究方法》第八章理解需求认真啃了一遍。这一章的特点很反常识概念多、流程多、图也多但偏偏没有一行能跑起来验证的代码。你觉得自己听懂了一到期末卷子或者课设文档上就露馅。作为过来人我强烈建议所有正在复习软工期末、准备课程设计或者毕业设计需求分析部分的同学把这章当成全书的逻辑枢纽来学——后面所有设计、测试、维护内容本质都是围绕需求真正被理解了没有展开的。这篇笔记我不按教材目录平铺只挑重难点讲需求工程七个活动怎么串成一条线、需求分类有哪些坑、分析建模三种视角的区别、用例和行为模型到底怎么用、需求验证与优先级在考试里以什么形式出现最后附上期末和课设里的高频陷阱速查。不管你是哪个学校只要考到软件工程范围基本跑不出这些东西。1. 需求工程七个活动不是流程背诵而是一条问题排查链Pressman把需求工程拆成七个过程活动起始Inception、导出Elicitation、精化Elaboration、协商Negotiation、规格说明Specification、确认Validation、需求管理Requirements Management。这个名单几乎是期末简答题的固定考点但只背名字没意义你必须把它们理解成一条从不知道要做什么 → 搞清楚要做什么 → 把结果锁住的链条。1.1 起始与导出先搞清楚为谁做、值不值得做起始阶段的重点不是收集功能而是回答三个前置问题系统为谁服务业务目标是什么这个项目值不值得启动很多同学一上来就写系统需要登录、需要管理用户顺序就错了。起始阶段要做的是识别涉众Stakeholders——不只是用户还包括客户、领域专家、运营人员、维护人员、甚至法务他们的立场可能完全不同。还要做初步评估项目的范围边界在哪技术上和经济上是否可行。这块在考试里常以选择或简答出现问你需求工程第一步是什么答案是建立项目根基而不是直接问用户要功能。导出才是真正接触用户需求的活动但导出不等于采访。Pressman特别强调多种获取技术配合使用协作式需求收集工作坊、深度访谈、问卷调查、场景分析、原型演示、观察用户真实工作过程等。我当年复习时容易忽略的是观察法——你以为用户会主动说出全部操作流程实际上大量业务知识是隐性的用户自己都说不清楚。所以访谈设计得很关键多用开放式问题引导比如如果这个功能不做你们现在最痛苦的是哪一步少问封闭式问题还要准备顶层问题来控制访谈节奏不要让用户跑题到某个技术实现细节里去。提示期末如果考需求获取方法不要只答访谈一个词尽量答出访谈、问卷、观察、工作坊、原型法等多个方法并用并能说明各适合什么场景。1.2 精化与协商把冲突变成排序精化阶段的目标是把起始和导出阶段收集到的模糊声明逐步转化为可供决策的模型。也就是说从这里开始需求从一句话愿望变成可分析的用例和模型。很多学生在这里又开始着急画图其实精化的核心动作是逐层分解从高层业务目标一层层拆到用户需求、系统需求。每一层的表述都必须可确认、可验证。协商是这七个活动里最容易被低估的一个。现实中需求冲突根本不是例外而是常态业务方要全自动化合规部门坚持保留人工审批产品经理要丰富功能开发评估后表示工期翻倍。所谓协商不是开一次会让大家投票而是基于商业价值、实现成本、技术风险和依赖关系对需求做取舍与排序。Pressman书中给出的协商要点包括识别冲突、达成一致、优先级排序、寻找折中方案。这中间必须有主持人、有记录、有结论输出。考试里常给你一段两个干系人意见相左的场景问你下一步应该怎么做——正确答案不是按领导说的办而是组织需求协商评估冲突项的价值与代价形成优先级共识。1.3 规格说明与管理文档不是终点变更才是规格说明就是把协商后的需求写成正式文档最典型的是软件需求规格说明SRS。要注意需求是有层次的用户需求业务人员能看懂的自然语言描述和系统需求足够详细、能被设计开发直接使用的描述是两个不同粒度。考试里偶尔会专门考系统需求特性比如完整性、一致性、可验证性、无歧义、可追踪性、可行性——这些词也是后续需求验证的基础别只当一套说法背要能拿具体需求例子判断它合不合格。需求管理则是处理变。唯一不变的就是需求一直在变这是软件工程的铁律。管理手段包括建立需求基线Baseline、需求追踪矩阵、变更控制流程、影响分析。在敏捷环境下这个活动落到产品待办列表Product Backlog上其实就是需求优先级排序和持续更新的体现。做课设时很多组第六周就宣布需求分析完成之后数据库字段一改再改本质就是需求管理缺位——没有基线没有变更评估改需求全凭某个人的一时兴起。这部分的简答题常考为什么需求必须管理标准思路是需求变更会影响估算、进度、设计、测试如果没有受控的变更流程项目会越改越乱、成本失控。2. 功能需求、非功能需求与领域需求分类是容易考、也最容易混淆的第一关需求分类是第八章里最基础、但也是最容易丢分的知识点。Pressman体系里常见的分类维度是功能需求、非功能需求和领域需求三类。很多同学觉得这个太简单了结果一考判断题就翻车——因为你以为系统应支持扫码登录是非功能需求实际上它是功能需求而系统应保证用户密码在传输过程中加密反而属于非功能需求。2.1 功能需求的边界该怎么划功能需求描述的是系统做什么给定什么输入产生什么输出执行什么行为。难点在粒度写得太粗变成模块名比如系统应管理订单完全无法指导设计和测试写得太细又变成实现细节比如系统应使用HashMap存储用户数据把设计决策提前塞进了需求层。一个合格的功能需求陈述应该包含行为主体、触发条件、输入、输出和业务规则。举个例子当管理员点击『批量导入』按钮并上传CSV文件时系统应逐行校验数据若某行不合法则跳过该行并在结果报告中记录原因——这才叫一条能指导后续开发的描述。考试常见出题方式是给你一句话让你判断是不是合格的功能需求或者让你把一句模糊描述改写清楚。练习题多做几道手感就出来了。还有一个高频易错点登录认证算不算非功能需求正确答案是要看你怎么描述。功能部分是系统应允许用户通过账号密码登录验证通过后进入主界面而系统应采用加密协议保护登录过程中的口令传输属于安全相关的非功能需求。判断标准很简单这个需求描述的是行为还是约束行为如何表现2.2 非功能需求与FURPS没有量化就没有意义非功能需求描述系统做得怎么样它约束的是性能、安全、可用性、可靠性等一系列质量属性。Pressman里常常提到FURPS这个需求分类框架由五个维度和一组附加约束组成类别含义典型示例FFunctionality功能与特性系统支持在线支付、支持多角色权限UUsability易用性与用户体验新用户能在5分钟内完成首次下单RReliability可靠性与容错系统年可用率不低于99.9%故障恢复不超过30分钟PPerformance性能指标20个并发用户下订单查询响应时间小于3秒SSupportability可维护性与可扩展性系统支持日志采集和远程告警Constraints约束条件必须部署在国产操作系统上必须满足数据合规要求考试里经常给一条需求问它属于FURPS中的哪一类。这里面最经典的陷阱是系统应运行流畅——这不是合格的非功能需求因为它没有量化指标。改写成系统在1000条订单记录范围内查询响应时间不超过2秒才算合格。另外可用性Usability和易用性Ease of Use也容易混可用性更偏用户在多大效率上能完成目标而单纯说界面友好是没有验收标准的考试你要能指出这个描述不可验证。2.3 领域需求最容易被忽略的需求类别领域需求来自应用领域自身的规则往往没有任何用户会专门提出来但系统不满足它就无法在行业里落地。比如银行系统的复式记账规则、电商系统按收货地区计算税率的规则、医疗系统对电子病历保存年限的合规要求。这些规则是领域专家默认你应该知道的知识教科书和通用需求模板里不会写。正因为领域需求隐晦需求导出阶段才必须引入领域专家和真实业务场景。做课程设计和毕业设计时我特别想提醒你选题时选一个自己真的熟悉的领域比选一个听起来高大上的领域重要得多。比如你做过社团管理就做社团活动管理平台你在实验室帮老师管过设备就做设备借用系统。因为你对这个领域的隐性规则天然有感知需求分析才能写出别人抄不出来的内容。反过来一上来就做智能养老平台智慧校园系统领域需求全靠编文档一深问就崩。3. 分析建模三件套数据模型、DFD与类模型的定位区别第八章理解需求里Pressman花了相当篇幅讲构建需求模型虽然完整的模型技术分散在后续章节但期末命题经常把需求分析和需求建模合并考。你要清楚一件事任何单一模型都无法描述一个软件系统完整的需求分析必须同时覆盖数据视角、流程视角和类/对象视角。3.1 数据模型业务视角的实体联系图数据模型描述业务中的核心数据对象及其关系核心概念是实体Entity、属性Attribute、关系Relationship、基数Cardinality和参与性Modality。注意需求阶段画ER图是业务视角不是数据库设计所以别急着标主键、外键和范式这些是实现细节。举个例子图书管理系统的读者借书关系实体是读者和图书关系是借阅一个读者可借多本图书一本图书同一时刻只能被一个读者借出这就是基数。参与性要说清可选的还是强制的读者可以一本书都不借可选参与但一条借阅记录必须关联一个读者和一个图书强制参与。这些在课设答辩时是老师最爱追着问的点特别是基数方向容易画反。还有一个考试爱考的细节递归关系。比如员工–员工一个员工管理多个下属员工一个员工只归属一个上级。这类一元关系很多同学画不出来或者画出来方向错。建议做题时先确定关系两端各是什么角色再填基数。3.2 数据流图DFD从上下文图开始逐层分解数据流图的核心元素只有四种外部实体、加工过程、数据流、数据存储。它的价值在于不依赖任何技术实现方式就能跟业务人员确认数据在系统里是怎么流动的。画DFD必须从上下文图Level 0开始把整个系统画成一个加工外部实体通过数据流与它交互一眼看清系统边界。Level 1 再把这个加工分解成主要子功能Level 2 继续细化。这里有两个高频考点一个是父子图平衡规则——父图中某个加工的所有输入输出流必须在子图中完整保留、不能多也不能少。另一个是命名规范——加工用动词名词验证登录、生成报表数据流和数据存储用名词用户信息、订单记录。有些同学图便宜把加工命名为数据处理等于没命名答辩肯定被追问。DFD和用例图的关系也经常考用例图面向用户视角表达谁能用系统做什么强调场景和目标DFD面向数据视角表达数据经过哪里的处理变成什么强调流动路径。两者互补不是重复。3.3 类模型与CRC卡靠角色扮演找出来的分析类面向类的模型从业务概念出发识别出候选类、属性、操作以及类之间的关系。需求阶段不要求写出完整的方法签名重点是搞清楚哪些名词值得作为类进入后续设计。我特别推荐大家掌握CRC卡类-责任-协作者这个方法因为它是应付课设需求分析时非常好用的头脑风暴工具。操作方式是把课堂或小组会议要讨论的类写在卡片顶部左栏写这个类的责任它知道什么、做什么右栏写为了完成责任需要跟谁协作。然后拿着典型业务场景比如读者借书一步步做场景走查这张卡片的类此时有没有责任如果发现负载过重或完全闲着就说明职责分配有问题。走查几个场景之后缺失的类自然就浮现出来了。类关系的考试重点是关联Association、聚合Aggregation和组合Composition三者区分。简单粗暴的判定口诀组合是同生共死的强归属订单被删除订单明细必须删除聚合是整体与部分但可独立存在班级和学生的生命周期不必一致关联则是普通的认识关系学生使用图书馆。考题常给几个类让你判断关系类型先定是否强归属再定是否共享生命周期基本不会错。4. 用例模型和行为模型一个给业务看一个给设计看如果数据流图和类图是静态视角那动态行为就得靠用例、状态图和顺序图来补。这几种模型在复习时特别容易混我建议用一个简单框架去记用例给业务干系人讲故事逻辑状态图给单个对象秀生命周期顺序图给一场协作画时间线。4.1 用例从业务目标倒推而不是罗列功能用例模型的核心不是画一个椭圆带几条线而是写清楚参与者和系统交互的完整流程。规范用例应包含参与者Actor、前置条件、后置条件、主成功场景、扩展场景备选流和业务规则。写用例最常犯的错有三个一是把参与者写成用户这种泛指没有区分普通用户和管理员导致权限逻辑不清二是把主场景写成二十多步的操作说明书被细节淹没了目标三是把用例名字写成数据管理这种无行为的话。比如管理员登录系统后点击新增图书、填写信息、点保存这不是好用例好用例是管理员新增一本图书系统校验ISBN唯一性成功后库存信息即时可见。前者是操作步骤后者才是业务目标。注意用例的粒度控制在一个参与者通过系统完成一个有价值的业务目标即可登录可能不是独立用例而是其他用例的前置条件。考试若让你给某个系统画用例图先用一句话概括核心目标再倒推出那3~5个最核心的用例别贪多。4.2 状态图单个对象的完整生命周期状态图描述一个对象从创建到销毁经历哪些稳定状态、哪些事件触发状态迁移。关键概念是状态State、事件Event、动作Action和守卫条件Guard Condition。拿订单对象举例稳定的状态可能是待支付、已支付、待发货、已发货、已完成、已取消。这里的坑在于很多人把已支付当成状态——其实支付成功是一个事件事件发生后订单进入的状态才是待发货或已支付取决于你怎么建模。另外状态图上的迁移必须写触发事件和可选守卫条件守卫条件就是布尔表达式比如仅当订单已支付且库存充足时订单才能进入待发货状态。考试里判断状态图还是顺序图最常出错我的判断顺序是题目里只有一个类/对象在变化且关注它处于什么阶段 → 状态图题目里有多个对象在发消息协作关注先后顺序 → 顺序图。4.3 顺序图多个对象在一次交互中的协作顺序顺序图的作用是把用例中的主成功场景从一个抽象目标细化成哪个对象向哪个对象发消息的协作过程。元素包括对象生命线、激活条、消息箭头和返回消息。画顺序图常见的失败姿势是把它画成干巴巴的步骤流程图——竖线不是流程框而是对象生命线箭头不是命令而是消息。你要先确认这个场景里到底有哪些对象参与了再给每个对象画一条生命线。比如新增图书的顺序图可能涉及管理员界面对象、图书管理控制对象、图书数据对象、校验服务对象消息从界面层一路传到数据层再逐层返回结果。在需求分析阶段顺序图最大的作用是帮你检查职责分配是否合理如果某个对象被发了很多消息、承担了所有逻辑说明类的设计有问题如果用例场景里写到了但顺序图里找不到对应消息说明分析漏了需求。把用例和顺序图对照着看很多漏洞一眼就暴露了。5. 需求验证与优先级排序考前必须掌握的评审清单需求分析做完不等于需求正确。Pressman明确把需求确认和后续的开发活动分开强调在动手设计之前必须对需求进行系统化评审。这个环节在考试里通常以判断题或简答题出现在课设答辩里则是老师考察你有没有真思考的切入口。5.1 需求验证要查这六项需求验证的核心检查项是正确性、完整性、一致性、无歧义、可验证性、可追踪性。实际上还要加一个可行性。考试如果给你一条需求让你判断问题出在哪你基本就按这六项去套检查项含义坏例子 → 好例子正确性需求是否反映真实业务目标系统应该让用户点赞 → 系统应允许已登录用户对他人发布的帖子点赞且同一用户对同一帖子只能点赞一次完整性是否遗漏场景或边界只写支持上传图片不写图片大小限制 → 补充单张图片不超过5MB支持jpg/png格式一致性多条需求之间是否冲突一个需求说所有操作在2秒内完成另一个需求说上传视频并转码 → 需拆分场景、设置不同性能指标无歧义每个读者理解是否一致系统应尽快处理数据 → 系统在1000条记录范围内导入时间不超过5秒可验证性有没有办法验收界面要美观 → 系统应通过可用性测试新用户无需培训即可完成下单流程可追踪性能否追溯到来源与后续产物每个需求都有编号、来源、对应的设计模块和测试用例其中无歧义和可验证性最常连在一起考。你只需要记住一句话凡是用了高效友好快速稳定这类形容词却没有任何量化指标的需求在软件工程意义上都是不合格需求。5.2 优先级排序别让所有干系人都全都要需求协商阶段输出的就是一份排好优先级的需求清单。日常项目里最简单实用的排序工具是MoSCoW法则Must必须有、Should应该有、Could可以有、Wont这次不做。考试里会让你对一组需求做MoSCoW划分或者让你从业务价值、实现成本、风险、依赖关系四个维度解释为什么某需求排得靠前。排优先级最难的不是排序这个动作而是顶住全都要的压力。我见过的成功做法是把每个需求做成一张小卡片上面写业务价值高/中/低、实现成本人天估算、技术风险高/中/低、依赖关系被谁依赖、依赖谁开会时所有卡片摆桌上让干系人自己在成本约束下做取舍。一旦把这个功能好不好换成这个功能值不值冲突就好化解了。课设里老师问为什么先做A不做B你就回答因为A是核心业务流程的Must需求B是用户管理里的Should需求且B依赖A的数据库结构所以排后——这个回答本身就体现了需求协商和管理意识。5.3 可追踪矩阵与变更影响分析需求追踪矩阵Requirements Traceability MatrixRTM是需求管理最常用的手段本质是一张需求–来源–设计–测试–状态的对照表。它的意义是出现变更时你知道这条需求动了受影响的代码模块和测试用例是哪几个。需求编号需求描述来源设计模块测试用例状态REQ-001管理员可批量导入图书教务科业务访谈Module: BookImportTC-001, TC-002已实现REQ-002导入数据超过1000条时给出分页预览教务科业务访谈Module: BookImportTC-003待开发变更影响分析就是基于这张表做扩散分析改REQ-001只接口和测试用例要不要跟着改要不要重新估算工作量这个流程看似官僚但在课设和实际项目里都是保命工具。很多小组后期越改越乱就是因为没有一个表能回答这次改动到底影响谁。6. 期末与课设高频陷阱一张速查表治好背了就忘最后这部分是复习冲刺用的。前面讲了原理和流程这里把最容易考、最容易错的点压缩成速查表可以直接用来做考前最后一遍过。6.1 高频混淆概念对照表易混概念判定关键记忆锚点功能需求 vs 非功能需求描述做什么还是做得怎么样登录行为功能密码加密传输非功能用户需求 vs 系统需求能不能被非技术人员读懂业务语言 vs 开发可用的精确描述用例图 vs DFD用户目标视角 vs 数据流动视角用例重角色和目标DFD重加工和数据流状态图 vs 顺序图单个对象的生命周期 vs 多个对象的协作看研究对象数量聚合 vs 组合部分能否脱离整体独立存在组合更强调整体控制部分生命周期需求验证 vs 测试活动验证发生在设计前测试发生在编码后验证的是需求的正确性测试是实现与需求的符合度6.2 课设/毕设场景里最容易被问倒的三句话第一句是你的非功能需求写了什么如果你答系统运行流畅、界面美观基本等于没答。正确做法是把非功能需求写成可验证指标比如系统在20个并发用户操作下核心查询接口的响应时间小于3秒第二句是为什么先做这个模块这说明老师想看你的优先级判断你要能讲清楚这个模块是核心业务流程的Must需求且被其他模块依赖第三句是这个需求从哪来的这是在问需求来源和可追踪性凡是说不出来源的需求都值得怀疑。提示做课设需求分析时建议用一页纸把干系人列表、核心用例清单、需求优先级、追踪矩阵四项列清楚。这张纸在答辩时比几十页复制粘贴的模板更能说明你真的理解了需求。6.3 复习路线建议如果备考时间紧我建议走两轮。第一轮先按需求工程七活动把流程串起来再分别攻需求分类、分析建模、行为建模、需求验证四个知识点块每块画一张概念图不要求背但要求能对着图讲清楚每个概念之间的关系。第二轮专门做需求改写题随便找几条模糊需求比如系统要支持快速查询用参考六项检查项和FURPS框架改写成合格表述。这种题型对口教材考试和软考都非常常见练10条这种题比单纯背概念有用得多。另外提醒一点这一章和后面的需求建模设计工程衔接非常紧复习时顺便把DFD和用例图多画两遍后面课设能省大量时间。我个人做课设栽过跟头也带过几届学弟学妹做毕设发现一个很朴素的规律凡是动手写代码前能花一周时间把需求真正想清楚、写成可验证用例并排好优先级的组后期几乎不会出现推倒重来凡是拿到题目就开数据库建表的组大概率在中后期陷入改字段、改逻辑、加需求的泥潭。关于理解需求这一章我个人操作里最有用的一个小技巧是第一周先别急着画任何正式图只用一句话回答谁在什么场景下要通过系统完成什么目标解决什么痛点。这句话如果写不顺说明你对需求的理解还没到位——后面所有用例、DFD、类图都只是这句话的展开而已。把这个句子磨清楚了第八章你才算真正过关。