<!-- Generated from applied-computing-au vic/unit3-4/sat/C08-2026/C08-Reference-Godot by port-reference-godot-to-wiki.py — do not hand-edit; re-run the port. -->
# Contingency Planning

*The 9–10 rung of C8-2: contingencies documented, and solutions to mitigate them documented. Specific beats plentiful.*

**Definition.** A contingency is something that could still go wrong with your project, paired with the mitigation you'd apply if it did. This isn't about evaluation scores — it's about whether your software will **actually work as promised** in your SRS.

## What a contingency table looks like

| Potential issue | Evaluation factor | Likelihood | Mitigation strategy |
|---|---|---|---|
| School network fails during demonstration | Efficiency (speed of processing) | Medium | Offline mode with local data storage |
| Users forget login details | Effectiveness (usability) | High | Password reset + clear instructions |
| Different screen sizes break the layout | Effectiveness (accessibility) | High | Responsive design, flexible containers |
| Software crashes on large datasets | Effectiveness (accuracy) | Low | Input validation and error handling |

**Likelihood:** **HIGH** — likely during normal use (typing mistakes, typical hardware) · **MEDIUM** — needs specific conditions (unusual input, particular devices) · **LOW** — exceptional circumstances only.

## The 4-step analysis

Take one requirement from your SRS and:

1. **Identify what can go wrong** — decompose it: *"scores (0–100)"* → what if someone enters 150? letters? nothing?
2. **Rate the risk** — likelihood plus one sentence of *why that likelihood*.
3. **Create a mitigation plan** — prevent the problem (validation), handle it gracefully (clear error message), guide the user (keep their input visible to fix), and check the cost (validation must be instant).
4. **Design your test method** — how you'll prove the mitigation works: can't submit invalid data, message is clear, tested with someone who hasn't used it before.

Do this once for a **functional** requirement and once for a **non-functional** one (e.g. a speed target: test on the *school's* older computers, not just your laptop, and build in a performance buffer).

## Success tips

1. **Be specific** — "make it faster" isn't a plan; "reduce clicks from 8 to 3" is.
2. **Test early** — don't discover the school-computer problem on demo day.
3. **Plan for real users** — people who didn't build it will use it differently.
4. **Focus on high-likelihood risks first.**
5. **Document your testing** — evidence of mitigation attempts is what the 9–10 band reads.

One well-planned mitigation with evidence beats five vague strategies. The blank template is in your class repo: `S-C08/C082-Contingency-Plan-Template.md`.