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

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

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

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