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

[article]
Summary:

Charles Suscheck explains the differences among traditional requirements, use cases, and user stories by describing and providing an example of each.

I’ve worked with a lot of teams transitioning to agile. In each situation, user stories always seem to be a sticking point, with a common question being, “What are the differences between traditional requirements, use cases, and user stories?” I’d like to answer this question with a description and example of each requirement type. I’ll also use a running example: Imagine that we’re writing software for placement firms, and one of the firms has requested the ability to search for candidates for a specific role by specialty within a geographic location. For example, “I want to find all business analysts who are Sarbanes Oxley (SOX) experts within fifty miles of New York City.”

ChoiceTraditional Requirements
Traditional requirements are usually thought of as capabilities and constraints of the system; the key term being system. All good requirements describe what the system can do or shouldn’t do, but those requirements that focus intensely on the system tend to deemphasize user interaction or business context related to the user or business. To be fair, many traditional requirements do provide context for business and users, but that is usually not the main focus of the requirement, rather it’s the system that is the focus.

The difficulty with having the system be the focus is that it’s easy to make assumptions about what the user wants.  I’ve seen requirements be the source of record for the system’s operation.  In such a case, interacting with the business or the user while the system is being developed reverted to a series of painful, negotiated change request. The work became a matter of giving the user exactly what she asked for, which may not at all be what she needed.

This is what really makes traditional requirements tough: They’re written from the system perspective. Additionally, they’re often written in the context of a process that enforces change control and a contract based on the requirements themselves. Throw in an ideology that encourages written communication between the business analyst and the development team, and you’ve got a tough job ahead when it comes to delivering value.  Changes become a series of tightly controlled negotiations.

According to the International Institute of Business Analysts (IIBA), good requirements can be described via these criteria:

  • Requirements are complete. They must be as complete as possible with no open-ended parts or opportunity for interpretation.
  • Requirements are testable. One must be able to create a test or some sort of proof that the requirement has been met.
  • Requirements must be consistent with each other with no conflicts between what they are specifying.
  • Requirements must be design-free. Software requirements should be specified in what the system must or must not do, but not in how the software will ensure the requirement is met; that’s design.
  • Requirements must be unambiguous. No wishy-washy statements nor (conceptually) anything that can be interpreted differently than intended.

As you can imagine, good traditional requirements are tough to write and are a rare commodity. If creating a good requirement is tough, writing an entire body of requirements into a complete and locked-down specification of the system is even tougher. The level of detail can lead to many interdependencies between requirements that have to be analyzed as the requirements are developed. While all requirements specifications have this difficulty, traditional requirements are particularly touchy since the focus is on the system rather than any user interaction.

The user understandably concentrates on the interface and his interaction with the system. A simple change in the user interface can create a ripple effect through the requirements. Unless a good requirements trace is available, even small

User Comments

25 comments
Anonymous's picture
Anonymous

It is a fallacy to state that traditional requirements are focused on the system. There is a clear divide between requirements that state the problem (stakeholder requirements) and those that define (but not design) the system (system requirements). The example given is a system requirement. I would expect to see two or possibly more levels of problem statement before you get to the requirement here. In fact, the requirements I would want to see would look not dissimilar to the user story example.
The approach is, to use a saying from winemaking, simple, but not easy. Define your overall goal, work out what must be achieved to reach the goal (these are capabilities and might need several levels, two is common), then work out what the system must do to provide the capabilities (these are functions, and again might need several levels). At each point, do not lose sight of non-functional requirements such as performance, security, etc.
User stories and use cases are great ways of identifying these capabilities, of course.

January 20, 2012 - 6:51am
Anonymous's picture
Anonymous

It is a fallacy to state that traditional requirements are focused on the system. There is a clear divide between requirements that state the problem (stakeholder requirements) and those that define (but not design) the system (system requirements). The example given is a system requirement. I would expect to see two or possibly more levels of problem statement before you get to the requirement here. In fact, the requirements I would want to see would look not dissimilar to the user story example.
The approach is, to use a saying from winemaking, simple, but not easy. Define your overall goal, work out what must be achieved to reach the goal (these are capabilities and might need several levels, two is common), then work out what the system must do to provide the capabilities (these are functions, and again might need several levels). At each point, do not lose sight of non-functional requirements such as performance, security, etc.
User stories and use cases are great ways of identifying these capabilities, of course.

January 20, 2012 - 6:51am
Anonymous's picture
Anonymous

It is a fallacy to state that traditional requirements are focused on the system. There is a clear divide between requirements that state the problem (stakeholder requirements) and those that define (but not design) the system (system requirements). The example given is a system requirement. I would expect to see two or possibly more levels of problem statement before you get to the requirement here. In fact, the requirements I would want to see would look not dissimilar to the user story example.
The approach is, to use a saying from winemaking, simple, but not easy. Define your overall goal, work out what must be achieved to reach the goal (these are capabilities and might need several levels, two is common), then work out what the system must do to provide the capabilities (these are functions, and again might need several levels). At each point, do not lose sight of non-functional requirements such as performance, security, etc.
User stories and use cases are great ways of identifying these capabilities, of course.

January 20, 2012 - 6:51am
Anonymous's picture
Anonymous

It is a fallacy to state that traditional requirements are focused on the system. There is a clear divide between requirements that state the problem (stakeholder requirements) and those that define (but not design) the system (system requirements). The example given is a system requirement. I would expect to see two or possibly more levels of problem statement before you get to the requirement here. In fact, the requirements I would want to see would look not dissimilar to the user story example.
The approach is, to use a saying from winemaking, simple, but not easy. Define your overall goal, work out what must be achieved to reach the goal (these are capabilities and might need several levels, two is common), then work out what the system must do to provide the capabilities (these are functions, and again might need several levels). At each point, do not lose sight of non-functional requirements such as performance, security, etc.
User stories and use cases are great ways of identifying these capabilities, of course.

January 20, 2012 - 6:51am
Anonymous's picture
Anonymous

The author notes that good requirements should have the following two characteristics:
1) "Requirements are complete. They must be as complete as possible with no open-ended parts or opportunity for interpretation."
2) "Requirements must be unambiguous. No wishy-washy statements nor (conceptually) anything that can be interpreted differently than intended."

However, the author also states that:
1) "user stories focus on customer value with a built-in imprecision meant to encourage communication."
2) "User stories (when used as intended by experts like Cohn and Cockburn) are just too loosely formatted to lend themselves to full documentation."

Clearly, user stories are intentionally not complete as possible and are ambiguous. Thus, user stories are not requirements but rather a verbal person-to-person communication technique for eliciting verbal requirements that are not documented, but rather rapidly implemented in code and test cases.

This leads to several limitations of user stories:
1) They require close person-to-person collaboration between developers and stakeholders/SMEs/customers. This is often not possible in practice, especially when dealing with large, expensive systems that are not developed in house.
2) A lack of documented requirements makes it very difficult to cost and schedule a large and complex system, especially when customers and developers belong to different companies so that financial contracts are an unavoidable fact of life.
3) While being agile is great when requirements truly need to change relatively often and rapidly, the lack of documented requirements enables the rapid unnecessary changing of requirements that can lead to unnecessary requirements churn and floundering. Volatile requirements, when change is not really necessary, has led to many cost and schedule overruns.
4) User stories can be an excuse for the customer, stakeholders, and SMEs to be sloppy in considering what they want/need. Although it is true that many people don't really know what they want until they can see it, finding out that you don't like the system until it is delivered (or at least a prototype is available) is too late to decide that it's not what you wanted after all. That is especially true for large, complex, expensive systems including systems that consist of more than just software (e.g., hardware, equipment, facilities)

So although user stories have their place and value and should be part of the requirements engineer's toolbox, they have their limitations and disadvantages as well as their benefits.

My problem is when groups of people pick single techniques as their only way of solving non-trivial problems (like engineering requirements). That's when using things like textual requirements, use cases, and (yes even) user stories become a matter of dogma and ideological purity. A good carpenter has many tools in their tool box providing a choice of multiple ways of doing something (it is better to have both flathead and Phillips screwdrivers as well as hammers/nails and wrenches/bolts). Software developers should be no different; selecting and using the right tool for the job at hand given the job and its constraints.

January 25, 2012 - 11:45am
Anonymous's picture
Anonymous

The author notes that good requirements should have the following two characteristics:
1) "Requirements are complete. They must be as complete as possible with no open-ended parts or opportunity for interpretation."
2) "Requirements must be unambiguous. No wishy-washy statements nor (conceptually) anything that can be interpreted differently than intended."

However, the author also states that:
1) "user stories focus on customer value with a built-in imprecision meant to encourage communication."
2) "User stories (when used as intended by experts like Cohn and Cockburn) are just too loosely formatted to lend themselves to full documentation."

Clearly, user stories are intentionally not complete as possible and are ambiguous. Thus, user stories are not requirements but rather a verbal person-to-person communication technique for eliciting verbal requirements that are not documented, but rather rapidly implemented in code and test cases.

This leads to several limitations of user stories:
1) They require close person-to-person collaboration between developers and stakeholders/SMEs/customers. This is often not possible in practice, especially when dealing with large, expensive systems that are not developed in house.
2) A lack of documented requirements makes it very difficult to cost and schedule a large and complex system, especially when customers and developers belong to different companies so that financial contracts are an unavoidable fact of life.
3) While being agile is great when requirements truly need to change relatively often and rapidly, the lack of documented requirements enables the rapid unnecessary changing of requirements that can lead to unnecessary requirements churn and floundering. Volatile requirements, when change is not really necessary, has led to many cost and schedule overruns.
4) User stories can be an excuse for the customer, stakeholders, and SMEs to be sloppy in considering what they want/need. Although it is true that many people don't really know what they want until they can see it, finding out that you don't like the system until it is delivered (or at least a prototype is available) is too late to decide that it's not what you wanted after all. That is especially true for large, complex, expensive systems including systems that consist of more than just software (e.g., hardware, equipment, facilities)

So although user stories have their place and value and should be part of the requirements engineer's toolbox, they have their limitations and disadvantages as well as their benefits.

My problem is when groups of people pick single techniques as their only way of solving non-trivial problems (like engineering requirements). That's when using things like textual requirements, use cases, and (yes even) user stories become a matter of dogma and ideological purity. A good carpenter has many tools in their tool box providing a choice of multiple ways of doing something (it is better to have both flathead and Phillips screwdrivers as well as hammers/nails and wrenches/bolts). Software developers should be no different; selecting and using the right tool for the job at hand given the job and its constraints.

January 25, 2012 - 11:45am
Anonymous's picture
Anonymous

The author notes that good requirements should have the following two characteristics:
1) "Requirements are complete. They must be as complete as possible with no open-ended parts or opportunity for interpretation."
2) "Requirements must be unambiguous. No wishy-washy statements nor (conceptually) anything that can be interpreted differently than intended."

However, the author also states that:
1) "user stories focus on customer value with a built-in imprecision meant to encourage communication."
2) "User stories (when used as intended by experts like Cohn and Cockburn) are just too loosely formatted to lend themselves to full documentation."

Clearly, user stories are intentionally not complete as possible and are ambiguous. Thus, user stories are not requirements but rather a verbal person-to-person communication technique for eliciting verbal requirements that are not documented, but rather rapidly implemented in code and test cases.

This leads to several limitations of user stories:
1) They require close person-to-person collaboration between developers and stakeholders/SMEs/customers. This is often not possible in practice, especially when dealing with large, expensive systems that are not developed in house.
2) A lack of documented requirements makes it very difficult to cost and schedule a large and complex system, especially when customers and developers belong to different companies so that financial contracts are an unavoidable fact of life.
3) While being agile is great when requirements truly need to change relatively often and rapidly, the lack of documented requirements enables the rapid unnecessary changing of requirements that can lead to unnecessary requirements churn and floundering. Volatile requirements, when change is not really necessary, has led to many cost and schedule overruns.
4) User stories can be an excuse for the customer, stakeholders, and SMEs to be sloppy in considering what they want/need. Although it is true that many people don't really know what they want until they can see it, finding out that you don't like the system until it is delivered (or at least a prototype is available) is too late to decide that it's not what you wanted after all. That is especially true for large, complex, expensive systems including systems that consist of more than just software (e.g., hardware, equipment, facilities)

So although user stories have their place and value and should be part of the requirements engineer's toolbox, they have their limitations and disadvantages as well as their benefits.

My problem is when groups of people pick single techniques as their only way of solving non-trivial problems (like engineering requirements). That's when using things like textual requirements, use cases, and (yes even) user stories become a matter of dogma and ideological purity. A good carpenter has many tools in their tool box providing a choice of multiple ways of doing something (it is better to have both flathead and Phillips screwdrivers as well as hammers/nails and wrenches/bolts). Software developers should be no different; selecting and using the right tool for the job at hand given the job and its constraints.

January 25, 2012 - 11:45am
Anonymous's picture
Anonymous

The author notes that good requirements should have the following two characteristics:
1) "Requirements are complete. They must be as complete as possible with no open-ended parts or opportunity for interpretation."
2) "Requirements must be unambiguous. No wishy-washy statements nor (conceptually) anything that can be interpreted differently than intended."

However, the author also states that:
1) "user stories focus on customer value with a built-in imprecision meant to encourage communication."
2) "User stories (when used as intended by experts like Cohn and Cockburn) are just too loosely formatted to lend themselves to full documentation."

Clearly, user stories are intentionally not complete as possible and are ambiguous. Thus, user stories are not requirements but rather a verbal person-to-person communication technique for eliciting verbal requirements that are not documented, but rather rapidly implemented in code and test cases.

This leads to several limitations of user stories:
1) They require close person-to-person collaboration between developers and stakeholders/SMEs/customers. This is often not possible in practice, especially when dealing with large, expensive systems that are not developed in house.
2) A lack of documented requirements makes it very difficult to cost and schedule a large and complex system, especially when customers and developers belong to different companies so that financial contracts are an unavoidable fact of life.
3) While being agile is great when requirements truly need to change relatively often and rapidly, the lack of documented requirements enables the rapid unnecessary changing of requirements that can lead to unnecessary requirements churn and floundering. Volatile requirements, when change is not really necessary, has led to many cost and schedule overruns.
4) User stories can be an excuse for the customer, stakeholders, and SMEs to be sloppy in considering what they want/need. Although it is true that many people don't really know what they want until they can see it, finding out that you don't like the system until it is delivered (or at least a prototype is available) is too late to decide that it's not what you wanted after all. That is especially true for large, complex, expensive systems including systems that consist of more than just software (e.g., hardware, equipment, facilities)

So although user stories have their place and value and should be part of the requirements engineer's toolbox, they have their limitations and disadvantages as well as their benefits.

My problem is when groups of people pick single techniques as their only way of solving non-trivial problems (like engineering requirements). That's when using things like textual requirements, use cases, and (yes even) user stories become a matter of dogma and ideological purity. A good carpenter has many tools in their tool box providing a choice of multiple ways of doing something (it is better to have both flathead and Phillips screwdrivers as well as hammers/nails and wrenches/bolts). Software developers should be no different; selecting and using the right tool for the job at hand given the job and its constraints.

January 25, 2012 - 11:45am
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

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!