Planning, Design, and Requirements Analysis
Requirements first, products second
Requirements work splits into functional requirements (what the system does) and non-functional requirements (how well it does it: performance, availability, security, usability, maintainability). Constraints are imposed limits such as budget, regulation, or an existing platform. Assumptions must be written down, because unanswered assumptions become design defects. Each requirement needs a verifiable acceptance criterion; if you cannot imagine a test for it, it is not yet a requirement.
Prioritization and traceability
Expect questions on MoSCoW (must, should, could, won't), on distinguishing a need from a want, and on tracing a requirement through design, build, and test. Change requests are normal; the exam wants the disciplined path: log it, assess impact, get approval, update baselines, then implement.
Design for failure
Design topics include single points of failure, redundancy, capacity headroom, and recovery targets. RTO is how long recovery may take; RPO is how much data loss is tolerable. A four-hour RTO with a fifteen-minute RPO means restores must be proven to complete within four hours and backups or replication must capture changes at least every fifteen minutes.
Traps
Questions blur RTO and RPO, or present a design that meets the stated requirement but violates an unstated constraint such as cost. Another common trap is the solution that is technically elegant but skips stakeholder sign-off.
Worked example
A stakeholder says the system must never lose more than fifteen minutes of transactions and must be back within four hours. Translate that into two numbers, then choose mechanisms: frequent incremental backups or synchronous replication for the RPO, and a documented, rehearsed restore procedure for the RTO. Restore time is usually dominated by process, not hardware, so rehearsal is part of the answer, not an optional extra.