User needs from the ground up, business goals from the top down — I translate between stakeholders and design solutions that work for everyone. That changes how products get made, not just what gets made.
The core activities per IREB, the basis of the CPRE certification. Administration runs alongside as requirements management. Applied, for example, at the German Red Cross.
Individual interviews with stakeholders and users, observation in the working context, review of existing documents.
Grouping, merging duplicates, exposing dependencies, naming contradictions.
Each requirement written so that its fulfilment can be checked.
Checked against the source and agreed with the parties.
Individual conversations come before group sessions, because people say different things in a group than alone. It also records how decisions actually get made: who signs off, who must be consulted, who can still block late.
This is where it becomes visible which statements rule each other out although each sounds plausible alone. Prioritisation runs against criteria agreed in advance, not against volume.
Who needs it, to what end, and how you will recognise it has been met. Checked against the criteria that make a requirement measurable: unambiguous, consistent, complete, traceable, verifiable, relevant, feasible.
Where positions diverge, I facilitate along the agreed criteria and observable evidence — not along hierarchy. The result is an agreed, prioritised list with written rationale.
Requirements change. Without a defined process for handling that change, a specification loses its binding force within weeks.
Status, ownership and dependencies in one view everyone can read — not a file one person maintains and understands. What something is waiting on, and which decision is outstanding, become visible. In the field: dependency management and group decision support.
I do not decide on behalf of the parties. I make sure a decision is possible: every position elicited, every contradiction named, every priority reasoned.
Two to six weeks, depending on scope and number of parties
For undertakings where the alignment is the risk — not the implementation.
Requirements have been collected but not agreed. The same question returns in every meeting.
Outcome: an agreed list with documented rationale.
Both sides assume the same reading. The divergence only shows up during implementation.
Outcome: a specification both sides have signed off.
Entries exist without a documented source, rationale or evidence that they still apply.
Outcome: a prioritised list with source and rationale per entry.
A list records what was asked for. Requirements engineering additionally establishes origin, purpose, dependencies, the acceptance criterion and the route for changes. The difference is not apparent while writing. It is apparent at acceptance.
Requirements engineering covers elicitation, documentation, and validation and negotiation — it produces the specification. Requirements management administers it afterwards: versions, prioritisation and changes across the project lifecycle. The terms are often used interchangeably but denote different tasks.
Not by negotiating between the positions — there the more senior opinion prevails and the conflict returns. What holds is a third, checkable basis: observed user behaviour, usage data, a test against a prototype. Where a genuine conflict of goals remains, I name it as such and put it to whoever is authorised to decide.
“It should be easy to use” is a wish. “A newly onboarded employee completes the first booking unaided in under four minutes” is a requirement: testable, with a determinable point of fulfilment.
Certified CPUX-F and Digital Innovation & Product Manager (IHK). In training for CPRE (IREB) and Scrum Product Owner. Evidenced by multi-party undertakings: the German Red Cross, Volkswagen with Microsoft, and the Vaillant intranet.
Then that is the result — considerably cheaper in week three than in month six. Conflicts of goals between departments are legitimate and need a decision from the responsible authority. My task is to name the type of conflict and present the basis for deciding it.
A free 30-minute first conversation: the situation, the parties, the open points.