简介ISO/IEC/IEEE 29148:2018 国际标准完整英文电子版内容聚焦系统和软件工程生命周期中的需求工程适合软件工程师、系统架构师、需求分析师、项目管理人员及相关专业学生阅读参考。资源包内仅含 1 个 PDF 文件大小约 3.51MB共 104 页原版排版清晰便于全文阅读、检索与按章节定位。目前已有 160 人下载学习。该标准正文依次涵盖范围、规范性引用文件、术语定义与缩写、符合性要求、前言及引言等完整结构系统规定了需求获取、需求分析、需求规约、需求验证和需求变更管理等活动的要求并明确了各项活动对应的任务与责任。标准适用于软件项目、系统项目和 IT 项目等各类项目类型对开展需求工程实践、建立流程规范或进行标准符合性评估均具有较高参考价值也适合作为需求工程相关课程与培训的延伸阅读材料。1. 需求工程标准为什么值得读291482018 到底管什么如果只让我从手头挑一份需求工程资料长期放在桌面我不会选某本书而是这份 291482018 标准文档。它不是科普读物而是系统和软件工程生命周期中“需求工程”的权威流程定义覆盖了需求的定义、开发、分析、验证和管理环节。很多人误以为它只是一堆术语和条文其实它真正解决的是“什么叫需求、需求怎么分类、怎么写才算正确、怎么管理变更和追溯”这些项目里最容易扯皮的问题。适合刚接手需求规格说明书的新手也适合被变更流程搞得焦头烂额的开发负责人。反直觉的一点是它并不教你写需求句子的语法而是给你一套评审需求文档的底线标准。读完之后你和同事争论“这条需求到底该不该写、写到什么粒度”时终于有了共同依据。2. 从标准到落地需求工程的核心流程与术语拆解2.1 需求工程在生命周期中的位置从概念到退役的输入输出291482018 将需求工程描述为生命周期流程的一部分横跨概念、开发、验证确认、运维和退役阶段。它的核心是把利益相关方的需要转化为一套可被系统设计、测试和验收引用的需求集合。我一般这样理解它的边界输入是业务目标、用户期望、法律法规和现有系统约束输出是利益相关方需求说明、系统需求说明以及需求追溯信息。需要注意需求和设计不是一回事需求描述“问题域”设计描述“解决方案域”。标准把两者之间的转换流程也做了定义避免你直接把实现方案写进需求规格。下面用表格说明需求工程活动与生命周期阶段的典型对应关系。这个表格不是标准原文而是我按照标准要求整理出的落地映射方便你对照自己当前的项目阶段。生命周期阶段需求工程活动典型输入典型输出概念阶段利益相关方需求开发和用户需求分析业务目标、用户访谈记录、原型利益相关方需求说明开发阶段系统需求开发利益相关方需求、系统架构约束系统需求规格说明书验证确认阶段需求验证与确认需求规格、测试用例验证报告、追溯矩阵运维阶段需求变更管理变更请求、缺陷报告变更评估记录、更新后的需求基线你在实际项目中如果连“利益相关方需求”和“系统需求”都混在一起后面的追溯矩阵和测试验收一定会翻车。标准明确把这两类需求分开定义还给出各自的关注点。利益相关方需求描述用户在特定场景下的预期能力不涉及实现细节系统需求把能力分解为系统的功能、性能、接口和约束可以被工程团队实现并验证。曾经有个项目组在评审会上争论“系统应该能在一分钟内启动”这条需求到底是利益相关方需求还是系统需求按标准拆解如果它来自用户预期的操作时长那么属于利益相关方需求如果它进一步规定了系统进程加载和资源初始化必须在 60 秒内完成则属于系统性能需求。这个区分直接决定验证方法和责任归属。2.2 需求类型与属性功能、性能、接口与约束怎么分类标准里没有强制把需求分成几个固定类别但定义了需求应具备的属性集合。实际工程中团队通用的做法是分五类功能需求、性能需求、接口需求、约束、非功能质量需求。分类的目的是为了后续验证和测试设计不同类别对应不同的验证手段。需求类型描述角度典型验证手段容易踩的坑功能需求系统“做什么”测试用例、场景演示写成“系统支持……”不写可观察结果性能需求量化到什么程度性能测试、基准测试只写“高效”不写具体数值与条件接口需求系统内外交互关系接口测试、一致性检查只写协议名不写数据格式与速率约束必须遵守的限制代码评审、合规审查把设计选择当成约束质量属性可靠性、安全性、可维护性等可靠性分析、安全评估没有定义度量指标需求属性是每个需求条目上的“身份信息”。我强烈建议你在需求条目模板里至少包含这几个属性唯一标识、需求文本、类型、来源、优先级、状态、验证方法、可追溯性。其中“验证方法”最好默认填“分析、演示、测试、检查”中的一种。标准对需求属性有专门讨论但它不强制你用什么字段名而是在过程要求里要求每个需求必须能被唯一标识、能被识别状态并有来源支撑。这份 29148 的价值就在这里它不指定工具和模板但给出要求允许你根据项目裁剪。2.3 需求质量特征与可验证性好的需求长什么样291482018 定义了一套需求质量特征这些特征是需求评审和自检的检查底线。常见包括正确、无歧义、完备、一致、可验证、可追溯、可行。不用死记只需要把每一条转成一个提问信号这条需求是否正确反映了利益相关方意图是否只有一种解释是否覆盖了所有必要场景有没有和其他需求打架能否通过一种已定义的方法验证能否追溯到上级需求是否在成本和技术上可行其中“可验证性”是重中之重。它决定你的需求是活的还是死的。一条无法验证的需求无论写得多么漂亮最后都会成为验收扯皮的导火索。标准要求的验证方法分为四类我常用它来反问需求编写者测试通过运行系统或系统模型执行规定的输入并观察输出分析通过数学计算、建模仿真或逻辑推演来确认演示通过运行系统功能观察其符合性的定性结果检查通过审查文档、图纸、代码或配置项来确认符合性。如果一个需求对应不到任何一种验证方法请立刻打回重写。这是这份标准带给我的最大改变从“凭感觉评审”变成“逐条找验证方法”。你可以在需求条目模板里增加一个必填字段“验证方法”并且限制可选值为上面四种这样不会有人再写“系统应具有良好的用户体验”这种只有形容词、没有度量、也没有验证方法的需求。3. 实际工作中怎么用需求开发、管理与验证的典型操作3.1 需求获取技术访谈、原型、场景分析怎么选29148 过程要求里的第一步是定义利益相关方需要帮助你找出真实的使用场景和期望。常见的需求获取技术包括访谈、问卷调查、原型演示、头脑风暴、场景分析、观察现有系统等。标准不会告诉你用什么技术但要求你必须通过一个已定义的过程来收集利益相关方需求而不是拍脑袋。选择技术的原则我很简单不确定用户怎么看就做原型不确定流程怎么走就做场景分析不确定历史问题就做访谈加问卷调查。每次获取活动都要有产出物产出物至少要记录参与角色、时间地点、讨论的关键点、形成的需求条目草案。访谈之后要把录音转成文字再用“需求过滤表”把原文变成候选需求过滤表列几列原话、关键要素、候选需求陈述、对应利益相关方类型。这一步做下来你才能真正把用户口语翻译成工程语言。举个例子用户说“设备不能经常死机”这是不完整的需求。通过场景分析和访谈追问你可能得到“设备在 90% 的持续运行时间内不因软件故障导致重新启动超过一次平均无故障时间不低于 500 小时”。这才是一条可以用验证方法检验的需求。标准对“正确性”的定义包含真实反映利益相关方需要所以不能跳过这个翻译过程。3.2 需求分析建模从文本需求到系统模型的映射需求分析的难点在于把一堆文本变成结构化的、可被设计使用的信息。常见做法是给每条需求建立唯一的标识拆分为原子级需求然后建立需求追溯矩阵。实际操作我一般分成三步对每个需求条目分配一个唯一标识例如 SYS-FUNC-001格式建议是“层级-类型-序号”。把复合需求拆成单条保证每条只表达一个意思便于验证和变更跟踪。建立追溯矩阵把上级需求映射到下级需求再把下级需求映射到设计元素和测试用例。需求ID需求文本类型来源优先级验证方法设计元素测试用例SYS-FUNC-001系统应能在 5 秒内完成启动性能用户访谈高测试启动模块TC-001SYS-IF-002系统应支持串口 115200 波特率接口硬件约束中演示通信模块TC-002SYS-CON-003系统应满足相关行业标准要求约束合规要求高检查安全模块TC-003这个矩阵看起来简单但能坚持维护好的团队并不多。很多团队在项目初期把矩阵填得满满当当一进入开发阶段就忘了同步。我一般用版本号控制矩阵在每次需求基线更新后强制走一遍“需求到测试”的映射没有对应测试用例的需求必须说明理由。3.3 需求管理流程基线、变更控制、追溯性矩阵落地需求管理在 29148 中包括配置管理、变更管理和追溯性管理。先把需求基线建立起来之后任何变更都要走变更控制流程。标准要求的不是复杂工具而是纪律。我习惯的最小变更流程是四步提交变更请求说明变更原因、提出人、影响评估初步结论影响分析核对受影响的上级需求、下级需求、设计元素、测试用例和项目进度决策评审由项目经理和关键干系人决定接受、拒绝或延期更新基线接受后更新需求条目、追溯矩阵和测试计划并通知所有相关方。这些步骤可以用一个简单的表格跟踪。状态字段为“提交、分析中、已评审、已接受、已拒绝、已实施、已验证”。只有状态走到“已验证”需求变更才算闭环。很多团队只更新了需求文档却忘了更新测试用例导致测试还在测旧需求这就是典型的追溯断裂。标准里的“双向追溯”要求每个下级需求都向上追溯到来源每个上级需求都向下分配到实现和验证环节。你可以用每周检查一次追溯矩阵来堵住这个漏洞。4. 避坑需求工程落地时最容易翻车的 5 个问题写这一章是我两次项目交付延期的血泪总结。每条记录都是真实项目里见过的场景按现象、原因、解决三步展开。4.1 编写阶段设计混入、词法混乱、虚词满篇问题 1需求写得太“聪明”把设计实现直接塞进需求现象需求规格书里出现“系统应采用缓存来提高查询速度”这类句子。评审时大家觉得没错开发也照着实现但复盘时发现真正的性能需求是“系统应在 300 毫秒内响应查询”而具体的缓存技术是设计选择。原因把“怎么做”和“做什么”混淆了。需求工程师急于表现得懂技术于是把方案当需求写。解决引用标准的说法需求必须关注与问题域相关的能力和条件而不是解决方案。改成“系统应在 300 毫秒内完成查询响应且支持每秒 100 次并发查询”。如果一定要限制技术选型把它放入约束或设计文档而不是需求。问题 2should、will、must 乱用但没人知道谁对验收负责现象文档中 could、should、may、shall 混用测试和验收时每一方有自己的解释。开发说 should 是建议用户说 should 是强制。原因没有统一的需求词法。平时口语习惯带到了正式文档里。解决参考很多项目团队的通行做法规定“shall”表示强制性需求“should”表示推荐但可选“may”表示允许的可选。在需求条目模板增加“强制性”字段值为“强制/可选”。同时写一条审核规则除“shall”外的动词不作为测试依据。从那以后我的团队评审需求时先查动词再讨论内容。问题 3把“无歧义”理解为“多写形容词”结果越写越虚现象需求文本写了大量“友好的界面”“有效的数据处理”看起来描述细致但验证时无从下手。原因没有用“可观察结果”来描述需求。所谓无歧义是指不同的人阅读时得到唯一的理解而不是指包含更多副词。解决改写思路是给需要验证的需求增加可观察的输入、条件和结果。无效短语通常不会通过“验证方法”必填字段的审查如果写不出任何一种验证方法这个词就是无效的。我在需求文档里加了一条约定凡是出现“友好的、有效的、良好的”等词必须在该条需求下补充可量化的定义。标准虽然不提供词表但可验证性特征提供了同样的判断依据。4.2 管理阶段优先级虚设、追溯断裂问题 4优先级永远都是高等于没有优先级现象每个需求编写者都把自己的功能标成 P0开发与测试无法排定资源交付时只能靠吵架。原因没有给出优先级定义和评判维度。解决定义优先级的三层标准必须完成不完成无法交付、应该完成有明确变通方案、可选资源允许则实现。评判维度包括业务价值、风险和依赖关系。并要求每条需求标注来源角色例如“产品经理”“客户代表”这样出现冲突时可以找到负责人仲裁。这个优先级字段在 29148 中可以落实到需求条目属性里。问题 5追溯矩阵只做正向追溯需求变更后测试用例没跟上现象用户要求修改某个流程需求更新了但测试计划和用例还是旧版本上线后功能不匹配导致返工。原因变更影响分析只检查了需求和设计漏掉了测试环节追溯矩阵没有作为变更评估的必备输入。解决在变更流程里强制要求“影响范围”清单必须包含测试用例、需求条目、设计元素、接口文档。我一般会在追溯矩阵中增加“关联测试”列每次变更评审时如果矩阵里没有提供关联测试清单则打回影响分析报告。这个习惯帮助我避免了不少潜在的交付事故。5. 上手一本标准文档如何高效阅读 291482018 并用于实际项目5.1 先把目录读成流程从术语到附录的阅读顺序拿到 104 页 PDF不建议从第一页逐字读到最后。我的阅读顺序是先读目录里的术语和附录再读过程要求。因为你带着问题去读才能把标准条款映射到自己的流程里。下面是一个可以照做的阅读计划。阅读顺序关注的章节内容阅读目标建议产出第 1 步术语定义统一团队语言建立需求术语表第 2 步需求工程过程概述建立全景流程画出适合自己团队的流程图第 3 步利益相关方需求定义过程掌握输入输出与活动设计访谈/原型记录模板第 4 步系统需求开发过程掌握需求条目与评价特征建立需求条目模板第 5 步需求管理与追溯相关条款掌握基线、变更、追溯制定变更控制流程第 6 步附录/示例参考文档大纲对照现有文档差距我第一次读这本标准只用了三个晚上不刻意背条款只问自己当前项目的哪个环节让我最痛苦再翻到对应章节找要求。标准本身像一本字典不需要全记住需要时能查到就是最大的价值。5.2 提炼能直接抄进公司流程的条款大多数团队不会把标准原样照搬而是把要求转成自己的模板和规则。我常用的做法是把 29148 中的要求逐条映射到公司文档模板里。比如标准要求需求具有唯一性、可追溯性、可验证性体现在模板上就是条目标识、追溯矩阵和验证方法三个字段。再比如标准要求需求开发过程中考虑运行环境和约束模板上的“关联约束”列就需要把相关约束与背景资料联系起来。下面是我整理的一个需求条目模板字段清单你可以直接抄进自己的表格。字段名是否必填填写说明需求ID必填格式“项目-类别-序号”需求文本必填一句完整陈述包含条件与结果需求类型必填功能/性能/接口/约束/质量来源必填文档编号或利益相关方名称优先级必填P0/P1/P2强制性必填强制/可选验证方法必填测试/分析/演示/检查约束关联可选涉及的外部约束编号实现阶段可选版本里程碑每次新项目启动我都会把这张表发给团队成员并在需求评审时逐条检查。它不一定完美但能保证最低限度不遗漏关键属性。5.3 对照标准审阅现有需求文档的检查单想用这份标准做一次需求文档体检可以按下面的检查单快速执行。这组检查项提炼自标准的核心要求而不是全部条款适合一轮两小时的评审会议。检查项判定标准检查方式需求可追溯性每条需求能回溯到来源抽查 10 条需求检查“来源”字段需求无歧义不同评审人给出的关键指标理解一致多人独立复述需求含义需求可验证至少有一种验证手段逐个查看“验证方法”字段需求一致性没有两条需求互相矛盾交叉比较相似功能需求需求完备性覆盖已知场景与约束对照用户场景清单需求可行性技术成本与进度可接受由架构师评审确认我在实际项目里不会一次检查所有需求而是抽取最有代表性的核心功能需求段按 6 个检查项打勾。检查结果如果在 6 项中少于 4 项我就判定这份需求规格书不合格需要打回修改。这比凭感觉“看起来挺详细”要靠谱得多。标准的最大价值不是让你背诵某个条文而是让你无论在哪个阶段都有一个可量化的评审依据。6. 验收入门用标准条款自评需求文档的一个落地小技巧如果你没时间做完整流程这里分享一个我每次写需求规格书都强制走一遍的自评技巧抽 10 条需求逐条填写“验证方法评估表”把它当作验收前排雷动作。操作步骤从需求文档里随机抽取 10 条尽量覆盖不同功能模块为每条需求回答四个问题这条需求是否有唯一标识是否有量化性能或明确结果是否来自已记录的来源是否至少对应一种验证方法给每条需求打分每个问题为 1 分低于 3 分的需求标记为“待修改”把所有“待修改”需求集中起来组织一次快速修订会。需求ID唯一标识可观察结果来源明确验证方法得分结论SYS-REQ-01211103补充验证方法SYS-REQ-03410113量化结果缺失SYS-REQ-05611013来源需补充这个技巧看起来简单但真的能让需求质量暴露无遗。有一回我负责的模拟项目X开发团队说需求评审都通过了结果我用这个表一查发现标准要求的“验证方法”栏有三分之一写的是“人工查看”而不是四种方法中的任何一种。后来我们花了两天才把这些需求改到可验证状态。从那以后我每次写需求文档都强制自己抽 10 条做这个自评填写验证方法评估表全部达到 4 分才敢提交评审。这正是 291482018 最实用的价值它没有替你想好怎么写但给了你一套“什么时候算写好”的判定依据。希望这个自评技巧也能帮到你。本文还有配套的精品资源点击获取