12:00 - 12:45
15:00 - 16:45


Hans van Loenhoud
Trainer-Consultant / 2nd chair
Taraxacum / IREB


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 ten years, he was involved in development projects for customers in finance, industry and government. Later, he specialized in consultancy on data management, information management and quality management.

Around Y2K Hans entered the field of software testing and worked as a test manager in various 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 and that both cannot deliver value without each other. Nowadays, he is committed to build the bridge between the two disciplines, as a regular writer and speaker on these topics and as a trainer for ISTQB, IREB and iSQI courses. He is also a lecturer on Business Requirements and on Test Management at the Amsterdam University of Applied Sciences.

Hans is a member of IREB, the International Requirements Engineering Board, participating in the Executive Committee, and in the Foundation Level neXt and the Advanced Level Elicitation working groups.

Speech: Diamonds are forever

In recent years we see a growing interest in innovative development methodologies labeled as Design Thinking. Several different approaches are on the market, and they all have certain basic principles in common: they are human-centered, aim at ill-defined problems, reject early commitment to a single solution, co-create with users and apply frequent learning – making – evaluating cycles.

The core of all these methodologies is the ‘diamond’: an alternation of divergent thinking, creating a large set of new ideas and convergent thinking, pruning these ideas until a single solution remains.

In this talk, I will first show how this diamond fits in some of the major Design Thinking variants. However, you don’t have to convert to a hard-core Design Thinker to apply the diamond in your daily work. With the right mindset, everybody can use this concept in every phase of developing new solutions.

I will concentrate on the alternation of divergent and convergent thinking, and on techniques that can help you to use this approach: how to generate more useful ideas and how to prune and filter until one valuable solution. Some simple practical examples will help you to grab to essence of it.

Key takeaways

  • The diamond approach - divergent thinking first to generate ideas, followed by convergent thinking to filter a solution - is useful in any development effort
  • Many techniques are available to support this approach
  • Most important is a mindset focused on innovation
Master-class: The Good, the Bad and the Ugly – requirements quality matters

Every software development effort starts with the establishment of requirements. They may be initial, high-level, coarse, to be refined later, but they should be there. And right from the start, high quality of these requirements is essential for further development. In practice however, quality is often disappointing, leading to inefficiency, massive refactoring, delays, budget run-overs, and the delivery of software products that are abandoned by the users.

From the Boehm curve, we learn that defects in requirements are among the worst ones:

late discovery, costly fixes. Therefore, quality of the requirements should be validated as early as possible. However, it is not always easy to recognize bad requirements. This may result in missing defects until they show up as failures in production.

In any development approach, BA’s should always validate their output before handover to users, developers and testers. There are several ways of dealing with defects in requirements. In case of doubt or open issues, contingency measures should be taken to mitigate the risk.

In this workshop, I will highlight key elements of requirements validation. It is vital to distinguish good from bad requirements, and to detect and remove the ugly ones (e.g., inconsistent, contradictory or missing).

We will discuss some examples of bad and ugly requirements, look into various validation aspects and exercise with the ‘given … when … then’ paradigm.

Key takeaways:

  • High quality requirements are essential for any system development approach
  • Thorough validation helps to deliver good requirements
  • Early validation prevents inefficiency and unnecessary refactoring
  • There are several ways of dealing with defects in requirements