Requirements, design, testing and architecture trade-offs
Core concepts
Know the software development life cycle: requirements, analysis, design, implementation, testing, deployment, and maintenance. Compare process models - waterfall, incremental, spiral, prototype, and agile/Scrum - and when each fits. Understand requirement types (functional versus non-functional), feasibility studies, and elicitation techniques. Study design tools: DFDs (context, level 0, level 1), ER diagrams, UML use case, class, sequence, and activity diagrams, and structured charts. Know cohesion and coupling (high cohesion, low coupling is desirable), modularity, and the difference between verification and validation. Testing levels: unit, integration, system, acceptance; techniques: black-box versus white-box, plus regression testing. Cover version control, configuration management, and maintenance categories.
Traps
A classic trap is mixing up DFD components: processes, data stores, external entities, and data flows - a DFD shows data movement, not control flow. Do not confuse verification (are we building it right?) with validation (are we building the right thing?). For evolving requirements, compare iterative feedback, risk investigation and delivery constraints rather than selecting a process name without the scenario’s evidence. State the diagram convention: some methods call the single-process context diagram level 0, while others reserve level 0 for its first decomposition. Preserve balanced external flows rather than infer the convention from the number alone.
Worked example
For a library system, the context diagram shows one process, "Library System", with external entities Member and Librarian, and data flows such as loan request and fine notice. Decompose to level 1 into processes like Issue Book, Return Book, and Calculate Fine, each drawing on data stores Book and Loan. Rule of thumb: external entities never talk directly to data stores; a process must sit between them.
Architecture choices and testable quality
Architectural styles are trade-offs. A layered design separates responsibilities but can add call overhead; an event-driven design decouples producers and consumers but requires delivery, ordering and duplicate-handling decisions. Microservices introduce independent deployment boundaries and distributed failure modes; they do not automatically create maintainability or eliminate transactions. Middleware can provide messaging, service discovery or transaction coordination, but its guarantees depend on configuration and failure assumptions. State what happens on timeout, retry and partial success before claiming reliability.
Quality attributes become useful when expressed as scenarios with an observable response and a measurement condition. For example, a supplied service may require that 95 percent of a specified read workload complete within 200 milliseconds at a stated concurrency. This is a hypothetical acceptance criterion, not a national examination rule or a universal performance target. Trace the criterion to the relevant architecture, implementation, test and monitoring evidence. Coupling is not always bad: an explicit stable contract can be preferable to concealed shared state. Similarly, reuse requires checking whether an abstraction preserves the real responsibilities rather than introducing a fashionable pattern. A design review should compare alternatives against requirements, identify assumptions and record unresolved risks before implementation proceeds.