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:
- Identify what can go wrong — decompose it: "scores (0–100)" → what if someone enters 150? letters? nothing?
- Rate the risk — likelihood plus one sentence of why that likelihood.
- 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).
- 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
- Be specific — "make it faster" isn't a plan; "reduce clicks from 8 to 3" is.
- Test early — don't discover the school-computer problem on demo day.
- Plan for real users — people who didn't build it will use it differently.
- Focus on high-likelihood risks first.
- 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.