Can You Use Agile Methods for Requirements in a DO-178C Program?
The short answer is yes. The longer answer is that agile methods are compatible with DO-178C, but only if you understand precisely what DO-178C actually requires and what agile is actually changing. Practitioners who conflate the two—who assume that adopting Scrum means escaping the documentation burden, or who assume that DO-178C demands a waterfall timeline—run into serious problems in both directions.
This article gives you the direct answer, the regulatory basis for it, and the specific practices that make iterative development work inside a DO-178C program.
What the FAA Has Actually Said
The FAA issued Advisory Circular AC 20-174, “Development of Civil Aircraft and Systems,” in 2011. It explicitly addresses iterative and incremental development methods, including agile. The AC is not an approval of any specific agile framework, but it establishes a clear principle: the FAA cares about what evidence you produce and whether it accurately reflects your software, not about the process structure you used to produce it.
The EASA position is consistent. AMC 20-152A (2021) provides guidance on airborne software that similarly focuses on objectives and evidence rather than mandating lifecycle shape.
DO-178C itself is objectives-based. Annex A defines 71 objectives across planning, development, verification, configuration management, quality assurance, and certification liaison. It does not specify a waterfall process. What it specifies is that:
- Software requirements must be developed and documented.
- Those requirements must be traceable to system requirements and to the tests that verify them.
- Reviews and analyses must be conducted and recorded.
- Configuration management must ensure that what was tested is what was certified.
None of these objectives logically require a single-pass waterfall. They do require discipline about when and how you close them.
Where Agile Fits Naturally
Iterative development maps cleanly onto several aspects of a DO-178C program.
Requirements refinement. System-level requirements from ARP 4754A are often incomplete or ambiguous early in a program. Agile practice—engaging stakeholders repeatedly, refining understanding sprint by sprint—is actually better requirements engineering than writing a complete SRS in month one and freezing it. DO-178C does not require requirements to be perfect before development begins. It requires that the final requirements are correct, complete, verifiable, and traceable.
Early integration and test. Continuous integration aligns with DO-178C’s verification objectives. Running structural coverage analysis and requirements-based test cases against each build—rather than waiting for a final integration phase—surfaces coverage gaps earlier and reduces the cost of fixing them.
Review cadence. DO-178C requires peer reviews of requirements, design, and code. Agile’s sprint review cadence provides a natural rhythm for conducting and recording these reviews, rather than scheduling a single large review event that everyone fears and no one does well.
Incremental builds for DAL decomposition. On programs that use DAL decomposition (DO-178C Section 4.4), lower-DAL components can iterate faster than higher-DAL components. Agile’s ability to run parallel workstreams at different cadences is an advantage here, not a complication.
What Agile Does Not Change
This is where programs fail. Agile changes how you work. It does not change what you owe.
The certification evidence package is fixed. Your DER or ACO will review a specific set of artifacts: Software Plans, Software Requirements Data, Software Design Description, Source Code, Executable Object Code, Software Verification Cases and Procedures, Software Verification Results, Software Configuration Index, and Problem Reports. These are not optional based on your process choice. Every one of them must accurately reflect the software that was certified.
Traceability is not optional at any iteration. DO-178C Table A-4 requires traceability from system requirements to software requirements, from software requirements to software design, from software design to source code, and from software requirements to test cases and test results. This chain must exist for every requirement in every build. You cannot defer traceability to the end of the program. If you do, you will discover that requirements drifted during development, that some requirements have no tests, and that reconstructing the chain under DER scrutiny is far more painful than maintaining it throughout.
Reviews must be recorded as they occur. DO-178C Section 6.3 requires that reviews be planned, conducted, and documented. A sprint review meeting that produces no written record of what was reviewed, what issues were found, and how they were resolved does not satisfy this objective. The Agile Manifesto’s preference for “working software over comprehensive documentation” is not a recognized defense in a DO-178C audit.
Configuration management must track every baseline. Every sprint that produces a build must be controlled. The Software Configuration Index must ultimately identify every component of the certified software. CM is not a post-project cleanup activity.
The Failure Mode to Avoid
The most common way agile programs fail in DO-178C is the documentation sprint problem. The team develops iteratively for eight months, then discovers that they need to spend the final three months reconstructing artifacts—writing requirements documents that match code that already exists, backfilling traceability, scheduling reviews of designs that were never formally reviewed.
This is not agile. It is waterfall with extra steps and compressed timelines. It typically produces low-quality artifacts that do not accurately reflect the software, and it produces DER findings that require rework.
The correct model is continuous closure: every sprint closes its DO-178C objectives for the work completed in that sprint. Requirements written in sprint 3 are reviewed in sprint 3, traced to design and test in sprint 3, and covered by configuration management from sprint 3 forward. When the program reaches its certification baseline, the evidence package is complete—not because it was written at the end, but because it was maintained throughout.
Practical Practices That Make This Work
Define your DO-178C lifecycle data as sprint outputs, not program outputs. Your sprint definition of done should include: requirements reviewed and issues resolved, traceability links created (upstream and downstream), test cases written or updated, and CM baseline updated. This is more demanding than a typical commercial software sprint, but it is the only way to keep the certification evidence current.
Use a tool that maintains the traceability chain natively. Manual RTMs in spreadsheets do not survive iterative development. Every time a requirement changes, every time a test case is updated, every time a design decision is revised, the matrix becomes stale. You need a tool where traceability is structural—where a change to a requirement automatically surfaces every downstream artifact that needs review—not a tool where traceability is a column you maintain by hand.
Separate the question of stability from the question of traceability. Requirements can be refined across multiple sprints without breaking DO-178C compliance. What matters is that each version of a requirement is reviewed, that changes are tracked, and that the current version is correctly linked to current tests. Instability is not a violation. Untracked instability is.
Plan your sprint cadence around verification closure, not just feature delivery. If you write a software requirement in sprint 4, the verification case for that requirement needs to be written, reviewed, and executed before the program closes. Work that does not have a closed verification record is not certifiable, regardless of how well it runs. Some teams plan verification sprints that trail feature sprints by one or two iterations, giving dedicated time to close coverage gaps before they accumulate.
Build your problem report process into the sprint cadence. DO-178C requires that open problem reports be dispositioned before certification. If your agile process does not have a formal mechanism for capturing, tracking, and closing problem reports, you will arrive at certification with an undocumented backlog that will delay your SCI.
How Modern Tooling Supports This
The traceability-maintenance problem—keeping a living, accurate traceability chain across dozens of sprints and hundreds of requirements—is where tooling choice has the most impact on program success.
Traditional requirements management tools like IBM DOORS and Polarion were designed for document-centric, change-controlled environments. They can support DO-178C traceability, but managing iterative refinement in them tends to be slow and requires significant manual overhead to keep traceability current. Teams often end up exporting to spreadsheets for sprint planning and then reimporting, which is exactly the kind of manual process that introduces traceability errors.
Flow Engineering (flowengineering.com) is built around a graph-based model that treats traceability as a first-class property of the data rather than a document attribute. When requirements are refined across iterations, the traceability graph updates with them—surfacing every downstream artifact that has become suspect and queuing it for review. This directly addresses the continuous closure problem: teams can move at sprint velocity while the tool continuously tracks what is and is not closed from a certification standpoint.
For DO-178C programs specifically, the ability to query the graph—“show me every software requirement that lacks a verified test case”—gives teams and DERs real-time visibility into certification gaps rather than discovering them at program close. Flow Engineering’s focus is on requirements-through-traceability rather than full PLM, which means it is not the right choice if you need integrated ECO management or hardware BOM tracking. But for the specific problem of maintaining DO-178C-compliant requirements traceability across an iterative development program, that specialization is a strength.
The Honest Assessment
Agile and DO-178C are compatible. The FAA has said so, the evidence framework supports it, and programs have certified using iterative methods. But compatibility requires discipline that many agile practitioners do not expect.
The regulator does not care that you worked in two-week sprints. The regulator cares that your software requirements are correct, that your tests cover them, that your reviews are on record, and that your configuration index accurately describes what was certified. If your agile process produces that evidence continuously and accurately, you will have a cleaner certification path than a waterfall program that produces the same artifacts under deadline pressure at the end.
If your agile process treats certification evidence as something to be produced after development is done, you will have a harder time than waterfall—because you will have to reconstruct a complex traceability chain from an iterative history that was not designed to support reconstruction.
The practice that makes agile work in DO-178C is not a process framework. It is a commitment to closing certification objectives at the rate you open them.