Requirements engineering is dead, long live the user story?

A long time ago

It's been quite a while since I took my IREB CPRE Foundation Level certification exam back in 2007 (incidentally, 2007 was the founding year of the International Requirements Engineering Board – IREB). At that time, the discipline of requirements engineering (RE) was really gaining momentum. Agility was more readily associated with the physical and mental fitness of a retiree than with software development.

Requirements Engineering vs. Agility?

In recent years, the tide has turned. Those who want to be successful are agile. Companies are undergoing agile transformations. Software is being developed using agile methodologies like Scrum or Kanban. Agility is therefore the new "young and dynamic." At the same time, in my perception, requirements engineering (RE) has been given a rather dusty image. Today, users write user stories, not use cases. Instead of specifications, story maps are created.

A few weeks ago, a fellow Product Owner asked me if we could run an IREB CPRE FL course. One thought then kept nagging at me: In the age of agility and user stories, does the knowledge about requirements engineering from CPRE still offer any real value? Or is the opposite true:

"RE is dead, long live the user story?"

The search for an answer

To find an answer to my self-imposed question, I went back to basics. Somewhere between "Scrum for Dummies," "Holacracy," "Kanban," and "Bitcoin," I found "Basic Knowledge of Requirements Engineering" by Klaus Pohl and Chris Rupp on my bookshelf. It's the official textbook for the CPRE Foundation Level exam.

I started browsing the pages. The deeper I delved, the more I realized: Even after five years in agile projects, I still apply the fundamentals of requirements engineering that I learned back then. Be it to define the context of the system to be developed, or to supplement user stories with valuable content for the development team. Product documentation is also much easier with methods from requirements engineering.

Requirements Engineering in the everyday life of a Product Owner

I recently used the Kano model successfully after a great story mapping workshop. We prioritized the developed user stories together with the stakeholders. The result was a shared understanding of the Minimum Viable Product (MVP).

Thanks to the wide variety of data collection techniques, I can quickly familiarize myself with new subject areas. They also help in identifying potential user stories, just as they help in determining traditional requirements.

Use cases, sequence and activity diagrams are excellent for documenting the system during development.

Business concept models also help in an agile world to build a glossary for a common technical language (who isn't familiar with the endless discussions about whether, for example, the "contract partner" and the "customer" are the same thing or different things).

And not forgetting my favorite tool: the sentence template. I still use it today to formulate business rules and sometimes even acceptance criteria.

Looking a little closer, with a small addition, the sentence template could even be used as a new User Story Pattern:

Between the two options:

"The CMS system must allow the content manager to delete blog posts so that outdated posts no longer appear on the homepage." and
"As a content manager, I want to be able to delete blog posts so that outdated posts no longer appear on the homepage."

There's not much difference anymore. And now the discussion can begin about whether the blogs should really be deleted or rather deactivated, or whether posts older than x years should be automatically removed.

I could list many more examples. But I think my question has been answered.

My answer

Requirements Engineering is alive and well!

The acquired basic knowledge also provides significant added value in agile projects. Requirements engineering and the methods taught in the CPRE Foundation Level help develop great software, regardless of the development model.

Good luck!

Yours truly, Benjamin Wyss