Stories, use cases, and traditional requirements

Comparing user stories, use cases, and traditional requirements.

Comparison example
The client has requested the ability to search for providers by provider specialty.

Traditional Style:
The provider search screen shall provide the ability to search for providers by provider specialty.

Use Case Style:
The client selects the provider search screen.
The system retrieves a predefined list of provider specialties and populates the specialty drop down list. The system displays the provider search screen.

The client selects a provider specialty and clicks search.
The system retrieves a list of providers that match the provider specialty search. [Alt 1]
The system displays the provider list result screen with the matching providers. [Alt 2]
End use case

Alt 1: If there are no matches, the system displays an empty provider list results screen with a message: “no matches found”. End use case.

Alt 2: If there are more matches than fit on one screen (currently 15), then the system displays the provider list result screen with 15 matching providers and a ‘next’ button at the bottom of the screen. Refer to “next button pressed” use case.

Story Style:
Story:
Search for providers by provider specialty.

Description:
As a system user, I need the ability to search for providers by specialty so that I can more efficiently refer patients to specialists.

Acceptance criteria:
The provider search screen will have a specialty search box.
The specialty search box will be pre populated by provider specialties (see specialty in the KDB).
Searching via the provider specialty will return a list of matching specialists or a message indicating that there are no matches.