---
# source: src/content/services/en/requirements-engineering.md
# route:  /en/services/requirements-engineering/
title: Requirements Engineering
group: consulting
audience: [enterprise, provider]
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.

That includes an analysis of today's system usage and an outlook over the next five years as
the measure for scaling. Requirements shared by several services are captured once. The
result also carries a budget request.

## What the workshops cover

Not everything at once, but these topics come up in every project:

- Availability requirements, meaning RPO and RTO
- Capacity and performance, today and over the planned horizon
- System and storage performance
- Security
- Data centre locations
- Data protection
- Application realities and legacy systems

The last one is the one most often missing and the most expensive to add late. An
application that needs a particular database version has a say in the architecture,
whatever else was planned.

## 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.