Use the boxes above to navigate between slides.
Press the N or P keys on your keyboard to access the Next and Previous Slides.
Press the B key to return to the top of the page.
If there is audio associated with a slide, you will see an audio controller appear.
If the audio controls are present press the play button to start the audio, and the pause button to stop it.
If you exit a slide before the audio is complete do not worry. The audio will stop playing, and will be ready for you the next time you access the slide.
The main objective of defining requirements in system development is understanding users’ needs, how the business processes are carried out, and how the system will be used to support those business processes. Use Case (UC) modeling helps to discover and understand the requirements for a new system.
A use case is a series of related interactions between a user (AKA “actor”) and a system that enables the user to achieve a goal. In other words, a use case describes the system's behavior as it responds to a series of related requests from an actor. UC models are text documents, NOT diagrams, thus UC modeling is primarily an act of writing text, NOT drawing diagrams. Although UC diagrams are not the primary deliverable of UC modeling, they can be useful because they:
show names of use cases and actors and their relationships.
illustrate the context of a system and its environment.
provide a quick way to list the use cases by name.
UC models are requirements, primarily functional or behavioral, that indicate what the system will do and define a contract of how the system will behave. A use case emphasizes user goals and perspective and answer:
Who is using the system?
What are their (typical) scenarios of use?
What are their goals?
Actor – something with behavior, such as a person (identified by role, NOT name), computer system, or organization. An example might be a cashier.
Scenario – a specific sequence of actions and interactions between actors and the system. Frequently, several variations of the business steps exist within a single use case. These different flows of activities are called scenarios or sometimes use case instances.
Use case – a collection of related success and failure scenarios that describe an actor using a system to support a goal.
Brief UC Description – Terse one-paragraph summary, usually of the main success scenario. When? During early requirements analysis, to get a quick sense of subject and scope. They frequently require only a few minutes to create.
Fully Developed UC Description – All steps and variations are written in detail, and there are supporting sections, such as preconditions and success guarantees. When? After many use cases have been identified and written in a brief format, then during the first requirements workshop a few (such as 10%) of the architecturally significant and high-value use cases are written in detail.
Types of Actors
An actor is anything with behavior, including the system under discussion itself when it calls upon the services of other systems. There are three kinds of actors:
Primary – A primary actor has its user goals fulfilled by using services of the system under discussion. We must identify the primary actor(s) first to find the user goals. These goals are what drive the UC. An example of a primary actor might be a cashier.
Supporting – A supporting actor provides a service (for example, information) to the system under discussion. Often a computer system, but could be an organization or person. We must identify the supporting actor(s) to clarify external interfaces and protocols. An example of a supporting actor might be an automated payment authorization service.
Offstage – An offstage actor has an interest in the behavior of the UC, but is not primary or supporting. We identify a supporting actor to ensure that all necessary interests are identified and satisfied. Offstage actor interests are sometimes subtle or easy to miss unless these actors are explicitly named. An example of an offstage actor might be a government tax agency.
Fully developed UC Description - Sections
Use case name: Uniquely identifies the use case. Name use cases with an active verb-noun pair.
Scenario: Identifies the specific scenario within the use case (if required).
Triggering event: Event that triggers the use case.
Brief description: A duplicate of the brief description of the use case constructed earlier.
Actors: A list of all actors involved with the use case.
Related use cases: Cross-reference other related use cases and the way they are related to this one.
Stakeholders: Identifies stakeholders who are interested parties other than specified actors. They might be users who do not actually invoke the use case, but who have an interest in results produced from the use case.
Pre-conditions: Identifies what the state of the system must be for the use case to begin, including what objects must already exist, what information must be available, and even the condition of the actor prior to beginning the use case. Only provide what is worth telling the reader, i.e., do not worry about logging in, etc.
Post-conditions: Identifies what must be true upon completion of the use case. They indicate what new objects are created or updated by the use case and how objects need to be associated. The post-conditions are important for two reasons. First, they form the basis for stating the expected results for test cases that will be used for testing the use case after it is implemented. Second, the objects in post-conditions indicate which objects involved in the use case are important for the design phase.
Flow of activities: Describes the detailed flow of activities of the specified scenario in the use case. They can be in single-column or two-column format. No matter the format, the flow of activities needs to illustrate steps performed by the actor does and how the system responds, step-by-step. The steps need to be numbered to help identify the sequence of the steps. Exception conditions will be tied to the steps numbered here.
Exception conditions: Alternative activities and exception conditions are described in the Exception conditions. The numbering of exception conditions must be tied to the specific steps in the flow of activities.
Use an essential versus concrete style. Keep the user interface out of the UC and focus on intent.
Write terse use cases
Write black-box use cases. Focus on responsibilities on, not internal workings, components or design.
Take an “actor” and “actor-goal” perspective.
How to find UC
Choose the system boundary.
Determine the primary actors.
Use the User Goal Technique to find UC – ask users to describe their goals for using the new or updated system.
Use the Event Decomposition Technique – identify all the business events the information system responds to, with each event leading to a use case. The appropriate level of detail for identifying use cases is one that focuses on elementary business processes (EBPs). An EBP is a task that is performed by one person in one place in response to a business event, adds measurable business value, and leaves the system and its data in a stable and consistent state. There are three types of events to consider:
External events – an event that occurs outside the system – usually initiated by an eternal agent or actor.
Temporal event – an event that occurs as a result of reaching a point in time.
State event – an event that occurs when something happens inside the system that triggers the need for processing.
Validate and refine UC using CRUD. “CRUD” is an acronym for Create, Read or Report, Update, and Delete, and it is often introduced with respect to database management. The CRUD technique is most useful when used as a cross-check along with the user goal technique. It includes these steps:
Identify the different types of data, i.e., customer, account, address, etc.
For each type of data, verify that a use case has been identified that creates a new instance, updates existing instances, reads or reports values of instances, and deletes (archives) an instance.
If a needed use case has been overlooked, add a new use case and identify the stakeholders.
With integrated applications, insure it is clear which application is responsible for adding and maintaining the data and which system merely uses the data.
Three Useful Tests
The Boss Test – If your boss asks what you have been doing all day, what will you tell him? That you have been logging in all day or that you have been creating customer accounts? Utilizing the Boss Test, logging in would not be a good use case, but create customer accounts would.
The Size Test – A UC is seldom a single action or step; typically, there will be many steps and in the fully developed format, there will often be three to ten typed pages.
Focus on Elementary Business Processes (EBP) – a task performed:
By one person.
In one place.
In response to a business event.
That has measurable business value.
Leaves the system and its data in a stable and consistent state.
Example UC UML Diagram
Back to Top