Six Steps to System Concept Design: From User Needs to Frozen Baseline

The article opens by contrasting a typical 40-page "system concept" document — filled with functional lists, performance metrics, and interface tables — against what a true concept should answer: what role the system plays, what capabilities it provides, where its boundaries lie, and what constraints govern it. The author argues that writing requirements as concepts causes downstream misalignment because concept reviews turn into requirement reviews, leaving no one accountable for the system's overall shape.

Definition: One Sentence, Four Questions

A system concept is defined as a holistic description of a system's role, external capabilities, boundaries, and constraints before the system is decomposed. It must answer four questions: (1) What role does the system play in its environment and what goals must it achieve? (2) What capabilities does it provide externally? (3) Where does its boundary stop? (4) What constraints bind it? If any question cannot be answered, the concept is incomplete regardless of document length. Goals must be measurable indicators, not vague statements like "improve experience."

Concept vs. Requirements, Solution, and Architecture

A table illustrates the distinction using cabin temperature control:

Requirements (what must be satisfied): "Cabin temperature must drop from 40°C to 26°C within 5 minutes" — a constraint with numbers.

System Concept (what we intend to build): "Cabin domain centrally manages temperature; driver faces a single entry point" — a shape, not a number.

Logical Architecture (internal division): "Temperature acquisition, flap control, airflow regulation as three logical components."

Physical Architecture (what to build with): "Specific sensor and actuator part numbers."

The key insight: requirements give numbers; concepts give shape. The concept decides how many components will exist and how they interact; requirements only constrain outcomes. Confusing the two turns concept reviews into requirement nit-picking.

Position in the Methodology

Using the Arcadia four layers — Operational Analysis (OA), System Analysis (SA), Logical Architecture (LA), Physical Architecture (PA) — the concept layer comprises OA and SA, both black-box. The common three-layer mapping is:

Concept Layer → OA + SA: black-box role, capabilities, boundaries, constraints

Logical Layer → LA: white-box components, responsibilities, interfaces

Physical Layer → PA: implementation, selection, deployment

The dividing line is consistent: before the box is opened, it's concept.

Six-Step Process

The six steps draw from Arcadia and configuration management practice:

Operational Analysis (OA) — forget "what we do," watch users

Boundary Definition (SA) — decide what we own

Black-Box Capabilities (SA) — state only what is provided, not how

Constraints & Assumptions (SA) — record hard limits and soft premises

Candidate Concepts & Trade Study — compare 2-3 concepts against criteria

Baseline Freeze — lock boundary, capabilities, key scenarios, constraints, assumptions

All six steps keep the box closed; each step decides only one thing.

Step 1: Operational Analysis — Watch the User

Arcadia's OA asks "what does the user need to accomplish?" not "what must the system do?" Using the cabin domain: without a unified domain controller, the driver adjusts temperature via a row of buttons, changes music on another screen, and mounts a phone for navigation — three interactions, three UIs, eyes off road three times. OA records external actors, their activities, interactions, and pain points. It produces problems, not system functions. Starting from user pain avoids merely tweaking existing solutions.

Step 2: Draw the Boundary — Who Owns What

With problems identified, draw the system boundary: for each external interaction, decide whether this system or another owns it. Cabin domain disputes: temperature control belongs to cabin, but compressor control? Seat heater switch belongs to cabin, but heating wire diagnostics? Unresolved boundaries cause interface mismatches and finger-pointing later. This is the system-environment boundary, not internal module boundaries — the latter cannot be decided until the former is fixed.

Step 3: Black-Box Capabilities — Verb-Object, Not Nouns

Arcadia prescribes verb-object phrases for capabilities: "calculate optimal route," "detect threat" — not "navigation module," "threat detection component." Nouns imply internal structure. A complete capability entry has four parts: (1) For whom (driver), (2) What is delivered (set cabin temperature to target), (3) Inputs (target temp, current temp, fan level), (4) Outputs (adjustment result, status feedback). Missing "for whom" loses the stakeholder; missing I/O forces guesswork during interface design. Counter-examples: "internal microservice architecture" is implementation; "supports OTA" is too vague — must specify what OTA upgrades and failure behavior.

Steps 4 & 5: Constraints, Assumptions, and Trade Studies

After capabilities, add constraints (hard: unit cost ceiling, vehicle lifetime, temperature range, regulations, safety integrity level) and assumptions (soft but recorded: "cloud service available for vehicle lifetime," "cabin screen ≥ 10 inches" — if falsified, concept must be redone). Then the often-skipped step: propose 2-3 candidate concepts and conduct a trade study. Define evaluation criteria first, then score candidates — never reverse the order. The comparison is at concept level, not part numbers. Example candidates for cabin domain:

Option A Centralized : one board hosts cluster, center stack, HUD — high integration, fewer parts, but single point of failure blacks out everything.

Option B Distributed : cabin domain handles center stack and infotainment; cluster runs independently — better isolation, cluster survives alone, but extra controller raises cost.

Trade dimensions: capability coverage, cost, risk, evolution potential. Selecting silicon at this stage means concept phase ended prematurely.

Step 6: Define KPIs and Freeze Baseline

Freeze these artifacts: system boundary, external capability list, key scenarios, key constraints, key assumptions. They become inputs to logical architecture. Without a baseline, changes happen silently — capabilities added, boundaries shifted, no traceability. Freezing does not forbid changes; it requires traceability: who requested, why, downstream impact. Six deliverables are produced:

System Concept Description: mission, goals, key assumptions, constraints, trade-study conclusion

Context Diagram: system plus external actors showing boundary

Operational Scenarios & Black-Box Use Cases: external interactions only

External Capability List (black-box function list)

High-Level Non-Functional Requirements & Top-Level KPIs

Candidate Concept Comparison Matrix (trade study matrix)

Not produced: internal component diagrams, internal interfaces, hardware selection — those belong to logical and physical phases.

KPIs at Concept Level: Success Definition, Not Performance Numbers

Concept-phase KPIs are not technical parameters (response time, control precision, CPU load) — those belong later. They define "success" with 3-5 measurable indicators, each having baseline, target, and measurement method. For the temperature example, current baseline: 3 touch points on center stack. Concept KPIs:

Steps to complete one temperature adjustment: baseline 3, target 1

Eyes-off-road events during adjustment: baseline 3, target 0

Single-attempt success rate for similar operations: regression guardrail

All three are testable and user-perceptible. Technical specs like response time or CPU usage are premature at this stage.

Acceptance: Four Questions to Pass Review

Before review, the concept must pass four checks:

Boundary drawn? Every external actor assigned to this system or another.

Capabilities complete? Each capability states for whom, inputs, outputs.

Externally understandable? Strip all internals; an outsider can judge if the system is worth building.

Alternatives and constraints documented? At least two candidate concepts with trade-off rationale; all constraints and assumptions recorded.

Fail any one, and the review will drift to "let's pick a chip" because the team has nothing else concrete to discuss.

Closing

The opening 40-page document isn't wrong — it just merges two phases: requirements (what must be satisfied) and concept (what we intend to build). Requirements can be long; concept should be short — one page, four questions, one boundary, two or three alternatives. The ultimate test: after reading the concept, can you draw the black-box diagram on a blank sheet? If yes, the concept stands; if no, you wrote something else.

References: ISO/IEC/IEEE 42010:2011 (architecture description, context views), Arcadia method (Thales, AFNOR Z67-140), Voirin's "Model-based System and Architecture Engineering with the Arcadia Method," ISO/IEC/IEEE 15288 (system life cycle processes).