The book “User Stories” from Mike Cohn (ISBN 978-0321205681) has inspired me to think about the relationship between user stories and requirements. In software development, agile methods are often preferred in recent years. The classic approaches, especially the waterfall model and the V-model, seem to be more and more outdated.
As a result, user stories are preferred more and more. Do user stories really help to deliver better software quality?

User Stories:

What is a user story? Mike Cohn writes the following:
A user story describes a functionality that is valuable for the user or the buyer of a system or software. User Stories are composed of three components:

• A written description of the story used for planning and reminders
• Talk about the story to work out the details of the story
• Tests that provide, document, and detail details, when a story is fully implemented

Ron Jeffries also describes these three aspects as “Card”, “Conversation” and “Confirmation”.
In addition, Mike Cohn defines the following six characteristics of good user stories:
Independent, negotiable, valuable, estimable, small, testable.

Requirements:

A definition of the term Requirement can be found in the blog IEC 61508: Specification – Architecture – Requirements. Is there any difference?
From my point of view, the great and very important commonality between user stories and requirements is the focus on the description of the functionality. On the one hand, this is almost automatically the focus of customer interest (important aspect in agile development). On the other hand, such user stories or requirements are usually easily testable.

The other user story features “independent, valuable, estimable and small” also apply without restriction to good requirements. Please do not make the mistake now and compare good user stories with bad requirements. I think this could happen very quickly because there are so many bad requirements written in a lot of projects. There is, unfortunately, still no broad consensus on what a good requirement is, even if many steps have been made in this direction.

The user story property “negotiable” usually does not apply to requirements. In addition, it also does not apply to requirements, which details to be discussed, rather than documented. A requirement is expected to be unambiguous. The root causes for these differences are the differences between the “agile” approach and the “classical” approach.

Conclusion:

The user story as well as the requirement focuses on the description of the functionality in the form of an independent, valuable, estimable, testable and small text. This shows the great similarity between the two different forms of describing software.
In my view, the differences shown offer great potential for further improving requirements engineering. The fact that a requirement has to be “negotiable” even after conclusion of the contract is shown by many, many projects from the past decades.

The level of detail is also one of the major problems of classical requirements engineering. The agile approach that there is no perfect textual description possible, which could replace a good conversation is very appealing to me because it also corresponds to my experience in life in general. It is to be desired that the classical requirements engineering understand the agile approaches as a possibility for further improvement.
On the other hand, it is very difficult in the field of safety-relevant development, to apply the approach that not everything has to be documented. In this sector you may have to defend the development process (including the requirements/user stories) at a court. In such a case, the experience shows also that it would be a great weakness if you have not documented everything.
As conclusion, it is important to note that there is still a need to further improve the methods to describe software systems. Neither user stories nor requirements solve the questions satisfactorily.

Are you ready for a status workshop, to analyse improvement potentials in your requirement engineering, then send a mail to: info[at]heicon-ulm.de or call +49 (0) 7353 981 781.