In the DO-178C lifecycle, verification is where teams show that the software meets its requirements and that the evidence behind that claim is complete, reviewable, and consistent.

This goes beyond running tests.

Verification under DO-178C also includes reviews, analysis, defect tracking, and, for higher criticality levels, structural coverage. The work itself is demanding, but the bigger challenge is keeping requirements, test cases, results, defects, and approvals connected as the project moves forward.

IBM Engineering Lifecycle Management (ELM) helps teams manage that work in one controlled environment. This article looks at how IBM ELM supports software verification activities under DO-178C and how it helps teams maintain the evidence needed for certification.

Table of Contents

Overview of DO-178C Software Verification

The purpose of verification in DO-178C is straightforward: to confirm that the software works as intended and that every part of the implementation can be traced back to approved requirements.

In practice, this means checking that requirements are accurate, complete, and consistent, that the design reflects those requirements, and that the code correctly implements the design. Teams also need to prove that the software behaves as expected during testing and that all verification work is documented in a way that can be reviewed later.

To achieve this, verification includes more than test execution. Teams review requirements, design, and code, create and run test cases, analyze the results, and perform structural coverage analysis for higher DAL levels.

A key concept in DO-178C is independence. For higher criticality software, verification activities often need to be performed by someone other than the original developer to ensure objectivity.

To demonstrate compliance, teams must provide requirements-based test coverage, clear links between requirements, tests, and results, documented review records, evidence of defects and their resolution, and coverage analysis results such as statement coverage, decision coverage, or MC/DC coverage.

This is often where verification starts to slow down. The issue is usually not a lack of testing activity, but the effort required to keep reviews, results, defects, and coverage data aligned and ready to show when needed.

How IBM ELM Supports Software Verification

1. Requirements-Based Testing with Engineering Test Management (ETM)
DO-178C expects testing to be driven by requirements, not by convenience or by what is easiest to test. Teams need to show which requirement is being verified, how it is being verified, and what result was obtained.

IBM Engineering Test Management helps organize this work in a controlled way. Teams can create test plans that reflect their verification strategy, define test cases that are linked directly to requirements, structure test steps and execution procedures, and monitor test progress and results as verification moves forward.

Because each test case is tied back to the requirement it verifies, teams can more easily demonstrate coverage and identify gaps. This is important for DO-178C because certification evidence must show not only that tests were performed, but that the right requirements were verified with the right results.

2. Connecting Verification Artifacts Across the Lifecycle
Clear connections between artifacts are essential for proving DO-178C compliance. IBM ELM helps teams connect requirements, test cases, execution results, defects, and code changes into one traceable lifecycle structure.

This means teams can see how a requirement is verified, which test results support it, what happened when a test failed, and which code changes were made to resolve the issue. Requirements stay connected to evidence, defects are easier to track, and fixes are documented in context.

Built-in views and reports also help teams identify missing coverage, unresolved issues, or weak traceability early, long before an audit or certification review.

3. Managing Reviews and Verification Evidence
Verification is not only about running tests. Reviews and analysis also play an important role in DO-178C because they show that requirements, design, code, and verification results were examined in a controlled way.

IBM ELM supports this by helping teams manage structured review steps for requirements, design, and code. Reviewers can provide comments, track resolutions, give electronic approvals, and create a clear audit trail of verification activities.

This makes verification evidence easier to control and easier to retrieve when needed. Instead of relying on scattered emails or informal review notes, teams can show who reviewed what, what issues were raised, how they were resolved, and when approval was given.

4. Defect Tracking and Resolution with EWM
Handling defects is a core part of verification because DO-178C expects teams to show how issues were identified, evaluated, corrected, and verified.

IBM Engineering Workflow Management helps manage this process in a traceable way. Teams can log defects directly from failed tests, track each issue from detection to resolution, and link defects to the affected requirements, code changes, and test results.

This creates a clear history of how each issue was handled. For certification, that history is important because it shows that defects were not only found, but also controlled, addressed, and documented as part of the verification process.

5. Supporting Structural Coverage Analysis
For higher criticality levels, especially DAL A to DAL C, DO-178C requires structural coverage analysis. Depending on the assurance level, this may include statement coverage, decision coverage, or Modified Condition/Decision Coverage, known as MC/DC.

The actual coverage analysis is usually performed in specialized external tools, but IBM ELM helps connect the results to the wider verification process. Coverage results can be linked to requirements and tests, tracked by status, and used to identify areas where additional testing may be needed.

This keeps coverage data from becoming a separate set of files that teams only revisit before an audit. Instead, it becomes part of the overall verification picture and can be reviewed together with the related requirements, tests, results, and evidence.

6. Planning and Monitoring Verification
Verification is not a one-time activity. It needs to be planned, monitored, and adjusted throughout the software lifecycle.

IBM ELM helps teams manage verification plans alongside requirements, development artifacts, tests, defects, and results. Dashboards can show progress, coverage, and overall verification completeness, while reports help prepare evidence for internal reviews, audits, and certification discussions.

This gives teams a clearer view of where verification stands at any point in the project. More importantly, it helps them identify gaps early, before they become end-of-cycle audit problems.

Common Verification Obstacles — and How ELM Helps

Obstacle 1 — Missing or Incomplete Test Coverage
Some requirements are easy to miss, especially when tests are managed separately from requirements.

How IBM ELM helps:
Traceability links and coverage views help teams see which requirements are already verified and which still need attention.

Obstacle 2 — Disconnected Verification Data
Test cases, execution results, defects, and approvals often end up split across tools or documents.

How ELM helps:
By keeping these artifacts connected, IBM ELM gives teams a more consistent verification record and better visibility into the current state of coverage.

Obstacle 3 — Audit Preparation Done Too Late
Verification evidence is often assembled near the end of the project, when missing links and incomplete records are harder to fix.

How ELM helps:

Evidence is captured as part of normal project work, so teams are not forced to reconstruct verification history at the last minute.

Obstacle 4 — Maintaining Independence
For higher DAL levels, verification independence needs to be visible in the process, not assumed.

How ELM helps:

Role-based workflows and approvals help teams separate development and verification responsibilities in a controlled way.

How Softacus Helps with DO-178C Software Verification in IBM ELM

IBM ELM provides the platform, but verification only works well when requirements, test assets, review flows, defects, and evidence are structured in a way that matches the project’s compliance needs.

Softacus helps aerospace and defence teams configure IBM ELM so verification becomes part of the normal lifecycle rather than a separate effort at the end. This includes support with requirements-to-test traceability, review and approval workflows, defect handling, reporting, and the alignment of verification records with certification expectations.

The aim is to make verification easier to manage in practice and easier to demonstrate when audits or certification reviews begin.

Conclusion

Software verification under DO-178C is not only about finding defects. It is about showing, with clear evidence, that requirements were checked, results were reviewed, issues were resolved, and the final state is acceptable for certification.

IBM ELM helps teams keep that work connected across requirements, tests, defects, approvals, and coverage data. When the environment is set up well, verification becomes easier to follow during the project and easier to demonstrate later.

For organizations using IBM ELM in aerospace or defence programs, that makes a real difference in how much manual effort verification requires and how confidently teams can prepare for review.