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

Basics of software standards compliance (Part 3)

Posted: 11 Jan 2016 ?? ?Print Version ?Bookmark and Share

Keywords:security assessment? safety-critical software? IEC 61508? Risk Reduction Factor? Safety Integrity Levels?

Following a series of fatal accidents in the mid-1990s, a formal investigation was conducted with the Therac-25 radiotherapy machine. Led by Nancy Leveson of the University of Washington, the investigation resulted in a set of recommendations on how to create safety-critical software solutions in an objective manner. Since then, industries as disparate as aerospace, automotive and industrial control have encapsulated the practices and processes for creating safety- and/or security-critical systems in an objective manner into industry standards.

Although subtly different in wording and emphasis, the standards across industries follow a similar approach to ensuring the development of safe and/or secure systems. This common approach includes ten phases:

1. Perform a system safety or security assessment
2. Determine a target system failure rate
3. Use the system target failure rate to determine the appropriate level of development rigor
4. Use a formal requirements capture process
5. Create software that adheres to an appropriate coding standard
6. Trace all code back to their source requirements
7. Develop all software and system test cases based on requirements
8. Trace test cases to requirements
9. Use coverage analysis to assess test completeness against both requirements and code
10. For certification, collect and collate the process artifacts required to demonstrate that an appropriate level of rigor has been maintained.

Phase 4 is discussed in the main body of this article. As a key topic in many software development standards, this article will not focus on any particular software development standard, but will discuss several standards whose key concepts hinge on a robust requirements capture process.

Every software development standard, across every industry, incorporates requirements capture as a key component to the development process, and justifiably so. Several studies over the past 3 decades, including the "Chaos" reports published by the Standish Institute, seeking to identify the top causes of software project failure have revealed that one of the top causes of failure relates to the requirements elicitation, definition and management processes. Having a robust requirements capture and traceability process should therefore be considered the backbone to a robust software development process. But what are requirements?

There are many detailed technical definitions of the term "requirements", all based around the concept that requirements are an expression of desired behaviour. Probably the most succinct definition derives from a 1979 paper by Barry Boehm entitled Guidelines for Verifying and Validating Software Requirements and Design Specifications. In this paper, Boehm differentiates between validation and verification by defining each via the following questions:

Am I building the right product?"

Am I building the product right?"

Furthermore, he explains that the role of validation is to establish the fitness or worth of a software product for its operational mission. In other words, validation is used to determine whether a software product meets its requirements, so requirements can be defined as an expression of what the "right product" is.

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