SFMEA – Software FMEA

Quality and newer software have become a new cancer in recent years. This is because developers think algorithms that carry more and more functions – including the security behind security. Is it worth doing security for software that performs analysis, only for security for determining needs, architecture or coding itself, but also for analysis. And importantly – SFMEA) focuses on the readability of the function name, which means that the system is program-based and focused on points. In SFMEA, the idea is to make the program functional, how much it performs, how good the code that contributed to the installation error, etc.

Typical defects (errors) analyzed while working with SFMEA are e.g.:

• the program displayed an alarm message despite the lack of an emergency in the product (system),
• built-in activation function without user requests,
• installation process blocked due to false memory overflow signal.

The SFMEA analysis is probably the most interesting and diversified risk analysis, due to the fact that it concerns a non-physical product (it is difficult to distinguish specific elements as in a typical DFMEA analysis), complex, and also possible to analyze under various so-called aspects (viewpoints), of which eight are distinguished. When you add the fact that SFMEA does not have any unified, standardized approach, it becomes obvious that its implementation will be a real challenge for companies. But as the practice of many organizations shows – it is definitely worth it!

The specificity of the SFMEA analysis is, inter alia, the fact that in practice many different types of forms are used (depending on the adopted aspect – viewpoint) and many risk indicators (eg ARPN or RPN).

Additionally, depending on the chosen methodology, RPN is sometimes a minima (the smaller the better) and sometimes a maxim (the bigger the better). Interesting right?

Author: Tomasz Greber