---
# source: src/content/services/en/requirements-engineering.md
# route:  /en/services/requirements-engineering/
title: Requirements Engineering
group: consulting
order: 6
tags: [strategy, architecture]
summary: Reconcile technology with processes and user needs before you buy. Otherwise you buy what demonstrated well and use whatever is left.
photoNeed: "A working session with a customer: a whiteboard with a real diagram, or two people over a laptop across a table"
stub: false
draft: false
---

## What it is for

So that the technology fits the business processes rather than the other way round.
Requirements engineering is the tool for reconciling technology, processes and what people
actually need, before a decision is made.

Without that step you procure what was convincing in the demo, and afterwards adapt whatever
can be adapted.

## How it runs

Systematically, in workshops. We help define and capture every relevant requirement and
figure: functional and non-functional, and in particular the numbers that later decide the
architecture.

## Why it comes first

Because other services build on it. A data management design without known access patterns
and retention periods is guesswork, and a disaster recovery design without RPO and RTO is
not a design.

Requirements engineering is therefore rarely the project somebody rings about, and often the
one the project should have started with.