Question 1 of 11: Software Design Artifacts and Their Use

Question 1: Software Design Artifacts and Their Use (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 set of requirements into a concrete blueprint for construction, and it does so by producing a family of artifacts rather than a single document. Typical outputs are an architecture description (the system's major components and their connections), detailed design specifications for each component (data structures, algorithms, control logic), interface specifications describing 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 the significant design decisions and the rationale behind them. Consider a library-catalogue system: the design stage for it would yield a class diagram showing Book, Member and Loan classes, an interface specification for a searchCatalogue(keyword) operation, and an entity-relationship schema for the underlying database — three distinct artifacts that together tell an implementer exactly what to build.

(b) Design and Requirements Engineering

Requirements engineering and design are adjacent, tightly coupled stages: requirements engineering establishes what the system must do and the qualities it must exhibit, while design decides how those obligations will be satisfied in a feasible, buildable structure. Design consumes the requirements specification as its primary input, and every design element should be traceable back to one or more requirements it exists to satisfy. The relationship is not purely one-directional, however: while designing, a team frequently discovers that a stated requirement is ambiguous, technically infeasible within budget, or in conflict with another requirement, and this feeds back into requirements engineering to renegotiate or clarify the specification. Non-functional requirements in particular — performance targets, security obligations, expected load — have an outsized influence on design because they usually determine the architectural style chosen, not just the detail of individual modules.

(c) How Design Artifacts Are Used Downstream

Design artifacts are working documents consumed by every later stage of development, not archival paperwork. Implementers use the class diagrams, interface specifications and data schemas as a direct 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, using them to understand why a component is structured as it is before making a safe change. Returning to the library-catalogue example, the Loan class diagram guides the developer implementing loan tracking, the same diagram lets a QA engineer write a test that checks a book cannot be borrowed twice simultaneously, and two years later a maintainer extending the system to support e-book loans consults the original architecture description to see where the new capability should be added without disturbing the existing catalogue and membership logic.

Practical Application

On a real project these artifacts are what allow a design team to 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.