<< Back to Requirements Management Home
Use Cases and Scenarios
Once you have developed an initial set of Functional Requirements during the Requirements Gathering
phase you will have a good understanding of the intended behavior of the system. You will understand what
functionality is desired, what constraints are imposed, and what business objectives will be satisfied.
However one shortcoming of a traditional 'laundry-list' of requirements is that they are static and don't
concern themselves with the different business processes that need be supported by one feature.
For example, in our fictitious online library system, the functionality for managing returns would need to
handle the separate situations where a borrower returns a book early and when he/she returns it late.
Although the same functionality is involved, they are different situations and the system would need
to handle the separate conditions in each use case. Therefore use-cases are a valuable way of uncovering
implied functionality that occurs due to different ways in which the system will be used. Also use-cases
provide a great starting point for the test cases that will be used to test the system.
A use case is a definition of a specific business objective that the system needs to accomplish. A use-case will
define this process by describing the various external actors (or entities) that exist outside of the system,
together with the specific interactions they have with the system in the accomplishment of the business objective.
Types of Use Case
Use cases can be described either at an abstract level (known as a business use-case) or at an
implementation-specific level (known as a system use case). Each of these is described in more
Business Use Case - Also known as an "Abstract-Level Use Case", these use cases are written in a technology-agnostic
manner, simply referring to the high-level business process being described (e.g. "book return") and the various
external entities (also known as an actor) that take part in the process (e.g. "borrower", "librarian", etc.). The business use case will
define the sequence of actions that the business needs to perform to give a meaningful, observable result to the
System Use Case - Also known as an "Implementation Use Case", these use cases are written at a lower level of detail
than the business use case and refer to specific processes that will be carried out by different parts of the system.
For example a system use case might be "return book when overdue" and would describe the interactions of the various
actors (borrower, librarian) with the system in carrying out the end-to-end process.
Typically you will start by defining the high-level business use-cases, and as the system requirements get defined, they will
will be "drilled-down" into one or more lower-level system use cases.
Scenarios and User Stories
One related artifact is the "business scenario" or user story. These are similar to
use cases in terms of what they seek to accomplish - a description of the how the system will carry
out a specified business process to fulfill the stated requirements. However unlike a use case
which is a step-by-step enumeration of the tasks carried out during a process (with the associated
actors), a scenario is much more free-form.
A user story is typically a narrative that describes how a user would experience the functionality
of the system. As the name suggests it is a "short story" that describes the tasks they carry out,
what information they see and how they interact with the system. User Stories have become more
popular with the advent of Agile Methodologies that emphasize
customer collaboration, user interaction and simplicity.
Use Case Diagrams
These are diagrams that can be used to more clearly illustrate the set of use cases that are provided by
the functionality in a system. The diagrams contain both the external entities that will be using the system
(also known as "actors") and the discrete use cases (or goals) that the users will be carrying out.
These diagrams are typically represented in the UML modeling language (though other forms do exist) and
will help the business analyst convey the relationships between the actors and their business goals and how
the design of the system needs to support their different objectives with integrated business processes.
Relationship to Functional and System Requirements
Use cases are often used as a means of discovering and representing functional and system requirements
since they define the interactions and tasks necessary for carrying our specific business objectives. However
they typically are not a good way of defining non-functional requirements such as technical requirements or
system qualities. A requirements traceability matrix is used to ensure completeness - namely that all functional
requirements are covered by at least one business use case, and that all system requirements are covered
by at least one system use case.
Relationship to Test Cases
Since you typically need to ensure that there is complete requirements test coverage for
a successful quality assurance program, use cases provide a good
starting point for the design of test cases that will be used to test that the system meets the specified requirements.
Once the requirements engineering actitivies have been completed and the business analysts are happy with the
requirements definition, the test writers can create test cases
based on the system use cases. This usually involves adding more detailed pre-conditions and post-conditions
and writing different test cases "variants" of the same use-case to cover different testing scenarios.
Part of this will involve the identification of the critical exception cases that could cause the system to
fail, and the development of the necessary test data to ensure full coverage of all test conditions.