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
Anonymous's picture
Anonymous

Hi Charles,
A short reaction on your great post from a requirements specialist in The Netherlands.
I agree mostly with you, traditional requirements are to much system focussed while requirements should, in my opinion, be user focussed. And both use cases and user stories are user focussed. And it is also true that user cases focus on value. A problem with user stories I've seen in practice is that user stories can be fragmented, users only see a small part of the big picture and sometime users miss the overview. In these situations story boards don't do the job all the time. Because use cases are more narritive users can better see the cohesion, the big picture.
In my experience you can use both use cases and user stories in an agile project. Which of the two depends on the situation, I agree on this point with you.
Great post, it made me think and cleared my opinion on this point.
Keep up the great work!

Jan Jaap Cannegieter

January 26, 2012 - 2:42am
Anonymous's picture
Anonymous

Hi Charles,
A short reaction on your great post from a requirements specialist in The Netherlands.
I agree mostly with you, traditional requirements are to much system focussed while requirements should, in my opinion, be user focussed. And both use cases and user stories are user focussed. And it is also true that user cases focus on value. A problem with user stories I've seen in practice is that user stories can be fragmented, users only see a small part of the big picture and sometime users miss the overview. In these situations story boards don't do the job all the time. Because use cases are more narritive users can better see the cohesion, the big picture.
In my experience you can use both use cases and user stories in an agile project. Which of the two depends on the situation, I agree on this point with you.
Great post, it made me think and cleared my opinion on this point.
Keep up the great work!

Jan Jaap Cannegieter

January 26, 2012 - 2:42am
Anonymous's picture
Anonymous

This is a interesting synopsis. Thanks for putting forth the examples and addressing this really common question, Dr. Suscheck.

I'm not sure I agree with the characterization of "traditional requirements." Seems to me that if you have a Business Requirements Document (BRD), it provides a business context and decidedly describes the business needs. With that in hand, one can write a Systems Requirements Specification (SRS) designed to meet the needs of the BRD. So, not sure the difference is a "system focus" vs. a "business focus" one.

I do think there are important distinctions.

Traditional requirements...

  1. are monolithic -- they are expressed in single documents which make them hard (not impossible) to separate, prioritize, work on, individually. There's a sense of "all or nothing" in this (you either approve the document or you don't).
  2. demand unavailable foresight -- in that to be "complete" requires people to be precise about things they don't know, either because they really have to "see it to know the difference" or there are interactions that are too complex to workout (or even see) ahead of time.
  3. are relatively massive -- in the physics sense... in that, because they are so detailed, they become a thing to maintain in and of themselves and thus effect an inertia. If they are complete, there is so much detail contained within that only those most intimate to the process actually critically read these documents. Once created and matured, these are often incredible expensive to maintain... and at some point they are abandoned.

Where as User Stories...

  1. are a decomposition into discrete units of work. These can be arranged in a number of ways and with relative ease. They each have their own lifecycle thereby allowing the PO to approve some and hold others.
  2. allow you to write at the level of detail you know now -- by allowing some requirements (either not well understood or not high priority) to be expressed more generally (via epics) and others (better understood or higher priority) to be decomposed into more detail respects the fact that learning is inherent in all but the most trivial knowledge work.
  3. are light-weight -- each story is expressed in the most important terms: what feature is being developed (serving a specific business need). The how can be documented (and should be where there are important details that impact correctness) as needed. In this way, the details are hashed out in the most effective way to align: through face-to-face conversations. Yes, as decisions are made, it can really help to write down the salient points.

All that said, the real value is not in what's written down, but the critical thinking that goes into it. In other words, "it's not the plan, but the planning." So, whether someone is critically thinking by writing, or critical thinking by whiteboarding, dialoging, it's the thinking that's the real value. If someone organizes their thoughts best by writing it out in a document, awesome, let 'em run. However, in terms of how the team executes on that thinking, there are clear benefits to writing requirements as User Stories.

The true value of having requirements articulated from a business perspective, from start to finish, is the alignment of the tooling with the need. At the delivery level, mutual understanding of need is the most critical thing. At the product level, aligning our work along the dimension of value streams (e.g. how does providing this incremental feature support, enhance, or optimize an existing step in a business process).

All other writing down is busywork and therefore waste.

(jesh! that last sentence sounds so final. In reality, I'm open to new data that shows otherwise... perhaps my blind spots are some assumptions I'm making about the context in which User Stories are utilized...)

January 26, 2012 - 7:35pm
Anonymous's picture
Anonymous

This is a interesting synopsis. Thanks for putting forth the examples and addressing this really common question, Dr. Suscheck.

I'm not sure I agree with the characterization of "traditional requirements." Seems to me that if you have a Business Requirements Document (BRD), it provides a business context and decidedly describes the business needs. With that in hand, one can write a Systems Requirements Specification (SRS) designed to meet the needs of the BRD. So, not sure the difference is a "system focus" vs. a "business focus" one.

I do think there are important distinctions.

Traditional requirements...

  1. are monolithic -- they are expressed in single documents which make them hard (not impossible) to separate, prioritize, work on, individually. There's a sense of "all or nothing" in this (you either approve the document or you don't).
  2. demand unavailable foresight -- in that to be "complete" requires people to be precise about things they don't know, either because they really have to "see it to know the difference" or there are interactions that are too complex to workout (or even see) ahead of time.
  3. are relatively massive -- in the physics sense... in that, because they are so detailed, they become a thing to maintain in and of themselves and thus effect an inertia. If they are complete, there is so much detail contained within that only those most intimate to the process actually critically read these documents. Once created and matured, these are often incredible expensive to maintain... and at some point they are abandoned.

Where as User Stories...

  1. are a decomposition into discrete units of work. These can be arranged in a number of ways and with relative ease. They each have their own lifecycle thereby allowing the PO to approve some and hold others.
  2. allow you to write at the level of detail you know now -- by allowing some requirements (either not well understood or not high priority) to be expressed more generally (via epics) and others (better understood or higher priority) to be decomposed into more detail respects the fact that learning is inherent in all but the most trivial knowledge work.
  3. are light-weight -- each story is expressed in the most important terms: what feature is being developed (serving a specific business need). The how can be documented (and should be where there are important details that impact correctness) as needed. In this way, the details are hashed out in the most effective way to align: through face-to-face conversations. Yes, as decisions are made, it can really help to write down the salient points.

All that said, the real value is not in what's written down, but the critical thinking that goes into it. In other words, "it's not the plan, but the planning." So, whether someone is critically thinking by writing, or critical thinking by whiteboarding, dialoging, it's the thinking that's the real value. If someone organizes their thoughts best by writing it out in a document, awesome, let 'em run. However, in terms of how the team executes on that thinking, there are clear benefits to writing requirements as User Stories.

The true value of having requirements articulated from a business perspective, from start to finish, is the alignment of the tooling with the need. At the delivery level, mutual understanding of need is the most critical thing. At the product level, aligning our work along the dimension of value streams (e.g. how does providing this incremental feature support, enhance, or optimize an existing step in a business process).

All other writing down is busywork and therefore waste.

(jesh! that last sentence sounds so final. In reality, I'm open to new data that shows otherwise... perhaps my blind spots are some assumptions I'm making about the context in which User Stories are utilized...)

January 26, 2012 - 7:35pm
Anonymous's picture
Anonymous

This is a interesting synopsis. Thanks for putting forth the examples and addressing this really common question, Dr. Suscheck.

I'm not sure I agree with the characterization of "traditional requirements." Seems to me that if you have a Business Requirements Document (BRD), it provides a business context and decidedly describes the business needs. With that in hand, one can write a Systems Requirements Specification (SRS) designed to meet the needs of the BRD. So, not sure the difference is a "system focus" vs. a "business focus" one.

I do think there are important distinctions.

Traditional requirements...

  1. are monolithic -- they are expressed in single documents which make them hard (not impossible) to separate, prioritize, work on, individually. There's a sense of "all or nothing" in this (you either approve the document or you don't).
  2. demand unavailable foresight -- in that to be "complete" requires people to be precise about things they don't know, either because they really have to "see it to know the difference" or there are interactions that are too complex to workout (or even see) ahead of time.
  3. are relatively massive -- in the physics sense... in that, because they are so detailed, they become a thing to maintain in and of themselves and thus effect an inertia. If they are complete, there is so much detail contained within that only those most intimate to the process actually critically read these documents. Once created and matured, these are often incredible expensive to maintain... and at some point they are abandoned.

Where as User Stories...

  1. are a decomposition into discrete units of work. These can be arranged in a number of ways and with relative ease. They each have their own lifecycle thereby allowing the PO to approve some and hold others.
  2. allow you to write at the level of detail you know now -- by allowing some requirements (either not well understood or not high priority) to be expressed more generally (via epics) and others (better understood or higher priority) to be decomposed into more detail respects the fact that learning is inherent in all but the most trivial knowledge work.
  3. are light-weight -- each story is expressed in the most important terms: what feature is being developed (serving a specific business need). The how can be documented (and should be where there are important details that impact correctness) as needed. In this way, the details are hashed out in the most effective way to align: through face-to-face conversations. Yes, as decisions are made, it can really help to write down the salient points.

All that said, the real value is not in what's written down, but the critical thinking that goes into it. In other words, "it's not the plan, but the planning." So, whether someone is critically thinking by writing, or critical thinking by whiteboarding, dialoging, it's the thinking that's the real value. If someone organizes their thoughts best by writing it out in a document, awesome, let 'em run. However, in terms of how the team executes on that thinking, there are clear benefits to writing requirements as User Stories.

The true value of having requirements articulated from a business perspective, from start to finish, is the alignment of the tooling with the need. At the delivery level, mutual understanding of need is the most critical thing. At the product level, aligning our work along the dimension of value streams (e.g. how does providing this incremental feature support, enhance, or optimize an existing step in a business process).

All other writing down is busywork and therefore waste.

(jesh! that last sentence sounds so final. In reality, I'm open to new data that shows otherwise... perhaps my blind spots are some assumptions I'm making about the context in which User Stories are utilized...)

January 26, 2012 - 7:35pm
Anonymous's picture
Anonymous

This is a interesting synopsis. Thanks for putting forth the examples and addressing this really common question, Dr. Suscheck.

I'm not sure I agree with the characterization of "traditional requirements." Seems to me that if you have a Business Requirements Document (BRD), it provides a business context and decidedly describes the business needs. With that in hand, one can write a Systems Requirements Specification (SRS) designed to meet the needs of the BRD. So, not sure the difference is a "system focus" vs. a "business focus" one.

I do think there are important distinctions.

Traditional requirements...

  1. are monolithic -- they are expressed in single documents which make them hard (not impossible) to separate, prioritize, work on, individually. There's a sense of "all or nothing" in this (you either approve the document or you don't).
  2. demand unavailable foresight -- in that to be "complete" requires people to be precise about things they don't know, either because they really have to "see it to know the difference" or there are interactions that are too complex to workout (or even see) ahead of time.
  3. are relatively massive -- in the physics sense... in that, because they are so detailed, they become a thing to maintain in and of themselves and thus effect an inertia. If they are complete, there is so much detail contained within that only those most intimate to the process actually critically read these documents. Once created and matured, these are often incredible expensive to maintain... and at some point they are abandoned.

Where as User Stories...

  1. are a decomposition into discrete units of work. These can be arranged in a number of ways and with relative ease. They each have their own lifecycle thereby allowing the PO to approve some and hold others.
  2. allow you to write at the level of detail you know now -- by allowing some requirements (either not well understood or not high priority) to be expressed more generally (via epics) and others (better understood or higher priority) to be decomposed into more detail respects the fact that learning is inherent in all but the most trivial knowledge work.
  3. are light-weight -- each story is expressed in the most important terms: what feature is being developed (serving a specific business need). The how can be documented (and should be where there are important details that impact correctness) as needed. In this way, the details are hashed out in the most effective way to align: through face-to-face conversations. Yes, as decisions are made, it can really help to write down the salient points.

All that said, the real value is not in what's written down, but the critical thinking that goes into it. In other words, "it's not the plan, but the planning." So, whether someone is critically thinking by writing, or critical thinking by whiteboarding, dialoging, it's the thinking that's the real value. If someone organizes their thoughts best by writing it out in a document, awesome, let 'em run. However, in terms of how the team executes on that thinking, there are clear benefits to writing requirements as User Stories.

The true value of having requirements articulated from a business perspective, from start to finish, is the alignment of the tooling with the need. At the delivery level, mutual understanding of need is the most critical thing. At the product level, aligning our work along the dimension of value streams (e.g. how does providing this incremental feature support, enhance, or optimize an existing step in a business process).

All other writing down is busywork and therefore waste.

(jesh! that last sentence sounds so final. In reality, I'm open to new data that shows otherwise... perhaps my blind spots are some assumptions I'm making about the context in which User Stories are utilized...)

January 26, 2012 - 7:35pm
Anonymous's picture
Anonymous

Great comments. Some of you are really excellent writers with interesting viewpoints of your own. You should apply this skill to writing an article. It's a good experience and gives back to the community much more than a comment on someone else's article can

January 26, 2012 - 7:45pm
Anonymous's picture
Anonymous

Great comments. Some of you are really excellent writers with interesting viewpoints of your own. You should apply this skill to writing an article. It's a good experience and gives back to the community much more than a comment on someone else's article can

January 26, 2012 - 7:45pm
Anonymous's picture
Anonymous

Great comments. Some of you are really excellent writers with interesting viewpoints of your own. You should apply this skill to writing an article. It's a good experience and gives back to the community much more than a comment on someone else's article can

January 26, 2012 - 7:45pm
Anonymous's picture
Anonymous

Great comments. Some of you are really excellent writers with interesting viewpoints of your own. You should apply this skill to writing an article. It's a good experience and gives back to the community much more than a comment on someone else's article can

January 26, 2012 - 7:45pm

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 24
Oct 12
Oct 15
Nov 09