Presented by Nelis Boucké, Alexander Helleboogh and Johan Peeters

Abstract:

The success of software is not only in the functions it supports, but also in the qualities it exhibits (like security, performance, usability and maintainability). In this session, we want to investigate how these qualities can be addressed, particularly how they can be described, planned and tracked within an agile work flow. Quality requirements are also often referred to as ‘non-functional’ requirements.

In this session, participants will gain hands-on experience with several techniques (like acceptance criteria on user stories, dedicated user stories, adjustments on the definition of ‘done’, abuser stories) for explicitly managing quality requirements in an agile project. Participants will be divided in small groups and choose one or two qualities to experiment with within the context of an example system. Each group will experiment with one or more techniques and share experiences through review of each others’ results and plenary discussion.

Why you should attend:

  • It’s hands-on
  • A chance to try out several techniques on a concrete case
  • Teams giving feedback to each other
  • Relevance: quality requirements are often overlooked in agile projects

Format and length: 90 mins interactive simulation. Participants will apply and evaluate different techniques on a concrete case.

Intended audience and prerequisites:

Developers, architects, project managers, product owners. Participants should have a good understanding how functional requirements are managed in agile projects.

Objective(s) of the session:

  • Understand how quality requirements fit into agile development
  • Experience which technique is more suitable for which quality
  • Get a chance to try out different techniques on a concrete case
  • Summarize and publish the outcomes of the session in some format (blog post, article, …)

Benefits for participants and presenter(s):

We will propose a number of alternative techniques for capturing quality requirements, each suited for handling some qualities but less suited for others. Some of these may be new to participants. We will try them out on a simple case study and evaluate their suitability. Participants will be invited to share their experiences dealing with quality requirements.