简介这是一份国际标准完整英文电子版标准号为ISO/IEC/IEEE 29148第二版发布于二〇一八年共一百零四页主题为系统和软件工程生命周期过程中的需求工程。资源面向系统工程师、软件需求分析师、项目经理以及质量保障人员用于规范需求获取、需求分析、需求规约、需求验证和需求变更管理等核心活动。该标准与ISO/IEC 15288、ISO/IEC 12207等生命周期标准配套使用适用于软件项目、系统项目和IT项目等多种类型为需求工程实施提供统一框架、术语定义和一致性要求有助于减少需求歧义、降低返工风险。资源为单个PDF文件包体大小三点五一MB内容包含范围、规范性引用、术语与缩写、符合性要求、前言及介绍等完整章节可直接作为编写需求规格说明、制定需求评审检查单和建立需求管理制度的参考依据。已有约一百六十人浏览学习适合希望深入掌握需求工程国际规范、提升需求过程能力的从业者使用。1. 用一份 104 页的英文标准先解决需求工程里最贵的问题拿到 ISO IEC IEEE 291482018 这份 Systems and software engineering — Life cycle processes — Requirements engineering 完整英文电子版第一反应往往是又是英文又是 100 多页大概只能躺在硬盘里吃灰。但真正被需求漏项、变更失控、验收扯皮折磨过的人会换个姿势看它这份标准解决的是需求工程里最贵的问题——需求从哪来、写成什么样算合格、怎么证明它被满足。本文不逐页翻译而是站在从业者角度把这份标准吃透怎么读、怎么裁剪、怎么写条目、怎么做验证、坑在哪。适合需求工程师、系统工程师、项目经理更适合刚转岗做需求管理的开发负责人。读完之后你手里会多一套能直接复用的评审方法和检查单。2. 先读懂再动手29148:2018 的章节主线与三种实用读法2.1 为什么必须看“生命周期过程”而不是只翻 requirements 章节标题里那串词不是装饰。ISO IEC IEEE 29148:2018 讨论的并不只是“怎么写需求文档”而是把需求工程放在生命周期过程里定义。原因很直接需求既不是起点也不是终点。任何一个系统从概念阶段开始到架构设计、详细设计、集成、验证、确认最后到运行维护中间每一步都在消费需求、也会倒逼需求变更。如果只盯着文件里带 requirements 字样的部分就会丢掉需求工程和后续验证活动之间的闭环。打个比方很多人把需求工程理解为“把用户想法记下来”于是做完访谈、写出一版需求规格就以为流程结束了。标准不这么看。它把你做的事情拆成一组活动引出、分析、规格化、验证和确认。这五件事不是五份独立文档而是五类必须持续执行的过程动作。哪怕你在敏捷迭代里也一样要回答一个问题这一轮迭代新增的需求有没有验证方法有没有确认渠道如果没有需求就没有真正完成。我一般会建议团队先把标准里的“过程”二字圈出来。它意味着这套做法不绑定具体开发模式。你是瀑布也好敏捷也好或者基于模型的系统工程也好都能把过程动作嵌进去。你要做的是把需求工程当作一条持续工作的流水线而不是项目计划里的某个里程碑。这就是 29148:2018 和许多“需求写作指南”的本质差别后者告诉你措辞怎么雕琢前者告诉你过程怎么运转。弄懂这个区别104 页读完就已经值了。2.2 扫读、精读、回查适合从业者的三遍式读法我拿到这份标准后不会从第 1 页一直读到第 104 页。那样读既慢又记不住。正确方法是把阅读拆成三遍每一遍带着不同任务。第一遍是扫读。目标只有一个建立标准的地图。花一两个小时把目录读细把正文里每一处带 shall 的句子做上标记把术语定义里不理解的关键词记到一页空白笔记上。这遍不要求看懂每条内容只要求你能回答“这份标准到底覆盖了哪些事”。第二遍是精读。目标锁定在需求工程流程本身把引出、分析、规格化、验证、确认这些动作各自对应的输入和输出记清楚。读到某个活动时马上想一想这个动作在我的项目里对应哪位角色、哪份文档、哪个工具这部分通常用两个整天可以完成。第三遍是回查。它不是系统性重读而是按需定位。比如评审前只查“可验证性”相关条款出需求规格前只查“内容要求”相关条款争议发生时查术语定义。回查越勤你对标准的熟悉度越深。三遍式读法可以整理成一张表直接贴在项目知识库里读法目标主要输出物扫读建立全书地图标记 mandatory 条款与术语章节地图、术语盲点清单精读理解需求工程活动的输入、输出与质量要求过程活动卡片、角色责任表回查按评审或审计场景定位原文评审问题清单、合规性证据注意精读阶段最忌讳逐词翻译。英文标准读得再细最终能落到项目上的不是一段译得漂漂亮亮的文字而是一条能推进工作的规则。我自己的习惯是精读时只做动词式笔记比如“输出利益相关方需求规格”“记录需求来源”“建立需求与验证项之间的追踪关系”。这类笔记在工作中复用率远高于翻译稿。2.3 把 104 页拆成可引用的条目章节地图与速查完整英文电子版的好处之一是便于检索。但检索的前提是你知道文档大概分为哪几个区域。对于 ISO IEC IEEE 29148:2018 这类标准文件常见结构是前言与引言、范围、规范性引用文件、术语和定义、主体流程内容、对具体文档的要求、以及资料性附录。其中“规范性”和“资料性”的差别很大前者是要求后者是参考。拿到 PDF 以后第一件事不是读而是把这一结构做成自己的速查索引。我会在 PDF 阅读器里做三件事一是为每章建立书签并把书签命名改成自己能看懂的短名而不是保留默认的 Chapter 4 这类命名二是把术语定义集中复制出来形成项目内部术语速查表三是把正文里带 shall 的句子单独摘出来标记为“评审时引用优先级最高”的内容。这样一份标准就从一个完整 PDF 变成了若干引用块评审会或方案讨论时能快速给出依据。还要注意引用方式。对外部评审或审计来说写“根据某标准”太模糊。规范的引用应该精确到条款号并给出原文摘录。一个可靠格式是项目内容标准名称ISO IEC IEEE 29148:2018引用条款条款号或章节名原文摘录英文原文不超过两句话本项目适用性说明为什么这条与项目相关准备怎么做这样做的价值在于需求评审中一旦出现分歧双方可以直指原文而不是各自凭印象争论。很多团队说“我们已经在用 29148 了”其实只是在文档封面挂了一个名字。真正用起来的标志是团队能够在每次评审时快速地引用和讨论它的原文条款。3. 从 PDF 到项目资产完整英文电子版怎么组织、裁剪和受控3.1 先做一件事给 PDF 建索引而不是把文件丢进共享盘一份英文标准被下载下来以后最常见的做法是放进共享盘一个“标准资料”文件夹里然后就再也没人打开。原因不是大家不爱学习而是标准没有变成工作接口。想让 ISO IEC IEEE 29148:2018 真正成为项目资产先要替团队把障碍拆掉。我先做的是索引。具体动作包括把 PDF 分成若干逻辑区块每个区块对应一到两个常见工作场景。例如“术语定义”对应评审争议处理“主体流程”对应过程裁剪“文档内容要求”对应编写模板。然后在笔记工具里建立一张章节地图写清楚这一块讲了什么、我在什么场景下会回来找它。这个动作不需要花太长时间但它解决了两个实际问题第一新成员不会面对一份 104 页的英文文档发怵第二老成员能在三分钟内定位一条规则。索引之后再给 PDF 建立版本识别信息。建议在文件名或文件属性里记录三样东西标准编号、年份、项目内部简称。比如“29148-2018-需求工程-受控版”。不要用“最终版”“新版本”这类名称评审时没人知道“最终版”是哪一版。3.2 裁剪到项目哪些条款必须用哪些可以按项目改这里必须说清楚29148:2018 是过程标准不是文档模板大全。完整英文电子版里的很多要求讲的是“一个规范的需求工程过程应当包含什么”并没有规定每个项目都必须原样照做。照搬所有条文通常会得到一份比标准还厚的公司模板最终没人看。正确的做法是裁剪且裁剪要有依据。裁剪的第一层是流程裁剪。小型项目、内部原型、合规审计不涉及的项目可以在过程活动上做明显简化。比如一个只有研发没有外部交付的原型机未必需要完整的利益相关方需求规格与系统需求规格双层结构可以把两层合并为一层。但即便合并需求的来源、验收标准和变更记录也不能丢。裁剪的第二层是文档裁剪。标准要求的是过程结果不要求文档数量和名称完全一致。你完全可以采取轻量文档但要能证明每个过程结果都有载体。第三层是模板裁剪。把标准里规定的内容条款当作必须覆盖的信息项放进公司既有模板而不是把标准原文粘贴到模板里。每次裁剪都要留下一行记录写清楚“裁掉了什么、为什么裁、风险是什么”。举个例子裁剪对象裁剪决定理由风险与应对利益相关方需求规格单独成文与系统需求规格合并项目规模小团队不足十人需求来源仍需追踪合并文档中用表格维护来源形式化验证活动改为评审与测试验证产品复杂度低对安全相关需求仍保留独立验证记录完整术语表只维护关键英文术语团队长期使用中文中文术语歧义风险由评审会机制兜底裁剪不是逃避而是把有限资源集中到高价值需求上。一个常见误用是到了验收阶段才发现标准里该做的事没做于是临时补文档。那不是裁剪是事后补票。真正的裁剪发生在项目早期并且有人对后果负责。3.3 术语表先行shall、should、will 的区别决定了合规判断阅读英文标准的第一道门槛不是长句而是情态动词。ISO IEC IEEE 29148:2018 这类标准里shall、should、will、may 四个词的含义是完全不同的。shall 表示要求是强制性的不做就不满足标准should 表示推荐是期望但不构成最低合规条件may 表示允许will 通常用于声明意图或陈述事实。中文里这几个词很容易被糊成同一个“应该”或“可以”这是后来评审争议的常见来源。项目里该怎么做建立一张术语表把每个关键情态动词固定成中英对照。比如在需求条目模板里约定凡需求正文有强制性约束一律写成“应”且同时保留英文原文或英文关键词“shall”。当某个外包方、硬件组、算法组对“应该”是不是硬性指标有分歧时直接看它对应的是 shall 还是 should立刻就能确定判断性质。术语表覆盖的不只是情态动词还包括需求工程里的高频词。stakeholder、requirement、verification、validation、traceability 这类词在中文里有多种译法比如 validation 常被翻成“验证”verification 也常被翻成“验证”结果两个含义完全不同的过程在中国团队里成了同一个词。这样的错误在地道的英文标准评审中尤其危险因为评审人一说“这项要不要 validation”翻译不一致会导致负责人答错题。我建议术语表采用三列结构英文原文、中文译名、项目内部含义说明。并约定对外文档中第一次出现时保留英文原文之后用中文名。防止“验证”和“确认”混用。千万别小看这个动作。很多团队跑到项目后期发现需求来源、验证方法、验收准则不能闭环根子不是能力而是术语从一开始就是乱的。4. 把 29148 变成日常流程规格编写、验证与追踪的落地路径4.1 需求条目怎么写主句、条件、约束与验收标准读了标准之后最该变成肌肉记忆的是需求条目的写法。常见做法是把一条需求拆成四部分主体、条件、行为、约束与验收标准。主体回答“哪个对象”条件回答“什么情况下”行为回答“要做什么”约束与验收标准回答“做到什么程度算完成”。这四个部分缺一个需求就可能出现歧义或不可验证。实际写出来的句子可以按下面的模板组织 “在[条件]下[系统或部件]应[行为]使[性能目标]并通过[验证方式]确认。”这看起来像套话但它保证了两个关键属性一是用了“应”对应 shall表示这是强制性要求二是它把验证方式写进需求正文而不是跑去测试计划里补。频道可以灵活调整比如先写行为再补条件但信息不能少。团队内部也可以把模板做成字段化让需求工具里每条需求自动由若干字段拼接成完整描述。对于更复杂的情况我一般会引导团队用表格管理单条需求。字段可以是需求编号、需求文本、来源、优先级、验收准则、关联风险。每个字段都有明确出处评审时逐列过不可能出现“需求本身谁都看不懂只能靠当面口头解释”的情况。口头解释能蒙混过去的一次评审早晚会在审计或测试阶段变成返工。写需求条目的另一个要点是“一条需求只表达一个要求”。很多工程师喜欢写一条大而全的需求把多个行为塞进同一句。表面上文档精简了实际上无法验证因为不同行为的完成条件不同。遇到这种情况宁可拆成两条分别给编号和验收准则也不要让评审人揣测你的断路器。4.2 可验证性检查用标准里的质量属性当评审清单ISO IEC IEEE 29148:2018 对需求质量有一个非常重要的提示需求不仅要正确还要具备可验证性、无歧义性、完整性、一致性、可实现性等属性。这些词不是考试概念而是评审现场的操作指标。每次需求评审前我建议把质量属性转成提问逐条过一遍。把质量属性翻译成评审问题时可以这样设计检查维度评审提问不通过时的现场表现必要性这条需求没有会怎样没有它也能满足业务目标说明这是伪需求无歧义性两个工程师理解是否相同现场两人给出不同解释完整性条件、约束、指标是否都写全了只写“速度快”没有数值和场景可验证性能否设计一次测试或分析证明它被满足测试人员无法给出验证活动一致性与其他需求和系统约束是否冲突两条需求互相矛盾却同时存在可实现性在当前技术条件下是否可能按期做到超出能力边界且没有备选方案评审会上最有力的做法是对每一条需求都逼问“可验证性”。如果这条需求不能关联到某个测试、分析、演示或检查项那它应该回到编写者手里继续改而不是进入基线。这不是苛刻。测试阶段最大的成本来自“需求不可验证”和“需求本来就是愿望清单”后者往往到了验收才发现。另外可验证性检查要注意“分析”作为一种验证手段不是万能的。对某些复杂系统需求里写着“应具备良好可靠性”这类无法从文本推导出验收条件的话需要补成具体指标比如故障间隔时间、可用率、最大恢复时间并说明这一指标通过仿真分析还是实测来确定。没有这种细化可靠性需求就是一句口号。4.3 追溯关系怎么建从利益相关方需求到系统需求的回查需求追溯是贯穿标准的重要主题。它回答一个问题每条系统需求从哪里来又流向下游哪一步在 ISO IEC IEEE 29148:2018 所描述的框架里最常见做法是把利益相关方需求作为上游把系统需求作为中间层再把设计和验证活动作为下游。每一层之间都要有可追踪的边。实际做的时候不需要买昂贵的工具。一个小团队用电子表格也能建立追溯矩阵关键是维护纪律。矩阵至少要有四列上游需求编号、下游需求编号、验证活动编号、状态。当需求变更时应能从任意一端出发找到所有受影响的节点。举个例子上游需求系统需求验证活动状态来源为用户提出的离线导入需求系统应支持标准格式文件离线导入导入测试用例编号 TC-XX已关联来源为监管要求备份周期系统应每天执行一次数据备份自动检查与日志审计已关联来源为某使用场景并发量系统应支持不少于 100 并发用户性能测试场景 ST-YY待关联有的团队只做正向追溯即从利益相关方需求追到系统需求有的团队只做反向追溯即从测试用例追回需求来源。真正可靠的是双向追溯。尤其到了变更评估时如果只能看到“这条需求改了”却看不到“哪些验证活动需要重跑”影响分析就是空的。影响分析没做全实际等于盲改这正是标准不希望看到的。我建议每两周做一次追溯状态检查把未关联、孤儿需求、无验证活动的条目单独列出来。检查的目的不是抓人而是让需求状态可视化。在大型项目中追踪关系是审计时最硬的证据。与其最后一个月突击补不如在每个迭代结束时顺手维护。时间成本更低信息也更真实。5. 落地 29148 的避坑手册五个高频问题从现象到解决5.1 翻车点一把标准条款当模板结果文档比标准还厚现象团队把 ISO IEC IEEE 29148:2018 全文转换成公司需求模板要求每个项目把所有信息项填满。结果是需求规格书动不动几百页评审人根本看不完真正有价值的需求淹没在大量空泛文本里。原因标准描述的是一个完整过程应该覆盖的内容不等同于每个项目都要输出全部文档。过程标准与项目模板被误认为一体是投入后最先遇到的坑。解决回到裁剪思路。项目在启动阶段就确定哪些标准条款必须直接满足哪些可以按项目规模和风险做简化并把裁剪记录存档。模板只保留与项目相关的必要条款其他内容放到公司级指南里不作为项目交付物。5.2 翻车点二需求条目写完了验证确认却没位置现象需求矩阵里列了几百条需求测试计划也写了但测试设计时发现大量需求根本没有可操作的验收准则。最后只能靠客户现场人为判断“好像满足”了。原因需求编写时只看文本是否漂亮没有把验证活动作为需求定义的一部分。需求工程和后续验证确认被当成两件事标准意义上闭环断裂。解决每条需求在进入评审前强制填写“验证方式”字段。验证方式可以是测试、分析、审查、演示。没有验证方式的需求不得进入基线。这样测试阶段不是把需求推倒重来而是按既定方式执行。5.3 翻车点三英文术语翻译不一致评审会上各说各话现象同一标准中验证和确认两个词在团队被统一翻译成“验证”。于是设计人员说“已经验证过了”质量人员说“还没确认”双方争论半天其实讨论的根本不是同一件事。原因英文原版没有扮演“单一事实源”的角色。团队依靠中文习惯自由翻译每个人理解又不一致。解决建立项目术语表明确 validation 与 verification 的分工与中文译名并在所有文档中保留英文原文对照。评审会遇到分歧时回到英文原文确认语义。这个习惯对英文版标准尤其重要也是投入这份标准后立竿见影的改进。5.4 翻车点四电子版散落各处审计时版本对不上现象项目里同时存在多个年份版本和多位同事自行截取的精简版。外部审计索要标准依据时同一评审点有人拿 2011 版有人拿 2018 版给出的依据各不相同。原因完整英文电子版作为受控资产没有指定唯一受控副本也没有建立版本识别规则。解决在公共位置放唯一现行有效版本文件名里写明标准编号、年份和受控字样。同时建立标准变更记录写清楚从哪一年版本切换到现在版本、切换时评估过哪些影响。关键评审记录中引用标准时复制原文并带上条款号不要让评审人自己翻找。5.5 翻车点五让标准取代工程判断指标堆满却不可测现象为了显得“合规”团队给每条需求都加了量化指标比如“系统应在 0.5 秒内完成所有操作”。但这些指标没有测量方法、没有测量环境也没有原始数据支撑最终成为验收时的空头支票。原因标准要求需求具备可验证性和可实现性但“写了指标”并不等于“验证方案成立”。团队用指标的堆砌替代工程判断是一种虚假满足感。解决把“可验证性”作为比“量化指标”更优先的标准。一条指标写出来之前先写测量方式。无法测量时明确写出“待定”列入风险清单而不是假装已经定义。这样标准反而成为保护你的依据因为它允许你在无法合理定义时要求进一步分析。6. 用一页检查单把 29148 固化到每次需求评审里标准读得再多不落到评审习惯里就是纸面功夫。我的做法是把 ISO IEC IEEE 29148:2018 里的需求质量属性压缩成一页评审检查单每次评审会前十分钟逐条过一遍。检查单不需要长十来个问题就够检查维度评审问题来源这条需求是否有明确来源能否追踪到利益相关方诉求必要性去掉这条需求系统能不能满足既定目标单一性这条需求是否只表达一个可独立验证的要求完整性是否写清了主体、条件、行为、约束与验收标准无歧义性两个人读这段文字是否能得到同一结论一致性与既有系统需求和外部约束是否冲突可实现性在当前技术和项目约束下能否实现可验证性能否用评审、分析、演示或测试证明需求被满足追溯性上游来源与下游验证活动是否都已关联变更风险如果这条需求变更哪些设计和测试活动会受影响这个检查单我用了很久效果稳定。它最大的价值不是发现错误而是逼着需求提出方把“我觉得系统应该这样”改成“系统在哪些条件下应做到什么程度”。散会后写需求的人不需要靠记忆补信息因为每个空缺都在评审现场露了一次面。我的习惯是只要检查单里有一项打不过这条需求就不放进基线。推迟一天进入评审好过做完整轮变更后推倒重来。这样的标准买回来才真正回本希望这套方法对你也有用。本文还有配套的精品资源点击获取