System Engineering · Requirements Engineering

Requirements that survive design, integration, and change.

We convert drawings, legacy specifications, interface descriptions, stakeholder input, and operating scenarios into an allocated requirement baseline with explicit verification criteria.

ElicitationDecompositionAllocationTraceabilityVerificationSafety & cybersecurity

See engineering examples ↓Discuss a requirements package

Drawing / datasheetGeometry, ratings, supplier constraints

Protocol / interfaceSignals, messages, timing, failure behaviour

Legacy productExisting behaviour, limitations, carry-over

Stakeholder needBusiness reason, user scenario, acceptance intent

→

Engineering analysisContext · constraints · decomposition · allocation · quality reviewTraceable, verifiable baselineSystem · HW · SW · mechanical · interfaces · verification

Engineering route

From source material to evidence

The workflow connects source evidence, system context, responsibility, and verification. Each step leaves a reviewable artifact.

Source material is catalogued and referenced. Drawings, datasheets, protocols, legacy requirements, architecture notes, regulations, and stakeholder statements remain traceable to the requirements derived from them.

Worked examples

How requirements look in practice

Five compact examples show the path from source material and system context to allocated requirements and verification. Use the arrows to move through the cases.

Dimensioned component interface drawing showing overall length, section length and two diameters

Interface definitionComponent drawing → controlled interfaceGeometry is the source. The requirement closes ownership, tolerance, mating and acceptance conditions.

Engineering context

The released drawing gives measurable geometry. The engineering task is to identify which characteristics control the system interface and which remain internal to the selected component.

MEC-IF-012

The mechanical assembly shall maintain the controlled mating geometry defined by the approved interface drawing.

Verification: drawing inspection + physical fit check

MEC-IF-020

The interface definition shall identify the applicable dimensional tolerances and datum references used for acceptance.

Verification: specification review + dimensional inspection

SYS-IF-030

The interface shall remain compatible with the defined mating component throughout the specified installation and service conditions.

Verification: interface review + mating / retention test

Public case studyHMI ↔ Control Board CAN protocolAuthority, E2E protection, timing, session handling and safe-stop behaviour.

Engineering context

The Control Board owns process state. The HMI requests changes. SAFE_STOP is a privileged path. The released analysis calculates a 27.7 ms worst-case path against a 50 ms requirement.

COM-AUT-010

The Control Board shall remain authoritative for process state and shall validate HMI requests before applying a state change.

Verification: protocol conformance + invalid-command test

COM-TIM-020

The end-to-end SAFE_STOP path shall actuate the output within 50 ms of the operator input.

Verification: timing analysis + loaded-bus test

COM-E2E-030

Safety-relevant protocol data shall be protected against corruption, repetition and stale delivery using the defined E2E fields.

Verification: fault injection across CRC / counter / timeout cases

COM-SES-040

A conflicting or stale session shall not transfer process authority to the HMI.

Verification: session-conflict sequence test

Open the full protocol case study →

Industrial vibro-feeder HMI and MCU control module

Industrial automation caseVibro-feeder HMI & control moduleLocal operation, CAN integration, diagnostics and service logging.

Engineering context

The module supports machine setup and operating parameters, communicates with feeder peripherals over CAN, and provides local diagnostics and logs for commissioning and service.

SYS-HMI-010

The module shall provide local operator access to machine setup and operating parameters through the HMI.

Verification: functional menu and parameter-access test

SYS-COM-020

The module shall exchange defined control and status data with feeder peripherals over CAN.

Verification: CAN conformance + machine integration test

SWR-DIA-030

The firmware shall expose detected faults and system-state information through the local diagnostics function.

Verification: injected fault + diagnostic display check

SWR-LOG-040

The firmware shall record defined event, fault, and system-state records for commissioning and troubleshooting.

Verification: generated event + log retrieval check

Open the full HMI / MCU case study →

Polyurea-potted interface adapter for factory use

Mechanical / process casePotted interface adapterProtection volume, connector clearances and repeatable production controls.

Engineering context

The released solution uses a compliant two-component polyurea route. Requirements control the protected volume, connector interfaces, production sequence and inspection evidence.

MEC-POT-010

After cure, the potting shall fill the defined internal protection volume around pins and electronic parts with no visible unfilled region at the specified inspection surfaces.

Verification: visual inspection of the cured assembly

MEC-IF-020

The potting process shall preserve all connector mating surfaces and required pin clearances.

Verification: inspection + physical mating check

PROC-POT-030

The production instruction shall define cleaning, masking, assembly orientation, pour, cure, and final inspection steps.

Verification: process review + first-article record

Open the full adapter case study →

Public reference exampleContinuous sintering furnace analysisOperational scenarios, HAZOP, safety decomposition and verification planning for a N₂/H₂ atmosphere furnace.

Engineering context

A representative, anonymised reconstruction against a synthetic powder-metallurgy line. The analysis follows the chain from unstable scrap and process observability through atmosphere hazards, system requirements, HW / SW allocation and verification.

SNTR-SYS-ATM-020

The system shall prove the atmosphere enabling condition separately for each zone whose nominal operating temperature is below the safe ignition temperature.

Verification: zonal interlock test

SNTR-SYS-SAF-020

Actuation of the emergency stop shall not remove the means of maintaining the atmosphere safe state.

Verification: emergency-stop test at temperature with atmosphere state monitored

SNTR-HWR-SAF-020

Belt motion shall be sensed by an encoder on the driven pulley, not on the motor shaft.

Verification: inspection + coupling-release fault injection

SNTR-SWR-REC-010

The software shall associate recorded process conditions with a batch by belt position and dwell time, not by wall-clock time at the exit.

Verification: batch transit / recording correlation test

68 requirementsSystem / HW / SWHAZOPVerification planRecorded derivations

Requirement quality

Quality checks that change the design outcome

We review each requirement for atomicity, engineering meaning, allocation, boundary conditions, and an objective PASS / FAIL path.

Ambiguity

Weak“The interface shall be fast and reliable.”

Engineered“The end-to-end SAFE_STOP path shall actuate the output within 50 ms of the operator input.”

Design leakage

Weak“Use component X and material Y to make the interface robust.”

Engineered“The potting process shall preserve all connector mating surfaces and required pin clearances.”

Verification

Weak“The controller should log errors.”

Engineered“The firmware shall record defined event, fault, and system-state records for commissioning and troubleshooting.”

Capability scope

What we can own

A focused audit, a complete requirements package, or ongoing ownership inside your engineering team.

Elicitation & context

Stakeholders, operating scenarios, system boundary, assumptions, constraints, degraded modes, open points.

System requirements

Functional behaviour, modes, performance, diagnostics, interfaces, failure response, maintainability.

HW / SW / mechanical allocation

Decomposition with explicit responsibility, interface ownership, derived limits, and implementation boundaries.

Interface requirements

Electrical, mechanical, communication and behavioural contracts; ICD inputs and controlled interface assumptions.

Safety & cybersecurity

Traceable safety or cybersecurity requirements derived from the applicable goals, analyses, and lifecycle context.

Verification & change impact

Verification method assignment, requirements-based tests, traceability, baselines, reviews, and change impact analysis.

Standards & frameworks

Applied where they add engineering control

Process depth follows the customer domain, product risk, assurance target, and existing engineering workflow.

ISO/IEC/IEEE 29148:2018Requirements engineering processes, information items, and requirements characteristics.Official reference ↗

Automotive SPICE® 4.0SYS.2, HWE.1 and SWE.1 for system, hardware and software requirements analysis.VDA QMC ↗

ISO 26262:2018Functional-safety requirements, decomposition, allocation, traceability, and verification for automotive E/E systems.Official reference ↗

ISO/SAE 21434:2021Cybersecurity engineering and traceable requirements derived from cybersecurity risk management.Official reference ↗

IEC 61508Functional-safety lifecycle context for applicable E/E/PE industrial safety-related systems.IEC reference ↗

Engagement models

Start where your project actually is

2–3 weeks

Requirements audit

Quality, ambiguity, missing constraints, weak decomposition, allocation gaps, verification gaps, and broken traceability — ranked into a remediation plan.

Defined work package

Requirements development

Turn concept material, drawings, legacy documentation, interfaces, and stakeholder input into a structured technical baseline.

Ongoing

Requirements ownership

Maintain the baseline, lead clarification, manage change impact, and keep architecture and verification aligned as the product evolves.

Stakeholder / system requirementsHW / SW / mechanical requirementsICDsTraceability matrixVerification matrixAssumption & open-point registersAudit findingsChange-impact analysis

Bring engineering source material

Drawing, protocol, legacy specification, backlog, or a system problem with open decisions.

We can review the source, resolve missing engineering context, and deliver a requirement baseline with allocation and verification.

Continue to system architecture → · Continue to protocol engineering →

Discuss a requirements package →