Continuous Requirements Engineering - from requirements engineering to requirements engineering

Hans van Loenhoud


Published material and recordings are the property of the Authors. They may only be used with respect to copyright.

Published material and recordings are the property of the Authors. They may only be used with respect to copyright.
Main message

Requirements Engineering is a continuous activity in every IT development project, from the inception up to the very end. Professional RE is essential for the success of the project and the quality of the product. It is relevant for all developers: not only for Product Owners and Business Analysts, but certainly also for testers.


In traditional IT projects, Requirements Engineering was often positioned as a separate initial phase, in which ‘all’ requirements for an IT system were documented in detail and ‘frozen’ as input for the development phase. As often seen, this approach does not work.

In recent years, we have realized that requirements develop over the entire course of a project from coarse-grained epics and features to detailed user stories and acceptance criteria by a continuous process of defining, refining and redefining. In the same time, we see a shift of focus from single-issue requirements elicitation for a certain customer to holistic solution provision for all stakeholders.

Professional Requirements Engineering ensures that during (and even after) the development process, the total set of requirements remains integer and consistent, thus preventing unnecessary refactoring, delays and cost overruns. This requires a constant search for the right balance between upfront elicitation (more certainty) and later-on elaboration (more flexibility), to find the right level of detail at the right moment (just enough, just in time), to decide between documentation and communication.

Requirements engineering is an activity in which all development team members are involved, not just a responsibility for the Product Owner or the Business Analysts. Architects, designers and programmers all take their part in re(de)fining the requirements. Testers play an important role as custodian of the overall product quality. Often, it is just in the elaboration of acceptance criteria, that quality requirements and constraints come to the surface. Recent developments in Requirements Engineering can be seen as an evolution. Basis factors like elicitation, specification and documentation are extended with success factors of solution design, elaboration and shared understanding.

This is summarized in the ‘RE Manifesto’.

Target group

Experienced testers, business analysts, product owners, project managers

5 Take-homes for attendants
  1. Requirements Engineering is no separate phase, preceding an IT project, but an on-going process that needs continuous attention during development
  2. Not every requirement can (nor needs to) be documented upfront in detail – ‘just in time, just enough’ is the better approach
  3. Requirements are re(de)fined in the course of the project, from coarse (‘epics’) to fine (‘acceptance criteria’)
  4. Look for the balance: upfront ⇔ during; abstract ⇔ concrete; speed ⇔ quality; …
  5. Testers play an important role in ensuring the quality, integrity and consistency of the requirements

Hans van Loenhoud – IT-consultant at Taraxacum BV, the Netherlands

Hans van Loenhoud graduated as a biologist and worked in ecological research at the University of Amsterdam.

In 1980 he switched to IT and started his career as a Cobol programmer. For more than 10 years, he was involved in development projects for customers in finance, industry and government. Later on, he specialized in consultancy on data, information and quality management.

Around Y2K Hans entered the field of software testing and worked as test manager in various development projects. During his work as a tester, he took interest in requirements engineering, because he is convinced that good requirements are a prerequisite for professional testing.

Nowadays, he is committed to build the bridge between the two disciplines, acting as a trainer for ISTQB, TMap, IREB and iSQI courses.