- About Us
- Contact Us
- Course Calendar
Identifying Use Cases is an important technique for business analysts and developers to master because they ensure they and their clients have a good understanding of what a product is for and how it will be used by future users.
The Use Case technique was popularised as a way to elicit a system’s required functions and to describe the interactions between a system and its users (actors). In Agile development, an Epic is the equivalent of a Use Case. An Epic is a named group of User Stories that have a common objective. Like Epics, Use Cases describe the functions of a product. Neither Epics nor Use Cases describe a product, a product component or a product feature. Both can be used to answer the questions “what would you use the product for?” or, “when you use it, what are you trying to achieve?”
Once the team knows what the product is for then they can start to think about how to use it. Use Case Descriptions (UCD) can help the team to identify User Stories and make sure that they are the “right” stories.
Regardless of the formality of approach, three steps are needed to understand the requirements to be met.
Perform the three steps iteratively within sprints.
Use Cases, like Epics, describe functions (not features)1and so for one Use Case there will be many User Stories. This view is supported by Use Case 2.02 which says that subsets of steps within a Use Case Description (UCD) are the source of a product “slice” to be developed – in effect a User Story.
A function is a reason for a system’s or product’s existence: a feature describes a property or component that is needed to achieve the goal of a function. Functions are abstract, features are concrete. For example, the function of a car is to transport people and/or things from one place to another. The wheels, engine, doors and seats are features that allow the car to do this.
The difference between Use Cases and Epics is the presence or absence of Use Case Descriptions (UCDs). Epics do not have Epic descriptions. For each Use Case as shown in the ovals in the diagram below, you need to write a Use Case Description (UCD). The UCD describes interactions between the actors and the system in order to achieve the goal of the Use Case.
This sequence of inputs and outputs between the Use Case’s actors and the system in question is called a scenario or a flow of events. Every UCD has one main flow/ scenario and some alternative flows/scenarios. The main and alternative flows describe all of the possible action sequences between the actors and the product.
A team working together to create or change a system must understand its functions (Use Cases/ Epics) and features (User Stories) to know what to design, build, buy, or change.
Anything, not just a software system, has Use Cases.
Knowing the requirements for your product is vital regardless of how they are recorded. They ensure the team understand why it is needed, what it is going to be used for and how it is going to be used.
The International Institute of Business Analysis (IIBA) and other authorities describe 3 levels of requirements.
Level 1 Requirements - Business Benefit Requirements
These requirements describe the goal of the organisation and the business benefit that will be achieved by using the system. They do not describe the outputs to be produced by the organisation.
For example, an automobile manufacturing business produces automobiles to earn revenue. The earned revenue is a benefit or outcome. The produced automobiles are outputs.
Use Cases are not about level 1. They are at Level 2.
Level 1 requirements provide the rationale for Level 2 requirements.
When teams work in an Agile way, it may be that Level 2 requirements are uncovered before Level 1 requirements have been discussed. To ensure that teams are outcome focussed, for every Level 2 requirement there should be at least one known Level 1 requirement.
Why are Level 1 requirements important for agile working?
Some Agile developments while efficiently producing products, sadly produce the wrong products thus delivering no value to the organisation. It is very important for the Agile team to be outcome as well as product oriented.
Level 2 Requirements - Users' Goals (Stakeholder Requirements)
A Use Case names a goal to be achieved by, or a function of, someone or something: e.g., “register a customer’s purchases”. It describes what a system is used for but does not describe any feature or features of that system.
A Use Case is an equivalent of an Epic, or a Function, or a User or Stakeholder requirement.
One Use Case = one User Goal = one Level 2 (functional) Requirement = one Epic = one Function.
An analyst will refine their understanding of a Use Case by talking with representative users to write a Use Case Description (UCD). A UCD describes the intent and order, but not the method, of actor and system actions to meet the goal of the Use Case.
Each Use Case has a UCD. The Epic technique is not as detailed as Use Cases with UCDs.
Sub-sets of the steps in a UCD are the source of and so validate User Stories – Level 3 Requirements.
When teams work in the agile way it can be that Level 3 requirements are discussed before Level 2 requirements are known. However, for every Level 3 requirement, there must be at least one Level 2 requirement that justifies it and each Level 2 requirement must be justified by at least one Level 1 requirement.
Level 3 Requirements - Required Features
Agile teams elicit Level 3 requirements by talking about and writing User Stories. Independently of design detail, a User Story describes a needed product feature. Each feature i.e., User Story is justified by a sub-set of steps within a UCD.
Use Cases with UCDs can be used by Agile teams to find User Stories. Sometimes User Stories are found before Use Cases. A Use Case gives the rationale for some User Stories.
Levels 1, 2, and 3 requirements can be found iteratively in sprints. For each sprint, the team has representative users, developers, testers, infrastructure people, business analysts … everyone needed to make sure that a fit-for-purpose product is delivered then used at an acceptable cost and within an acceptable timeframe. The team delivers and tests a little and often.
1. When the effort is kicked-off, identify Use Cases for a release
2. Release a version of the product