8年资深BA坦言:80%的软件项目翻车,都死在需求没做对,你信吗?

项目团队里做了 8 年的需求分析师，见过最冤的项目死法，从来不是技术写不出代码，是需求从根上就歪了。

几年前公司接了个小电商项目，客户拍着桌子说 “就做个普通下单的 App，很简单”，这位BA同事没多想就开始排期开发。结果上线前一周，客户突然问：怎么没有分销功能？他觉得这是电商标配，这位BA觉得他从来没提过。最后硬加了两周班赶出来，尾款还被扣了一截，锅全扣在这个 BA 头上。

后来才慢慢明白，做需求从来不是客户说什么就是什么。从一句模糊的 “做个电商 App”，到一套可落地、可测试、可交付的软件，中间有一套完整的方法论 —— 就是需求工程。很多人觉得这是虚头巴脑的流程，在我看来，它就是项目的保命符。

今天拿公司之前结项的社区电商 App 项目，把需求工程的六步拆得明明白白。不管你是 BA、产品还是开发，看完至少能少踩一半需求坑。

🎤需求获取：别只盯着老板聊，找全所有干系人

需求获取主要指收集来自不同问题和不同层次的需求信息，包括识别潜在用户的需求，这可能包括与利益相关者的会议、问卷调查、访谈和观察，其目的是通过多种途径收集和理解用户的需求信息，确保在软件开发前清晰地了解用户希望通过软件解决的问题，从而形成全面的用户视图或产品需求说明书。

很多新人做需求获取，就是拉着客户老板聊一下午，回来就写文档，这是最容易踩的坑。同一个电商项目，老板关心盈利和成本，运营关心后台好不好用，仓管关心库存准不准，真正下单的宝妈关心操作方不方便。我们当时除了对接客户负责人，还单独找他们的运营、仓管各聊了一轮，甚至找了几个小区的目标用户做了访谈。最后挖出来很多客户自己都没意识到的需求：比如宝妈大多带娃单手刷手机，下单按钮必须大、步骤必须少；仓管每天要盘点，后台得有一键导出库存表的功能。这一步的核心就是广撒网，别漏角色，别把一个人的想法，当成所有人的需求。

🔍需求分析：去伪存真，把模糊的话掰碎了说

需求分析是对获取的需求进行归纳、整理和分析，梳理需求之间的关系，识别需求的本质和隐含需求，以确保需求是可行的、一致的，并且没有遗漏。这包括对需求信息去伪存真、对需求进行分类、优先级排序和潜在冲突的识别。

比如，收上来几十条零散需求，不能全往 PRD 里塞。需求分析的本质，就是做筛选、做分类、排优先级、找冲突。比如这个项目，客户一开始既要做分销裂变，又咬死 3 个月必须上线，这就是明摆着的冲突。我们把所有需求分成 P0 到 P2 三级：下单、支付、物流查询这些核心功能是 P0，一期必须做；分销、积分商城是 P1，放二期；还有客户随口提的直播功能，直接归到 P2，以后再说。更重要的是把模糊的描述落地：客户说 “页面要流畅”，就得明确成 “首页加载时长不超过 2 秒，适配 95% 以上主流机型”。没有这一步，后面全是无休止的扯皮。

🗺️需求建模：画一张图，比写一千字都管用

需求建模典型的例子包括业务流程图、用例图、活动图、数据流图等，例如，数据流图（Data Flow Diagram，DFD）需求分析方法，采用自顶向下逐步细化的结构化分析方法表示目标系统，包含 4 种基本元素（模型对象）—— 数据源、处理、数据存储和外部项。而最常用的方法和工具是 IBM UML、OMG SysML 等。

就说电商最容易吵架的扣库存环节：到底是加购就扣，还是提交订单扣，还是支付成功再扣？光靠嘴说永远说不清。我们当时画了一张完整的下单流程图，从加购、提交订单、支付到扣库存、生成订单，每一步的分支和异常都画清楚，客户、开发、测试看一眼就懂。这一步花两个小时，后面至少能少吵两天架，性价比极高。

📝需求描述：写 PRD 的核心，是没有歧义

需求描述（定义）主要是以清晰、准确、规范的方式形成需求文档，这份文档详细描述了软件的功能需求、非功能需求、假设和限制条件。之前比较正式的说法是需求规格说明书（Requirements Specification），而工业界会称之为 “市场需求文档”（Marketing Requirement Documentation，MRD）或 “产品需求文档”（Product Requirement Documentation，PRD）

这步大家常说的写 PRD、需求规格说明书。很多人写需求爱写空话，比如 “用户可以取消订单”，这就是给自己埋雷。合格的需求描述必须准确、完整、无二义。

我们当时写取消订单的需求是这么定的：订单处于 “待发货” 状态时，用户可在订单详情页发起取消；无需商家审核，提交即时生效；库存同步释放，退款原路返回，到账时效 1-3 个工作日。前提、操作、结果、边界全写死，开发知道怎么实现，测试知道怎么测，客户也挑不出歧义。

✅需求评审与确认：拉齐所有人，签字才算数

需求评审是指开发方和客户方共同对需求文档进行评审，检查需求是否满足正确、完整、可行、无歧义、一致和可验证、可跟踪等质量要求。需求评审是为了及时找出需求中潜在的问题，并做出相应的修改建议，然后与相关的组或人员就这些问题进行协商并达成一致意见。双方对需求达成共识后做出承诺。需求确认，要确定产品需求文档中详细而具体的内容 —— 对所开发软件的功能、性能、用户界面及运行环境等做出详细的说明，如对应业务需求的功能点、具体的性能指标、支持的运行平台、需求项的优先级等，并评估基于这些软件功能项能否满足用户的业务需求。

很多公司的需求评审就是走个过场：开发低头划水，客户随便点头，最后出问题全不认。真正的评审，必须拉上所有干系人 —— 客户负责人、我方开发、测试、运维，一条一条过需求。当时我们评审的时候，开发提出来第三方支付接口联调周期比预想长，得留余量；测试提出来售后退款的异常场景没覆盖，得补上。所有问题都记录在案，改完之后双方负责人签字确认。这一步不是走形式，是给需求上保险：以后再要加东西，就是正式变更，不能随口说了算。

🛠️需求管理：贯穿全项目，变更不能随口来

需求管理贯穿整个软件开发过程，其主要任务是跟踪需求的状态、对需求的变更进行控制和管理，确保需求的稳定性和项目的顺利进行。例如，如果客户申请添加一个新的功能，如会员积分系统，业务分析师需要评估这一变更的影响，并更新需求文档。

别以为 PRD 签完字就万事大吉，需求管理要跟到项目上线为止。做项目哪有不改需求的？关键是怎么改。做到一半客户说要加积分抵扣，不能直接答应，也不能硬怼。走正式变更流程：先评估工作量、对工期的影响、需要增加的成本，整理成变更申请，客户签字确认之后，再同步给所有团队调整排期。我见过太多项目越做越乱，就是因为没管好变更，今天加个功能，明天改个逻辑，最后工期拖到没边，团队累得要死还落埋怨。

最后说两句从业多年的感触

需求工程从来不是为了卡流程、摆架子，是用来保护项目，也保护我们这些做事的人。很多人总嫌麻烦，总想跳过几步快点开发，结果前面省的那点时间，后面都要加倍补回来。软件工程从 1.0 迭代到 3.0，工具换了一茬又一茬，流程变了一遍又一遍，但需求的本质从来没变：把模糊的、零散的、随口说的想法，变成清晰的、一致的、所有人都认账的落地标准。方向定准了，后面的努力才不算白费。就这么简单的道理，很多人摔了好几次跤才懂。