Stage 4 – Architecture & Component Design

Capstone Design

Imron Rosyadi

Stage 4 – Architecture & Component Design

From Requirements to a Buildable Design

Capstone Design – Stage 4 Focus Session

This deck covers Stage 4 – Architecture & Component Design in the course V‑Model.

Pre‑requisites for students: - Stage 2 complete: DCP‑100B (Stakeholder Requirements, STR-*). - Stage 3 complete or nearly complete: DCP‑200 (System / SW Requirements, REQ-*).

Goals of this session: - Explain what architecture and component design mean in the context of this course. - Connect to ISO/IEC/IEEE 15288 & 29148: - Architecture Definition - Design Definition - Requirements Allocation - Show key deliverables (what goes in your Stage 4 design docs). - Use ECE‑relevant examples (embedded system, FPGA/DSP, networked systems, medical/wearables).

Learning Objectives – Stage 4 Session

By the end of this session, you will be able to:

1. Explain the role of Stage 4 – Architecture & Component Design in the V‑Model.
2. Describe the Architecture Definition and Design Definition processes from 15288/29148.
3. Explain Requirements Allocation: how REQ-* get assigned to components.
4. Create and interpret architecture diagrams and component design descriptions for ECE systems.
5. Identify the key Stage 4 deliverables for your capstone project.

Emphasize that Stage 4 is where you decide the structure of your system: what pieces exist, how they communicate, and what each piece is responsible for.

It is not yet coding or PCB layout – it is the blueprint you will build from.

V‑Model – Where Stage 4 Fits

• Stage 3 defined what the system must do (REQ-*).
• Stage 4 defines how the system is structured so those REQ-* can be met.
• It sets up the units/components you will verify in Stage 6.

Point out the vertical alignment: - Stage 4’s architecture & design are what Stage 6’s unit tests and Stage 7’s integration tests will target.

If Stage 4 is fuzzy, it becomes hard to say what a “unit” or “component” even is.

Standards Context – 15288 & 29148 in Stage 4

In Stage 4, we mostly apply three processes from the standards:

1. Architecture Definition (15288)
   • Identify main system elements and how they interact.
2. Design Definition (15288)
   • Refine architecture into detailed component designs sufficient for implementation.
3. Requirements Allocation (29148/15288)
   • Allocate system requirements (REQ-SY-*) to specific hardware, firmware, and software components (REQ-HW-*, REQ-SW-*, etc.).

Note

Think of Stage 3 as defining the target. Stage 4 defines the structure of the arrow you will shoot at that target.

Stress that we’re not memorizing these standards; we’re using them as guidance for good engineering practice.

We care that students: - Structure their systems. - Allocate requirements. - Document their designs clearly.

Architecture vs. Detailed Design – Big Picture

• Architecture (high level):
  • Major components (e.g., sensors, gateway, backend, UI).
  • How they communicate (interfaces, protocols).
  • Deployment view (what runs where).
• Component Design (lower level):
  • Internal structure of each component (modules, threads, state machines, data flows).
  • Internal interfaces and data structures.
  • Algorithms, timing, and resource allocation details.

Tip

Architecture answers: > “What are the main parts and how do they connect?”

Component design answers: > “What does each part look like internally?”

ECE analogy: - Architecture ≈ block diagrams in datasheets. - Design ≈ detailed schematics, state machines, pseudo‑code.

Both must be consistent with REQ-* defined in DCP‑200.

15288 – Architecture Definition Process

Purpose (adapted): To generate a set of architectural views of the system that:

• Describe major elements and their relationships.
• Satisfy system requirements (REQ-*).
• Provide a basis for design, implementation, and integration.

Key Architecture Definition activities:

1. Analyze system requirements (REQ-*) to identify needed capabilities and constraints.
2. Identify system elements (hardware, software, people, external systems).
3. Define architectural patterns (client–server, layered, microcontroller + gateway, etc.).
4. Develop architectural views, such as:
   • Logical / functional view (what functions sit where).
   • Physical / deployment view (what runs on which hardware).
   • Interface view (APIs, protocols, data flows).
5. Evaluate architecture against requirements and constraints (feasibility, performance, modifiability).

Students don’t need to enumerate all possible views, but they should at least have: - A top‑level block diagram. - A deployment view (ESP32 here, server there, etc.). - A data/communication view (how data flows from sensors to UI).

15288 – Design Definition Process

Purpose (adapted): To transform architecture into detailed design descriptions that:

• Specify how each system element will be implemented.
• Are consistent with allocated requirements.
• Are concrete enough for implementation and unit testing.

Key Design Definition activities:

1. Refine system elements into lower‑level components (e.g., microcontroller tasks, software modules, HDL blocks).
2. Define internal interfaces (function APIs, message structures, registers, etc.).
3. Specify algorithms and data structures (e.g., filter structure, control logic).
4. Capture design constraints (timing budgets, memory limits, power budgets).
5. Document designs in forms appropriate for your project:
   • Diagrams (UML, block diagrams, state machines)
   • Pseudo‑code, interface tables, register maps
   • Partial prototypes if necessary to de‑risk design choices

Note

In this course, Stage 4 design docs should be detailed enough that: - Another competent capstone student could implement your design from the documentation.

Encourage teams to resist the urge to “just start coding” or “just start wiring” without a shared design.

Decisions made & documented here will: - Reduce integration surprises. - Improve testability in Stage 6/7.

Requirements Allocation – What and Why

Requirements Allocation = assigning each system requirement (REQ-SY-*) to:

• One or more hardware components (REQ-HW-*), and/or
• One or more software components (REQ-SW-*), and/or
• Combined behavior of multiple components.

This ensures:

• Every REQ-SY-* has a home in the design.
• Each component knows what requirements it must satisfy.
• You can later verify at the right level (unit vs integration).

Tip

Practically: - Make a table: REQ-SY-* → Component(s). - Then, if helpful, derive more specific REQ-HW-* and REQ-SW-*.

Emphasize: Allocation is not just paperwork.

If you don’t allocate requirements, you risk: - Nobody implementing a needed behavior. - Multiple components trying to do the same thing. - Confusion in testing (“who is responsible for this latency?”).

Example: High‑Level Architecture – Smart Lab Sensor Network

Major elements in this architecture:

• Sensor Nodes – embedded hardware for sensing and wireless communication.
• Gateway – aggregates sensor messages, forwards to backend.
• Backend Server – data store, application logic, alerts, APIs.
• Web Dashboard – front‑end for technicians and managers.
• Campus IT – authentication and network services.

Show how this diagram came from Stage 3 REQ-*: - We needed wireless sensors, a centralized data store, and a web UI. - We also must integrate with campus auth: hence the explicit IT block.

Ask students: - What other architectures could we have used (e.g., no separate gateway, sensors talk directly to cloud)?

Example: Requirements Allocation (Excerpt)

Using the Smart Lab architecture:

System Requirement (REQ-SY-*)	Allocated Component(s)
REQ-SY-001 – Store latest temp/humidity per lab	Sensor Node, Gateway, Backend DB
REQ-SY-003 – Dashboard refresh every 60 s	Backend API, Web Dashboard
REQ-SY-010 – Create overheat alerts	Backend Alert Logic
REQ-SY-061 – Notify technicians within 120 s	Backend Notification Service, Email/SMS Agent
REQ-SY-060 – Dashboard loads in ≤ 3 s (95% of time)	Backend (performance), Web Dashboard (UI), Network
REQ-SY-092 – Use HTTPS for web access	Web Server / Backend, Campus IT
REQ-SY-081 – Detect missing sensor (“sensor fault”)	Gateway, Backend, Dashboard UI

Note

Allocation helps: - Clarify which component is responsible for each behavior. - Identify cross‑cutting concerns, like performance and security.

Encourage teams to create a full allocation table (maybe in a spreadsheet), even if they don’t put every line in the report.

This also helps them define unit test scopes in Stage 6.

ECE Example – Remote Instrument Lab Architecture

Consider a Remote Electronics Lab system:

• Students remotely control benchtop instruments (oscilloscope, function generator) via a web interface.

Possible requirements allocation:

• Session management, exclusivity (REQ-SY-104): Application Server.
• Instrument command translation: Lab PC Instrument Controller.
• User scheduling/booking: Web Front‑end + Application Server.

Ask: - Where do we enforce “only one student per instrument at a time”? - Who is responsible for timing guarantees (e.g., latency)?

This forces them to think about responsibility assignment in architecture.

ECE Example – FPGA‑Based DSP System Architecture

Project: Real‑time ECG filter on FPGA + Microcontroller.

Possible allocation:

• Sampling requirements (REQ-HW-100): ADC + FPGA interface.
• Filter characteristics (REQ-SW-100): FPGA DSP blocks.
• End‑to‑end latency (REQ-SY-101): ADC + FPGA + MCU + UI pipeline.
• Logging and configuration: MCU + UI + Network.

Show how architecture clarifies timing budget: - If end‑to‑end latency must be ≤ 100 ms, you can allocate sub‑budgets to each block.

This will later inform design details (e.g., pipeline depth, communication method).

Architecture Views – What You Should Capture

In your Stage 4 docs, you should capture at least:

1. Logical / Functional View
   • Components and their responsibilities (e.g., sensor, gateway, server, UI).
2. Physical / Deployment View
   • Which components run on which hardware (e.g., ESP32, Raspberry Pi, cloud VM).
3. Interface / Data Flow View
   • What data flows between components (e.g., messages, API calls, timing).

Optional but useful views:

• State machines for critical control logic (e.g., operating modes).
• Sequence diagrams for important scenarios (e.g., alert generation, remote login).

Tip

Diagrams should be simple and consistent. Pick a style (e.g., boxes + arrows, or simple UML) and stick to it.

Encourage them to label arrows with: - Protocol (e.g., MQTT, HTTP, UART). - Direction. - Frequency/performance hints if relevant.

Remind them diagrams are communication tools, not art projects.

Component Design – Example (Backend Service)

For the Smart Lab system, one architectural element is the Backend Server.

At design level, we can refine it into:

Design decisions to capture:

• GW Interface Module:
  • Protocol used (e.g., TCP, MQTT, custom).
  • Message formats and parsing logic.
• Alert Module:
  • How thresholds are applied (sliding window? instantaneous?).
  • How notifications are queued and sent.
• API / Auth:
  • Endpoints, parameters, error codes.
  • Which endpoints require which roles.

Explain that this level of design helps: - Developers break down coding tasks. - Testers plan unit tests for each module (Stage 6).

Encourage using simple module diagrams, plus text/pseudo‑code for key behaviors.

Component Design – Example (Sensor Node)

For the Sensor Node (embedded microcontroller):

A typical embedded design breakdown:

• Hardware:
  • MCU, sensor chip, power supply, antenna.
• Firmware tasks:
  • Sensor reading task.
  • Communication task.
  • Power management task.

High‑level firmware structure (conceptually):

- init()
  - configure sensor
  - configure radio
  - load config (sampling interval, node ID)

- main loop
  - wait for sampling interval
  - read sensor
  - package reading with timestamp and node ID
  - send to gateway
  - handle retries / errors

You might capture a state machine:

• Idle
• Measure
• Transmit
• Retry
• Error

And a register / message format:

• Byte 0–1: Node ID
• Byte 2–5: Timestamp
• Byte 6–7: Temperature * 10 (int16)
• Byte 8–9: Humidity * 10 (int16)
• Byte 10–11: CRC

Note

Design details like tasks, states, and packet formats are what distinguish Stage 4 design from Stage 3 requirements.

Stress: This is the level at which you can meaningfully assign people tasks and estimate effort.

Also: these design details will support specific unit/integration tests later (e.g., packet parser test, sensor driver test).

Linking Design Back to Requirements

A good Stage 4 design explicitly answers:

• For each major component, which REQ-* does it help satisfy?
• For each critical requirement, where in the architecture/design is it addressed?

Example (Smart Lab):

Component	Key Requirements It Addresses
Sensor Node Firmware	REQ-HW-001, REQ-HW-060, REQ-HW-061, REQ-SY-030
Gateway	REQ-SY-030, REQ-SY-032, REQ-SY-081
Backend Alert Module	REQ-SY-010, REQ-SY-011, REQ-SY-061
Web Dashboard Front-end	REQ-SW-041, REQ-SW-042, REQ-SW-100, REQ-SW-101
Auth Integration	REQ-SY-090, REQ-SY-050

Tip

If you can’t point to any part of your design that fulfills a given REQ-*, either the requirement is missing in the design or mis‑allocated.

Encourage teams to do a quick traceability sanity check before the Stage 4 gate review.

This also helps them spot over‑engineering – components that don’t seem to support any requirements.

ECE Example – Wearable Health Monitor Design

System: Wearable heart‑rate and activity monitor.

High‑level architecture (simplified):

Design activities:

• Decide sampling rates and buffer sizes on the MCU.
• Design algorithms for HR and activity detection (e.g., filters, peak detection).
• Specify BLE characteristics and messages between wearable and phone.
• Define API between phone app and cloud.
• Decide where to implement tachycardia detection logic:
  • On the wearable?
  • On the phone?
  • On the cloud?

Each choice affects: - Latency (e.g., REQ-SY-213 – alert within 300 s). - Power consumption, connectivity needs.

Ask: - If connectivity is lost, where can we still detect dangerous conditions? - How do we allocate safety‑critical requirements to the most reliable component?

This is a real architectural design trade‑off.

Common Pitfalls in Stage 4

• Jumping straight to code/PCB without shared architecture
  • Leads to mismatched assumptions and integration pain.
• Architecture too vague
  • “We have a microcontroller and a server” with no clarity on responsibilities or protocols.
• Over‑specifying design as requirements
  • In Stage 3, you may have already locked in implementation details unnecessarily.
• No clear mapping from requirements to components
  • Some REQ-* have no home; some components exist with no purpose.
• Ignoring non‑functional aspects in design
  • Architecture doesn’t consider performance, power, security, or safety until too late.

Warning

Stage 4 is where you make big structural decisions. Getting them wrong is expensive to fix later.

Reinforce: It’s okay to iterate, but large changes after Stage 4 can cascade through implementation and tests.

Encourage design reviews: - Within the team, - With advisor, - Possibly with stakeholders for sanity checks.

Stage 4 Key Deliverables (for This Course)

Your Stage 4 outputs should include:

1. Architecture Description
   • Top‑level block diagram (logical view).
   • Deployment / hardware mapping view.
   • Interface / data‑flow view.
2. Component Design Descriptions
   • For each major component: responsibilities, internal structure, interfaces.
   • State machines or sequence diagrams for critical behaviors.
   • Key algorithms (at least at pseudo‑code or block diagram level).
3. Requirements Allocation Summary
   • Table mapping REQ-SY-* to components (and optionally to REQ-HW-* / REQ-SW-*).
4. Design Rationale and Trade‑offs
   • Why you chose this architecture (e.g., central gateway vs direct cloud).
   • How you addressed major risks (performance, safety, security).
5. Updated Risk / Open Issues List (if architecture reveals new risks)

These deliverables are typically captured in:

• A Stage 4 design document (e.g., DCP‑300 / 400), and
• Slides/diagrams for the Stage 4 Gate Review.

You may tie this to your course’s actual document IDs (e.g., DCP‑300: High‑Level Design, DCP‑400: Detailed Design).

Make clear that Stage 4 must be approved before full‑scale implementation (Stage 5).

Summary – Stage 4 Takeaways

1. Architecture Definition (15288)
   • Identify major components and their interactions.
   • Expressed in clear diagrams/views.
2. Design Definition (15288)
   • Refine components internally (modules, tasks, state machines, algorithms).
   • Provides enough detail to start implementation and unit test design.
3. Requirements Allocation (29148/15288)
   • Map each REQ-SY-* to specific components.
   • Ensure every requirement is owned and testable at the right level.
4. Good Stage 4 artifacts connect:
   • Stakeholder & system requirements (Stages 2–3)
   • Implementation & verification plans (Stages 5–7)

Important

Stage 4 is the bridge from “what” to “how”. It gives your team a shared blueprint for building and testing your system.

Encourage teams: - Don’t skip Stage 4 because “we know the tech stack”. - Even small projects benefit from explicit architecture & design.

Mention that many real‑world system failures trace back to poor architecture, not bad code.

Next Steps for Your Team

1. Review your DCP‑200 (REQ-*)
   • Make sure they are stable enough to base a design on.
2. Draft your Architecture
   • Identify main components and draw initial diagrams.
   • Check that the architecture can, in principle, satisfy all REQ-*.
3. Define Component Designs
   • For each component, specify responsibilities, interfaces, and internal structure.
   • Use diagrams and brief text/pseudo‑code.
4. Perform Requirements Allocation
   • Map each REQ-SY-* to component(s).
   • Adjust architecture or requirements if you find gaps or conflicts.
5. Prepare for Stage 4 Gate Review
   • Be ready to explain:
     • Why you chose this architecture.
     • How it satisfies key requirements.
     • How you will break work into components for implementation and testing.

Tip

A clear Stage 4 design: - Makes coding and building in Stage 5 faster and safer. - Makes testing and integration in Stages 6–7 more straightforward.

Consider assigning an exercise:

• Take your current project.
• Draw a top‑level architecture diagram.
• Identify 3–5 key REQ-SY-* and show which components they map to.

Review in class or in lab to reinforce these concepts.