#4 Establishing the System Context

Why System Context Is the Starting Point

In any systems engineering lifecycle, the Concept Definition phase sets the foundations not by listing features, but by understanding the environment that gives rise to them. Before defining what the system must do, we first explore:

• Where will it operate?

• Who will interact with it?

• What external systems will it rely on?

• What constraints and risks does that environment impose?

This step is frequently underrepresented in process diagrams, yet in our practice, it is a critical checkpoint. Without it, we risk producing requirements that are over-engineered, irrelevant, or fragile in real-world use.

Establishing system context is not about collecting background facts it is about constructing the operating frame that shapes requirements, design trade-offs, test strategies, and risk posture.

1. The Physical & Operational Environment

Understanding the physical and operational setting helps constrain the feasibility envelope of the system. It defines the operating range, expected stressors, and infrastructure availability, all of which influence design decisions.

Key dimensions typically include:

• Deployment locations (indoor, outdoor, mobile, fixed)

• Power/network availability and quality

• Environmental exposure (temperature, dust, condensation, tampering)

• Usage load cycles (peak hours, expected idle time)

• Maintenance access windows and lifecycle constraints

Locker System Support Example: Deployed in semi-sheltered transit corridors, expected to handle peak demand at commuter rush hours, with service only allowed during night shifts.

Documenting these factors prevents us from specifying systems that are impractical to install, maintain, or operate under expected conditions.

2. Stakeholder Mapping and Needs

Requirements do not just come from users, they emerge from all parties who touch or influence the system. A structured stakeholder analysis helps uncover functional, compliance, and lifecycle needs early, especially from those who are often overlooked.

We use models like the Stakeholder Onion Diagram to identify:

• Core users (direct interaction)

• Operators and maintainers

• Support personnel (e.g. cleaners, site staff)

• Influencers (site owners, procurement)

• Regulators (data, safety, accessibility)

Each group brings:

• Needs - what they want the system to enable

• Concerns - what risks they want it to avoid

Image Source: BAWiki – Stakeholder Onion Diagram

Locker System Support Example:

Cleaners may need access space and worry about damaging equipment; regulators require audit logs and impose retention rules.

Capturing these early allows us to shape requirements that respect all stakeholder expectations, reducing late-stage change requests or compliance gaps.

3. Categorising External Interfaces

Why we do this

Interfaces represent dependencies and unrecognised interfaces are a major source of integration risk. Grouping them into types helps ensure none are missed and clarifies ownership.

We classify them as:

• Physical (mounting, enclosure fit)

• Energy (power supply, battery backup)

• Information (data flows, network protocols)

• Human (control panels, access ports)

This structure allows clearer scoping of integration tasks, clearer allocation of subsystem responsibilities, and early visibility of interface specifications that must follow.

Locker System Support Example:

An admin portal might imply either a web UI (HTTPS) or a CLI over SSH a distinction that drastically changes development and security controls.

4. System Context Diagram (SCD)

A simple block diagram often called a System Context Diagram is the clearest way to communicate boundaries, actors, and external systems. It becomes a shared mental model across engineering, client, and delivery stakeholders.

A well-structured SCD shows:

• The System Under Design boundary

• Human actors and their interaction points

• External systems (power, network, SMS gateway, cloud admin)

• Data and control flows (e.g., “OTP sent via SMS,” “admin command via web portal”)

System Context Diagram

Even if informal, this diagram aligns team understanding and reduces ambiguity during architecture and interface design.

5. Boundary Conditions, Assumptions & Early Risk Capture

Every context analysis embeds assumptions about site infrastructure, user behaviour, network reliability, etc. Capturing these early enables proper risk control, validation planning, and requirement realism.

We build a Boundary Conditions Table:

Context Factor	Assumption	Risk if Invalid	Mitigation Strategy
Power availability	230V AC at each site	May require expensive retrofit	Survey top 3 sites pre-PDR
Network access	LTE always available	Remote OTP fails → access denial	Add fallback mechanism; validate on-site
Installer skill	Basic technician level	Cabling faults or incorrect anchoring	Build installer guide; checklist

We also:

• Tag each with stability level: Confirmed / Assumed / TBD

• Feed high-impact items into the project risk register with owners assigned

This connects concept analysis to formal risk management ensuring context errors do not become test escapes.

 6. Context-Derived Resilience Requirements

Environmental or operational realities often create hidden failure modes. Surfacing them early allows us to design in resilience, rather than react after defects are discovered in test or deployment.

Example chain:

Cold weather → condensation → PCB corrosion → lock failurePublic tampering → exposed override → false alarms

From these, we derive:

• Hardware design decisions (e.g., conformal coating, gasket seals)

• Monitoring requirements (e.g., moisture sensors, admin alerts)

• Policy mitigations (e.g., periodic inspection frequency)

These become explicit, testable requirements grounded in context, not guesses.

7. Traceability Begins Here

Context is not background. It is the source layer in the requirement hierarchy.

Each item in the context model becomes:

• A parent of one or more requirements

• Tagged by source

• Assigned a stability attribute (e.g., Confirmed, Assumed)

This supports:

• Traceability matrices

• Verification planning

• Engineering change impact analysis

Locker System Support Example:

• Context item: “Semi-sheltered corridor installation, down to -5°C”

• Derived requirement: “Shall operate from -5°C to +45°C”

• Test case: “Cold chamber test at -5°C for 4 hours”

Why This Step Anchors the Entire Lifecycle

Neglecting context work leads to:

• Requirements churn (rework when assumptions fail)

• Qualification test escapes (system passes lab tests, fails in field)

• Operational failure (unit unusable due to unseen site constraint)

In practice, these failures are expensive not because the design was wrong, but because the assumptions were invisible.

Taking time to understand the system context gives every downstream engineering decision an anchor in reality. It turns assumptions into assets, and constraints into clarity.

Next: Defining the System Boundary and Interfaces

With the world around the system now defined, we are ready to draw the lines:

Defining the System Boundary and Interfaces We will formally declare what the system is (and is not), map its internal vs. external elements, and define what interfaces must exist technically, contractually, and physically.