How can we demonstrate the reliability of a system that is required never to fail?

Non-functional requirements describe the restriction of the system between systems that limits our choice for constructing a solution to the problem. In systems engineering, non-functional requirements are requirements that specify criteria that can be used to judge the operation of a system rather than specific behaviors. This defines how a system is supposed to be. But how can we demonstrate that these requirements are testable? How can we exhibit the reliability of a system that is required never to fail?

With computers becoming a highly factor nowadays, there is a decisive need to ensure that systems continue to function even when a component fails. The reliability of a system is the probability of failure-free software operation for a specified period of time in a particular environment. Identifying non-functional requirements are also an important factor affecting system reliability. Measurement in software is still in its infancy. No good quantitative methods have been developed to represent software reliability without excessive limitations. Various approaches can be used to improve the reliability of software.

With the advent of the computer age, computers, as well as the software running on them, are playing a vital role in our daily lives. We may not have noticed, but with a continuously lowering cost and improved control, processors and software controlled systems offer compact design, flexible handling, rich features and competitive cost. People used to believe that software never breaks. Without being proven to be wrong, optimistic people would think that once after the software can run correctly, it will be correct forever. A series of tragedies and chaos caused by software proves this to be wrong. These events will always have their place in history.

Software can make decisions, but can just as unreliable as human beings. Fixing problems may not necessarily make the software more reliable. On the contrary, new serious problems may arise. Once perfectly working software may also break if the running environment changes. This makes us wondering whether software is reliable at all, whether we should use software in safety-critical embedded applications.