Progress begins with the requirement.

How we work

Across 28 businesses, our development approach connects a clear objective with system design, evaluation, and validation. Each project defines the evidence needed to move forward.

Architecture

How a program moves

DWG 05 · 5 nodes

  1. In

    Requirements

  2. 01

    Design

  3. 02

    Development

  4. 03

    Validation

  5. Out

    Next decision

Sequence

  1. InRequirements

  2. 01Design

  3. 02Development

  4. 03Validation

  5. OutNext decision

A shared development framework, adapted to the technical needs and maturity of each program.

  1. Define the objective

    Stage 1

    Start with the intended application, operating environment and constraints. A clear requirement makes it possible to assess the technical scope and the questions a project must answer.

    A defined objective and an initial set of requirements.

  2. Design the system

    Stage 2

    Consider the architecture, interfaces and dependencies together. The relevant business provides the technical context, including where other disciplines or external partners may be needed.

    A proposed architecture with clear responsibilities and interfaces.

  3. Develop and evaluate

    Stage 3

    Use the form of development appropriate to the question: analysis, software, models or physical prototypes. Evaluate assumptions before committing to the next stage of work.

    Development evidence that can inform the next decision.

  4. Validate against requirements

    Stage 4

    Define the tests, standards and approvals an intended application would require. Demonstrated results must be assessed against those requirements before readiness is established.

    Results assessed against agreed criteria.

  5. Plan for the full lifecycle

    Stage 5

    Consider commissioning, operation, support and eventual replacement as part of the project scope. Responsibility for each stage is established through the project agreement.

    An agreed plan for deployment and ongoing responsibility.

Evidence before commitment

The standard of evidence depends on the application. A software interface and a physical system each require their own evaluation. Those stages stay clear in a project discussion.

Where regulatory approval, classification or clinical review is relevant, those requirements belong in the scope from the outset. A proposed design or published illustration does not establish that those requirements have been met.

The programs

Build the frontier
with us.

Share the objective, the requirements, and the business you want to reach. Project and partnership enquiries all come through the same form.

Discuss a Project