# 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.

<!--
Guidance: How to use this template
- Run the analysis as a facilitated workshop with design, development, test,
  operations and product. One person cannot see all the failure modes.
- Analyse functions, not code files. Ask "how can this function fail to do
  what it should?" for each function in scope, then trace effects and causes.
- Agree the severity, occurrence and detection scales BEFORE scoring and keep
  them stable for the whole analysis, otherwise numbers are not comparable.
- Do not treat the risk priority number as a precise measure. Use it, or an
  action priority table, to rank work; high severity always gets attention.
- Re-score after actions are complete and keep the worksheet as a living
  record linked to the backlog and to incident postmortems.
-->

## Document control

<!-- Guidance: Identify the analysis, its scope and the team. Status moves Draft -> In review -> Approved -> Superseded. -->

| Field | Value |
|---|---|
| Document ID | [FMEA-SYS-001] |
| System / service | [Name], [version or release] |
| Analysis type | [Design SFMEA / Interface SFMEA / Process (deployment) SFMEA] |
| Version | [0.1] |
| Status | [Draft / In review / Approved] |
| Facilitator | [@facilitator] |
| Owner | [@engineering-lead] |
| Workshop dates | YYYY-MM-DD, YYYY-MM-DD |
| Classification | [Internal / Confidential] |
| Last updated | YYYY-MM-DD |
| Related | [Architecture description], [SRS], [Threat model], [Incident reports], [Test plan] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Engineering lead | [@name] | [Approved / Approved with comments] | YYYY-MM-DD |
| Reliability / SRE lead | [@name] | [Decision] | YYYY-MM-DD |
| Quality / safety lead | [@name] | [Decision] | YYYY-MM-DD |
| Product owner | [@name] | [Decision] | YYYY-MM-DD |

## Revision history

<!-- Guidance: Record each scoring round. Re-scoring after actions is a new version, not an overwrite. -->

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Scope, structure and function analysis |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Failure analysis and first scoring from workshop 2 |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Actions agreed and approved |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Re-scoring after actions FM-004 and FM-007 completed |

## Contents

<!-- Guidance: Keep in sync with headings. -->

1. [Introduction and scope](#1-introduction-and-scope)
2. [System structure](#2-system-structure)
3. [Functions and requirements](#3-functions-and-requirements)
4. [Rating scales](#4-rating-scales)
5. [Failure analysis](#5-failure-analysis)
6. [Risk evaluation](#6-risk-evaluation)
7. [Recommended actions](#7-recommended-actions)
8. [FMEA worksheet](#8-fmea-worksheet)
9. [Re-scoring after actions](#9-re-scoring-after-actions)
10. [Results, residual risk and follow-up](#10-results-residual-risk-and-follow-up)
11. [Appendices](#11-appendices)
12. [Standard and licence note](#standard-and-licence-note)

## 1. Introduction and scope

<!-- Guidance: Planning is the first step of an FMEA. State why the analysis is done, what is in and out, the assumptions and who takes part. Vague scope produces an endless worksheet. -->

### 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

| In scope | Out of scope |
|---|---|
| *Example:* Payment authorisation API, risk scoring worker, ledger writer | *Example:* Card network internals (treated as an external dependency) |
| *Example:* Deployment pipeline for these services | *Example:* Corporate identity provider (covered by its own FMEA) |
| *Example:* Interfaces to fraud provider and message broker | *Example:* Physical data centre failures (covered by DR plan) |
| [Item] | [Item] |

### 1.3 Level of analysis

| Item | Choice |
|---|---|
| Analysis level | *Example:* Component (service) level, with function-level failure modes |
| Lifecycle stage | *Example:* Detailed design complete, before system test |
| Approach | *Example:* Functional SFMEA for services, interface SFMEA for external calls |
| Mission or operating profile | *Example:* 24x7, peak 1,200 authorisations per second on sale days |

### 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

| Name | Role in analysis | Area of knowledge |
|---|---|---|
| [@name] | Facilitator | FMEA method |
| [@name] | Design authority | Architecture |
| [@name] | Developer | Authorisation service |
| [@name] | Tester | Test design and coverage |
| [@name] | SRE | Monitoring, incidents, operations |
| [@name] | Product | Customer and business impact |

## 2. System structure

<!-- Guidance: Break the system into elements so every failure mode has a home. Use the same names as the architecture description. Stop at the level where the team can still reason about behaviour. -->

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

```mermaid
flowchart LR
  C["Client apps"] --> API["EL-01 Authorisation API"]
  API --> RS["EL-02 Risk scoring worker"]
  API --> FP["EL-05 Fraud provider (external)"]
  RS --> MB["EL-03 Message broker"]
  MB --> LW["EL-04 Ledger writer"]
  LW --> DB[("EL-06 Ledger database")]
```

| Element ID | Element | Type | Owner | Notes |
|---|---|---|---|---|
| EL-01 | *Example:* Authorisation API | Service | [@team] | Stateless, 6 replicas |
| EL-02 | *Example:* Risk scoring worker | Service | [@team] | Model loaded at start-up |
| EL-03 | *Example:* Message broker | Platform | [@platform] | Three-node cluster |
| EL-04 | *Example:* Ledger writer | Service | [@team] | Single writer per partition |
| EL-05 | *Example:* Fraud provider | External | [Vendor] | 300 ms contractual p99 |
| EL-06 | *Example:* Ledger database | Data store | [@dba] | Primary plus two replicas |
| [EL-NN] | [Element] | [Type] | [Owner] | [Notes] |

## 3. Functions and requirements

<!-- Guidance: List what each element must do, with measurable requirements. Failure modes are the negation of these functions, so precise functions give precise failure modes. -->

| Function ID | Element | Function (verb + object) | Requirement / performance | Source |
|---|---|---|---|---|
| FN-01 | EL-01 | *Example:* Return an authorisation decision | p99 latency under 400 ms; decision for 100% of valid requests | SRS-PERF-012 |
| FN-02 | EL-02 | *Example:* Score transaction risk | Score within 150 ms; model version recorded with each score | SRS-FR-044 |
| FN-03 | EL-04 | *Example:* Record each approved payment exactly once | No duplicates, no losses; ledger lag under 5 s | SRS-FR-051 |
| FN-04 | EL-01 | *Example:* Reject requests without valid credentials | 100% of unauthenticated requests rejected | SEC-REQ-003 |
| FN-05 | Pipeline | *Example:* Deploy a new version without downtime | Zero failed requests during rollout | OPS-REQ-010 |
| [FN-NN] | [EL-NN] | [Function] | [Requirement] | [Source] |

## 4. Rating scales

<!-- Guidance: Tailor the scales to your domain and keep the definitions concrete. A 1-10 scale is common; a 1-5 scale is easier to agree on. Whatever you choose, document it here and do not change it mid-analysis. -->

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.

| Score | Rating | Criteria for software and services |
|---|---|---|
| 10 | Hazardous | Harm to people or a breach of law or regulation without warning |
| 9 | Regulatory | Breach of law, regulation or contract with warning; reportable data breach |
| 8 | Very high | Core function unavailable for all users; financial loss or data corruption |
| 7 | High | Core function unavailable for a segment; incorrect results visible to users |
| 6 | Moderate | Core function degraded; manual workaround needed |
| 5 | Low | Secondary function unavailable |
| 4 | Very low | Secondary function degraded; most users notice |
| 3 | Minor | Cosmetic or minor issue; some users notice |
| 2 | Very minor | Noticed only by attentive users or operators |
| 1 | None | No discernible effect |

### 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.

| Score | Likelihood | Example frequency in production |
|---|---|---|
| 10 | Almost certain | More than once per day |
| 9 | Very high | About once per week |
| 8 | High | About once per month |
| 7 | Moderately high | About once per quarter |
| 6 | Moderate | About twice per year |
| 5 | Occasional | About once per year |
| 4 | Low | Once in 2 to 5 years |
| 3 | Very low | Once in 5 to 10 years |
| 2 | Remote | Seen in the industry, not in this system |
| 1 | Nearly impossible | Prevented by design, for example by type system or formal constraint |

### 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.

| Score | Detection likelihood | Example control |
|---|---|---|
| 10 | Not detectable | No test, no monitor; users report it |
| 9 | Very remote | Found only by manual log review after the fact |
| 8 | Remote | Manual exploratory testing only |
| 7 | Very low | Generic alert (for example error rate) fires after significant user impact |
| 6 | Low | Specific alert, but after some user impact |
| 5 | Moderate | System or integration test covers the scenario |
| 4 | Moderately high | Automated test in CI plus canary analysis |
| 3 | High | Contract or property-based test blocks the merge |
| 2 | Very high | Static analysis or type checking blocks the build |
| 1 | Almost certain | Failure prevented by design and verified automatically |

## 5. Failure analysis

<!-- Guidance: For each function, list failure modes, then for each mode the effects (local, next level, end user) and causes. Typical software failure modes: no output, wrong output, late output, output at the wrong time, duplicate output, partial output, unauthorised output. -->

### 5.1 Failure mode taxonomy

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

| Mode class | Description | Example |
|---|---|---|
| Omission | Function does not produce an output | Authorisation request times out with no decision |
| Commission | Function produces an output when it should not | Payment recorded for a declined request |
| Incorrect value | Output is wrong | Risk score uses a stale model |
| Timing | Output is too late or too early | Ledger lag exceeds 5 s |
| Duplication | Output produced more than once | Payment written twice after retry |
| Partial | Output incomplete | Ledger entry missing currency field |
| Security | Function bypassed or misused | Request accepted with expired token |

### 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

| Control type | Purpose | Examples |
|---|---|---|
| Prevention | Reduce the chance the cause occurs | Code review, design patterns, idempotency keys, schema validation, rate limits |
| Detection | Find the cause or failure before users are affected | Unit and contract tests, canary analysis, synthetic checks, SLO alerts |

## 6. Risk evaluation

<!-- Guidance: Explain how risks are ranked. Show the formula and its limits, and state the thresholds that trigger mandatory action. -->

### 6.1 Risk priority number

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

$$
RPN = S \times O \times D
$$

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

| Rule | Action required |
|---|---|
| $S \ge 9$ | Action mandatory or formal risk acceptance |
| $RPN \ge [200]$ | Action mandatory before [release] |
| $[100] \le RPN < [200]$ | Action planned within [two sprints] |
| $RPN < [100]$ | Monitor; review at next FMEA update |

## 7. Recommended actions

<!-- Guidance: Actions should reduce severity (design change), occurrence (prevention) or detection (better tests and monitoring), in that order of preference. Each action needs an owner, a date and a link to the backlog. -->

| Action ID | Failure mode | Action | Rating targeted | Owner | Due | Ticket | Status |
|---|---|---|---|---|---|---|---|
| ACT-01 | FM-003 | *Example:* Add idempotency key on ledger writes and enforce a unique constraint | O, D | [@dev] | YYYY-MM-DD | [PAY-812] | In progress |
| ACT-02 | FM-001 | *Example:* Add circuit breaker and cached fallback decision for fraud provider timeouts | S, O | [@dev] | YYYY-MM-DD | [PAY-815] | Open |
| ACT-03 | FM-004 | *Example:* Add contract test for token expiry and alert on rejected-token ratio | D | [@qa] | YYYY-MM-DD | [PAY-820] | Done |
| ACT-04 | FM-006 | *Example:* Automated rollback when canary error rate exceeds baseline by 2x | D | [@sre] | YYYY-MM-DD | [OPS-301] | Open |
| [ACT-NN] | [FM-NNN] | [Action] | [S/O/D] | [@owner] | YYYY-MM-DD | [Ticket] | [Status] |

## 8. FMEA worksheet

<!-- Guidance: One row per cause. Keep text short and specific. Use the IDs from sections 2, 3 and 7 so the worksheet can be traced. Wide tables are easier to maintain in a spreadsheet; export here for review. -->

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

| FM ID | Element / function | Failure mode | End effect | S | Cause | Prevention control | O | Detection control | D | RPN | Action |
|---|---|---|---|---|---|---|---|---|---|---|---|
| FM-001 | EL-01 / FN-01 | *Example:* No decision returned (timeout) | Checkout fails for the customer; lost sale | 8 | Fraud provider p99 above 2 s during its peak | Client timeout 500 ms | 6 | Error-rate SLO alert | 6 | 288 | ACT-02 |
| FM-002 | EL-02 / FN-02 | *Example:* Score computed with stale model | Fraud let through or good customers declined | 7 | Model reload fails silently after deploy | Model version check in start-up | 4 | None specific | 8 | 224 | [ACT-NN] |
| FM-003 | EL-04 / FN-03 | *Example:* Payment written twice | Customer charged twice; reconciliation effort | 8 | Broker redelivery after writer crash before ack | Ack after commit | 5 | Nightly reconciliation report | 6 | 240 | ACT-01 |
| FM-004 | EL-01 / FN-04 | *Example:* Expired token accepted | Unauthorised payment request processed | 9 | Clock skew tolerance set to 24 h by mistake | Config review | 3 | Manual pen test yearly | 8 | 216 | ACT-03 |
| FM-005 | EL-04 / FN-03 | *Example:* Ledger lag above 5 s | Balance shown to user is out of date | 5 | Hot partition on large merchant | Partition by merchant and day | 5 | Lag metric with alert | 3 | 75 | Monitor |
| FM-006 | Pipeline / FN-05 | *Example:* Faulty release reaches all replicas | Full outage of authorisations | 8 | No automated canary gate | Code review, staging tests | 4 | Manual watch of dashboards | 7 | 224 | ACT-04 |
| [FM-NNN] | [EL / FN] | [Mode] | [Effect] | [S] | [Cause] | [Control] | [O] | [Control] | [D] | [RPN] | [Action] |

## 9. Re-scoring after actions

<!-- Guidance: After an action is verified (test passes, alert proven, design change deployed) re-score S, O and D and record the evidence. Do not re-score on intent. -->

| FM ID | Action | Evidence of completion | S | O | D | New RPN | Change | Accepted by |
|---|---|---|---|---|---|---|---|---|
| FM-001 | ACT-02 | *Example:* Load test LT-44 shows fallback decision in 120 ms with provider disabled | 6 | 4 | 4 | 96 | 288 to 96 | [@name] |
| FM-003 | ACT-01 | *Example:* Chaos test CE-12 kills writer before ack; zero duplicates in 10,000 runs | 8 | 2 | 3 | 48 | 240 to 48 | [@name] |
| FM-004 | ACT-03 | *Example:* Contract test CT-207 in CI; alert tested in game day GD-05 | 9 | 2 | 3 | 54 | 216 to 54 | [@name] |
| [FM-NNN] | [ACT-NN] | [Evidence] | [S] | [O] | [D] | [RPN] | [Change] | [@name] |

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

<!-- Guidance: Summarise for decision makers: top risks, actions completed, risks accepted and when the FMEA will be reviewed again. -->

### 10.1 Summary

| Metric | Before actions | After actions |
|---|---|---|
| Failure modes analysed | [42] | [42] |
| Failure modes with $S \ge 9$ | [3] | [3, all with actions or acceptance] |
| Failure modes with $RPN \ge 200$ | [7] | [1] |
| Highest RPN | [288 (FM-001)] | [224 (FM-002)] |

### 10.2 Accepted residual risks

| FM ID | Residual risk | Reason for acceptance | Accepted by | Review date |
|---|---|---|---|---|
| FM-002 | *Example:* Stale model not detected until drift report | Fix requires model registry migration planned for Q[n] | [@product-owner] | YYYY-MM-DD |
| [FM-NNN] | [Risk] | [Reason] | [@name] | YYYY-MM-DD |

### 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

<!-- Guidance: Keep supporting material here: workshop notes, glossary and links to evidence. -->

### 11.1 Glossary

| Term | Meaning in this document |
|---|---|
| Failure mode | The way in which an element fails to perform its function |
| Effect | The consequence of a failure mode on the element, the system and the user |
| Cause | The weakness or event that leads to the failure mode |
| Control | A measure that prevents a cause or detects a cause or failure mode |
| RPN | Risk priority number, the product of severity, occurrence and detection |
| AP | Action priority, a table-based ranking used as an alternative to RPN |

### 11.2 Workshop records

| Date | Participants | Scope covered | Notes link |
|---|---|---|---|
| YYYY-MM-DD | [Names] | *Example:* Sections 2 to 3, elements EL-01 to EL-03 | [Link] |
| YYYY-MM-DD | [Names] | *Example:* Failure analysis and scoring | [Link] |

## 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.