Introduction to Use Cases

Introduction

Use cases have been introduced by Ivar Jacobson [1] more than 20 years ago. They are used to express functional requirements from the user perspective. What does it mean?

For example, if you imagine a conference system, or any other system, you can express requirements either from the system or user point of view. The system point of view would be expressed by answering question what kind of functionality systemu should provide (e.g. "system should enable uploading a paper"). This approach is often used to express functional requirements. It is not bad idea of course, but if you try to develop SRS only by expressing system point of view, you can get to the point where you are not sure what was the purpose of certain functions? And this is the place where user perspective (and use cases) is useful. If you would like to express user point of view, you should start asking questions like what user (actor) would like to accomplish by using the system?, how the system will support actor in obtaining the goal? This kind of thinking helps you to identify critical functionality. If actor is not able to achieve meaningful goals, the system will not fulfil its mission for sure. For example if our conference system is considered, actor - Author would probably like to achieve at least two goals - submit a paper and read review. Of course to submit a paper, Author will have to obtain lesser goals like for example registering to the system. It may sounds trivial if we consider such a simple example, but if you consider real cases actor's goals may not be so clear when you start to elicit requirements...

Use-Case Model

When talking about use cases, you will very often hear about use-case model. Such model consists of both actors and use cases [2].

Actors

A single actor represents end-user, system or device, which is supposed to collaborate with the system under development. It is important to remember that if we talk about human actors, we don't think about certain people like for instance John Smith (who does something in our organization), but about a certian classes / archetypes of users. We can also say that actor can be perceived as a role in the system. A real user (e.g. mentioned J. Smith), can play different roles (be a different actor) in different use cases.

For example if we talk about mentioned conference system you could imaging that there is Mr Smith, who is a member of organizing comittee of the conference. He is responsible for managing the conference system e.g. for adding, removing user accounts. When he does that, he acts as an actor - Administrator. However, the same Mr Smith may like to submit his paper for the conference. In that case he would become an actor called Author.

Use Cases

So, we know now, that use case presents functionality from the user (actor) point of view. Each use cases refers to important goal actor would like to obtain: Use case = actor's goal

Levels of Use Cases

Use cases can present interaction at different levels. Typically we use three levels:

• business level - this kind of use cases tend to answer the question why user goals are important. Cockburn names them white use cases [3]. In most cases such use cases present business processes (you can use use-cases as an alternative for graphical notations like UML or BPMN). Use case presenting business process looks a little bit different than standard one [4] (for example it will focus on interaction between people and organizations).
• user level - these kind of use case focuses on goals directly valuable for actors (Cockburn calls them blue [3]). In case of the conference system, this kind of goal for PC Chair would be assigning reviewers to submitted papers.
• subfunction level - these are goals which have to be obtained in order to be able to obtain user-level goal (Cockburn calls them indigo or black [3]). For instance you will have to login to the system in order to be able to submit a paper.

Actors and Use Cases

In most cases we divide actors to two groups:

• main actors - those are actors who are "personally" interested in obtaining the goal.
• secondary actors - these kind of actors also appear in use case but their role is to support main actors in obtaining their goals.

Typical Parts of Use Case

According to guidelines for writing use cases [3,5] the most typical parts of use case are:

• unique ID,
• name - it should refer to the goal of use case (expression in active form: verb + object),
• actors - a list of main and secondary actors,
• description - a brief summary of what use case is about,
• level,
• main scenario (main flow, main course) - a typical way of obtaining the goal, typically presented as a list of steps (in form: actor + verb + object).
• alternative scenarios (flows, courses) - alternative ways of obtaining the goal of use case,
• exceptions - during the execution of use case special situations may occur (for example there might be some errors, failures); exception consists of event which appears and scenario which is executed in that case,
• extensions - present  additional scenarios, which can be realized by actor during the execution of use case,
• triggers - they describe situations in which triggers use cases execution,
• pre-conditions - a list of conditions, which should be satisfied when use case is about to be executed,
• post-conditions - a list of conditions, which should be satisfied after execution of the use case is finished.

If you are interested in knowing how people author use cases (what is the intensity of certain use-case properties observed in real projects) see our UCDB database, you can also read the paper [6].

Relations Between Use Cases

There are three relations between use cases in use-case models:

• inclusion (<<include>>) - if A includes B, it means that the scenario of the use case B is included (in some point) to one of the scenarios of use case A (it is obligatory).
• extension (<<extend>>) - if A extends B, it means that while executing scenarios of B (in some point) actor can execute scenarios of use case A (optionally).
• generalization / specialization - A is a specialization of B, it means that A "inherits" all scenarios from B, what is more it can alter them, extend them, as well as add new scenarios / steps.

Ways of Presenting Use Cases

A typical approach to author use cases is to write them using natural language. However, you can use graphical notations like UML (sequence or activity diagrams) or present them as a structured text.

You can find examples of the latter approach in the Use-Case Benchmark Specifications.

Use-Case Diagram

Use-case diagrams are part of the UML notation. From my experience, they are often incorrectly perceived as use cases themselves. I would rather say that they are a kind of maps presenting actors, names of use cases and relations between them. They help to visualize a set of use cases as you can see below. Use cases are presented as elipses, connected with actors. You can also present relations between use cases on that kind of diagram.

You can read more about Use Case Diagram in a separate article.

References

1. I. Jacobson. Object-oriented development in an industrial environment. ACM SIGPLAN Notices, 22(12):183–191, 1987.
2. G. Övergaard and K. Palmkvist. Use cases: patterns and blueprints. Addison- Wesley, 2005.
3. A. Cockburn. Writing effective use cases. Addison-Wesley Boston, 2001.
4. J. Nawrocki, T. Nędza, M. Ochodek, and Ł. Olek. Describing Business Processes with Use Cases. In BIS, pages 13– 27, 2006.
5. S. Adolph, P. Bramble, A. Cockburn, and A. Pols. Patterns for Effective Use Cases. Addison-Wesley, 2002.
6. B. Alchimowicz, J. Jurkiewicz, M. Ochodek, and J. Nawrocki: Building Benchmarks for Use Cases Computing and Informatics. 2010.