URDAD
Request a trial

Stop writing your business down three times.

Requirements live in documents, designs in diagrams and behaviour in code — kept in step by hand until they drift apart. URDAD replaces all three with one technology-neutral model of what your organisation’s services must do and how, and generates the diagrams, documentation, tests and running processes from it.

Try the playgroundRequest a trial

In the browser — nothing to install, no sign-in.

The URDAD modelling tool showing the motor insurer example: the model tree on the left, the Process claim process drawn as a diagram in the middle, and the selected element's details on the right.The URDAD modelling tool showing the motor insurer example: the model tree on the left, the Process claim process drawn as a diagram in the middle, and the selected element's details on the right.
The modelling tool, in the playground — a motor insurer's claims process. Open it there.

Why URDAD?

  • Nothing drifts out of step

    Requirements, design and running processes are one model, not three documents. Every diagram and document is regenerated from it whenever it changes, and the optional execution environment runs the approved processes as modelled — so what was specified is what runs.

    The full argument: nothing drifts out of step

  • Change who does the work, not the process

    A process asks for a service by its contract, never by who provides it. A person, an existing system, a partner or another process can answer it, so automating or outsourcing a service changes no process. And the model names no technology, so it outlives the systems that implement it.

    The full argument: change who does the work, not the process

  • Evidence for audit, as a by-product

    Every requirement is traced to the step that meets it, and every change is reviewed, signed off and recorded. The AI assistant only proposes: nothing reaches the model until a person accepts it. The tool certifies nothing itself; it keeps the evidence you need to.

    The full argument: evidence for audit, as a by-product

How it works

  1. Specify

    For each service the business must provide, state who needs it, when it is refused, and what it guarantees when it is not.

  2. Design

    Allocate each requirement to a lower-level service or an activity and orchestrate them into a process — then the same one level down, by your team, another domain’s or an external provider.

  3. Verify

    The tool checks every process against its contract as you model, and can test it with cases generated from the model — nobody writes a test.

  4. Execute

    Optionally, the execution environment runs the approved processes as modelled, with people and existing systems answering — every answer checked against its contract.

  5. Evolve

    Every change is made in a project, reviewed, signed off and activated; the diagrams, documents, tests and running processes follow.

The URDAD method. Analysis, in the requirements specification phase: 1 Service — the service required, the domain responsible for it and its stakeholders; 2 Requirements — pre-conditions as refusals, post-conditions as guarantees, related ones grouped as one, and the request and response data. Related requirements of one domain become one higher-level requirement, decomposed one level down. Design: 3 Allocation, in the responsibility allocation phase — each condition to a service request or an activity; a new service's contract goes to a domain, which accepts it, forwards it to the domain it belongs to, or rejects it so that it stays in your domain; and inputs are augmented as design needs them. 4 Process, in the process orchestration phase — orchestrate the requests and activities, handle every refusal and populate the response. 5 One level down, for each service the process requests: its contract is specified first if it does not yet exist, then it is designed by your own team, which repeats steps 1 to 4, by another domain's team, with URDAD or in its own way, or by an external provider held to the contract. Never locked in: any contract can later be outsourced or automated without its requesters changing.
The method in one figure: specify what a service must do, allocate each requirement, orchestrate the process — then the same one level down, by whoever provides each service.

The method in full

The tool suite

  • Model once

    • Nobody draws or redraws a diagram; every view is generated from the model.
    • A team edits the same model together, live, with every change recorded.
    • Each process is checked against its requirements as you work.
    Explore model once

  • Govern change

    • The model changes only through projects, each taken through phases to sign-off.
    • Roles say who may do what; regulated projects add the checklists their rules require.
    • A permanent record of who changed, reviewed and approved what.
    Explore govern change

  • Execute and test

    • The approved processes run as modelled; there is no hand-written program to drift from them.
    • Tests generated from the model — nobody writes a test, a stub or a data set.
    • Every answer is checked against its contract, and the party at fault is named.
    Explore execute and test

  • Share and integrate

    • Documentation generated from the model, and published where your people already read.
    • Processes and decisions to and from BPMN and DMN, so you are never locked in.
    • Connects to your identity, delivery, secrets and AI providers without tying you to one vendor.
    Explore share and integrate

URDAD and BPMN

BPMN draws what happens, in which order, and who does it. URDAD starts from what a service must achieve — when it may be refused and what it guarantees — and checks every process against that. Each does its own job well, and you can use both: the tool imports processes and decisions from BPMN and DMN and exports them back.

Choose BPMN when

  • You want to document an existing process quickly.
  • Your people, a partner or a regulator already read or ask for BPMN.
  • The process is genuinely unstructured.
  • Processes are owned and run one at a time on a BPMN engine you already have.

Choose URDAD when

  • The model must last, and be shared across the organisation.
  • Requirements must be traceable and verifiable — an auditor asks why a step exists.
  • Services may move between your own teams and external providers.
  • One model should drive documentation, tests and execution, without being redrawn.

Where URDAD falls short

  • It is not a standard, and this is the only tool that supports it.
  • Few people know it yet; analysts learn a method, not just new shapes.
  • It asks for more thought up front than drawing a flow.
  • Some unstructured processes must be restructured before they can be modelled.
  • Its execution environment and its interoperability are young.

The full comparison, construct by construct

Where URDAD comes from

URDAD has been developed and published in peer-reviewed journals and conferences since 2007.

All publications

See it for yourself

Try the playgroundRequest a trial

Not ready for either? Browse the resources — the method, example models, tutorials and specifications.