Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > Embedded

Basics of software standards compliance (Part 5)

Posted: 04 Apr 2016 ?? ?Print Version ?Bookmark and Share

Keywords:Standards compliance? system safety? defects? software? code?

In practice, the traceability process is normally started by mapping requirements to code, but it is the start of the feedback process between the code under development and the requirements. It is, of course, critical that all of the code under development be traceable to the original requirements to ensure that the system be feature complete, but this traceability also helps to ensure that no components are added to the software that are not part of the original system definition.

Extraneous components identified through this traceability process must be evaluated against the original requirements to determine whether they are superfluous to the system design. If they are, then they should be removed or disabled. However, extraneous components identified through this process are not always superfluous. Often they are critical for system functionality, and they therefore become what are referred to as "derived requirements". As critical components, these components must also be tested to completion, so the requirements documentation must be updated to reflect these derived requirements as they are identified so that test cases can be created for them.

For project managers, this process is also valuable for monitoring development progress. Being able to trace code to requirements helps answer the question, "How much of the system has been completed?" For systems developed under contract, this traceability becomes a critical way to ensure that contractual schedule obligations are met.

An increasing number of software tools work with requirements capture tools to make this process even easier. Figure 1 shows a tool that integrates with requirements capture tools and creates a mechanism not only for mapping requirements to the implementing code but also for assessing the impact of a change in either requirements or code.

Figure 1: A screenshot of TBmanager showing the mapping between requirements and code. (Source: LDRA Technology)

Developing software and system test cases based on requirements
When it comes to developing software and system test cases, there are two primary objectives for using requirements as the basis for creating them: to validate the requirements themselves, and to provide a basis for creating a necessary and sufficient set of test cases for testing the system under development.

By being a source of what the "right" system is, requirements provide the basis for creating the black box test cases required by safety- and mission-critical development standards, such as DO-178C. As a result, requirements must be stated in testable terms, and in turn, the final software product must be proven to satisfy the stated requirements. This means that all of the system test cases stem from one or more of the original requirements.

Good, testable requirements provide the best reference for creating black box test cases. They provide key criteria such as the starting state of the system, including the status of any data structures and/or databases, the required test case inputs, and the expected final state of the system. In practice, however, requirements can seldom be taken as read. The process of creating test cases from requirements helps to identify incomplete and ambiguous requirements and helps to raise the additional questions necessary for clarifying their meaning. Being aware of this allows good testers to stay alert to unintentional gaps in the original requirements and to work to resolve them.

Since the publication in 1981 of Barry Boehm's groundbreaking book Software Engineering Economics, it has been recognised that the earlier in the development process that a defect is found, the cheaper it is to correct. Black box test case development can start as soon as the requirements are received and be used in parallel with software development as a means of validating the requirements themselves. By adopting this "test early, test often" approach, the incompletions, ambiguities, and open questions identified in the requirements can be highlighted early in the development process, saving significant development cost.

To meet the objectives for testing safety- and mission-critical systems as defined by the industry standards, it is necessary to prove that the complete system was built by verifying that all of the system requirements had been implemented. This is one of the primary purposes of mapping code to requirements. And, subsequently, when it comes to testing, code coverage analysis must be used to prove that all of the software in the system has been exercised to the level required for the system safety level.

?First Page?Previous Page 1???2???3?Next Page?Last Page

Article Comments - Basics of software standards complia...
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top