Software FMEA: [System or service name]

Software Failure Mode and Effects Analysis (SFMEA) for a software system, service or component. The structure is aligned with the FMEA process described in IEC 60812:2018 (planning, structure and function analysis, failure analysis, risk evaluation, actions and documentation), adapted to software and services. Replace every [bracketed] value and every row marked Example. The scales and thresholds shown are examples to tailor, not values taken from the standard.

Document control

Approvals

Revision history

Contents

1. Introduction and scope
2. System structure
3. Functions and requirements
4. Rating scales
5. Failure analysis
6. Risk evaluation
7. Recommended actions
8. FMEA worksheet
9. Re-scoring after actions
10. Results, residual risk and follow-up
11. Appendices
12. Standard and licence note

1. Introduction and scope

1.1 Purpose

This analysis identifies the ways [System name] can fail to deliver its functions, the effects of those failures on users and on the business, their likely causes and the controls that prevent or detect them. Its output is a ranked list of actions that reduce risk before [release / go-live / the next architecture review].

Example: The analysis supports the go-live decision for the new payment authorisation service in [Region] and feeds the reliability backlog for Q[n].

1.2 Scope and boundaries

1.3 Level of analysis

1.4 Assumptions and constraints

• [Assumption, for example: the message broker provides at-least-once delivery.]
• [Assumption, for example: infrastructure failures are covered by the DR plan and are only considered when they change software behaviour.]
• [Constraint, for example: the analysis must be complete two weeks before the release freeze.]

1.5 Team

2. System structure

The structure below shows the elements analysed and their relationships. Each element has an ID used in the worksheet.

3. Functions and requirements

4. Rating scales

The team uses 1 to 10 scales. Scores are agreed by consensus in the workshop; where the team disagrees, the higher score is recorded and the disagreement noted.

4.1 Severity (S)

Severity rates the worst credible effect of the failure mode on the user, the business or safety, assuming it occurs.

4.2 Occurrence (O)

Occurrence rates how likely the cause is to happen and produce the failure mode during the operating period, given current prevention controls.

4.3 Detection (D)

Detection rates the ability of current detection controls to find the cause or the failure mode before it reaches the user. A low score means detection is likely.

5. Failure analysis

5.1 Failure mode taxonomy

The team uses the following generic software failure modes as prompts for each function.

5.2 Effects

Effects are recorded at three levels: local (the element itself), next higher level (the service or system) and end effect (user, business or regulator). Severity is scored on the end effect.

5.3 Causes and mechanisms

Causes are the design or process weaknesses that lead to the failure mode. For software, typical causes are logic errors, missing input validation, unhandled exceptions, race conditions, resource exhaustion, configuration errors, incompatible interface versions, dependency failures and deployment mistakes. Each failure mode may have several causes, each scored for occurrence separately.

5.4 Current controls

6. Risk evaluation

6.1 Risk priority number

The risk priority number (RPN) combines the three ratings:

With 1 to 10 scales the RPN ranges from 1 to 1,000.

Example: a duplicate ledger write with $S = 8$, $O = 5$ and $D = 6$ gives $RPN = 8 \times 5 \times 6 = 240$.

6.2 Limits of the RPN and action priority

The RPN is an ordinal product, not a measure of risk. Very different combinations give the same number (S 10, O 2, D 2 and S 2, O 5, D 4 both give 40), and a small change in one rating can move an item across a threshold. For that reason this analysis also applies these rules:

• Any failure mode with $S \ge 9$ requires an action or a documented risk acceptance by [role], whatever its RPN.
• A combination of $S \ge 7$ and $O \ge 6$ requires an action.
• Some organisations replace the RPN with an action priority (AP) table that ranks severity first, then occurrence, then detection, into High, Medium and Low priority. If your organisation uses such a table, record the AP column in the worksheet and use it in place of the RPN thresholds below.

6.3 Thresholds

7. Recommended actions

8. FMEA worksheet

The worksheet records each failure mode with its effects, causes, controls, ratings and actions. Ratings are the initial (before action) scores.

9. Re-scoring after actions

Severity usually changes only when the design changes the effect, for example a fallback that keeps checkout working. Better tests reduce detection; prevention controls reduce occurrence.

10. Results, residual risk and follow-up

10.1 Summary

10.2 Accepted residual risks

10.3 Review triggers

The FMEA is reviewed when any of the following occurs:

• A major design change, new dependency or new interface.
• An incident whose failure mode is missing from the worksheet, or whose occurrence or detection differs from the score.
• Before each major release, and at least every [12] months.

11. Appendices

11.1 Glossary

11.2 Workshop records

Standard and licence note

Structure aligned with IEC 60812:2018 (Failure modes and effects analysis (FMEA and FMECA)), for the overall FMEA process of planning, structure and function analysis, failure analysis, risk evaluation, actions and documentation. The rating scales, thresholds and software failure mode taxonomy are examples written for this collection. This template is original text written for this collection and reproduces no text from the standard; obtain the standard for its normative requirements. Template licence: MIT.