• Twitter
  • LinkedIn
  • Xing
+49 7353 981781
Heicon Ulm
  • HOME
  • COMPANY
  • PRODUCTS
  • HEICON BLOG
  • English
    • Deutsch
    • English
  • Menu Menu
You are here: Home1 / A_Requirement Engineering2 / User Stories – The better Requirements?

User Stories – The better Requirements?

A_Requirement Engineering

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.

 

29. January 2017/0 Comments/by HEICON Global Engineering GmbH
Tags: Functional Requirements, Functional Safety, Requirements, Software Engineering, Software Requirements, User Stories
Share this entry
  • Share on Facebook
  • Share on Twitter
  • Share on WhatsApp
  • Share on Pinterest
  • Share on Reddit
https://heicon-ulm.de/wp-content/uploads/2020/08/DI1A6236_klein_Requirement_Eng.jpg 475 684 HEICON Global Engineering GmbH https://heicon-ulm.de/wp-content/uploads/2020/07/heicon-logo-5.png HEICON Global Engineering GmbH2017-01-29 22:28:512021-02-02 21:55:15User Stories – The better Requirements?
You might also like
Functional Safety Freedom from Interference – The practice in Industry!
Railway EN 50128 configurable Systems – The solution?
Requirement Engineering Are you still writing documents or are you already specifying?
Requirement Engineering Requirement/Code Reviews – The better TDD?
Automotive Fault Injection Test in ISO 26262 – Do you really need it?
Requirement Engineering Non-Functional Requirements – A challenge?
0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Categories

  • A_Requirement Engineering
  • B_Validation and Verification
  • C_Config- / Change Management
  • D_Security
  • FuSa__General
  • FuSa_Aerospace
  • FuSa_Agriculture
  • FuSa_Automotive
  • FuSa_Industrial
  • FuSa_Railway

Contact

HEICON Global Engineering GmbH
Dipl. Ing. (FH) Martin Heininger
Kreuzweg 22
88477 Schwendi

Phone: +49 7353 – 98 17 81
Mobile: +49 176 – 24 73 99 60

Email: info[at]heicon-ulm.de

IMPRINT  |  DATA PROTECTION

Specification Architecture Requirement in IEC 61508; Is there any differenc... Industrial Validation and Verification Implicit Testing – A good idea (Part 1)?
Scroll to top