Defining Requirement Types: Traditional vs. Use Cases vs. User Stories

[article]

as the project progresses. User stories are intended as a means to foster collaboration.

Although user stories aren’t agile in and of themselves, they do emphasize collaboration, which makes user stories difficult to use in non-agile projects. I’ve seen teams that had trouble practicing agile end up with user stories that seemed like highly detailed traditional requirements.  Over specification can lead to a series of iterations that become mini waterfalls with each phase (analysis, design, code, and, test) becoming an exercise in writing out an inordinate amount of detail. This is counter to the Agile Manifesto’s principle that “the most efficient and effective method of conveying information to and within a development 
team is face-to-face conversation.”

To sum up the differences: Traditional requirements focus on system operations with a tendency toward detailed system specification; use cases focus on interactions between the user and the system with a similar tendency of detailed specification; and user stories focus on customer value with a built-in imprecision meant to encourage communication.

User Story Example
Title:
Search for candidates by role, specialty, and geographic location.

Description:
As a candidate search user, I need the ability to search for candidates by specialty so that I can more efficiently refer patients to specialists.

Acceptance Criteria:
The candidate search mechanism has the ability to enter a role.

The candidate search mechanism has the ability to enter a specialty.

The specialty search will have a list of candidate specialties from which to select.

Searching via the candidate specialty will return a list of matching specialists or a message indicating that there are no matches.

If there are more results than can fit on one page, the system will provide the capability to view the list in pages or sections.

Conclusion
Are user stories better than other types of requirements specification? It depends on the situation, but in a collaborative environment, my experience leads me to say yes.

User stories will not make your project agile, and the lack of them will make it challenging to become agile. However, user stories encourage a number of principles from the Agile Manifesto:

  • Welcome changing requirements, even late in 
development. Agile processes harness change for 
the customer's competitive advantage.
  • Business people and developers must work 
together daily throughout the project.
  • The most efficient and effective method of 
conveying information to and within a development 
team is face-to-face conversation.
  • Working software is the primary measure of progress.

If you have a decidedly non-agile environment, will user stories help? Again, it depends on the team. If a team is steeped in waterfall or heavy iterative processes and uses the “big requirements up front” approach, that team likely will influence the user stories, turning them into traditional requirements. User stories are somewhat vague and lend themselves to successive refinement; up-front planning and design is not where their forte lies. Detailed specification is often the practice in heavy process controlled environments before coding begins so that the requirements can be used to budget and plan the entire project.  That makes the requirements the source of record for the system with very little room for collaboration. User stories (when used as intended by experts like Cohn and Cockburn) are just too loosely formatted to lend themselves to full documentation. If, on the other hand, the team is open to collaboration with the analysts or business owners, and the project sponsors can tolerate change, user stories can help collaboration.

User Comments

25 comments
Wilfried van Hulzen's picture

In my experience User Stories are very good for capturing high level requirements, expectation or business/user level goals, for the system. When necesary, which depends on the development approach, these can be detailed into system requirments and/or use cases.
This detailing should not be limited to hierarchy - a requirement or use case may contribute to several user stories.
And while user stories may overlap in subgoals or implied functionality (which follows from shared reqiurements or use cases), they should remain consistent.
Any built-in imprecision to me is not meant to encourage communication but is intended to avoid overspecification at an early stage or at business/user level. Whether to resolve that imprecision through detailed requirements determined by communication or through communication in an Agile setting depends on the process.

Finally, while face-to-face communication may be the most efficient method for conveying information, I hesitate to qualify it as the most effective. For that some record of the conversation topic as starting point and record of conversation outcome would be required, where the format of that record may be a user story, requirement, use case, mock-up/prototype, or other capture of the goal or need for the system.

September 3, 2012 - 6:35am
Wilfried van Hulzen's picture

In my experience User Stories are very good for capturing high level requirements, expectation or business/user level goals, for the system. When necesary, which depends on the development approach, these can be detailed into system requirments and/or use cases.
This detailing should not be limited to hierarchy - a requirement or use case may contribute to several user stories.
And while user stories may overlap in subgoals or implied functionality (which follows from shared reqiurements or use cases), they should remain consistent.
Any built-in imprecision to me is not meant to encourage communication but is intended to avoid overspecification at an early stage or at business/user level. Whether to resolve that imprecision through detailed requirements determined by communication or through communication in an Agile setting depends on the process.

Finally, while face-to-face communication may be the most efficient method for conveying information, I hesitate to qualify it as the most effective. For that some record of the conversation topic as starting point and record of conversation outcome would be required, where the format of that record may be a user story, requirement, use case, mock-up/prototype, or other capture of the goal or need for the system.

September 3, 2012 - 6:35am
Wilfried van Hulzen's picture

In my experience User Stories are very good for capturing high level requirements, expectation or business/user level goals, for the system. When necesary, which depends on the development approach, these can be detailed into system requirments and/or use cases.
This detailing should not be limited to hierarchy - a requirement or use case may contribute to several user stories.
And while user stories may overlap in subgoals or implied functionality (which follows from shared reqiurements or use cases), they should remain consistent.
Any built-in imprecision to me is not meant to encourage communication but is intended to avoid overspecification at an early stage or at business/user level. Whether to resolve that imprecision through detailed requirements determined by communication or through communication in an Agile setting depends on the process.

Finally, while face-to-face communication may be the most efficient method for conveying information, I hesitate to qualify it as the most effective. For that some record of the conversation topic as starting point and record of conversation outcome would be required, where the format of that record may be a user story, requirement, use case, mock-up/prototype, or other capture of the goal or need for the system.

September 3, 2012 - 6:35am
Wilfried van Hulzen's picture

In my experience User Stories are very good for capturing high level requirements, expectation or business/user level goals, for the system. When necesary, which depends on the development approach, these can be detailed into system requirments and/or use cases.
This detailing should not be limited to hierarchy - a requirement or use case may contribute to several user stories.
And while user stories may overlap in subgoals or implied functionality (which follows from shared reqiurements or use cases), they should remain consistent.
Any built-in imprecision to me is not meant to encourage communication but is intended to avoid overspecification at an early stage or at business/user level. Whether to resolve that imprecision through detailed requirements determined by communication or through communication in an Agile setting depends on the process.

Finally, while face-to-face communication may be the most efficient method for conveying information, I hesitate to qualify it as the most effective. For that some record of the conversation topic as starting point and record of conversation outcome would be required, where the format of that record may be a user story, requirement, use case, mock-up/prototype, or other capture of the goal or need for the system.

September 3, 2012 - 6:35am
Madhava Verma Dantuluri's picture

Good share. New age process of defining the use cases and implementation process.

March 2, 2014 - 11:56am

Pages

About the author

Charles Suscheck's picture Charles Suscheck

Dr. Charles Suscheck is a nationally recognized agile leader who specializes in agile software development adoption at the enterprise level. He is one of only 11 trainers worldwide and 3 in the US certified to teach the entire Scrum.org cirriculum.  With over 25 years of professional experience, Dr. Suscheck has held positions of Process Architect, Director of Research, Principle Consultant, Professor, and Professional Trainer at some of the most recognized companies in America. He has spoken at national and international conferences such as Agile 200X, OOPSLA, and ECOOP on topics related to agile project management and is a frequent author in industry and academia. Dr. Suscheck has over 30 publications to his credit.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Sep 22
Sep 24
Oct 12
Nov 09