Question 1 of 6: Software Design Artifacts and Their Role

Question 1: Software Design Artifacts and Their Role (10 marks)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

(a) Artifacts the Design Stage Produces

The design stage translates an agreed requirements specification into a concrete blueprint that a construction team can build from, and it does this by producing several distinct artifacts rather than a single document. The typical set includes an architecture description (the system's major components and how they connect), detailed design specifications for each component (its internal data structures, algorithms and control logic), interface specifications stating every operation a component exposes to the rest of the system, structural and behavioural diagrams (class diagrams, structure charts, sequence or state diagrams), a data model or database schema, and a written record of significant design decisions and their rationale. Consider a hotel-booking system: its design stage produces a class diagram showing Room, Guest and Reservation classes, an interface specification for a checkAvailability(dateRange) operation, and an entity-relationship schema for the reservations database — three distinct artifacts that together tell an implementer exactly what to build.

(b) Requirements Analysis in the Software Engineering Process

Requirements analysis sits at the front of the software engineering process, immediately after requirements elicitation and before design begins. Its job is to take the raw, often inconsistent statements gathered from stakeholders and turn them into a structured, validated, prioritised requirements specification — resolving ambiguity, detecting conflicts between requirements, and separating functional requirements (what the system must do) from non-functional requirements (the qualities it must exhibit, such as performance or security). This specification becomes the primary input to design: every design decision should be traceable back to one or more requirements it exists to satisfy, and the non-functional requirements in particular have an outsized influence on design because they typically determine the architectural style chosen (for example, a hard real-time NFR pushes the designer toward an event-driven architecture) rather than only the detail of individual modules. The relationship also runs backward: while designing, a team frequently discovers that a requirement is technically infeasible within budget or conflicts with another requirement, and this feeds back into requirements analysis to renegotiate the specification before design proceeds further.

(c) How Design Artifacts Are Used Downstream

Design artifacts are working documents consumed by every later stage of development, not archival paperwork produced only to satisfy a process gate. Implementers use the class diagrams, interface specifications and data schemas directly as a blueprint, writing code whose module boundaries mirror the design's component boundaries. Testers derive test cases from the same artifacts: a state diagram or interface specification tells a tester exactly which transitions or operations must be exercised, and integration tests are organised around the interfaces the design defines between components. Maintainers rely on the architecture description and design-rationale record long after initial delivery, consulting them to understand why a component is structured as it is before making a safe change. Returning to the hotel-booking example, the Reservation class diagram guides the developer implementing booking logic, the same diagram lets a QA engineer write a test that checks a room cannot be double-booked for overlapping dates, and a maintainer extending the system to support group bookings later consults the original architecture description to see where the new capability fits without disturbing existing availability logic.

Practical Application

On a real project these artifacts are what let a design team hand work to an implementation team with confidence: a well-specified interface lets two developers build the client and the service behind it in parallel, each coding against the agreed signature rather than against each other's source code.