In a safety-first industry like aviation, quality is neither a goal nor a luxury – it is essential. Whether discussing hardware, maintenance, or software – each element and/or system must function flawlessly. Every component, process, and system is held to the highest standard because even the smallest failure can result in serious consequences.
When it comes to custom aviation software development these standards have become even more demanding. The aviation software must meet very strict regulatory requirements and undergo rigorous evaluation at every stage of development. To manage this, the aviation industry uses a well-structured framework called Software Assurance Levels (SWAL).

Understanding the SWAL framework
Software Assurance Levels or SWAL is a framework used in safety-critical industries like aviation, nuclear industry or in the automotive sector to provide software safety management. SWAL enables organisations to match development rigor with potential risk, ensuring that software systems controlling critical operations receive appropriate verification intensity.
While SWAL1 and SWAL2 are focused on the most critical systems, and SWAL4 and SWAL5 cover systems that have little or none safety impact - SWAL3 is the critical middle ground in aviation quality assurance. The SWAL framework's structured approach to risk management is particularly important as aviation technology trends continue to advance toward more automated and connected systems.
SWAL3 does not cover life-threatening systems like SWAL1 does, hazardous systems like SWAL2, or non-impactful functions that do not affect the safety of the flight (e.g., cabin lighting) like SWAL5. However, SWAL3 covers systems that may not be catastrophic upon failure, but their impact, particularly in a scenario with high stress, can increase the overload of the pilot and affect the flight. This middle ground makes SWAL3 a key level for ensuring the reliability of the software.
The critical role of SWAL3 in aviation safety
Software Assurance Level 3 is embedded in systems that are operationally relevant and support the pilot’s decision-making, reducing the mental load, and providing redundancy when a partial failure occurs. The failure of a system, e.g. Communication Management Software, may not immediately endanger the flight, but often becomes the critical link in a crisis.
Case studies from commercial aviation demonstrate how secondary instrumentation and information systems play a significant role in maintaining operational efficiency during non-standard conditions. SWAL3 systems provide pilots with supplementary data sources that become essential when primary systems show inconsistencies or during complex operational scenarios like weather challenges, emergency descents or landings, etc. Industry analysis indicates that properly functioning support systems significantly reduce crew workload during irregular operations, allowing for more effective decision-making and resource management.
Quality assurance for SWAL3 implementation
Once the importance of SWAL3 is understood, it is just as crucial to recognise the role played by Quality Assurance (QA) in general. At its core, Quality Assurance fundamentally aims to reduce risk. Within the context of SWAL3, QA activities – including rigorous verification, strict process adherence, and comprehensive coverage – directly mitigate various risks, such as operational, financial, legal, and safety risks.
Comprehensive coverage and traceability
A structured technique to achieve a comprehensive coverage is the Requirements Traceability Matrix (RTM). By using it, the QA team verifies that each requirement (whether it is a functional or a safety one), which has been identified during the SWAL3 operational analysis, has its own corresponding test cases and results, and no requirement is overlooked.
This type of traceability, known as bidirectional, guarantees full requirements coverage. On one hand, if a requirement is not covered by tests – it is being flagged, and on the other hand – if a test case cannot be traced to a specific requirement its purpose is being questioned.
Software anomalies in aviation systems often result from incomplete requirements traceability. When critical signals are misinterpreted between interconnected systems, the consequences can affect aircraft handling and passenger safety. Thorough requirements coverage ensures that these integration points are properly verified, particularly for redundant components that become critical during degraded operational modes
High code coverage is essential in the context of SWAL3 to gain confidence that the system has been thoroughly tested under different test conditions. Such coverage is an indicator for a rigorous QA process which offers insights about the maturity and stability of the software. Another benefit of achieving a high code coverage is uncovering pathways that have not yet been tested. What does that look like in practice? The QA team ensures that not only the normal operational scenario is covered, but also the failures, and even edge cases, while being consistent with SWAL3’s required thoroughness.
By achieving comprehensive coverage, the QA team provides documented evidence that all critical paths and functions have been tested, which is quite often already a regulatory expectation for safety-critical software.
Rigorous verification and validation
In the context of Quality Assurance, verification is methodically performed at multiple stages to confirm that, adhering to the specified requirements, the product is built right. Validation, on the other hand, ensures that the right product was built – its intended use is fulfilled.
Verification activities are built into the SWAL3 development lifecycle as verification ensures that the specified requirements and standards are met while maintaining a high quality throughout the entire development process. In addition to that, unit testing, integration testing, and system testing are also systematically performed and documented, meaning that each requirement is verified by one or more tests (this can be seen in the RTM).
During the verification, a well-structured QA process mandates both the entry and the exit criteria for each stage of the lifecycle (which also means that the testing phase will continue until 100% of the requirements are verified). By enforcing them, the QA team not only endorses a high software quality, but also catches defects early on. And that, documented by different studies and practices, has proven it is both cheaper and safer to fix problems found in the requirements (or their design) at an as early as possible stage in their development.
The validation itself involves the testing of the integrated system by performing realistic operational scenarios to ensure that the system’s performance fulfills its intended role.
By combining both verification and validations, the QA team provides confidence that the software not only meets its specifications, but also the same specifications address the needs they need to meet. Such an approach is vital because, while the SWAL3 software is not the most critical one, it can still contribute to significant hazards, if not verified properly.
Process adherence in SWAL3 quality management
In addition to their role in development, QA teams also emphasize the importance of the process itself. Following a process that is both well-defined and standard-compliant is just as crucial.
In the aviation domain where safety is pivotal, compliance to different safety standards, such as ED-109 for the ATM Software, is more than often mandatory.
The Software Quality Assurance (SQA) process is done by ensuring that the software meets the predefined standards while systematically monitoring and improving the development processes.
The practical side of quality assurance
What does that mean in practice? The QA team is performing checks and reviews to verify:
✓ All tests are run and successfully passed
✓ All requirements and changes are well-documented
✓ Complete traceability is maintained throughout the process
In case any deviations are found, the QA team takes immediate corrective actions:
- Failed tests trigger defect reports
- Unclear requirements undergo more in-depth clarification
- Process gaps receive targeted improvements
Key drivers for stringent QA process adherence
The Boeing 737 MAX incidents in 2018 and 2019 emphasize the absolute necessity of adhering strictly to defined processes and rigorous software testing procedures. Max’s faulty flaw - the MCAS software involved higher criticality (SWAL1/SWAL2), these incidents vividly demonstrate the potential consequences when QA processes and testing rigor fall short, reinforcing the critical importance of disciplined process adherence even at SWAL3.
Adhering to a Quality Assurance process ensures consistency and repeatability. By consistently following a well-defined process and following it, the QA team can produce evidence (tests, test results, documentation, review records) that the software, following SWAL3, was developed with due diligence. Which is key evidence not only for the stakeholder, but for the regulators as well.
Another aspect of the quality process is configuration management. Quality Assurance ensures that the documentation, source code, and test artifacts are version-controlled with all changes meticulously tracked. By doing that, a common risk is prevented – losing track of what is being delivered and/or testing the wrong version of the software.
Last, but not least – continuous improvement. After each project’s phase or major milestone – a retrospective or lessons-learned analysis might be included. This is done based on data/evidence and learning from that. Over time, these improvements boost efficiency and reduce defects.
How does our Dreamix QA team implement SWAL3?
When it comes to the SWAL3 development, we at Dreamix apply the same level of discipline and rigor that is expected of any safety-critical domain. Our process starts with a comprehensive planning phase where all software assurance activities are mapped out in accordance with the respective guidelines, e.g. ICAO Doc 4444, NM B2B Reference Manual, and IFPS Dictionary of Messages. Each requirement undergoes traceability mapping from requirements to tests to ensure bidirectional coverage through structured Requirements Traceability Matrixes, e.g. via Jira’s Xray. Our development workflow incorporates mandatory peer reviews, independent verification, and multi-tiered testing strategies, including decision coverage and edge-case validation.
Our continuous improvement processes include:
- Structured lessons-learned reviews after each major development phase
- Cross-functional retrospectives involving software development, QA, and project management teams
- Systematic evaluation of successes and challenges encountered
- Documentation of all findings and insights
- Direct integration of learnings into future planning cycles
- Ongoing refinement to improve efficiency and resilience
- Alignment with evolving regulatory expectations and operational realities
Our quality assurance infrastructure features:
- Strict separation between development and verification teams
- Independent assurance to eliminate bias
- Qualified or documented tool assessment processes
- Comprehensive configuration management
- Systematic anomaly tracking procedures
- Version control for all artifacts
- Review logging for complete audit trails
- Audit-ready documentation at every stage

Ultimately, our SWAL3 assurance approach is not just about meeting standards, it is also about proactively managing risk, building trust in every release, and making safety an embedded feature of our software solutions building the future of aviation.
Conclusion
In summary, Quality Assurance within the SWAL3 framework represents far more than just adherence to regulatory compliance. It is a comprehensive and proactive discipline that meticulously manages risks through extensive test coverage, rigorous verification and validation, and unwavering adherence to clearly defined processes.
Such rigorous attention to quality not only ensures operational reliability, but it also safeguards human lives, fosters stakeholder confidence, and upholds the stringent safety standards that aviation demands. Dreamix adheres to these exacting quality assurance and development procedures throughout the entire software development lifecycle. In an industry where even minor oversights can cascade into critical incidents, robust QA practices within SWAL3 are essential for maintaining trust, ensuring safety, and preserving the impeccable standards that define modern aviation.
We’d love to hear about your aviation software project and help you meet your business goals as soon as possible.
