A design-specific type of technical requirement used to verify that an as-built built item is, in fact, a specimen of that design to within the tolerances established as part of that design. Often referred to as an “Acceptance Criterion”.
Contrast with Qualification Requirement, which establishes that a design is good enough to be worth building (software: distribute). An Acceptance Requirement establishes whether or not the shop actually managed to build one of them (software: whether the installer left a properly functioning installation).
These requirements are traceable to and part of the design, and are Qualified as part of it. In practice, that is usually retroactive – we put the Qualification Article(s) through Acceptance testing first in order to properly condition them for Qualification testing in a sense that will be relevant to eventual production and subsequent field use. The outcome of the Qualification test may, or may not, force changes to the Acceptance requirements (see also Selected Item Drawing), the design, or both. This relationship lays the technical ground work for the notion that any S/N passing Acceptance would also pass Qualification and can therefore be employed by the End User to the limit conditions specified in the Development Specification, even though that S/N may not yet have been exposed to those conditions.
Because these requirements are part of (traceable to) the design, it is possible to accept multiple S/N’s (more than just the Qualification articles) on risk – the risk being that all of them might have to be scrapped, re-worked, or repaired when the Qualification results come in. See, for example, the many 787-8’s that sat around Paine Field for a long, long time: they matched the design before we found out it didn’t work very well.
In legacy practices, the documentary relationship between the design and the Acceptance Requirements could reside in a C-spec. More modern practices have lost track of the traceability from them to the design (erroneously tracing them to, and parameterizing them in accordance with, the Development Requirements), so the best practice is to ensure that they all appear on the identifying drawings: either on the face or in the notes, either directly or by reference.
Most modern System Engineers will find most of the fore-going discussion of things like drawings to be utterly mysterious…which is part of the problem. Understanding these practices is necessary in order to understand how requirements relate to the real world.