# DO-178C documents: what each one is for and in what order to write them

Source : https://consignestudio.fr/en/guides/do-178c-document-list/ · published 2026-10-27 · Antoine Despres, Consigne

A DO-178C file has five plans (PSAC, SDP, SVP, SCMP, SQAP), three standards (requirements, design, code), the development and verification data, then three closing documents (SCI, SECI, SAS). Write the PSAC first, because it sets everything else, and keep traceability up to date as you go. Here is each document, its role and the mistakes that come up most.

## DO-178C in one minute

DO-178C (ED-12C in Europe) does not describe a development method. It sets **objectives** a piece of airborne software must meet to be accepted by the authority, the **activities** that achieve them and the **data** that prove it. The number of applicable objectives and the independence required depend on the **software level**, set by the system safety assessment.

| Level | Most severe failure condition the software can contribute to | Expected structural coverage |
|---|---|---|
| A | catastrophic | MC/DC, decision, statement |
| B | hazardous | decision, statement |
| C | major | statement |
| D | minor | none |
| E | no safety effect | DO-178C does not apply beyond identifying the level |

The objectives are grouped in the ten Annex A tables (A-1 to A-10). For each objective and each level, they say whether it applies, whether it must be met with independence, and the control category (CC1 or CC2) of the data produced. Keep these tables open next to your plans.

> Practitioners say "DAL" for software. The acronym comes from ARP4754A; DO-178C says "software level". In practice both mean the same thing.

## The documents, grouped by stage

### Plans: what the team will do

| Document | Role | DO-178C section |
|---|---|---|
| **PSAC** · Plan for Software Aspects of Certification | The agreement with the authority: which software, which level, which processes, which data, which additional considerations | §11.1 |
| **SDP** · Software Development Plan | Requirements, design, coding and integration processes, environment, transition criteria | §11.2 |
| **SVP** · Software Verification Plan | Reviews, analyses, tests, coverage, independence, verification environment, regression | §11.3 |
| **SCMP** · Software Configuration Management Plan | Identification, baselines, problem reports, archiving, rebuild | §11.4 |
| **SQAP** · Software Quality Assurance Plan | Audits, QA authority, conformity review | §11.5 |

### Standards: numbered, checkable rules

| Document | Role | Section |
|---|---|---|
| Requirements standard | How to write a verifiable high-level requirement | §11.6 |
| Design standard | Architecture and low-level requirement rules | §11.7 |
| Code standard | Language subset, complexity rules, prohibitions | §11.8 |

A good standard lets a reviewer write "deviation from RQ-04" rather than "vague requirement".

### Development and verification data

| Document | Role | Section |
|---|---|---|
| **SRD** · Software Requirements Data | High-level requirements, including derived requirements | §11.9 |
| **SDD** · Design Description | Architecture and low-level requirements | §11.10 |
| Source code and executable object code | With their configuration identification | §11.11, §11.12 |
| **SVCP** · Verification Cases and Procedures | Test, review and analysis cases and procedures | §11.13 |
| **SVR** · Verification Results | Results, coverage, gap analyses | §11.14 |
| Problem reports | Form, workflow, safety impact analysis | §11.17 |
| Quality assurance records | Audits, conformity review | §11.19 |

If requirements and tests live in a tool (Jira, Polarion, DOORS…), these documents become the **dated export** of the tool, with the baseline reference.

### Closing

| Document | Role | Section |
|---|---|---|
| **SCI** · Software Configuration Index | Everything needed to rebuild, reload and re-verify the software | §11.16 |
| **SECI** · Life Cycle Environment Configuration Index | The environment: compilers, options, tools, host machines | §11.15 |
| **SAS** · Software Accomplishment Summary | The point-by-point answer to the PSAC: what was done, deviations, open problem reports | §11.20 |

If tools eliminate, reduce or automate an activity without their output being verified otherwise, they must also be qualified (§12.2). Qualification follows DO-330, which has its own plans and data.

## The writing order that avoids rework

1. **Confirm the level** with the systems team. It comes from the safety assessment, not from a software decision.
2. **Write the PSAC**, at least in outline. It sets what the other plans will detail.
3. **Inventory the tools** and decide on qualification. This is often where a project discovers a hidden cost.
4. **Write the SDP, SVP, SCMP, SQAP and the three standards.**
5. **Review the plans** internally, then submit the PSAC to the authority.
6. **Develop** while keeping the traceability matrix up to date: system requirement, high-level, low-level, code, test.
7. **Verify**: every test traces to a requirement; structural coverage is measured on requirements-based tests, not on tests written for coverage.
8. **Close**: SCI, SECI, QA conformity review, SAS.

## Reviews with the authority (SOI)

In practice the authority, or the organisation acting for it, steps in at four points, the "stages of involvement". They are defined not by DO-178C itself but by authority documents (FAA Order 8110.49A and, on the EASA side, the applicable AMC 20-115).

| Review | What you will be asked |
|---|---|
| SOI 1 · planning | Consistent, approved plans and standards under configuration; additional considerations justified |
| SOI 2 · development | A sample of requirements, design and code, reviewed, traced, under configuration |
| SOI 3 · verification | A sample of cases, procedures, results, coverage, problem reports |
| SOI 4 · final | SCI, SECI, SAS, conformity review |

The best rehearsal: pick a system requirement yourself and follow it down to the test and its result. That is exactly what the authority will do.

## The ten most common mistakes

1. Plans written for the authority, not the team, then not followed.
2. PSAC submitted too late, after development has started.
3. Independence claimed but not held (review closed by the author).
4. High-level requirements that describe the design.
5. Unverifiable requirements: "quickly", "sufficient".
6. Derived requirements not fed back to the system process.
7. Traceability rebuilt at the end of the project.
8. Tests written from the code to reach coverage.
9. Verification tools used to remove an activity without qualification.
10. Quality assurance reporting to the project manager, with no power to stop.

## What really changes with the level

A good level D plan looks like a good level A plan, with fewer objectives and less independence. The differences that weigh most:

| Point | A | B | C | D |
|---|---|---|---|---|
| Structural coverage | MC/DC, decision, statement | decision, statement | statement | none |
| Data and control coupling analysis | yes | yes | yes | no |
| Object code not traceable to source | to be analysed | no | no | no |
| Verification independence | strong | strong | per Annex A | per Annex A |

> Before dropping an activity because it "does not apply at your level", check it in the Annex A tables of your copy. The standard prevails.

## Start from a structured file

The [DO-178C template kit](https://consignestudio.fr/en/do-178c-templates/) provides these 17 documents as Word templates, set for levels A to D, with writing guidance, examples, review checklists in Excel and a preconfigured traceability matrix. It refers to the sections of the standard without reproducing its text, and replaces neither the authority nor experience. The plan review checklist (level C) is free on the same page. For rail software, see the [EN 50128 template kit](https://consignestudio.fr/en/en-50128-templates/).

## Sources

- RTCA DO-178C / EUROCAE ED-12C, Software Considerations in Airborne Systems and Equipment Certification, 2011 (sections cited by number, text not reproduced)
- RTCA DO-330 / EUROCAE ED-215, Software Tool Qualification Considerations
- FAA Order 8110.49A, Software Approval Guidelines
- EASA AMC 20-115D, Airborne software development assurance using EUROCAE ED-12 and RTCA DO-178