Loading...
A solution is useful when it addresses a defined problem for its intended users. Analysis establishes what is needed; design explains how the proposed model and components can provide it.
What you'll be able to do
Identify the intended users, their present task and the constraints that make a solution valuable. Dialogue can reveal exceptions that a programmer would not infer from a short initial request. Requirements should state observable outcomes rather than vague qualities such as “fast” or “easy”.
A measurable requirement might specify that a report includes all bookings in a selected date interval and orders them by start time. Distinguish required functionality from optional enhancements and record relevant assumptions. A clear data model connects the real entities and relationships to the information the system will retain.
Plan suitable data structures, database relations, algorithms and module boundaries. A module’s interface should make inputs, outputs and effects clear. Interface designs should reflect user tasks and validation needs rather than begin with decorative screens detached from the processing model.
Use diagrams, pseudocode or tables where they communicate a decision more clearly than prose. An algorithm design should be detailed enough to explain a difficult calculation or state transition. A screenshot of a menu alone cannot explain how the core problem will be solved.
A prototype can test an uncertain interaction or technical approach before a large implementation depends on it. Feedback may refine requirements and design, so development need not follow a rigid once-only sequence of phases. Keep the rationale for significant changes.
Tackle the critical path early: the essential dependency without which the system or investigation cannot work. For a route planner, correct graph modelling and route calculation matter before polishing a colour scheme. Iteration is purposeful revision based on evidence, not an excuse to omit requirements or leave the design unexplained.
| Vague statement | More testable requirement |
|---|---|
| Produce useful reports | Include all bookings within the selected dates, ordered by start time |
| Handle bad input | Reject an end date earlier than the start date with a clear message |
| Make it fast | Use a defined representative dataset and stated response target |
Attempt the task before opening its worked response. Record each change of state, explain the rule used, and check the result against the original requirements. Code examples labelled Python 3 use that language’s conventions; pseudocode states its own assumptions.
Common mistakes to avoid
Key takeaways
Test yourself
Answer a few questions, then review anything you missed.
Start with the quiz above to check the key ideas. You can also choose another topic from the practice library.