Software Design and Development
From requirements to design
Software development begins by turning a client's needs into a specification, then into a design, then into code. Candidates must distinguish functional requirements (what the system does) from non-functional requirements (performance, usability, security, portability). Learn the software development lifecycle stages and the common methodologies: the waterfall model (sequential, documentation-heavy, poor at absorbing change) versus iterative and agile approaches (incremental delivery, frequent feedback). Understand design tools - data flow diagrams, context diagrams, structure charts, pseudocode and UML class or use-case diagrams - and what each communicates.
Traps to watch
A frequent trap is confusing a context diagram (whole system as one process, external entities only) with a level-0 data flow diagram (breaks the system into major processes). Another is labelling a constraint such as "must run on the school's existing network" as functional. Questions often ask you to justify a methodology for a scenario: match the method to the project's volatility, size and client involvement rather than naming your favourite. Also be ready to explain maintainability features - modularity, cohesion, coupling, naming conventions and internal documentation.
Worked example
A small bakery wants a stock-ordering app with a fixed deadline and stable requirements, and the owner cannot attend regular meetings. Rule of thumb: stable requirements plus limited client availability points toward a plan-driven (waterfall-style) approach with clear sign-off milestones; volatile requirements plus an engaged client points toward iterative development.
Rule of thumb
For every design question, ask what does this artefact show, and who reads it? If you can answer both, the classification is usually correct.