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
About the author
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.
