Question 1 of 6: Design Artifacts, Input and Effort, and Downstream Use

Question 1: Design Artifacts, Input and Effort, and Downstream Use (equal value)

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) Architecture Design vs. Detailed Design

Software architecture design works at the level of the whole system: it identifies the major components, subsystems or modules, decides how they are structured and connected, and fixes the significant technical decisions (architectural style, technology choices, how components communicate) that are expensive to change later. Detailed design works one level down, inside each component the architecture has already identified: it specifies the internal algorithms, data structures, class/method signatures and control logic needed to actually implement that component. The relationship between the two is hierarchical and constraining — detailed design is carried out within the boundaries the architecture design has already fixed, so a detailed designer cannot silently redraw a component boundary the architecture defined. For a personal address book application, the architecture design decides that the system will have a Presentation Layer, a Business Logic Layer and a Data Access Layer, and that they communicate through calls and returns; the detailed design then works out, inside the Business Logic Layer alone, the exact algorithm for validating a new contact's phone number and the precise method signature addContact(Contact c): boolean that the Presentation Layer will call.

(b) Basis/Input to Design and How It Affects the Resulting Design

The basis or input to software design is the requirements specification produced by the preceding requirements-engineering stage — both the functional requirements (what the system must do) and the non-functional requirements (the quality attributes it must exhibit, such as modifiability or performance targets). This input affects the resulting design in two distinct ways. First, the functional requirements determine WHICH components and operations the design must provide: the address book's functional requirements to add, delete, modify, save and load contacts mean the architecture must contain, at minimum, contact-management logic and a persistence mechanism — a design cannot invent a component the requirements never called for, nor omit one they did. Second, the non-functional requirements determine HOW those components are structured, typically deciding the architectural style itself: if the address book's non-functional requirements demand high modifiability, the design responds with a layered structure specifically to satisfy that target, even though the identical functional requirements could be met by the flatter, less structured Design 1 shown later in Question 4(b). The quality and completeness of this input therefore has a direct, causal effect on the resulting design's own quality: an incomplete or ambiguous requirements specification — for example, one that never states whether the same phone number can belong to two contacts — forces a design team to guess, and a wrong guess produces a design that must later be reworked once the ambiguity surfaces during implementation or testing.

(c) How Later Stages Use the Design Artifacts

Implementers use the architecture design as their component map and the detailed design as their per-component blueprint, writing code whose module boundaries mirror the architecture and whose internal logic follows the detailed design's specified algorithms and data structures. Testers derive their test strategy from the same two artifacts: the architecture design tells testers where component boundaries are, so integration tests are organised around exactly those interfaces, while the detailed design's specified logic and data structures tell a unit tester which internal paths and edge cases must be exercised. Maintainers rely on the architecture description long after delivery to understand where a change belongs without disturbing unrelated components, and on the detailed design record to understand why a specific algorithm was chosen before altering it. For the address book example, a tester writes an integration test that calls the Business Logic Layer's public interface exactly as the architecture specifies, a separate unit test exercises the phone-number validation algorithm the detailed design specified, and two years later a maintainer extending the system to support international phone numbers consults both artifacts to see exactly which validation routine needs to change and which layer boundary must not be disturbed.

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 architecture and detailed design let two developers build the Business Logic Layer and the Presentation Layer in parallel, each coding against the agreed interface rather than against each other's source code.