Agile Requirements Engineering

2021 04 03 head

Lately, I was asked which new approaches should be used for agile requirements engineering. Did we find a new silver bullet to write software specifications the agile way?

The answer is easy. We do not need new approaches or complicated processes. Start with proven principles and learn.

Impact Mapping and Story Mapping are successful approaches to identify and prioritize your functions. Specification by Example and User Stories as a discussion allow you to refine your understanding of what your customers need.

Acceptance Testing verifies the implementation fulfills the expected behavior. You get the mechanism to avoid regression problems when releasing your application for free.

The associated theory was published in seminal books more than a decade ago. Start applying the principles. You can later still improve your approach based on your learning.

A nice overview was published in the Professional Product Owner [1] written by the stewards of the product owner certification path under

If you prefer videos, search for Gojko Adzic, Roman Pichler, Mike Cohn or Christian Hassa. These experts are often speakers at conferences. You will find recordings of their speech on various platforms such as YouTube or Vimeo.

Our job is NOT to develop software. Our job is to change the world.

— Jeff Patton

Give 2% of users 100% of what they need, not 100% of people get only 2% of their needs.

— Gojko Adzic



Use Impact mapping and story mapping to classify and order your functionality. Story mapping works hand in hand with the release plan artifact I cited in a previous post. You have not only the key functionality you want to deliver, but also a tentative plan when you will deliver them.

Vision, roadmap, and release plan are needed artefacts for any product development using Scrum as a development approach. The mapping identifies the stories to realize in a release to satisfy the customer’s needs. A nice discussion of these concepts can be found in Strategize [2].

The nice think is that impact mapping and story mapping are quite compatible with design thinking. We can nicely connect the different directions used in agile product development and marketing departments.

Each specification story has acceptance criteria. These criteria are the specifications of your product.

The Scrum community clearly states that product backlog items are not specifications. They are work items for the Scrum team. If you want to use stories to describe your needs instead of the specification by example approach, it is OK, but please not in the backlog.


Acceptance criteria is a form of specification by example. Acceptance tests - see ATDD and BDD - are the automatic check for specification by example.

2021 04 03 test pyramid

The gain of implementing the acceptance criteria as ATDD is guaranteed elimination of regression issues. You also get automatic generation of test plans, test results and requirement documents. Your documents are always in sync with the source code of your product. An additional advantage is all these artifacts are under source code management and fully auditable.

I had success with Fitness Functions to describe and validate non-functional requirements. We recommend taking this approach. You can extend your automatic validation to non-functional requirements with the same mechanisms as for functional requirements.


You could use the following reference books to bootstrap and strengthen your agile specification process:

Specification by example

was published in 2009, twelve years ago [3].

Impact Mapping

was published in 2012, ten years ago [4],

User Story Mapping

was published in 2014 eight years ago [5]. Mike Cohn did also write about user stories [6].

Building Evolutionary Architectures

Fitness functions are described in this seminal book [7]. It is also a recommended reference to my SWAT Software Architecture and Techniques bachelor lecture taught at technical universities. The book was published in 2017, five years ago.

I currently teach the SWAT course at the department of computer science of the technical university of Luzerne. [1]

Agile requirements engineers can find valuable information in seminal books [8, 9, 2, 10, 7].


The most effective software architecture approach is Domain Driven Design.

The requirement analysis approach predating DDD is Event Storming.

Event Storming is a collaborative analysis practice that brings together domain experts and developers for a common understanding of the needs to be realized. Conducted in the form of a workshop, its purpose is to quickly discover what is happening in the software domain. Compared to other methods, it is extremely light and intentionally does not require any computer support. The result is expressed in sticky notes on a wall.

The SWAT course naturally also discusses DDD and event storming. This blog also contains an architecture series digging into agile architecture approaches. The first article describes Agile Architecture Principles.


[1] D. McGreal and R. Jocham, The Professional Product Owner. Addison-Wesley Professional [Online]. Available:

[2] R. Pichler, Strategize. Pichler Consulting, 2016 [Online]. Available:

[3] G. Adzic, Bridging the Communication Gap. Neuri Limited, 2009 [Online]. Available:

[4] G. Adzic, M. Bisset, and T. Poppendieck, Impact Mapping. Provoking Thoughts, 2012 [Online]. Available:

[5] J. Patton, User Story Mapping. O’Reilly and Associates, 2014 [Online]. Available:

[6] M. Cohn, User Stories Applied. Addison-Wesley Professional, 2004 [Online]. Available:

[7] N. Ford, R. Parsons, and P. Kua, Building Evolutionary Architectures: Support Constant Change, First. O’Reilly Media, 2017 [Online]. Available:

[8] A. Osterwalder, Value proposition design. 2014 [Online]. Available:

[9] R. Pichler, Agile product management with Scrum. Addison-Wesley, 2010 [Online]. Available:

[10] R. Pichler, How to Lead in Product Management. 978-1-9163030-0-3, 2020 [Online]. Available:

1. Lecture videos in German for Spring Semester 2021 are available under Switch Tube