产品技术要求怎么写才经得起注册检验

结论：技术要求是检测的依据，写的时候就要想着怎么测

产品技术要求是注册检验的执行依据。检测机构按它测、按它判，写成什么样就按什么样执行。

这带来一个实际结果：技术要求里的每一句话，都会在检测阶段被兑现一次。 指标写得含糊，检测时就没法判；指标定得过严，量产件可能过不了；指标写了但方法不明确，不同机构测出来的结果可能不一致。

所以撰写时的基本心态应当是：每写一条，就问一句「这一条怎么测、怎么判」。

五条判断标准

这五条里，第三条和第五条最容易被忽略。

可复现要求把试验条件写到足够细：环境条件、样品状态、加载方式、读数时机。这些没写清楚，两家机构按各自的理解执行，结果对不上，而两份报告都没错。

可达则是个现实问题。研发阶段用精心调试的样机定出来的指标，量产件未必能稳定达到。指标定得过高，等于给自己埋雷——每批出厂检验都在临界线上挣扎。

常见的写法问题

一是照抄标准条款而不筛选。 把适用标准的条款整段搬进技术要求，包括不适用于本产品的部分。检测时按技术要求执行，就会测一堆本来不必测的项目，其中一些还可能因为不适用而判不合格。

二是指标没有测量条件。 写「使用寿命不少于若干次」，但没写在什么载荷、什么频率、什么环境下。这样的指标无法执行。

三是用定性描述代替定量指标。 「外观良好」「运转平稳」这类表述没有判定依据。如果确实需要定性判断，应当给出判定方法和参照样。

四是型号规格覆盖交代不清。 技术要求适用于多个型号时，要说明各型号的差异以及指标是否一致。不交代清楚，检测时不知道该测哪几个型号，覆盖论证也无从做起。

五是与说明书、标签不一致。 技术要求里写的参数，与说明书标称值、标签上的信息要对得上。这三处分开写，很容易出现不一致，而审评是会交叉核对的。

指标值怎么定才合理

定指标时有两个参照：标准的要求和产品的实际能力。

下限由标准定。 适用标准有强制要求的，技术要求不能低于它。

上限由量产能力定。 在标准要求之上留多少余量，取决于工艺稳定性。余量太小，量产波动就会造成不合格；余量太大，等于对自己提出了不必要的要求。

比较合理的做法是：拿一批量产件（不是精调样机）实测，看数据的分布范围，在分布的下边界之外再留一定裕度作为指标值。用样机数据定指标，是后续出厂检验频繁不合格的主要原因之一。

写完之后怎么自查

建议用这个顺序过一遍：

逐条问「怎么测」，说不出方法的，补充方法或删掉；逐条问「怎么判」，没有限值或判定规则的，补上；逐条问「适用吗」，不适用的删掉；把技术要求与说明书、标签并排对照，核对所有重复出现的参数；最后拿一批量产件的实测数据对照指标值，看余量是否合理。

这五步做完，技术要求基本就经得起检测阶段的执行了。这件事在送检之前做，成本是几个小时；在报告出来之后发现问题，成本是重新送检。

与检测机构的前置沟通

技术要求定稿之前，把草稿给检测机构看一遍，是性价比很高的一步。

检测机构关心的是可执行性：这条能不能测、条件够不够明确、按这个写法会测出什么。这些反馈往往能提前发现几个问题。而这一步通常不收费，也不占多少时间。

实际中见过的情况是：技术要求已经随资料提交，检测时才发现其中一条按字面执行会得出不合理的结论，这时候要改技术要求，涉及资料的变更，麻烦程度远超提前沟通。

一份技术要求要服务几个对象

技术要求写出来之后，会被几类人分别使用：检测机构按它执行、审评人员按它审查、企业内部按它做出厂检验、采购方有时也会索取它作为验收依据。

这几类使用者的关注点不同，但共同的需求是明确。含糊的表述对谁都不方便：检测机构要来回确认，审评人员会提问，内部检验各人理解不一，采购方无法据此验收。

所以写作时可以用一个简单的检验：把某一条拿给没参与过这个产品的人看，问他能不能据此设计出一个试验。答不上来，这条就还需要改。

修订时的版本管理

技术要求会随产品迭代而修订。修订时要注意两件事：

一是版本号与生效日期要清楚，并且检测报告上应当写明依据的是哪一版。同一个产品不同时期的报告依据不同版本，这在追溯时是必须能区分的。

二是修订内容要留痕。哪一条改了、为什么改、改动是否影响已有的检测结论，这些应当有记录。尤其是指标值放宽的情形，需要说明放宽的依据，否则容易被质疑是为了迁就不合格结果。

我们的做法

我们收到委托后会先通读技术要求，把三类问题标出来：无法执行的、条件不充分的、以及适用性存疑的。这个动作在报价阶段就做，不等到开测。

标出来之后与委托方逐条确认。多数问题在这个阶段改，只是改文件；到了检测阶段再发现，改的就是进度。 有些委托方最初觉得这一步多余，走过一次之后通常会在下个项目里主动把草稿先发过来。

如果你的技术要求正在撰写或者已有草稿，可以发过来一起看一遍可执行性，或者直接联系：132 4819 8029。能力范围见服务介绍，送检要求见送检要求，流程见检测流程。

English version

Conclusion: technical requirements are the basis for testing, so write them with testing in mind

Product technical requirements are what registration testing executes against. The laboratory tests to them and judges against them: whatever is written is what gets done.

That has a practical consequence. Every sentence in the technical requirements gets cashed in during testing. Vague indicators cannot be judged. Over-tight indicators may fail on production units. An indicator written without a method may give different results at different laboratories.

The right frame while drafting is therefore to ask, for each line, how this would be measured and how it would be judged.

Five tests for a good requirement

Measurable: there is a defined measurand and method, otherwise the laboratory cannot execute it. Judgeable: there is a limit or decision rule, otherwise conformity cannot be determined. Reproducible: conditions are defined closely enough that another laboratory would obtain the same result. Applicable: every clause genuinely applies to this product, otherwise inapplicable items may be tested and failed. Achievable: production units can meet it consistently.

Reproducibility and achievability are the two most often neglected. Reproducibility requires stating environmental conditions, sample state, loading method and when readings are taken. Without these, two laboratories following their own reasonable interpretations produce different results and neither is wrong.

Achievability is a practical matter. An indicator derived from a carefully tuned prototype may not be met consistently by production units. Setting it too high means every batch release test runs close to the line.

Common drafting problems

Copying standard clauses wholesale without filtering, including parts that do not apply. Testing then follows the technical requirements and produces unnecessary items, some of which may fail precisely because they do not apply.

Stating an indicator without measurement conditions, such as a service life figure with no load, frequency or environment specified. Such an indicator cannot be executed.

Using qualitative description in place of quantitative limits. Phrases such as good appearance or smooth operation give no basis for judgement. Where qualitative assessment is genuinely needed, give the method and a reference sample.

Leaving model and variant coverage unclear. Where the requirements cover several models, state the differences and whether indicators are identical, or the laboratory cannot know which models to test and coverage cannot be argued.

Inconsistency with the instructions for use and the label. Parameters appearing in all three places must agree, and reviewers do cross-check.

Setting values sensibly

Two references apply: what the standard requires and what the product can actually do.

The floor is set by the standard. Where a mandatory requirement applies, the technical requirement cannot be less demanding.

The ceiling is set by production capability. How much margin to leave above the standard depends on process stability. Too little margin and normal variation causes failures; too much and you have imposed an unnecessary burden on yourself.

A reasonable approach is to measure a batch of production units, not tuned prototypes, look at the distribution, and set the indicator with margin beyond the lower edge of that distribution. Setting indicators from prototype data is one of the main reasons batch release testing later fails repeatedly.

Self-checking the draft

Go through in this order. Ask how each line would be measured and add a method or delete the line. Ask how each would be judged and add limits. Ask whether each applies and delete those that do not. Place the requirements alongside the instructions for use and the label and reconcile every parameter appearing in more than one. Finally compare the indicator values against measured data from production units and check the margin.

Doing this before submission costs a few hours. Discovering the problem after the report is issued costs another round of testing.

Talking to the laboratory first

Sending the draft to the laboratory before finalising is a high-value step. Laboratories care about executability: can this be measured, are the conditions defined, and what will this wording actually produce. That feedback usually surfaces a few problems, generally costs nothing and takes little time.

We have seen technical requirements already submitted with the dossier, with testing then revealing that one clause taken literally produces an unreasonable conclusion. Changing the requirements at that point means amending filed documents, which is far more troublesome than an early conversation.

How we handle it

On receiving a commission we read the technical requirements through and flag three categories: clauses that cannot be executed, clauses with insufficient conditions, and clauses whose applicability is doubtful. We do this at the quotation stage rather than waiting until testing begins.

We then go through the flags with the client. Most issues at that stage are document changes; the same issues found during testing are schedule changes. Clients who initially think this step is unnecessary usually send the draft ahead on the next project.

If your technical requirements are being drafted or exist in draft, send them over and we will review executability. Phone or WeChat: +86 132 4819 8029.