Testers need the requirements for the system under test as their input. High-quality requirements are essential for proper testing. In practice, this quality is often found to be disappointing.

From the Boehm curve, we learn that defects in requirements are among the worst ones: late discovery, costly fixes. However, for a tester, it is not always easy to recognise bad requirements. This may result in false negatives or even missing some defects.

In this presentation, I will highlight key elements of professional requirements engineering. This allows testers to distinguish good from bad requirements, and even to detect the ugly (e.g., inconsistent, contradictory or missing). 

In any development approach, testers should always start with an early review of their input. There are several ways of dealing with defects in requirements. In all cases, testers should analyse the resulting risks.

Good requirements for both development and testing are the best guarantee for a high-quality system!

Requirements develop over the course of a project from coarse-grained epics to detailed user stories by a continuous process of defining and redefining. Requirements Engineering should ensure that during the whole development, the total set of requirements remains integer and consistent, thus preventing unnecessary refactoring, delays and cost overruns.
Today, we see a shift of focus from single-issue requirements elicitation for a single client to holistic solution provision for all stakeholders; organisations only define certain project scope, and requirements engineering creates solutions that remove a problem or facilitate a goal. Therefore, emphasis on the engineering part is growing, whereas the need for (documented) requirements in decreasing.

Basis factors like elicitation, specification and documentation are extended with success factors of solution design, elaboration and shared understanding. 
This is summarised in the ‘RE Manifesto’.

In traditional development , Requirements Engineering used to be a separate initial phase. In this phase, all (?!) requirements for the system were 'frozen' and later changes were disencouraged. 
In Agile, requirements are treated in a flexible way, as a backlog that is continuously adjusted by the team. Requirements often get little attention, due to reluctance against upfront documentation. However, professional Requirements Engineering can be very beneficial, not as an initial phase, but as a continuous process during each iteration. It ensures that the entire set of requirements on the backlog remains complete and consistent, thus preventing rework and delays.

This asks for an ongoing search for the right balance between upfront specification (stability) and in-time elaboration (flexibility); a task for the whole team, not just for the PO or the BA.
In this workshop, the concept of continuous Requirements Engineering is explained and substantiated with some small exercises.