Why Everyone Gets DLA 20 Wrong
Most people treat the Dla 20 Functional Assessment Guide like a checklist you tick off before sending something to a client. It isn't. It's a methodology for proving that a system, piece of equipment, or software component can actually do what it claims under conditions that resemble real use. I learned that the hard way about four years ago when a contractor submitted a DLA 20 assessment for a comms module that passed every test on paper but failed in a mobile field environment within three weeks of deployment. DLA 20 is a British defence standard document that provides the framework and procedures for carrying out functional assessments of military equipment and systems. It sits alongside other defence standards like DLA 21 (reliability assessment) and DLA 22 (maintenance assessment). The guide covers everything from defining functional requirements, establishing test conditions, documenting performance data, to producing the final assessment report that goes into the technical file. The core idea is straightforward: you take a piece of hardware or software, define what it is supposed to do, then verify that it actually does it. But the devil is in the details. The guide specifies particular environmental conditions, operational profiles, and performance criteria that vary depending on the type of equipment. A handheld radio gets assessed differently than a vehicle-mounted radar system, even though they follow the same underlying methodology.
The Process — From Paper to Proof
Here is how I typically work through a DLA 20 assessment. Step one is scoping, which most people rush through. You need to nail down exactly which functions fall within the assessment boundary. A common mistake is including functions that belong to another subsystem or excluding ones that critically affect the system's ability to perform its primary role. I once saw an assessment skip the emergency shutdown function because it was "handled by a separate control panel," which turned out to be wrong — the panel and the system share the same validation lifecycle. After scoping, you move to functional decomposition. This means breaking the system's overall purpose down into individual, testable functions. For a navigation unit, you might have functions like position acquisition, course computation, display update, and alarm generation. Each of these needs its own acceptance criteria defined in measurable terms. "Works correctly" is not an acceptance criterion. "Acquires GPS position within 45 seconds in open sky with PDOP below 2.5" is. Then comes the test condition definition, which is where the Dla 20 Functional Assessment Guide really earns its keep. The standard specifies environmental test parameters — temperature ranges, humidity, vibration profiles, electromagnetic interference levels — based on the intended operating environment. If your system is rated for arctic conditions, you don't test it at 20 degrees Celsius and call it a day. I have seen assessments gloss over the lower temperature limits because the testing lab didn't have a chamber that could go below minus ten. That's not an acceptable excuse.
Once the tests are designed, execution follows. Documentation during this phase matters more than most people realise. Every test result, every deviation, every anomaly needs to be recorded with enough detail that someone reading the report six months later can understand exactly what happened. I keep a running log alongside the formal test sheets because the formal sheets never capture the little things that turn out to matter during the audit.
Get the Full Details
Common Pitfalls I See Repeatedly
The biggest issue I encounter is vague functional descriptions. When the original requirements were written loosely, the assessment inherits that ambiguity. Phrases like "user-friendly interface" or "acceptable response time" slip into the documentation and then become impossible to verify. You have to push back on this. Go to the source requirements and demand specificity. If you can't get it from the original brief, you need to establish baseline assumptions and get them signed off by the responsible authority. Another frequent problem is testing under ideal conditions. That is, testing everything in a climate-controlled lab with fresh batteries and perfect signal conditions. The DLA 20 methodology requires testing across the full operational envelope, not just the happy path. I recently worked on a sensor assessment where the manufacturer's documentation showed perfect results at sea level. The system was actually going to be deployed at altitude. We had to run the full functional assessment again at simulated altitude conditions, which added about two weeks and roughly eight thousand pounds to the project. Worth it, obviously, because the sensor's sampling rate degraded significantly once we introduced the pressure differential. A third pitfall involves the interface between subsystems. DLA 20 assessments often treat interfaces as black boxes — you assume the connected system works because it has its own valid assessment. That assumption breaks down when timing constraints, protocol mismatches, or power delivery issues come into play. I recommend testing at least the critical interfaces under realistic conditions rather than relying solely on individual subsystem assessments.
Documentation That Won't Get Returned
The final report is what everyone actually cares about, and it's also where most assessments get sent back for revision. The guide requires a specific structure: scope and objectives, reference documents, functional description, test methodology, results with raw data references, deviations and their impact analysis, and a clear conclusion with pass/fail status for each function. I suggest organising the results section by function rather than by test event. It makes it much easier for the reviewer to trace from requirement to test to outcome. Mixing the two approaches creates this frustrating jigsaw puzzle where you're constantly flipping between pages to confirm that a requirement was actually tested. The reviewer will spot it immediately and ask for a restructuring. Raw data should be referenced, not pasted in full. Include a data register table that maps each test event to its source file location. Keep the main report readable and put the supporting data in an appendix or separate data archive. A 200-page report with 180 pages of spreadsheet dumps is not a good report.
When DLA 20 Isn't the Right Tool
Not everything needs a full DLA 20 functional assessment. Commercial off-the-shelf equipment that already carries a valid type approval may only need a suitability review rather than a complete re-assessment. Similarly, software patches and minor updates to an already assessed system can often be handled through a targeted functional review focused on the changed components. Trying to run a full DLA 20 process on a Windows update is a waste of everyone's time. The guide also doesn't cover cybersecurity assessment in any meaningful detail. If your system handles sensitive data or connects to networks, you'll need to layer in additional assessments — typically aligned with Ministry of Defence policy documents on information assurance. DLA 20 will not protect you from a vulnerability scan showing unpatched endpoints.
Where to Get the Document
The actual DLA 20 standard document is available through the UK Ministry of Defence's online ordering system and various defence standards distributors. It is not a free document — expect to pay somewhere between fifty and one hundred fifty pounds depending on the format. Make sure you are getting the current version, as these standards get updated periodically and using an outdated edition will cause problems during compliance checks. If you're working on a UK defence project, your quality assurance team should already have access. If not, ask them first before you go purchasing it independently. I've seen people buy the standard, read it, and then realise their specific programme uses a tailored variant that supersedes the base document.
A Practical Note on Timeline and Effort
A typical DLA 20 functional assessment for a moderate-complexity system takes about three to six weeks from scoping to final report, assuming you have all the test equipment and access to the system under assessment. More complex systems — something with multiple subsystems, embedded software, and harsh environment requirements — can easily stretch to twelve weeks or more. Budget accordingly. The biggest time sink is usually getting the test environment set up to the required specifications, not the testing itself. Planning the assessment early in the development cycle saves enormous effort. If you can align your design verification tests with the DLA 20 requirements from the start, you avoid the scramble of retrofitting an assessment onto a finished product. I always recommend treating DLA 20 compliance as a design input rather than a testing afterthought.
