Use Cases

What is a use-case?

In software and systems engineering, a use case is a list of actions or event steps typically defining the interactions between a role and a system to achieve a goal. The actor can be a human or other external system. Find out more.

A use case is a methodology used in system analysis to identify, clarify and organize system requirements. The use case is made up of a set of possible sequences of interactions between systems and users in a particular environment and related to a particular goal.

In the diagram, the system is constrained within the boundary (box), there are four actors shown, and the use case is an action that one or more specific users can perform.

The Unified Modeling Language (UML) is a general-purpose, developmental, modeling language in the field of software engineering that is intended to provide a standard way to visualise the design of a system.

You can see from this that there are two related concepts- a "use case" (the 'what') and a use-case diagram- a visual representation of the system, users and tasks to be achieved.

Use cases detail the requirements- where is this in the SDLC?

Could the use-cases documented be useful in these stages?

Analysis
Design
Developing
Testing

Think about how they might be used, if at all, in each of these stages.

Requirements

There are several ways to categorise requirements. Groupings are often

The links provided are pretty comprehensive in outlining each of these requirement types.

Where does this 'fit' in the sdlc?

The use-cases documented help the development team answer many of the predictable questions about an application's requirements.

Why develop use cases? How does this technique facilitate the system development process? I suspect the common but unspoken answers to the first question, "Why do you develop use cases?" might be "because everyone else is using this technique" or "because I am expected to provide use cases." It is actually the answer to the second question of:

"How does this technique facilitate the system development process?" that will give us a clue as to why use cases are such a valuable technique. First, any system that is built or bought has certain things it needs to accomplish, provide support for or compliance with, namely:

Accomplish

business goals

Provide support for..

user tasks
system functions
quality attributes

Provide compliance with..

policies
regulations
legal requirements

Keeping these things in mind, what questions should be asked to facilitate the discovery of what is needed? What will the developers actually implement?

The use case diagram will become an important part of the documentation for the project, from the initial conversion of business goals to use-cases at the initial stages of the project, right through to the approval by the customer signing off on the release of the product, and at all the stages in-between. Many people will refer to this diagram as it passes through development.

Any technique that describes what the system has to do in the context of a user task needed to achieve a business goal not only ensures that only required functionality is built, but also enables quality attributes, policies and regulations to be applied in this context as well. The use case diagram and use case are just such techniques.

Business use-case

A business use case is a high-level description of how a business goal is achieved (not yet technical). To turn that into a diagram, lets use an example:

"A customer visits the website to browse and buy products. Payment is processed by an external provider."

The goal of that sentence is to make sure you can:

Recognize what part of a business process translates into which use case diagram element.
Ask the right questions to get this info (this is called elicitation).

From this we can get:

Diagram Element

Actor: Customer

Use Case: Browse Products

Use Case: Buy Products

Use Case: Process Payment

Actor: Payment Provider

From Business use-case

“A customer visits the website...”

“...to browse...”

“...and buy products.”

“Payment is processed by an external provider.”

“...external provider” = another system or actor

Typical Questions to Elicit Use Case Elements

What roles interact with this system? → Actors
What tasks do users need to perform? → Use Cases
What happens in each task step-by-step?
Are there optional or repeated steps? → Extend/Include

use case diagram

As shown here:

Actors are users or systems that interact of the system- these can be people or other systems. Primary actors are always to the left of the system.
The system has a boundary- only actions that take place within the system are listed inside
Each Use Case is an oval. Within this oval the general structure of the use-case is Verb-Noun. e.g. Pay Bill, Cancel Order, Create Account... and so on.

The system shown here is a relatively simple one, and one easy to recognise. You can imagine for an ATM, the actor may be a bank customer, and the actions may include use-cases such as 'Enter PIN', 'Print Transactions' etc. The system boundary shows waht happens inside the system.

Relationships

In this example created on draw.io, we have an example of using a forum on the popular micro-learning site SoloLearn. There are two new annotations you may have spotted being used in this example.

include
extend

When we see an <<INCLUDE>> annotation (think of this like a note) it means that this is a requirement. That means in the context of the example above, that if the learner were to post a question, the system would require (mandate / demand) that they:

Enter a title for the question
Enter a description in the body/message box
Complete a captcha for security reasons.

We can take it that all three of these cases must be completed in order to post a new question.

Note that the arrowhead is 'on' the included use-case, rather than the parent use-case.

Now the <<EXTEND>> annotation is a little different- this is not a mandatory task. You can see from the example that when you opt to view the Q&A forums, you may (optionally):

View Posts
Post a question

You do not have to do either of these things- but they are possible to do once you have activated the parent case, i.e. gone to the Q&A forums.

Note that the arrowhead is 'on' the base (parent) use-case, rather than the extended use-case.

How to Decide Between <<include>> and <<extend>>?

1️⃣ Ask Yourself:

Is this always required? → <<include>>

Is this an optional/conditional feature? → <<extend>>

2️⃣ Arrow Direction:

<<include>> → The arrow points to the required use case.

<<extend>> → The arrow points back to the main use case that might get extended.

You will find similar distinctions when you create an account on SoloLearn. When creating a site account, you will be required to enter your full name, email and a password. These are <<INCLUDE>> use-cases for making an account. Logging into the site another way (optionally, so <<EXTEND>>) would be to login with your Facebook or Google accounts, which will then insist that you authorise the site to access certain fields of information from your profile. Is this an example of <<include>> or <<extend>>?

What is a use-case table?

Okay, so use-cases document the 'what' - the activities that can be completed on the site or application. What about the order, the steps needed to complete that task? What must be true before this action is completed and what must be true after the action is completed?

Think about this- you are on an e-commerce site and click an item you want to buy- what must be true in order to initiate this purchase? Well, you probably need to have an account created and be logged in.

If you click "checkout and pay", what must be true to go to the payment area? Well, we should probably make sure there is something in the basket, otherwise we might give a message that there is nothing to purchase.

Use case tables are a structured format for documenting use cases in text form. A sample table and notes are in the doc below:

UseCaseTable

You can see that there is a very detailed series of steps for just a single use-case. The table records:

the use case
the actor involved
preconditions
a detailed series of steps that will lead to a successful outcome (i.e. the use case is performed)
postconditions

The alternate flow shows other conditions that can happen and so must be taken account of. Sometimes a flow results in the original use-case not being successfully completed, and this is then referred to as an Exception flow.

Note that pre and post conditions are quite important, not just in UML diagrams but also in writing comments and docstrings for code.

Tips for Use Cases

Develop Iteratively

You will not know all the details of a user task on the first pass. Expect to elaborate further to:

Discover additional steps, rules, qualities or alternate paths.
Document all the data that is needed for a particular step.

Know when to re-package

As we have seen, each use case is a set of steps. Often when you revisit a user task you discover all sorts of things that intentionally were not dealt with or not known at the time. The result can be a lot of additional steps -- so many that you may feel that the entire system will be captured in this one use case.

This is a warning sign that you need to "repackage" the steps either in another user task or as an alternate path. (More than 10 steps in a use case warrants asking the question "Is this more than one user task?")

Here is the secret! The pre/post-conditions act as "bookends" because they define what has to be true at the beginning and the end of the user task. If you need to repackage the steps, note that the pre/post-conditions will not only help with this process, but they will also associate one user task (use case) to another. There can be a lot of talk around, "Is this one use case, two use cases, three use cases OR is it one use case with two alternate flows OR…?" Wow, give that discussion about 10 minutes and then make a decision.

If you have to "repackage" the steps later, so be it -it is only a regrouping!

Focus on 'what', not 'how'

Don't constrain design by using "banned" words that indicate a particular design. Some "banned" words are: click, dropdown, and button, among others. By using these words you are making a demand on the design- not your job!

Some "useful" words that convey the same idea without constraining the design are: select, provide, request and so on. When you talk with customers, they will often describe their needs in a system context which has HOW all through it. A great way to acknowledge what they have said is to restate the sentence/idea as a WHAT and perhaps take a note on their "design idea." Know that once you have described the WHAT, you are done!

The Power of the Use Case

Simply stated, the power is:

A use case is a user task which is necessary to accomplish something important to the business (business goal).
By asking the straightforward question, "What are the steps?" the functional requirements "fall out."
Test cases can be easily derived from a well-defined user task (use case).

There you go! You may have to restate the power a number of times before those who have never asked the questions we started with can finally answer:

Why develop use cases?
How does this technique facilitate the system development process?

So Use Case Tables can be a very simple list of basic information about use cases or contain more detailed information. A typical table is shown here and you can see that the elements may refer to both business rules as well as non-functional requirements- not just the functional requirements that may come to mind first.,

What are user stories?

User stories are another way to document the use-cases that an actor can perform within a system. In essence, the aim is restated such that

As an <actor> I need to
be able to <use case>
in order to/ because <business case/ other rationale>

For example:

In a training company with its own training centre:

The Course Manager has a requirement to schedule training courses and reserve rooms, in order to make available courses visible and to ensure courses run effectively
The Training Centre Manager has a requirement to keep track of what training is running, in order to ensure appropriate allocation of trainers to courses
The Financial Accountant has a requirement to maximise the amount of time that the training rooms are in use, in order to maximise revenue from the rooms

Page updated

Google Sites

Report abuse