DO-178B was a comprehensive and levelled set of software development activities and objectives.  F ive Safety Integrity Levels (SILs)  were  included in the standard – levels A, B, C, D, and E – with level A being the most safety critical and Level E having no impact on aircraft safety.  Obligatory  “ a ctivities”  were  to be  completed in order to achieve  specific “objectives.” A comprehensive cross-referencing of these objectives  was  provided in the standard against each of the five SILs. In this way, DO-178B  wa s well structured and its intent clearly defined.  

DO-178B assume d  a traditional software development life cycle that progresses linearly from requirements through design and code to integration and test. Its process model resemble d  a waterfall or V model in which validated requirements  we re a given (DO-178B d id  not mention requirements validation), and there  was  a de facto partitioning of the requirements engineering and software development processes. “Derived Requirements,” non-functional requirements derived from the design or implementation process,  we re  an  exception to this.  

Verification in DO-178B c a me primarily from top-down testing, an approach that  often  represent ed  60 to 80 percent of the project budget and  wa s driven up because “testing”  wa s first performed on the integrated software system long after the requirements and design commitments ha d  been made.  

​ DO-178B verification focuse d  on test coverage of functional requirements and software structures via structural coverage analysis, as well as data and program-control structures. The measurement of data and control coverage  wa s typically performed as a manual, ad hoc analytical process, escalating verification costs.  

Finally, in DO-178B, traceability (causal links between requirements at different levels and associated software development art e facts)  had to  be established before the software system  wa s considered certifiable. These causal links include d  both static links that  had to  be established and maintained (such as mapping from low-level requirements to source code) and dynamic links (as determined by structural coverage analysis).  

Typically,  certification readiness include d  a verification of traceability called “slice analysis,” which follow ed  one high-level software requirement to its low-level requirement(s) and associated test cases through design to source code and then to object code.