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.”
Traditional 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 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 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
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.
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.
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.
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.
Good share. New age process of defining the use cases and implementation process.
Mr. Suscheck,
i finds myself in the middle of this delima presently. My challenge is the ability to capture non-functional requirements (i.e. how fast something needs to run, how flexible the app must be to adapt to scale up and out) in the agile user story methodology. I’ve worked on a number of true agile scrum projects and while they are successful in delivering software typically the software is absent numerous let’s call them system hardening attributes that would ensure the system was secure, performant and scalable. It seems the one best process to capture system and user information continues to allude us. Thoughts? If I’ve missed a similar response apologies for duplication of questions.
Pages