不管你是正在被课程设计折磨的软件工程专业学生还是刚入职就被拉去开需求评审会的初级开发只要你碰过软件项目大概率都经历过这样的场景产品经理拿着一份用户想要一个高大上的系统的模糊描述开发一脸茫然地问那到底要做什么测试在旁边等着拿需求文档却迟迟等不到。最后项目延期了大家互相甩锅根子往往就出在需求分析这个环节。这篇博文要聊的就是软件工程第三章的核心内容——需求分析。我会先把需求分析的基本概念、流程和建模工具讲明白再拿一个高校新闻网站的项目案例完整拆一遍从需求获取到需求规格说明书落地的全过程最后把我这些年在项目里踩过的需求坑、总结的避坑技巧全部抖出来。无论你是正在做课程设计的学生还是刚入行的开发这篇文章都能让你少走不少弯路。1. 需求分析到底在分析什么1.1 需求分析不是问用户要什么这么简单很多初学者以为需求分析就是拿着本子问用户你想要什么功能然后把答案记录下来就完事了。真要这么简单软件工程这门课可以直接取消市面上也不会有那么多烂尾项目了。需求分析的本质是把用户脑中模糊的、碎片化的、甚至自相矛盾的期望转化成一整套准确、完整、可验证的软件行为描述。你面对的用户往往不知道自己真正想要什么或者只能说出我要一个像淘宝一样的系统我要一个能管新闻的网站这种话翻译过来等于是说我要一个能跑的软件信息量几乎为零。所以需求分析人员干的事情表面上是沟通实则是三件事一是挖出用户没明说但真实存在的需求二是把业务语言翻译成技术语言三是把所有需求整理成能让开发、测试、项目经理都看得懂、能执行的文档。这个过程需要你跟用户聊、跟业务方吵、跟开发确认反复迭代好几轮才能把用户想要什么和系统该做什么对齐。再往深了说需求分析在软件工程里承担的是一个承上启下的作用。承上它承接可行性研究和项目计划阶段确定的目标范围启下它的产出物——需求规格说明书直接决定了后续设计、编码、测试能不能顺利推进。你后面画的架构图、写的接口文档、设计的测试用例本质上都是在需求分析结果上做的二次加工。需求这边歪一厘米开发那边就能偏出一公里去。1.2 需求的两个大类功能需求与非功能需求做需求分析第一件事是学会给需求分类。软件工程里最经典的分法是把需求分成功能需求和非功能需求两大类再加上一层约束条件。功能需求指的是系统必须做什么是用户能直接感知到的行为。比如高校新闻网站里管理员可以发布新闻访客可以浏览新闻注册用户可以发表评论这些都是功能需求。功能需求通常可以从用户的业务动作中直接提炼也是初学者最容易上手的一类。非功能需求则是系统做得怎么样的要求它不直接对应某个具体功能但决定了用户用起来爽不爽。举几个常见的例子网站首页要在3秒内加载完成性能需求系统全年可用率要达到99.5%可靠性需求界面风格要统一、操作要符合用户习惯可用性需求代码要方便后期加功能可维护性需求。这类需求因为不直观经常被忽视但恰恰是项目上线后用户吐槽最多的地方。约束条件则是项目必须遵守的边界比如必须用Java开发、只能部署在Windows服务器上、开发周期不能超过3个月、预算控制在50万以内等等。约束条件通常来自公司决策、客户合同或技术环境的限制需求分析时同样需要明确记录。需求类型回答的问题举例高校新闻网站功能需求系统做什么发布新闻、审核稿件、浏览文章、发表评论非功能需求系统做得怎么样响应时间不超过3秒、支持500人同时在线约束条件在什么限制下做使用Spring Boot框架、数据库用MySQL把这三类需求全部识别出来、写清楚需求分析的任务才算真正完成。如果只盯着功能需求看那你做的只是产品功能清单不是需求分析。2. 需求分析五步走从用户那里挖出真需求2.1 需求获取别只靠开会四种方法轮流用需求获取是整个需求分析的第一步也是最考验人际沟通能力的环节。获取需求的方法有很多我实战下来最常用的有四类各有各的适用场景最好组合着用。第一种是用户访谈。这是最传统也最灵活的方式你可以事先准备问题清单也可以顺着用户的话临时追问。访谈的关键技巧是不要只问你想要什么功能而是问你平时怎么干活遇到什么问题最头疼从用户的痛点里反推需求。比如你问新闻网站编辑发一篇新闻要几步他说要登录后台、填标题、填正文、传图片、选分类、点发布、等审核你就能顺藤摸瓜梳理出一整条业务流。第二种是问卷调查。当用户数量多、分布广、没办法逐一访谈时问卷能帮你快速收集大量信息。但问卷设计要特别注意问题要具体、选项要周全尽量别用开放题否则回收上来的答案五花八门没法统计。我见过最离谱的一份问卷里面全是您觉得系统应该好用吗这种废话这种问卷填了等于白填。第三种是现场观察。坐到用户旁边看他实际操作一天比聊十次都管用。用户嘴上说我们评论审核很简单你到现场才发现他要同时打开QQ群、Excel表和后台三个窗口手动复制粘贴几十条评论信息这一刻你才知道简单两个字有多沉重。这也是需求分析人员最容易忽略但价值最高的方法。第四种是原型法。快速做一个能点击的、带基础界面的可交互原型让用户在上面点一点、玩一玩用户在看到具体东西之后往往会说出很多之前根本想不到的需求。很多做课程设计的学生直接跳过原型阶段一上来就写代码最后交出来的东西跟用户想要的天差地别这就是没利用好原型这个需求探针。实际项目中我一般建议先用访谈加观察摸清核心业务流程再用问卷覆盖更广的用户群体最后用原型与用户逐项确认。四种方法不是选一个而是配合着打组合拳。2.2 需求分析与建模把人话翻译成图从用户那里收集到的原材料通常是杂乱无章的。用户会说我想能看新闻最好评论能带图管理员要能删掉垃圾评论这些话是原始需求还不能直接交给开发。需求分析阶段要做的是把这些人话整理归类剔除矛盾补齐遗漏最终转变成结构化的模型。这个建模的过程在软件工程里叫需求建模核心产出物就是各种分析模型图。最常见的三种是描述用户与系统交互行为的用例图、描述数据结构关系的E-R图、描述数据流转过程的数据流图。这三种图我后面单独用一整章来拆解因为它们就是需求分析阶段最核心的交付物能不能把图画明白直接决定了你需求分析的水平。建模的时候有一点要特别注意分析模型的粒度要跟系统规模匹配。做一个课设级别的新闻网站你画个包含十几个用例的用例图、三四张表的E-R图已经足够做一个企业级电商系统你可能需要几十上百个用例、十几张图来完整描述。不要小项目画大图也不要大项目拿一张图糊弄事这个度需要在实际操作中慢慢找感觉。2.3 需求规格化写出一份能落地的SRS需求分析做完了得把结论落成文档这份文档在软件工程里叫软件需求规格说明书SRSSoftware Requirements Specification。它是整个需求分析阶段最重要的产物后续的设计、编码、测试都以它为依据。SRS没有绝对的模板但业界常用的IEEE 830标准值得参考主要包含这几块内容引言编写目的、项目背景、术语定义、总体描述产品视角、用户特征、运行环境、约束条件、外部接口需求用户界面、硬件接口、软件接口、通信接口、系统功能需求按功能模块逐条列出、非功能需求性能、安全、可用性等、其他需求如国际化、法律合规等。写SRS有个核心原则每个需求条目必须可验证。什么叫可验证就是清带测试工程师过来他能看着这一条写出对应的测试用例。比如系统要很快就不可验证而系统在普通4G网络环境下首页加载时间不超过3秒就可验证。我在评审会上见过太多写着界面美观大方操作简单便捷这种空话的需求文档这种条目既没法设计实现也没法测试纯属凑字数。给需求条目编号也是SRS的硬性要求。比如FR-001表示第一条功能需求NFR-001表示第一条非功能需求。别小看编号这个动作有了编号你才能建需求追踪矩阵才能在后期的变更管理中明确知道改动影响哪些模块。我见过不编号的需求文档改需求的时候只能用就是登录那个功能改一下来沟通最后改没改全、影响多大谁也说不清楚。2.4 需求验证评审会上吵出来的高质量需求需求文档写出来不代表就完事了还得经过验证——也就是常说的需求评审。评审的目的是在动手开发之前发现需求中的错误、遗漏和矛盾因为修复一个需求阶段错误的成本比修复一个编码阶段错误要低十倍甚至百倍。需求评审通常以评审会的形式进行参加的人包括需求分析人员、客户或用户代表、开发人员、测试人员和项目经理。会上由需求分析人员逐条讲解需求参会各方从不同角度挑毛病开发关注技术可行性测试关注可验证性用户关注是否满足业务需要项目经理关注进度和资源是否匹配。我第一次参加需求评审时被开发当面问你这条需求是不是写错了就脸红后来经历的评审多了才明白评审会上吵得越凶项目开发阶段就越顺利。吵不清楚的需求放到开发阶段才暴露修改的成本可就是几何级增长了。评审结束后所有提出的问题必须记录在案明确修改方案和责任人不能开完会就翻篇了。除了正式评审需求验证还可以配合原型走查。把做好的原型拿给用户操作一遍观察用户的实际行为和反馈往往能发现文档评审发现不了的操作细节问题。用户看了原型说这里不应该弹窗应该直接跳转这种宝贵意见光看文字文档是不可能有的。3. 三个必须掌握的建模工具用例图、E-R图、数据流图3.1 用例图把用户和系统的互动画清楚用例图是需求分析中出镜率最高的图也是初学者最容易画糊的图。它的核心作用是把谁和系统能发生什么交互用图形化的方式表达清楚。一张标准的用例图包含三个要素参与者Actor、用例Use Case和系统边界。参与者是那些与系统交互的外部角色注意是人或系统不是具体的某个人。在高校新闻网站里参与者可以是访客、注册用户、编辑、审核员、管理员。画参与者的时候我习惯先列角色清单问自己两个问题谁需要系统提供功能谁能修改系统里的数据答完了参与者基本就齐了。用例是系统对外提供的一个完整功能服务名字一定要用动词短语比如发布新闻审核评论浏览文章。这里最容易犯的错是把系统里的一个操作步骤当成用例比如点击发布按钮就不是用例发布新闻才是因为后者有完整价值、有明确起点和终点。另外一个容易犯的错是过早画出系统的内部细节记住用例图关注的是系统对外能做什么不是系统内部怎么做。用例之间的关系也要搞清楚最常见的是包含关系include和扩展关系extend。包含关系里一个用例总是包含另一个用例的步骤比如发布新闻总是包含验证用户权限画的时候从发布新闻指向验证用户权限扩展关系则是在特定条件下才触发附加行为比如浏览文章在文章含附件这个条件下扩展出下载附件。分清楚这两种关系用例图的逻辑才会严谨。3.2 E-R图数据关系一张图说透E-R图实体-联系图是数据库设计的基石也是需求分析阶段描述数据模型的核心工具。它由实体、属性和联系三部分组成。实体是现实世界中独立存在的对象比如高校新闻网站里的用户新闻评论属性是实体的特征比如用户有用户名、密码、邮箱联系是实体之间的业务关系有一对一、一对多、多对多三种。以电商购物系统为例如果让你画E-R图你至少能抽出这几个实体用户、商品、订单、订单项、购物车。画联系的时候要重点分析一个用户可以下多个订单1:N一个订单可以包含多个商品而一个商品也可以出现在多个订单里M:N这时需要通过中间表订单项来拆分。你如果连订单项这个中间实体都没想到后期数据库设计一定会出大问题。画E-R图最核心的能力是从一段模糊的业务描述里把实体和联系抽出来。我习惯用标注法先把描述中的名词圈出来这些大概率是实体或属性再把表示动作的词圈出来这些大概率是联系。比如用户可以在系统上发布新闻新闻可以挂在多个分类下圈出用户、新闻、分类、发布、挂在再判断用户和新闻是1:N新闻和分类是M:N图就开始成形了。E-R图的粒度同样需要控制。课程设计级别的项目全局一张E-R图就行大型系统建议按模块分组画比如用户模块一张、订单模块一张避免一张图挤几十个实体。画完之后跟数据库设计人员对一遍看能不能直接照着建表这是检验E-R图画得好不好的硬标准。3.3 数据流图与状态图让流程和状态不再含糊除了用例图和E-R图数据流图和状态图也是需求分析阶段常用的建模工具区别在于它们关注的维度不同。数据流图DFD描述的是数据在系统中的流动和处理过程包含外部实体、加工、数据存储和数据流四个要素。画DFD的关键是分层先画顶层图把系统看成一个整体标出外部输入和输出再逐层细化把加工拆成子加工一直到每个加工都能清楚表达业务逻辑为止。比如新闻网站的系统顶层输入是用户提交的新闻内容输出是审核通过的已发布新闻往下拆一层就有了编辑填写稿件审核员审核稿件管理员发布上线这些子加工。DFD画得好的项目开发阶段几乎不会出现不知道数据从哪来、往哪去的迷茫。状态图则是描述某个对象在不同状态下如何转移的图最适合用来表达状态复杂的业务对象。拿新闻来说它的状态可能有草稿、待审核、已发布、已下线状态转移的触发条件是编辑提交审核通过管理员下线。我见过很多项目的状态逻辑一团乱麻编辑说新闻可以改审核说只能改没审的管理员说已发布的也能改——其实就是没画状态图导致各方对状态理解不一致。一张状态图贴墙上谁也不用吵。4. 高校新闻网站需求分析实战拆解4.1 项目背景与角色设定理论讲再多不如实际跑一遍。接下来我用一个高校新闻网站的项目案例把从需求获取到SRS落地全流程串一遍。这个案例是很多高校软件工程课程设计的经典选题因为它覆盖面广、需求不复杂、又有清晰的业务逻辑非常适合用来练习需求分析。假设我们接到的原始需求就一句话学校需要一个新闻网站用来发布校内新闻。这句话能做的东西太多了想要把它变成一份能开发的需求文档得先明确项目背景和干系人。高校新闻网站的使用者从角色上说至少有四类访客校外人员只能看公开内容、校内师生注册后可以评论互动、编辑各院系的通讯员负责投稿、审核员和管理员宣传部老师负责审核和发布以及用户管理。角色设定清楚后接着做访谈确认业务流程。去采访一个真实的新闻编辑你会发现发一篇新闻的流程是这样的编辑登录后台、填写稿件标题和正文、上传配图、选择所属栏目、提交审核审核员登录后台、查看待审稿件列表、逐篇打开检查、通过或退回退回的稿件编辑修改后重新提交审核通过的稿件由管理员选择发布时间、置顶状态后发布。这个流程走下来比你凭空想象做一个新闻发布系统要靠谱得多。需求分析里面最忌讳的就是不懂业务乱猜哪怕是课程设计也建议你去真正了解哪怕一个真实场景。4.2 功能需求清单怎么列基于前面的角色和业务流程我们就可以开始整理功能需求清单了。把每个角色在业务流程里的每个动作提取出来转换成系统的功能描述。新闻浏览功能是面向所有访客和注册用户的核心需求包括首页展示新闻列表、按栏目分类浏览、查看新闻详情、关键词搜索新闻。新闻发布功能面向编辑包括在线编辑稿件、上传图片附件、投稿到指定栏目、查看审核状态、修改被退回的稿件。审核发布功能面向审核员和管理员包括查看待审稿件列表、审阅稿件详情、审核通过或退回、已发布稿件下线、设置置顶和推荐。用户管理功能面向管理员包括用户注册审核、用户禁言和删除、角色权限分配。评论互动功能面向注册用户包括发表评论、删除自己的评论、管理员删除违规评论。这五块功能列出来后再给它做优先级划分。我会用MoSCoW法把功能分为Must必须有、Should应该有、Could可以有、Wont这期不做四档。比如新闻浏览、新闻发布、审核发布是Must评论互动是Should在线编辑器里的图片水印是Could社交分享是Wont。优先级的价值在于当项目周期吃紧时你知道先砍哪些功能而不是砍完核心功能导致项目不能用。4.3 非功能需求怎么定功能需求之外高校新闻网站的非功能需求同样不能省。性能方面考虑到学校官网会在开学季、重大活动时迎来访问高峰可以定义首页在并发200用户情况下响应时间不超过3秒支持同时在线500人。这个指标怎么来的不是拍脑袋是根据学校规模预估的——比如在校师生3万人、平时在线率约1%到2%再留一定余量。安全方面新闻网站要防止SQL注入和XSS跨站脚本攻击评论内容必须经过敏感词过滤管理员密码要加密存储并且定期更换。可用性方面要求新用户在不看使用手册的情况下就能完成注册、浏览、评论操作界面文字统一、导航清晰。兼容性方面要支持Chrome、Edge、Safari等主流浏览器还要考虑移动端自适应——学生现在基本都是用手机刷校园新闻这个不满足项目上线等于失败一半。可维护性方面系统要采用模块化设计新闻模块、用户模块、评论模块解耦后续新增一个活动报名模块时不能影响现有功能。这些非功能需求看起来不如功能需求那么显眼但等到上线后的运维阶段你才会意识到写没写进SRS的差别有多大。5. 需求变更与需求蔓延项目失控的头号杀手5.1 需求变更为什么避不开需求分析做得再充分需求变更依然无法完全避免。原因很简单用户需求本身是动态的市场环境在变、政策在变、用户的想法也在变。比如新闻网站做到一半学院领导突然要求加一个书记信箱栏目这种事在真实项目里太常见了。但需求变更本身不可怕可怕的是无序的需求变更。我见过最典型的反面教材是用户一个电话说要改个字段开发随手就改了既不评估影响也不更新文档过了两周测试拿着旧文档来验收发现功能对不上再去翻代码发现改动了十几个地方连带引发了另外几个bug。这种改一个字段崩半个系统的闹剧几乎都是需求变更失控造成的。需求蔓延则更隐蔽它指的是在项目过程中需求像滚雪球一样越滚越大。反正都做了新闻网站顺便加个活动公告模块吧要不再加个失物招领功能每一个小需求看起来都人畜无害加起来就是压垮项目的最后一根稻草。控制需求蔓延靠的是前期把项目边界定清楚后期严格执行变更流程。5.2 变更控制流程怎么落地需求变更必须走一套标准的控制流程这是软件工程里反复强调的纪律。第一步是提出变更申请不管是用户还是项目组内部所有变更必须通过正式的变更申请单提交写明变更内容、原因和期望时间。第二步是影响分析由开发、测试、项目经理共同评估变更对工期、成本、质量的影响明确改哪些模块、改多少工作量、会引入什么风险。第三步是变更审批由变更控制委员会CCB决定接受还是拒绝CCB的成员通常包括用户方代表、项目经理、技术负责人。第四步是执行变更批准后就按修改后的需求文档执行开发同时更新需求追踪矩阵里对应的条目。第五步是验证与记录测试确认变更实现正确后将变更记录归档备查。这套流程看起来有点重但对稍微正式一点的项目都是必要的。哪怕你做课程设计也可以简化地走一遍找个文档记录需求变更让甲方哪怕就是你的指导老师签字确认再动手改代码。有了这套流程你至少能回答三个问题需求为什么变、变了什么、影响了什么。需求追踪矩阵是这个流程里特别重要的工具简单说就是一张表左边列需求编号和内容中间列对应的设计模块、代码文件、测试用例右边列状态。需求一变扫一眼矩阵就知道哪些代码和测试要跟着改。没有这张表需求变更就是一场灾难。6. 常见问题与排查技巧实录6.1 需求环节高频问题速查说了这么多我把实际项目里最常遇到的需求分析问题整理成一张速查表。这些问题在学校课设里出现频率极高在企业项目里也同样存在遇到的时候直接对照排查就行。症状可能原因解决思路用户说我不知道要什么用户缺乏具象参考用原型或竞品引导用户对比、确认需求文档写了一大堆开发说看不懂条目太粗、描述含混按用户动作对象结果格式重写每条需求开发做到一半用户频繁加需求项目边界没界定变更无流程建立需求基线变更必须走审批测试写的用例和需求对不上需求不可验证每条需求必须有可量化的验收标准各方对评论审核理解不一致术语没有统一建术语表用状态图统一描述流程功能都实现了用户却说不满意非功能需求被忽略补充性能、可用性、安全等非功能需求这里面最值得展开说的是需求文档写了但开发看不懂的问题。我见过太多学生写的需求文档通篇是该系统界面友好操作便捷功能齐全这种正确的废话。解决这个问题有一个笨但好用的方法写每条需求时都用作为某角色我希望系统能做什么以便达到什么目的的格式。比如作为编辑我希望在提交稿件后能实时查看审核状态以便及时处理被退回的稿件。这么写角色清楚、动作清楚、价值也清楚开发一眼就能看懂。6.2 这些实操中的坑我替你踩过了最后分享几个我在需求分析实操中踩过的坑希望大家能绕开。第一个坑把所有时间花在画图上忽略了需求本身的逻辑。软件工程课设里很多小组交上去一堆用例图、E-R图结果一细问连新闻的状态流转都没想清楚。图是需求的载体不是需求本身。正确的做法是先花时间把业务流程走通、把需求条目写清楚再用图把结论表达出来。图服务于文档不是为了凑页数。第二个坑跟用户确认需求时只问对不对不问行不行。课堂上做演示时用户可能随口说行就这样但真实的业务场景里一个功能要经过审批、留痕、合规检查不是一句行就完事了的。确认需求的时候一定要往下多问一层追到业务规则和异常处理。比如用户说评论可以删除你要追问谁能删删了还能恢复吗删除要留操作日志吗多问这几个问题你的需求深度就会比大多数人扎实。第三个坑忽视需求评审代码写完了才后悔。我见过一个课设小组五个人分头开发没有统一的需求文档最后模块之间接口对不上只能连夜返工。如果在开发前组织一次需求评审让所有开发人员对着需求文档逐条过一遍把不理解的地方提前揪出来这个返工完全可以避免。第四个坑不维护需求追踪矩阵。项目小的时候你可能觉得表格可有可无但只要是超过两周的项目、超过三个模块的功能需求追踪矩阵就能帮你大忙。特别是在需求变更时矩阵能让你几分钟内圈定影响范围而不是像无头苍蝇一样全局排查。6.3 需求分析的后续延伸需求分析做完之后并不意味着你跟需求彻底没关系了。后续的概要设计、详细设计阶段你要依据SRS来画架构图、设计数据库、定义接口测试阶段测试工程师要依据SRS来设计测试用例、做需求覆盖度分析项目验收阶段验收标准同样来自SRS里定义的功能需求和非功能需求。换句话说需求分析的质量直接决定了整个项目的天花板。如果这个项目要继续往下走下一步可以考虑做的是把需求阶段定义好的用例边界作为设计阶段的模块划分依据把E-R图直接转成数据库表结构把数据流图中的加工映射成系统的功能模块。这些衔接工作越顺项目开发的效率就越高。另外如果项目体量允许还可以对已上线系统的用户反馈做一轮需求复盘看看哪些需求预估过高、哪些没考虑到的真实需求被用户反复提及。这种复盘对个人需求分析能力的提升非常明显比多画十张图都管用。毕竟需求分析是一门实践的学问只有被真实项目检验过的需求才算得上是真正的需求。