DO-178C Part 4 - Software Verification with IBM ELM

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.

The purpose of verification in DO-178C is simple: make sure the software actually works and does what it’s supposed to. That involves checking that:
● Requirements are accurate, complete, and consistent
● The design properly reflects those requirements
● The code correctly implements the design
● The software behaves as expected during testing
● All verification work is documented and can be reviewed  

To achieve this, teams carry out a range of activities, including:
● Reviewing requirements
● Reviewing design
● Reviewing code
● Creating test cases
● Running tests
● Analyzing results
● Performing structural coverage analysis (for higher DAL levels) 

A key concept in DO-178C is independence. For higher criticality software, verification must be performed by someone other than the original developer to ensure objectivity.
To demonstrate compliance, teams also need to provide:
● Requirements-based test coverage
● Clear links between requirements, tests, and results
● Documented review records
● Evidence of defects and how they were resolved
● Coverage analysis results (such as statement, decision, or MC/DC coverage)

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

1. Requirements-Based Testing with Engineering Test Management (ETM)
DO-178C expects testing to be driven by requirements, not by convenience or tool availability. Teams need to show which requirement is being verified, how it is being verified, and what result was obtained.
● Create test plans aligned with verification strategies
● Define test cases directly linked to requirements
● Organize test steps and execution procedures
● Track test progress and results in real time
Each test case is tied back to the requirement it verifies, making it easier to demonstrate full coverage — a key DO-178C expectation.  

2. Connecting Verification Artifacts Across the Lifecycle
Clear connections between artifacts are essential for proving compliance. IBM ELM makes it possible to link:
● Requirements to test cases
● Test cases to execution results
● Defects to failed tests
● Code changes to resolved issues
This keeps everything connected from start to finish — requirements are verified, issues don’t get lost, and fixes are all documented.
Built-in views and reports make it easy to spot missing coverage or gaps early, long before an audit. 

3. Managing Reviews and Verification
Evidence Verification isn’t just about testing — reviews and analysis play a big role too.
IBM ELM supports this by enabling:
● Organized review steps for requirements, design, and code
● Electronic approvals and sign-offs
● Comment tracking and resolution
● Full audit trails of verification activities
This ensures all verification work is properly recorded, controlled, and easy to access when needed.

4. Defect Tracking and Resolution with EWM
Handling defects is a core part of verification.
With IBM Engineering Workflow Management, teams can:
● Log defects directly from failed tests
● Track progress from detection to resolution
● Link defects to requirements, code, and test results
● Maintain a clear history of how issues were handled
This makes sure every issue is documented, addressed, and visible — exactly what DO-178C expects.  

5. Supporting Structural Coverage Analysis
For higher criticality levels (DAL A–C), DO-178C requires structural coverage analysis, including:
● Statement coverage
● Decision coverage
● Modified Condition/Decision Coverage (MC/DC)
While the actual coverage tools are usually external, IBM ELM helps bring everything together by:
● Linking coverage results to requirements and tests
● Tracking coverage status
● Highlighting areas where additional testing is needed
This ensures coverage data becomes part of the overall verification picture, not something separate. 

6. Planning and Monitoring Verification
Verification isn’t a one-time activity — it needs to be planned and continuously monitored.
IBM ELM supports this by:
● Managing verification plans alongside development artifacts
● Providing dashboards to track progress and coverage
● Monitoring overall verification completeness
● Generating reports that make audits and reviews much easier
This gives teams a clearer view of verification progress and helps them spot gaps before they turn into end-of-cycle audit problems.

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.

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.

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.