CH.05 · DETAILED DESIGN

Software Design & Architecture

Principles of Detailed Design

The bridge between architecture and code — where components stop being boxes on a diagram and become blueprints precise enough to build from.

Chapter 05 · Lecture 01 Comes after Requirements + Architecture Leads to Software Construction Next chapter Design Patterns
01

The Big Picture — Where Detailed Design Fits

Software design isn't one step, it's a pipeline that gets more concrete at every stage. Detailed Design is the third stop.

🧠 Mnemonic — R.A.D.C. → "Real Architects Draft Carefully" — Requirements → Architecture → Detailed Design → Construction.
R
RequirementsWhat the system must do. Gathered & documented.
↓
A
ArchitectureMacro-design — overall structure & component interactions.
↓
D
Detailed DesignMicro-design — refine each component's internals & interfaces.
WE ARE HERE
↓
C
ConstructionActual coding. The goal we're eventually building toward.

🏗️ Why the shift matters

Architecture asks "what are the big pieces and how do they talk?" Detailed Design asks "exactly how does each piece work inside?"

Worked example — banking app:

  • Requirements: users must check balances / transfer money
  • Architecture: client–server model, database, app, security layer
  • Detailed Design: for login → specify password validation, authentication, session management
  • Construction: implement login, account management, transfer features
02

What Is Detailed Design?

One sentence to memorize: Detailed design refines architecture until it's complete enough to implement — it defines each component's internal structure and behavior.

BLUEPRINT ANALOGY

📐 Detailed Design = Blueprints

You don't write code yet — you specify exactly how every part will work: algorithms, database schemas, interfaces, class diagrams.

EX — Login needs: password rules (min length, special chars) · hashing + salting for auth · session timeout & refresh tokens.
CONSTRUCTION ANALOGY

🔨 Construction = Building the House

Developers translate the blueprint into actual, executable code — source files and builds.

EX — Writing the real validatePassword() function · implementing the auth API · coding the session module.

↔️ The Designer's Mental Model — Think Both Directions

Detailed design sits between Requirements/Architecture and Code. A good detailed designer can move either way:

Requirements
+ Architecture
forward: design details until code →
↑
← backward: reverse-engineer code into design
Detailed Design
→
↓
Code

REVERSE ENGINEERING = analyzing existing code to figure out what the system does, how it's structured, and how it maps back to the design/requirements. Needs industry-grade tools: UML modeling, code generators, compilers, version control.

03

The 5 Key Tasks — U.C.E.D.M.

Everything a detailed designer does falls into five tasks, always roughly in this order.

🧠 Mnemonic — U.C.E.D.M. → "Uncle Chris Eats Dinner Monthly" — Understand → Create → Evaluate → Document → Manage.
U
Understand Architecture & RequirementsFocus only on what's allocated to YOUR component
+

Unlike architecture (where the complete requirement set is evaluated), detailed design focuses on requirements allocated to specific components.

EX — Big components like SensorManager, VideoManager, ClientManager get assigned to different teams. Each team refines its own piece, adds detailed requirements (validation, performance), and preps it for coding.
C
Create Detailed DesignsStructural + Behavioral design of each component
+

Four things get designed (mnemonic: I.G.I.D. → "Igloos Grow In Denver"):

  • Interface Design — internal & external
  • GUI Design — the graphical user interface
  • Internal Component Design — structural & behavioral
  • Data Design — database, data dictionary
E
Evaluate Detailed DesignsMainly via Technical Reviews
+

Five rules for a good technical review:

  • Send the review notice early — give people real time to prepare
  • Include a technical expert + stakeholders
  • Include someone from QA / testing
  • Focus on how the design meets functional & non-functional requirements
  • Document the review — capture & assign action items
EX — Reviewing an e-commerce checkout: check that it ensures secure payments (non-functional) and smooth order processing (functional).
D
Document the DesignThe Software Design Document (SDD) + friends
+

Three key documents:

  • SDD (Software Design Document) — the main design record, used by programmers, testers, maintainers, integrators
  • Interface Control Document — describes interfaces & how components communicate
  • Version Control Document — what's in each release: files, scripts, executables
M
Manage / Monitor ImplementationKeep design and code in sync
+

This is about synchronicity — how well detailed design follows architecture, and how well code follows detailed design. See the callout below — it's a favorite exam topic.

04

Inside the SDD — Sample Table of Contents

You don't need to memorize every line — know the shape: Intro → Architecture → Detailed Design (per component) → Glossary → References.

1. Introduction
1.1 Date of Issue · 1.2 Context · 1.3 Scope
1.4 Authorship · 1.5 Change History · 1.6 Summary
2. Software Architecture
2.1 Overview · 2.2 Stakeholders · 2.3 Design Concerns
2.4–2.6 Architectural Viewpoints → Design Views
3. Detailed Design
3.1 Overview
3.2 Component 1 → Viewpoint → View
3.3 Component 2 → Viewpoint → View
3.4 Component n → Viewpoint → View
4. Glossary   5. References

📖 What each part means

Scope: high-level overview + limits of what the SDD covers.

References: all documents referenced — helps stakeholders spot inconsistencies in how a technology is used.

Body: the main section — where stakeholders understand how the software is to be constructed.

Change history: log of what was added, deleted, or changed in the SDD over time.

05

Detailed Design Synchronicity

⚠

Synchronicity = how well detailed design adheres to architecture, and how well code adheres to detailed design.

Low synchronicity → a flaw in the process → risk of project failure. It matters most during maintenance or when new engineers join.

EX — Architecture requires encrypted login, but detailed design forgets encryption and the code just stores plain passwords → synchronicity is broken.
06

Quick-Fire Flashcards

Tap a card to flip it. Good for a 5-minute recap right before an exam.

07

Practice Questions

Written from this chapter's content (no separate question file was uploaded, so treat these as self-check practice, not official past-paper questions).

08

One-Screen Recap