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.

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

Experienced testers, business analysts, product owners, project managers

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