We deliver requirements engineering, architecture, interface management, verification and RAMS assurance for complex, multi-disciplinary, multi-vendor projects — rail and metro, intelligent transport and tolling, hospital, airport and campus systems, industrial automation and large software platforms. Practice is tailored to ISO/IEC/IEEE 15288 and INCOSE guidance, and sized to your project rather than to a textbook.
Systems engineering is how large, multi-disciplinary, multi-vendor projects stay whole from concept to handover — every requirement owned, every interface named, every claim verified before anyone signs.
Most complex programmes do not fail because the engineering is hard — they fail because nobody owned the boring parts. Requirements stay vague until a contractor reads them differently to the client. Interfaces between vendors go undocumented until two systems built to spec refuse to talk to each other. Testing gets pushed to the end of the schedule, and safety evidence gets assembled in a panic before a review. Every gap like that becomes a change order, and a change ordered late costs more than the same fix made in month one.
Our approach starts with a systems engineering management plan sized to the job, not a template built for a programme ten times the size. Requirements are written to be verifiable from month one, architecture and interface control documents are agreed before procurement closes, and verification and validation are planned alongside the design rather than bolted on afterwards. RAMS analyses and safety cases are built from evidence as the programme runs. Because we build software ourselves, we also build the traceability tooling and digital-thread dashboards behind the paperwork — and can act as your independent assurance partner.
Most ‘integration problems’ are requirements problems discovered late. We move that discovery to month one.— Qubit engineering team
From the first stakeholder need to the safety case that closes the programme out — nothing falls into the gap between disciplines.
We elicit requirements from stakeholders, specifications and standards, then write them to EARS-style quality rules so each one is atomic, unambiguous and testable. Requirements are allocated to subsystems and managed with full traceability in DOORS Next, Jama Connect or Polarion — whichever your programme already runs — so a change upstream shows its impact downstream in minutes.
We define functional and physical architecture and model it properly in SysML, using Cameo Systems Modeler or Capella rather than static diagrams nobody maintains. Trade studies weigh options against your real constraints — cost, schedule, risk, technology maturity — and every architecture description follows ISO/IEC/IEEE 42010, so the model stays the single source of truth as the design matures.
Every interface gets an N² analysis to find it, an entry in the interface register to track it, and an ICD with a named owner on each side before two vendors build to different assumptions. We sequence integration across contractors so the order of testing matches the order dependencies actually unlock, not the order the contracts happened to be signed.
We write the V&V strategy while the architecture is still being drawn, not after it is frozen, and keep a live requirements traceability matrix that shows exactly which test, analysis, inspection or demonstration closes each requirement. Factory, site and system integration test procedures are built to the same standard, and every acceptance decision ships with an evidence pack, not a verbal assurance.
We run FMEA/FMECA and fault tree analysis to find what can fail and how badly, keep a hazard log that stays alive for the whole programme, and allocate safety integrity levels with a defensible apportionment. Safety cases are written to EN 50129 or IEC 61508 with evidence linked at every claim, and we can support your independent safety assessor directly through the review.
We set baselines that hold, run change boards that record why a decision was made, not just what changed, and track obsolescence before a part vanishes from the market mid-programme. Because we build software ourselves, the digital-thread tooling linking requirements, models, tests and change records in one place is something we build for you, not licence to you.
From the first stakeholder conversation to a safety case that closes the programme out.
We run workshops with every stakeholder group, write a concept of operations, log constraints and assumptions, and agree in plain language what ‘done’ actually looks like before a single requirement gets drafted or a supplier is approached.
Needs become structured, verifiable requirements — each one atomic, allocated to a subsystem and traced from source to test method — and baselined so everyone works from the same version.
We define functional and physical architecture in SysML, run trade studies on the options that matter, and write ICDs for every interface — so procurement packages go out with boundaries already agreed, not implied.
Test plans are written against the requirements baseline, not invented at the bench. We run factory, site and system integration testing and capture every result as evidence, not a tick in a spreadsheet.
We validate against the original concept, assemble the safety case from evidence gathered along the way, and run the acceptance process — so handover is a formality, not the point where problems surface.
A requirement nobody can verify is a requirement nobody can trust. We write every requirement to atomic, unambiguous, testable form, tag it with a verification method — test, analysis, inspection or demonstration — and link it straight to the test case that closes it. Coverage dashboards show every subsystem's status by name, and a change to one requirement shows its downstream impact in minutes, not weeks.
Most integration failures are not technical surprises — they are interfaces nobody wrote down. We draw an N² diagram at every baseline so every subsystem pairing gets checked, not just the obvious ones, then write one ICD per interface with a named owner on each side. Boundary hazards get captured in the same pass, and the integration sequence is agreed with every vendor before a cable gets pulled.
An assessor does not want assurances — they want an argument, and an argument needs evidence. We run hazard identification workshops that build a living hazard log, allocate and apportion safety integrity levels across subsystems, then link every mitigation claim to the test, analysis or inspection evidence that backs it. The result is an ISA-ready pack the assessor can actually follow, not a folder of loosely related documents.
Everything we produce is tool-agnostic where it matters: requirements export as ReqIF so they load into whichever tool your programme already runs, and models export to standard formats rather than locking you into ours. Documents stay living — baselined, versioned, and updated as the design changes — not frozen the day they are issued. At handover you get the full digital thread: requirements, models, tests and safety evidence linked, not scattered across five folders.
Every method we use traces back to a standard, a code or a recognised body of practice.
The lifecycle, requirements and safety codes every design decision is checked against.
Requirements, modelling and test-management tools we work in — including yours.
Interchange formats that keep your data portable between tools and teams.
Across Qubit systems engineering engagements, 2021–2026. Illustrative until replaced with audited figures.
Six settings where multiple disciplines and vendors have to work as one system, not five.
Signalling, rolling stock, platform screen doors and control systems from multiple suppliers, where RAMS assurance and interface control decide whether the system passes its safety case.
Signals, tolling and control-room software specified to open standards, where a clear ConOps and architecture keep five separate procurement packages working as one system.
Life-safety, security, building and IT systems that must interoperate under a single authority, where requirements and interface ownership prevent five contractors building five islands.
Control systems, safety instrumented systems and plant automation where IEC 61508 and hazard analysis are not paperwork — they are the difference between a shutdown and an incident.
Power, water and control-room systems where an operator's picture has to be right the first time, and where RAMS thinking earns its keep long before an incident.
Large software platforms and products with regulatory or safety obligations, where requirements traceability and structured verification hold up to an audit, not just a demo.
Anonymised examples. We're happy to walk through the full story on a call.
A metro depot programme brought together signalling, power, platform screen doors and building systems from six different contractors, each confident their own scope was fine. We ran systems integration support across the depot, built an interface register and an ICD library so every boundary had a named owner, and kept the traceability matrix current as designs changed. The independent safety assessor signed off against evidence, not assurances.
An intelligent transport programme spanning signals, tolling, CCTV and communications needed one requirements baseline instead of five separate specifications that half-agreed with each other. We wrote and structured 1,800 requirements with full traceability, then ran factory and site acceptance testing across twelve subsystems from four different vendors. Change requests dropped once every requirement had one clear, testable, owned statement behind it.
Can't find your answer? Drop us a line — we usually reply within a day.
Talk to usNo — it earns its keep anywhere a project has multiple disciplines, multiple vendors, or a safety or compliance obligation: hospitals, airports, campuses, industrial plants and large software platforms all benefit from the same discipline. We scale the process to the project, so a mid-size hospital system gets a proportionate SEMP, not the paperwork built for a rail franchise.
Enough to make requirements, interfaces and verification traceable — no more. We size the SEMP to the project's complexity and risk: a smaller programme might get a lightweight requirements set and a single integration test plan, while a safety-critical rail or hospital system gets the full RAMS treatment. The goal is control, not ceremony.
Yes. We can review requirements, architecture or test evidence produced by another team, or support your independent safety assessor directly through hazard workshops and safety case review. Where we have also done the design work ourselves, we are upfront about that and structure the engagement so independence stays real where you need it, not nominal.
We work regularly in DOORS Next, Jama Connect, Polarion, Cameo Systems Modeler and Capella, and we're comfortable picking up whichever tool your programme already runs rather than insisting on our own. Requirements and models exchange through ReqIF and standard formats, so switching tools mid-programme does not mean losing your traceability.
We define interfaces and responsibilities clearly enough that your contractors know exactly what they own, then chair the integration and change boards that keep everyone working from the same baseline. We're vendor-neutral in every recommendation, and where a vendor's design does not meet an agreed interface, we say so early — in the ICD review, not at site acceptance testing.
Yes, and to related standards such as EN 50128 for software or IEC 61511 for process safety, depending on your sector. Each safety case is built from a hazard log and evidence gathered through the programme rather than assembled at the end, so it stands up to genuine assessor scrutiny rather than a paper exercise.
Tell us where the requirements are unclear or the interfaces are undocumented, and we'll come back with a scoped plan — sized to your programme, not a textbook.