1. 嵌入式系统需求获取为什么是“硬骨头”做嵌入式开发这些年我越来越确认一件事产品后期最贵的Bug往往不是写代码写出来的而是需求阶段埋下的。尤其对嵌入式系统来说需求获取的难度比纯软件项目高出一截因为你要面对的问题不是“用户想要什么功能”而是“在一堆物理约束下这个功能到底怎么才算做对了”。1.1 嵌入式需求与纯软件需求的核心差异纯软件项目做需求获取对象通常清晰用户、流程、数据、权限、界面。你坐在用户旁边看看他每天怎么操作问问他哪些地方不顺多半能聊出一份像样的需求清单。但嵌入式系统不是这样它的“用户”往往不是一个能清楚表达需求的人而是“设备 操作者 物理环境”三者的组合。比如一个电机控制器用户告诉你“转得快一点”但这句话背后牵涉到最大电流、温升限制、机械惯性、通信周期、安全停机时间等一系列边界条件。这些条件用户不会说甚至他自己也说不清但它们恰恰决定了软件能不能稳定工作。这类系统的需求还有个显著特点硬件耦合。软件跑在特定MCU上内存大小、外设数量、中断优先级、功耗预算全部是约束。你在需求获取阶段如果只记下“实现PID控制”而忽略了采样频率和PWM分辨率的要求等到硬件定型后再改就非常痛苦。所以嵌入式需求获取重点不在“记录功能”而在“挖掘约束”。另一个容易踩的坑是实时性。用户说“响应要快”这在纯软件里可能指界面不卡但在嵌入式里“快”需要被拆解成具体数字从传感器采样到执行器动作的最坏延迟是多少中断响应时间上限是多少超过这个上限会造成什么后果这些数字如果在需求获取阶段没有敲定后续做任务调度、资源分配时就会反复返工。1.2 需求获取在嵌入式开发流程中的真实位置很多团队把需求获取当成项目启动前的一两周杂活然后急着进入设计、编码。这是对需求工程最大的误解。对嵌入式项目而言需求获取应该是贯穿项目早期的迭代过程而不是一次性事件。你第一轮拿到的只是用户对系统的大致期望第二轮才可能确认边界条件第三轮往往要结合原型演示才能让用户反应过来“哦原来我要的是这个效果”。我见过一个做智能家居网关的团队需求文档写得很漂亮功能列表一条条列得很全但完全没提“断网后本地自动化规则应该怎样执行”。开发按默认方式实现了——断网后规则全部失效结果部署到用户家里用户发现灯和窗帘在断网时就“死了”体验极差。这就是典型的需求获取环节没有触及真实使用场景只收集了“正常情况”下的功能漏掉了异常、边界、降级运行的场景。所以我说需求获取是嵌入式开发的“地基工程”。地基没打牢上面盖的楼再漂亮也撑不住。这也是我写这篇文章的初衷分享嵌入式系统软件需求获取的实操方法不是教科书式的流程罗列而是我在多个项目里反复验证过的、能真正减少后期返工的干货经验。2. 常见需求来源与获取手段怎么选才靠谱嵌入式系统的需求来源远比想象中多很多团队只盯着“用户访谈”结果漏掉了一大批重要来源。我把实际用下来有效的来源和手段整理了一下供你对照自己的项目情况选择。2.1 需求来源清单别只盯着用户访谈嵌入式系统的需求来源至少可以分成五类每一类都不能省第一类是直接用户或客户。他们提供功能期望、操作习惯、使用场景。这一层最容易获取但也最容易“失真”。因为用户往往描述的是他“想要的结果”而不是“系统应该具备的行为细节”。比如用户说“这个设备要能远程升级”但没说升级过程中断电了怎么办也没说升级失败了怎么回滚。你要做的是把用户的期望转化成具体行为并追问边界场景。第二类是系统与硬件约束。MCU选型、内存容量、通信接口、供电条件、传感器精度、执行器响应时间这些即使客户不提也必须写进需求里。硬件团队给过来的每一个参数都要在需求阶段就确认否则等软件开发到一半发现Flash不够用就只能砍功能非常被动。第三类是行业标准与法规要求。医疗设备、汽车电子、工业控制这些领域尤其重要。比如IEC 62304、ISO 26262、IEC 61508它们对开发流程、文档、验证活动有硬性要求。这些“合规需求”在需求获取阶段就要明确识别否则到认证检测环节才补成本和周期都会失控。第四类是运维与可制造性需求。设备怎么在产线上烧录程序、怎么标记版本、现场工程师怎么调试、用户怎么恢复出厂设置这些需求经常被忽略但非常影响产品生命周期。我见过一个项目功能什么都好就是没有把“设备唯一标识读取”做成独立接口结果量产时产线软件匹配不到设备硬生生拖了两周。第五类是衍生需求。通过分析以上来源自己推导出来的需求比如安全保护机制、异常处理策略、数据备份方案。这类需求最考验经验也最容易被团队遗漏。2.2 获取手段对比每个方法都有自己的主场做需求获取不只“开会访谈”一条路我按适用场景整理了个对照表手段适用场景优点注意点结构化访谈获取显性功能需求、用户期望直接、快速容易被用户带偏需提前准备问题清单现场观察了解实际操作流程、环境约束能看到用户“说不出来”的细节耗时且用户可能因被观察而改变行为原型验证需求模糊、交互复杂的功能让用户直观确认需求原型开发投入需控制警惕用户误解原型即成品场景与用例分析梳理系统在真实环境下的运行流程覆盖正常/异常/边界路径需要用户配合描述详细场景质量属性研讨明确性能、可靠性、安全等非功能需求把模糊的质量期望变成可验证指标需要技术人员深度参与每种手段都不是万能的。比如现场观察我在一个农业灌溉控制器的项目里用过发现农户实际操作时根本不会按照手册上写的步骤来他们会手动开阀、会跳过自动流程、会在设备报警时直接断电重启。这些行为如果只做访谈绝对发现不了但它们直接决定了控制器的软件策略设计。后来我们特意在需求里加了一条“设备必须具备断电恢复后自动回到工作状态的能力”就是现场观察带来的价值。而原型验证在嵌入式上的成本比纯软件高很多因为原型不只是一个界面还牵扯到硬件交互。这里我建议用“最小可运行原型”只实现核心逻辑和必要的I/O交互不要贪多。原型的目的不是交付而是帮助用户确认操作流和数据流帮助开发团队确认技术可行性。3. 从模糊表述到可验证需求一步步拆给你看需求获取的目标不是“收集一堆用户想法”而是产出“可验证的软件需求说明”。这中间有一条很关键的路要走把模糊、口语化、不完整的原始信息转化成结构化的、可测试的、无歧义的需求条目。3.1 需求条目怎么写才能避免“听起来对但没法测”很多团队的需求文档里充满了这种条目“系统应具有良好的响应速度”“界面应友好易用”“系统应具备完善的异常处理能力”。这类表述在评审时没人反对但到了测试阶段就抓瞎——什么叫“良好”怎么测“友好”“完善”到什么程度算完我在实际项目中使用的写法是“能力 条件 指标”三段式。举个例子用户说“设备反应要快”别直接写“反应要快”而是拆成可以验证的需求条目当控制命令通过现场总线到达设备后设备应在50ms内完成校验并向执行器输出新的控制信号。在正常操作条件下从用户按下紧急停止按钮到系统切断执行器电源的响应时间不得超过50ms。系统应能检测总线通信中断并在通信中断持续超过1秒后进入安全状态并给出本地声光报警。再比如用户说“设备要可靠”你就要问清楚他对“可靠”的定义。是平均无故障时间还是某个关键功能的失效率我做过一个数据采集终端的项目用户说“数据不能丢”跟负责的工程师深聊之后确认了可量化的指标在正常供电条件下本地存储数据在掉电后应完整保留不少于30天在通信恢复后应自动补传掉线期间采集的数据补传成功率不低于99.9%。好的需求条目应该具备以下几个特征一是可验证测试工程师看了知道怎么设计测试用例二是无歧义开发工程师看了不会产生“他说的可能是另一个意思”的想法三是粒度适中一条需求描述一个能力不要一句话裹着三四个功能点四是可追溯每条需求都能追溯到它的来源——是用户说的还是标准要求的还是硬件约束推导的。我习惯用表格统一记录这些条目表头至少包括需求编号、需求描述、验收标准/测试方法、优先级、来源、关联硬件/接口。这套格式看着简单但在项目沟通中非常有用尤其是当客户有异议时需求编号可以精确定位到讨论对象而不是在文档里翻来翻去靠记忆猜。3.2 优先级划分不要被用户带节奏需求优先级是需求获取阶段必须完成的工作而且不能完全听用户安排。用户往往把每个需求都说成“必须做”真实情况是受限于项目时间和成本你必须做取舍。我在嵌入式项目里常用的优先级维度有两个价值和风险。价值指的是这个需求对用户核心目标和项目成功的影响程度风险指的是实现这个需求所需的技术不确定性、硬件依赖、对系统其他部分的影响。两个维度交叉可以画出四个象限高价值低风险优先做高价值高风险重点投入低价值低风险看情况做低价值高风险果断砍或延后。比如我已经提过的那个智能家居网关项目“断网后本地自动化规则继续执行”这个需求客户一开始没提我们做优先级分析时发现这个功能虽然只影响一个异常场景但对用户的核心体验影响很大——用户买回家90%时间都依赖本地自动化而不是远程App控制。于是我们把它的优先级提到最高同时单独评估了实现的复杂度需要本地规则引擎、需要掉电保存规则配置、需要在网络恢复后做状态合并。这样一分析开发心里就有底了。我建议优先级一定要跟客户面对面确认拿出分析结果给他看让他理解“为什么这个需求要排后面那个异常场景为什么值得投入”。大多数客户是讲道理的前提是你有数据支撑而不是随口拍脑袋。3.3 质量标准和非功能需求的获取嵌入式系统的非功能需求容易被忽略但往往决定产品成败。性能和实时性是最明显的部分但还有几个经常被遗忘一是功耗。电池供电的设备软件策略直接决定续航。需求获取阶段必须问清楚目标工作电流、待机电流、峰值电流、目标续航时长、充电一次允许的时间区间。这些直接影响任务调度和休眠策略的设计。二是生命周期。这个设备要用多少年在什么样的温湿度环境下工作是否需要支持远程维护维护期间是否允许短暂停机回答这些问题才能定义可靠性需求和维护性需求。三是兼容性和升级性。硬件版本可能迭代通信协议可能升级你的软件需求需要预留兼容策略。很多老产品后期改造困难就是因为在需求阶段没有明确“向前/向后兼容”的要求。四是安全性。这里既包括功能安全比如用软件实施的保护逻辑失效时系统不能进入危险状态也包括信息安全设备联网时的安全认证、数据加密要求。工业、汽车、医疗领域尤其要重视这两个“安全”都可能是一票否决项。有一次我参与一个车载传感器模块的项目客户给的原始需求只有功能列表完全没有提信息安全。我们做需求评审时追问了一句“这个模块和车机之间是怎么鉴权的数据是否需要加密”客户才意识到他们内部的安全规范没有同步过来后来补了十几条安全相关需求。这种事如果到联调阶段才发现改动范围就不是一个模块能控住的了。4. 一次完整的嵌入式需求获取活动我是怎么组织的每次在项目启动阶段组织需求获取活动我都会有一套固定流程。这套流程不算花哨但很实用能保证软件团队、硬件团队、客户三方在短时间内对齐关键信息减少返工。4.1 会前准备是成败的关键很多人以为需求获取最重要的工作是开会其实真正的功夫在会前。我在正式访谈之前一定会花至少两天做以下准备第一收集背景资料。产品定位是什么目标市场是谁有没有上代产品或竞品可以参考客户有没有提供已有的规格书或初步设计书把这些资料通读一遍形成自己的初步理解。第二拉出待确认的问题清单。这些问题不是随便写的而是从背景资料中找出的矛盾点、模糊点、缺失信息。比如资料上说“支持多种接入协议”但没说支持哪几种就需要问再比如“设备在异常时自动重启”就需要追问自动重启的条件、次数限制和重启后的状态。第三明确参与方。访谈不能只叫客户方的项目经理最好能叫上实际使用设备的人、维护设备的工程师、以及客户那边的硬件工程师。不同角色看到的系统完全不同缺一个角色就漏一块需求。第四准备一个简单的需求启发示例。我会提前写几个“坏需求”和对应的“好需求”案例在现场演示给客户看让客户理解我需要的描述粒度。大多数人不是故意把需求说模糊而是不知道怎么表达才够准确。给个示例沟通效率翻倍。4.2 访谈中的提问策略顺着说追问验证访谈中我会分三层提问。第一层是开放式问题比如“这个设备在你们现场主要解决什么问题”“目前你们是怎么做某个操作的”目的是了解背景和真实场景。第二层是细化问题针对对方提到的每个功能点追问“有没有边界情况”“发生什么情况时需要特殊处理”。第三层是验证问题把已有的理解复述给客户听让他确认或者纠正。实际做下来我发现第二层追问是拉开团队差距的关键。比如客户说“设备要支持现场调试”很多需求工程师写到这儿就停了但真正到现场调试过的工程师一定会追问调试接口是本地串口还是远程网络口调试过程中系统是否继续跑控制逻辑调试结束后怎么恢复正常工作模式调试期间如果发生安全报警怎么处理这些追问看着细碎但每个都对应一个后续开发的子功能。访谈过程中一定要现场做记录并且用投影或共享屏幕把记录实时展示给客户看避免“会后各说各话”。我会把记录分成两个区域已确认的需求点、待澄清的开放问题。每聊完一个模块就同步一次让客户随时可以纠偏。这样访谈结束初步的需求骨架基本就出来了。4.3 会后整理与确认需求文档的第一版怎么成型访谈结束后我一般在48小时之内输出第一版需求说明文档趁记忆还新鲜、客户对讨论内容还有印象时及时进入确认循环。文档格式就按我在第3节说的表格来需求编号、描述、验收标准、优先级、来源。这里有一个我自己踩过坑后总结的重要习惯需求文档必须同时发给客户和内部开发团队让双方并行评审。客户负责确认描述是否反映了真实需求开发团队负责评估可行性、识别遗漏约束。有一回我只发给客户确认客户回复“都挺好”结果开发团队一看发现有两个功能当前选型MCU的Flash根本放不下只能再去改需求、改方案白白浪费了两周。需求确认会通常要开一到两轮。第一轮逐条过需求条目确认每条都清晰、无歧义、可验证第二轮重点关注冲突项和优先级排序比如客户要求“成本必须压到某个价位”和“功能必须全保留”这两个目标冲突时需要现场表决策取舍。会议结束输出一份“需求基线”所有后续设计和开发都以此为准。需求基线的调整必须走正式的变更流程这是控制范围蔓延的底线。4.4 需求获取阶段常见的“经验陷阱”做多了你会发现需求获取的很多坑不是技术问题而是沟通和认知问题。我总结了三类最常见的陷阱第一类叫“客户说的就是对的”。很多需求工程师把客户的话当圣旨客户说“要支持”他就写“必须支持”完全不做可行性分析和验证。实际上客户的技术背景有限他可能只是需要一个结果对实现路径并不固执。你有责任基于专业知识给出更合理的实现建议而不是把客户的每个字都落实成需求。第二类叫“开发团队沉默是金”。需求获取不只是需求工程师和客户之间的事开发团队必须参与。我见过太多项目需求评审时开发工程师全程不说话等需求冻结进入开发阶段才说“这个做不了”“那个没预留接口”。正确的做法是开发团队在需求阶段就积极参与对每个需求条目的技术可行性、工作量、风险给出输入把问题解决在早期。第三类叫“过度依赖文档忽视隐性知识”。需求文档再完善也无法覆盖所有上下文信息。有时候客户团队里某个资深工程师头脑里的经验比任何文档都值钱。我会在正式访谈之外主动约这些关键人物喝杯咖啡聊聊从闲聊中往往能听到文档上根本没有的宝贵信息——比如哪个传感器在特定环境下会漂移、哪个通信协议在这个现场会遇到干扰。5. 常见问题与排查技巧实录做嵌入式需求获取你总会反复遇到一些“经典毛病”。我这里挑几个高频问题配上排查思路和解决建议以后你遇到类似情况可以直接对照处理。5.1 客户说“就按上一版改”但上一版文档已经找不到了这个问题在不少维护型项目里非常常见。客户说“你就在上次那个版本上加个功能就行”但项目换了人、文档又没归档大家只能靠记忆对齐需求——这基本是灾难的开端。排查方法很简单不要依赖口头记忆先找到可追溯的基线。如果确实没有文档就花时间从代码仓库的历史版本、测试报告、现场运行日志反向重建需求基线。这个工作不轻松但省不掉否则你改完的功能很可能与客户预期南辕北辙。我的建议是从第一次接触开始就坚持“可追溯”原则每次沟通完都输出一份简短纪要写明“本次沟通确认了什么、变更了什么、疑点有哪些”发给相关人员确认存底。这个习惯成本很低但能为后续需求管理省下很多心力。5.2 用户对“响应快”的评价标准工程师和客户完全不在一个频道有一次做工业读卡器项目客户说“读卡响应要快”开发团队理解成“50ms内读卡成功率高”结果交付后客户仍然抱怨“慢”。现场一看发现用户说的“慢”其实是读卡器在连续读卡模式下第二次、第三次读卡的间隔时间以及读卡成功后指示灯反馈的延迟。前者是算法优化问题后者是I/O响应问题跟“50ms读卡”没有直接关系。这类问题的排查思路是把客户的“主观体验”拆解成“可观测指标”。不要急着跟客户争论“我们已经很快了”而是问他“你能不能描述一下你认为的慢具体发生在哪个操作环节从你按下按钮到设备反应你感觉隔了多久”拿到具体操作场景后用示波器或逻辑分析仪去量真实的延迟时间找到瓶颈在哪里。从需求角度讲这把主观体验转化为“场景 指标”的描述就已经是一次高质量的需求细化了。后续测试也有明确目标可循。5.3 需求评审会上没人说话会后意见铺天盖地这个场景我太熟了。评审会上问“大家有没有问题”全场安静一周后各个相关方的意见通过微信群、邮件、口头转述四面涌来。原因无外乎两个要么参会的人没提前看资料要么他们觉得会议氛围不适合当场提反对意见。我的应对方法是用“主动点名”替代“开放式提问”。评审会前发资料时就附上“我会按需求编号逐条过大家提前在自己关心的条目上标注意见”。会上每过一条需求直接点名负责对应模块的工程师和客户代表先让他们表态再问其他人有没有补充。这个方法听着有点严苛但效率极高也给了每个人必须表达意见的压力反而避免了“会后意见”满天飞的情况。还有一个技巧需求评审会的时间不要超过两小时超过两小时人的注意力急剧下降评审质量会明显滑坡。如果需求量大就分功能域开多场别指望一次性评完所有条目。5.4 需求的“范围蔓延”从一句“顺便加个小功能”开始嵌入式项目开发周期长客户在开发中途提新需求是常态。最怕的是那些“听起来很小”的需求“顺便加一个日志导出功能”“反正都做了再加一个参数显示呗”。每个单看都不大但累积起来就是无底洞直接挤占核心功能的排期。我的处理办法是任何需求变更都要走评审不能口头答应。评审时先评估工作量、对现有架构的影响、对进度的冲击然后走变更审批流程。客户如果坚持要做就要接受相应的周期和成本调整。你不需要当坏人你只需要把事实摆在桌面上让决策者在知道代价的前提下做选择。在需求获取阶段提前做“范围边界说明”也很有用。文档里写明“本阶段明确不做什么”能有效避免后期扯皮。比如“本版本不实现远程固件更新的自动回滚仅实现手动恢复模式”把丑话说在前面后面才好办事。5.5 非功能需求没说清测试阶段才发现性能不达标这种事在嵌入式项目里不少见。需求文档写了“系统应支持100个设备在线”但没说清楚是“同时上报”还是“分时上报”也没说“在什么网络条件下支持”。开发按分时上报设计测试按同时上报来压结果性能一测就崩。排查思路是在需求阶段就为每个性能指标补充测试条件。不要写“系统应支持100个设备在线”要写“在100个设备同时在线且每30秒上报一次数据的条件下网关CPU占用率应低于50%平均数据转发延迟应低于200ms”。这样测试团队知道怎么压开发团队也知道怎么设计。我建议项目启动时就把“性能摸底测试”的初步计划拿出来哪怕只是文档形式。它不是在测试阶段才存在的东西而是应该在需求获取阶段就明确约束和条件这样后续所有技术和资源决策才有依据。6. 实战案例复盘一个工业数据采集终端的需求获取全过程前面讲了不少方法和技巧最后用一个我实际参与过的工业数据采集终端项目做完整复盘把整个流程串起来看你会发现很多理论上的问题在这个案例里都能找到对应。6.1 项目背景与初步接触这个项目的基本情况是给某设备制造商做一个数据采集终端采集设备运行状态数据通过4G网络上传到云平台同时需要在本地保存一段时间的数据作为备份。客户最初提供的需求描述非常粗糙大概只有几段话要做个盒子能采数据能联网上传数据不能丢能在手机上看到设备状态。显然这个信息量完全不够支撑开发。我们做了两轮深度访谈第一轮是客户方的项目经理和市场人员了解产品定位和商业目标第二轮是客户方的硬件工程师和现场维护人员了解部署环境和运行场景。通过这两轮访谈我们梳理出了几个关键边界条件现场供电不稳定经常有短暂断电网络信号在部分厂区较差可能长时间离线客户需要远程修改采集参数但不能开放所有参数只允许修改采样频率和上报周期。这些信息直接改变了需求设计方向。比如“数据不能丢”就不再是一句口号而是变成了一系列具体需求本地存储空间需要支持至少7天的数据缓存、掉电数据不丢失、网络恢复后自动补传等。如果没有第二轮访谈按最初的理解去做大概率会在产品部署后出现“数据丢失”的客户投诉。6.2 需求分析中的几个关键决策这个项目里有两个决策很有代表性。第一个是本地数据存储方案。客户最初设想的是用SD卡存储但我们评估后发现现场环境有振动和粉尘SD卡接口的可靠性存在风险。同时设备需要支持频繁的断网补传存储写入模式必须高效稳定。后来我们综合评估了嵌入式存储方案的成本和可靠性在需求文档里明确为“使用板载存储器存储容量不低于4GB”同时补充了“存储介质应支持至少10万次擦写循环”的需求。这个变化在需求阶段就完成了开发团队就不用在后期为存储方案的技术选型纠结也不用担心客户在量产阶段突然提出换存储介质的小道消息。第二个是远程参数配置的安全控制。客户说“远程能改参数就行”但开发团队追问了“哪些人能改、怎么确认权限、改错了怎么办”之后才把这一条拆成一个完整的配置管理需求配置通道需要设备认证、配置操作需要记录日志、参数修改后需要设备重启生效或热加载。这背后其实是信息安全需求和可维护性需求不拆开的话开发时会漏得很难看后期被攻击或误操作时再补救就晚了。6.3 成果物与复盘最终我们交付的需求文档不是一本厚册子而是一套结构化的表格加说明大概分成六块系统概述与运行环境、功能需求、非功能需求、接口需求、安全与可靠性需求、需求追溯矩阵。每一块都用我前面讲过的“能力 条件 指标”写法进行描述。客户的技术负责人对这套文档的评价是“把模糊的想法变成了可以逐条验收的条款”。这个项目的复盘也让我固化了几条经验第一需求获取不是“收集信息”而是“共同设计”。你要跟客户一起把一个模糊想法变成一个具体系统的描述。客户不一定比你懂技术但他比你懂业务场景你比自己更懂实现方案——结合起来才能做出靠谱的需求。第二需求获取必须“生产出文档”而且要快。趁信息还没凉趁客户还在意这件事把文档发出去确认。拖得越久越没人愿意认真看后面漏需求的概率越大。第三需求获取阶段就要让测试人员介入。测试人员的思维方式是“我怎么才能证明这个需求被做对了”这种思维在驱动需求细化时特别有用。你写“设备应支持远程升级”测试人员会问“升级断网怎么办升级包校验失败怎么办升级成功后需要重启吗”这些问题对完善需求太重要了。7. 写在最后需求获取是持续校准的过程如果你问我做嵌入式系统开发这么久最想对后来者说什么我会说需求获取不是项目启动前的一个关卡而是贯穿整个开发过程的持续校准。因为嵌入式系统太依赖物理环境、硬件行为和用户操作习惯而这些变量在项目开始前不可能100%被看清。你在开发中会不断发现新问题、新约束、新场景这时你就要回头审视需求文档判断它是否需要更新。这不是“需求没做好”而是“需求获取在持续进行”的正常表现。我自己的习惯是每周花半小时到一小时把本周开发中遇到的“理解偏差”“新场景”“新约束”记录在需求文档的待澄清区里周会时同步给客户和开发团队。这样需求文档就变成了一个动态文档而不是开工后就被封印的僵尸文档。关于需求获取这个主题能讲的东西还有很多比如自动化工具、建模语言、团队协作机制但核心思路始终不变把不确定变成确定把模糊变成具体把“我以为”变成“我们确认过”。如果你正准备启动一个嵌入式项目我的建议是别急着画架构图、写代码先把需求获取这关扎扎实实过一遍——你省的不仅是后期改代码的时间还有团队的信心和客户的信任。最后再分享一个花了多次项目才笃定的技巧需求获取全程要保持“幼稚的好奇心”。不要因为某个问题听起来太基础就不敢问比如“这个按键按下去之后用户希望在1秒内看到什么反馈”。大部分需求遗漏都不是因为大家不懂技术而是因为不再像新手那样追着问“然后呢”。做一个对需求有执念的人项目会变得顺利很多。