URDAD
Request a trial

Traceability by construction

URDAD (Use-Case/Responsibility Driven Analysis and Design) is a method and a tool suite used by cross-functional teams across an organization to specify and evolve an executable, technology-neutral business model. The model is the central artifact from which diagrams, documentation, tests, process implementations and service contract compliance monitors are generated — no hand-synchronised artefacts to keep in step, no interpretation gap between requirements and code.

Try the playgroundRequest a trial

It runs in the browser, with nothing to install and 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, showing a motor insurer's claims process. Open it there.

Outcomes

Why URDAD?

  • Nothing drifts out of step

    Requirements, design and running processes are held in one model rather than in three documents. Every diagram and document is regenerated from it whenever it changes. Furthermore, 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 requests a service through its contract, and never names who provides it. A person, an existing system, a partner or another process can thus answer it, so automating or outsourcing a service changes no process. In addition, the model names no technology, and hence it outlives the systems which 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 which meets it, and every change is reviewed, signed off and recorded, including each AI proposal a person accepts. The tool certifies nothing itself. It keeps the evidence which you need in order to do so.

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

AI assistance

AI that proposes, people who decide

The AI assistant turns informal requirements into proposed model elements and checks the model against them. Because the model is precise, its proposals can be checked, and none of them becomes part of the model until a person accepts it.

  • Reviewed one by one

    Every proposal is accepted or rejected by a person, and nothing reaches the model or a co-editor before then.

  • Verified like everything else

    An accepted proposal is an ordinary element of the model, so verification and the phase gates check it exactly as they check one made by hand.

  • Provenance on every element

    Each accepted element records the requirement it came from, and is flagged when that requirement later changes.

  • Your model, your provider

    The language model, hosted or your own, is chosen by an administrator and reached only by the server.

AI assistance in the manual

The method

How it works

  1. Specify

    For each service which 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. The same is then done one level down, by your team, another domain’s team or an external provider.

  3. Verify

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

  4. Execute

    Optionally, the execution environment runs the approved processes as modelled, with people and existing systems answering. Every answer is 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 then 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, and then do the same one level down, by whoever provides each service.Full size: The method in one figure: specify what a service must do, allocate each requirement, orchestrate the process, and then do the same one level down, by whoever provides each service.

The method in full

What you get

The tool suite

  • Model once

    One model of what your services must do and how, from which every diagram and document is drawn, shared by everyone at 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, with no hand-written program to drift from them.
    • Tests are generated from the model, so 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

Positioning

URDAD and BPMN

BPMN draws what happens, in which order, and who does it. URDAD, on the other hand, starts from what a service must achieve, i.e. when it may be refused and what it guarantees, and checks every process against that. Each does its own job well, and one can use both, as 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.
  • You need a standard that many tools support.
  • You need a mature execution engine today.

Choose URDAD when

  • The model must last, and be shared across the organisation.
  • Requirements must be traceable and verifiable, e.g. when an auditor asks why a step exists.
  • Every service needs a contract from which its tests are generated and to which its providers are held.
  • Services may move between your own teams and external providers.
  • One model should drive documentation, tests and execution, without being redrawn.

The full comparison, construct by construct

Research

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, i.e. the method, example models and specifications.