#7 Architecting the System and Allocating Subsystems

This phase transforms stakeholder needs and system requirements into an engineered architecture. It sits at the pivotal transition between Concept Definition and Subsystem Design in the V-Model. We establish not just what the system must do, but how it is structured to do it.

This phase links three critical transitions:

1. Context → Architecture

2. Architecture → Subsystems

3. Requirements → Allocation

Handled rigorously, it turns the system into a defendable structure one that can withstand integration pressure, interface risks, and future change.

System Architecture Framework

Architectural Mandate

• Purpose: Translate contextual needs and formal system requirements into a logical, physical, and testable structure.

• Inputs: Validated context models, baselined functional/system requirements, stakeholder constraints.

• Avoid: Ivory-tower abstraction divorced from environment and delivery realities.

Architectural Viewpoints

We ensure these views remain traceable to the context #4 Establishing the System Context and requirements #6 Defining the System Functions and Requirements.

Locker Example, Logical View: OTP Request → OTP Validation → Lock Actuation → Audit Logging.

Physical View: Touchscreen, embedded controller, solenoid lock, SMS gateway, admin web server.

Pattern Selection and Boundaries

• Modular vs. monolithic

• On-device vs. cloud logic

• Redundancy vs. fail-safe behaviour

Anti-pattern: Designing subsystems around teams (e.g., "Mechanical Module") instead of logical separation.

Failure Propagation & Resilience

• Map failure modes from context ( #4 Establishing the System Context )

• Architectural mitigations: Isolation, retry buffers, watchdogs

• Safety boundaries: Secure OTP validation and lock control must not share resources

Locker Example: LTE module reboot must not disable local unlock logic. Architectural separation enforced.

Subsystem Allocation Protocol

Decomposition Principles

• Subsystems should own functional slices, not hardware chunks

• Derived requirements must be raised for constraints (e.g., mounting, thermal)

Example:

• FR-01 (OTP Validation) → SR-01-1 (Touchscreen input) → Software team

• SR-01-2 (DB check latency < 2s) → Backend team

Allocation Risk Traps

Interface Control Discipline

Interface Taxonomy ( #5 Defining the System Boundary and Interfaces)

Interface Control Document (ICD) Evolution

For critical interfaces (e.g., lock control), require L2 maturity minimum before freeze.

Accountability

Use a RACI Matrix:

• Responsible: Engineering owner

• Accountable: Subsystem lead

• Consulted: QA, Safety, Security

• Informed: Project Management, Client

Handover Quality Control – Validation Gates

Allocation Integrity Checks

• No unallocated system requirements

• No subsystem requirement without parent

• All requirements testable (defined verification method)

Interface Risk Review (FMEA)

• Review shared buses, supply paths, and timing dependencies

• Flag emergent behaviour risks (e.g., retries colliding with lock actuation)

Resource Budget Discipline

Required Deliverables

• System Block Diagram (logical + physical)

• Subsystem Specification Pack (with traceable SRs)

• Interface Control Document Suite (ICD)

• Resource Budget Table

• Dependency Matrix (cross-subsystem)

• Verification Responsibility Matrix

Exit Criteria

• All interfaces ≥ L2 maturity

• All FRs and SRs linked bidirectionally

• All cross-subsystem dependencies mapped

• Resource budgets peer-reviewed

• Safety-critical boundaries isolated

• FMEA completed for shared resources

Closing Reflection

This phase transforms requirements into defendable structure. Its rigor determines whether integration is a verification exercise, or a forensic investigation into emergent failures.

Done right, it gives:

• Modular change control

• Defined subsystem contracts

• Reliable verification roadmaps

What’s Next?

Interface Control & Integration Planning

How we:

• Transform ICDs into testable contracts

• Build dependency-driven integration sequences

• Prototype high-risk interfaces before full build