Means-of-compliance map
Means-of-compliance map evidence review for software assurance teams
This review checks the logic that maps each software requirement to how it will be shown compliant, confirming that a means assigned on paper leads to real evidence. It runs before a submittal, during a finding response, or after a change reshuffles the requirement set, and it is done by or with the software assurance team that owns the map. The work follows each requirement from its assigned means of compliance to the evidence that means is supposed to produce, and it flags every requirement that has a method named but no evidence path behind it. You receive a gap list, an evidence map exposing where the requirement-to-evidence logic breaks, and a closure sequence for software assurance leadership.
When this review is needed
- A means-of-compliance map is nearly final and each requirement's method needs checking for a real evidence path.
- A finding questions whether a requirement's assigned means actually yields evidence or just names a method.
- A change added or split requirements and the map has not been re-walked to assign and connect them.
- The map was built top-down and no one has confirmed each assignment resolves to something the package will contain.
The problem
Assigning a means of compliance is quick; producing the evidence behind it is not, and the two get out of step. A requirement gets tagged as compliant by review, or by test, or by analysis, and the tag looks complete on the map. But the map records intent, not existence: the review might never have been scheduled, the test might cover a sibling requirement instead, the analysis might have been deferred. A requirement can carry a confident means assignment while nothing downstream actually produces the evidence that means implies.
What gets reviewed
- Each requirement checked for an assigned means of compliance appropriate to its type
- Each assigned means followed to the specific evidence it is supposed to produce
- Requirements sharing a means checked so the evidence actually covers each one, not just the group
- Derived and changed requirements checked for assignment and for an evidence path
- Means that defer to another document checked that the target document accepts the assignment
- Map references checked against the certification basis and the applicable software level
What gets validated
- Every requirement carries a means of compliance suited to what it states, not a default tag
- Each assigned means resolves to a scheduled or produced piece of evidence, not just a label
- A means shared across requirements yields evidence covering each requirement individually
- Derived and recently changed requirements are both assigned and connected to evidence
- A means that points to another document is one that document actually takes responsibility for
Evidence normally required
- The means-of-compliance map in its current state
- The requirement set the map assigns methods to
- The evidence set or plan the assigned means are meant to produce
- The change history covering added, split, or derived requirements
- The certification basis and applicable software level
Common discrepancies
- A requirement assigned compliance by review where no such review is scheduled or recorded
- A test-based means covering a group whose evidence addresses only some of its requirements
- A derived requirement present in the design but absent from the means-of-compliance map
- A means that defers to a document whose scope does not, in fact, cover the requirement
What is at stake
A requirement with a means but no evidence path is a compliance hole that the map hides rather than exposes, because the assignment reads as progress. It surfaces late, when the evidence is assembled and the requirement has nothing to point to, and closing it then can mean scheduling a review or test at the worst possible time. Across many requirements, unbacked assignments make the map look more complete than the package is.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Confirm every assignment
Check that each requirement carries a means of compliance suited to what it states.
Follow means to evidence
Trace each assigned means to the specific, scheduled or produced evidence it should yield.
Test shared and deferred means
Confirm grouped and cross-referenced assignments actually cover each requirement they claim.
List and order the gaps
Record each unbacked assignment and sequence resolution so shared and deferred means come first.
What the buyer receives
- A gap list naming each requirement whose assigned means has no evidence path
- An evidence map showing where the requirement-to-evidence logic connects and where it breaks
- A closure sequence ordered so shared-means and deferred assignments are resolved before dependent requirements
Who uses the output
- Software assurance leadership confirming the map's assignments are backed before submittal
- Assurance engineers connecting or reassigning the requirements flagged with no evidence path
- Certification leadership judging whether the map reflects the package or overstates its completeness
How the work fits into the transaction or program
The review runs on the map after the means are assigned but before the map is trusted as the compliance argument's spine. It confirms each assignment leads to real evidence, and its gap list drives the scheduling, reassignment, and connection work that turns intended means into a package that holds.
Start with a single asset
Confirm requirements trace through verification.
Jurisdiction-specific considerations
FAA and EASA accept a common set of software compliance methods but frame acceptable means differently in their guidance, so a method sufficient for one authority can need supplementing for the other. The review notes where an assignment defensible under one framing needs a stronger or additional means to carry under the other.
Regulatory limits
The review checks that assigned means lead to evidence. It does not accept the means of compliance, make a compliance finding, or determine that a method is adequate for the requirement's software level. Those judgments rest with the applicant's authorized representatives and the authority.
What this review does not cover
- Producing the reviews, tests, or analyses the assigned means call for
- Accepting the means of compliance or making a compliance finding
- Selecting the software level or reassigning it for the item
Specific to this review
- A means-of-compliance map records intent, so an assignment can look complete while the evidence it implies was never scheduled.
- Shared means are the common trap: one test tagged against several requirements often substantiates only the one it was written for.
- Deferred means fail silently, because the requirement points confidently at a document that never agreed to carry it.
Sources
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
Federal Aviation Administration. FAA type certification process, certification basis establishment, and compliance findings.
SAE International. Development assurance process at aircraft and system level, including requirements capture and validation.
Frequently asked questions
How is this different from a requirements-trace review?
A trace review confirms requirements connect to design and verification. This one checks the layer above it: that the method chosen to show each requirement compliant actually leads to evidence at all, before you rely on it as your compliance argument.
Relevant glossary terms
Related pages
Where this fits
Talk to an engineer who has done this work
We will walk through your current state, the records or evidence involved, and a scoped first engagement.
Talk through the aircraft, records, evidence, deadline, and next useful step.