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

[article]

interface or business process changes can be difficult to manage.

Traditional Requirements Example
The candidate search system shall provide the ability to search for candidates by role, specialty, and geographic region.

The role shall consist of any role listed in the DB_F01_ROLE_CAN database.

The specialties shall consist of any specialties in the DB_F01_SPEC_CAN database. 

The geographic regions must be specified via city, state, and optionally a radius in miles from the city.

Use Cases
Use cases attempt to bridge the problem of requirements not being tied to user interaction. A use case is written as a series of interactions between the user and the system, similar to a call and response where the focus is on how the user will use the system. In many ways, use cases are better than a traditional requirement because they emphasize user-oriented context. The value of the use case to the user can be divined, and tests based on the system response can be figured out based on the interactions. Use cases usually have two main components: Use case diagrams, which graphically describe actors and their use cases, and the text of the use case itself.

Use cases are sometimes used in heavyweight, control-oriented processes much like traditional requirements. The system is specified to a high level of completion via the use cases and then locked down with change control on the assumption that the use cases capture everything.

Both use cases and traditional requirements can be used in agile software development, but they may encourage leaning heavily on documented specification of the system rather than collaboration. I have seen some clever people who could put use cases to work in agile situations. Since there is no built-in focus on collaboration, it can be tempting to delve into a detailed specification where the use case becomes the source of record rather than a mechanism for conversations.

Use Case Example
The placement specialist selects a candidate search.

The system retrieves a list of candidate specialties and populates the candidacy list.

The system retrieves a predefined list of candidate specialties and populates the specialty  list.

The system retrieves a predefined list of geographic regions.

The system displays the candidate search screen.

The placement specialist selects a candidate specialty.

The placement specialist selects a candidate role.

The placement specialist selects a geographic region.

The system identifies the region and populates the subregion.

The placement specialist selects the geographic subregion.

The placement specialist selects the search initiation button or mechanism.

The system retrieves a list of candidates who match the candidate specialty search. [Alt 1]

The system displays a list of candidates who match the search. [Alt 2]

End use case

Alt 1:  If there are no matches, the system displays a message indicating that no matches were found. End use case.

Alt 2:  If there are more matches than the user can view, the system will provide the capability to display multiple pages. End use case.

User Stories
User stories are more narrative than either traditional requirements or use cases.  They are intended to describe what the user wants to be able to do. Additionally, user stories focus on the value that comes from using the system rather than a detailed specification of what the system should do. User stories are often called a metaphor for the work being done by the system. The purpose is to capture enough that the agile team can estimate the user story and understand it enough to draft a rough design. The story’s details are collaboratively worked during conversations so the user story itself becomes a promise to hold a conversation

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