![Page 1: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/1.jpg)
RequirementsEngineering
Southern Methodist University, CSE 7316 – Use cases
http://www.oracle.com/technology/products/jdev/collateral/papers/10131/gettingstartedwithusecasemodeling.pdf
![Page 2: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/2.jpg)
Use Cases
A use case describes particular functionality that a system is supposed to perform or exhibit by modeling the dialog that a user, external system, or other entity will have with the system developed.
Actor – entity interacting with the system, e.g., a user, a device, or another system.
[Pfleeger, p.265]
![Page 3: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/3.jpg)
Use cases
Formal definition; a use case describes a sequence of actions a system performs that yields a result of value to a particular actor Describes the interactions between a user and a
system Focus on what the system does for the user
![Page 4: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/4.jpg)
Motivation
Each use case describes a possible scenario of how an external entity interacts with the system. The collection of uses cases paints a picture of the complete functionality of the system.
• Customers can read use cases to see if the system will include all desired functionality
• System designers use use cases to lay out the systems objects and data elements
• Testers employ use cases as a basis for system testing
![Page 5: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/5.jpg)
What is use case modeling?
The core items of use case modeling are use cases and actors.
Whenever we discuss the requirements of a system we recognize one or more people or things that have an interest in the behavior of that system.
These are called the stakeholders of that system.
![Page 6: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/6.jpg)
What is use case modeling?
A use case describes how the system should respond under various conditions to a request from one of the stakeholders to deliver a specific goal
This is primarily done in the form of a scenario that describes a sequence of steps
Each use case captures a “contract” for the behavior of the System under Discussion (SuD) to deliver a single goal
Ultimately, the functional requirements of a system can be captured by describing how the SuD should respond to all possible requests as a series of use cases
![Page 7: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/7.jpg)
What is use case modeling?
In this way you can specify an important part of, but not all requirements
Requirements you cannot capture this way are non-functional requirements, business rules, the user interface and other requirements that are not suitable to be described as a scenario
![Page 8: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/8.jpg)
Use case modeling steps
Find the system boundary Find the actors Find the use cases
Specify the use case Create scenarios
![Page 9: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/9.jpg)
Use case model components
Actors; roles played by people or things that use the system
Use cases; things that the actors do with the system Relationships; meaningful relationships between
actors and use cases System boundary; a box drawn around the use
cases to denote the edge or the boundary of the system being modeled
![Page 10: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/10.jpg)
The system boundary
What is part of the system and what is external to the system
Positioning of boundary has big impact on functional and non-functional requirements
Defined by who or what used the system Drawn as a box
![Page 11: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/11.jpg)
Actors
An actor is anyone or anything with behavior The primary actor is the stakeholder that
interacts with the SuD to achieve a specific goal
The primary actor is often, but not always the one who triggers the use case
It is not, when the use case is actually triggered by an actor who does this on behalf of the real primary actor, or when the use case is triggered by time
![Page 12: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/12.jpg)
Actors
Specifies a role that some external entity adopts when interacting with the system directly
Represents a user role or a role played by another system
Always external to the system Outside our control
![Page 13: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/13.jpg)
Finding actors
Who or what uses the system? Who installs the system? Who starts and shuts down the system? Who maintains the system? Who gets and provides information to the
system?
![Page 14: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/14.jpg)
Time as an actor
For modeling things that happen to your system at a specific point in time but which don’t seem to be triggered by an actor Automatic system backup that runs every morning
![Page 15: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/15.jpg)
Actors
Sometimes an (external) actor needs to provide a service to the SuD Such an actor is called a supporting actor
An actor can be the primary actor for one use case and the supporting actor for another
In general an actor is a role rather than a specific person, job title or thing, although incidentally it can be
The SuD is also an actor Not every stakeholder will directly interact with
the SuD and will show up as an actor
![Page 16: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/16.jpg)
Actors
An example might be the board of directors of the company or the Tax and Customs Administration, which also may require things from the system that must be taken into account
It is important to discover these “hidden” actors at an early stage as it may reveal requirements that may be missed otherwise
![Page 17: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/17.jpg)
Scenarios
The main part of a use case is its scenario A scenario describes a sequence of steps
that are executed in order to fulfill the goal the use case is supposed to deliver
For example, the scenario that describes how to get a parking ticket from a machine could look like this:
![Page 18: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/18.jpg)
Example Scenario
Buy Parking Ticket1. The Car Driver enters a coin in the Ticket Machine2. The Ticket Machine indicates until when the Car
Driver can park3. The Car Driver continues with step 1 and 2 until
satisfied4. The Car Driver presses the button to retrieve the
parking ticket5. The Ticket Machine prints the parking ticket
![Page 19: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/19.jpg)
Scenarios
The scenario must be easy to read Therefore you should avoid scenarios of
more than nine steps and you should always use the active voice, stating exactly who or what is doing what This includes the SuD itself
In the scenario above everything goes as planned, which therefore is called a main success scenario
But in many cases there are exceptions that require a deviation from the planned scenario
![Page 20: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/20.jpg)
Scenarios
In this example exceptions may consist of the Car Driver entering a coin of invalid currency or aborting the transaction
Exceptions are documented as extensions
![Page 21: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/21.jpg)
Extensions
An exception is documented by specifying an alternate route in the scenario, which is called an extension (related to, but not the same as an extension use case, which will be discussed later on)
Extensions can be added to the main success scenario as follows:
![Page 22: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/22.jpg)
Buy Parking Ticket
Main Success Scenario: 1. The Car Driver enters a coin in the Ticket Machine 2. The Ticket Machine validates the coin 3. The Ticket Machine indicates until when the Car Driver can
park 4. … Extensions: 2a Invalid coin: 2a1 The Ticket Machine returns an invalid coin 2a2 Return to step 1 3a Car Driver aborts transaction: 3a1 The Ticket Machine returns the coins that have been
entered 3a2 The scenario ends
![Page 23: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/23.jpg)
Extensions
There is no standard for the layout of a scenario, let alone how to add extensions
It is good practice to number the steps of the main scenario and to put the extensions after that instead of in between in order to keep the scenario readable
Number the extensions in such a way that it is clear at what step it exits from the main success scenario and what point it returns
For example, a third extension that also exits at step 2 would be numbered as 2b1, 2b2, etc.
![Page 24: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/24.jpg)
Use Case Properties
Although it is the core the scenario is not the only thing there is to say about a use case
Other aspects (or properties as you may call them) of a use case may consist of the following: Scope: the name of the (part of the) system the use case
belongs to Stakeholder: someone or something that has an interest in
the goal the use case delivers Primary Actor: the stakeholder who or which initiates the
use case to achieve a goal Brief Description: a brief description of the goal the use
case is supposed to deliver
![Page 25: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/25.jpg)
Use Case Properties
Level: at what level the use case has been written Preconditions: what conditions must be met before the
scenario can start Postconditions: what conditions must be met for a valid end
of the scenario, to be divided into minimal guarantee(s) and success guarantee(s)
Trigger: the event or sequence of events that initiate the use case
![Page 26: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/26.jpg)
Use Case Templates
There is also no standard that dictates what properties need to be included in a use case
What you need to write down for use cases depends on the situation, especially on who is writing it and for what purpose
For example, if an on-site team performs the requirements definition and analysis, while the design and implementation is done remotely, you need to be very explicit and you probably specify all these properties and even more
On the other hand, a small team that performs the requirements definition up to the implementation in one and the same room may suffice with specifying only a few properties, perhaps only the Brief Description
![Page 27: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/27.jpg)
Use Case Templates
Before you start your project you should decide upon templates that are going to be used
In practice it suffices to use two templates for each project
You use a simple one with only a few properties for use cases that do not need to be worked out in detail
You use a more extensive one that has all properties that are relevant, for the other use cases The first template is commonly called the Casual
version and the second one the Fully Dressed version. Review and modify the templates to fit the needs of your
project You may want to add properties like Brief Description,
Number, Priority or Status.
![Page 28: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/28.jpg)
www.oracle.com/.../use_case_model_1001.gif
![Page 29: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/29.jpg)
High-Level Example Scenario: ATM banking for the week. 1. Sally Jones places her bank card into the ATM. 2. Sally successfully logs into the ATM using her personal
identification number. 3. Sally deposits her weekly paycheck of $350 into her savings
account. 4. Sally pays her phone bill of $75, her electric bill of $145, her
cable bill of $55, and her water bill of $85 from her savings account
5. Sally attempts to withdraw $100 from her savings account for the weekend but discovers that she has insufficient funds
6. Sally withdraws $40 and gets her card back
![Page 30: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/30.jpg)
Detailed Example Scenario: A successful withdrawal attempt at
an automated teller machine (ATM) 1. John Smith presses the “Withdraw Funds” button 2. The ATM displays the preset withdrawal amounts ($20, $40, …) 3. John chooses the option to specify the amount of the withdrawal 4. The ATM displays an input field for the withdrawal amount 5. John indicates that he wishes to withdraw $50 dollars 6. The ATM displays a list of John’s accounts, a checking and two savings
accounts 7. John chooses his checking account 8. The ATM verifies that the amount may be withdrawn from his account 9. The ATM verifies that there is at least $50 available to be disbursed from the
machine 10. The ATM debits John’s account by $50 11. The ATM disburses $50 in cash 12. The ATM displays the “Do you wish to print a receipt” options 13. John indicates “Yes” 14. The ATM prints the receipt
![Page 31: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/31.jpg)
Scope and level
Use cases can be written for different purposes
They can be written to describe a business process, to describe the functional requirements of a system or to document the design of a system
Use cases can also be written at different levels of detail, from high to low level
![Page 32: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/32.jpg)
Design scope
The design scope of a use case can be the enterprise, a specific system or a subsystem
Use cases that are used to describe the business process are typically of scope “enterprise”
The design scope is not a specific property of a use case (thus not be confused with the “scope” property) but something you should consider carefully to make sure you understand what is inside and what is outside the boundary of the use case
![Page 33: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/33.jpg)
Design scope
Something that is essential for the use case but outside its boundary, must be covered either by another actor (which may be a supporting actor) or another use case
For instance, if some other system delivers data that is essential to the use case, you do not model how that system works but model it as an actor
![Page 34: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/34.jpg)
Business and system use cases Business people write Business uses cases that
have the business as subject and are used to document business processes
Software developers write System use cases that have the system as subject and describe how actors communicate with the system to achieve their goals. “Sell Books” will be a business use case, where “Browse Catalogue” will be a system use case
![Page 35: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/35.jpg)
Business and system use cases Business use cases are created by business
analysts and describe the business, whereas system use cases are created by developers and describe the system
Use cases can be of different level, from high-level Summary uses cases, through mid-level User Goal Use cases, to low-level Subsystem use cases.
![Page 36: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/36.jpg)
Pre-conditions and guarantees
You use Preconditions to specify the conditions that must hold true before the scenario of the use case starts and will not be checked again after that
Often a precondition indicates that some other use case has already run to set up the condition
Write preconditions as a set of assertions, for example “User is logged on”, “Credit Card has been validated” and so on. Consider putting preconditions that hold for multiple use cases, in a separate document
Instead of including the assertion in the use case, you then include a reference to the generic precondition
![Page 37: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/37.jpg)
Pre-conditions and guarantees With Minimal Guarantees you specify what, from the
viewpoint of the stakeholders, at least must hold true in case neither the main success scenario nor any alternate route has successfully finished
The most common Minimal Guarantee is “The System has logged how far it got”
Minimal Guarantees are written as a set of assertions that must be satisfied at the end of any path of the scenario, for example “All entered information must have been stored”
![Page 38: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/38.jpg)
Pre-conditions and guarantees With Success Guarantees you specify what must
have been achieved at the end of the main success scenario or any alternate route
Success Guarantees are also written as a set of assertions that describe what would satisfy any of the interests of the stakeholders
These assertions add to the Minimal Guarantees Mind that Preconditions and Guarantees may be
related to, but are not the same as business rules.
![Page 39: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/39.jpg)
Use case diagrams
A use case diagram provides an index to use cases
The following gives an overview of the conventions you should apply when drawing use case diagrams
![Page 40: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/40.jpg)
Actors and use case diagrams In a diagram you include actors as people-like
figures and use cases as ellipses and draw lines that indicate the relationships, or communications between them
It is custom to draw the primary actor and other stakeholders that communicate with the use case to the left and secondary actors to the right
Put the primary actor at the top, as in the following example
![Page 41: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/41.jpg)
Actors, use cases and communications
![Page 42: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/42.jpg)
Use case inclusion
A use case inclusion is another way to say that one use case calls the other
Higher-level use cases may call lower-level use cases (that is: require the behavior of lower-level use cases). the higher-level use case includes the lower-level one, hence the
term “inclusion”. A typical example is a Summary use case that includes User
Goal use cases Another typical example is a User Goal use case that includes
some reusable Subfunction use case, like “Log On” If you want to express this in the scenario of the Summary use
case, you underline the name of the lower-level use case, as in the following example:
![Page 43: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/43.jpg)
Use case inclusion
Log Ticket Main Success Scenario: 1. The Helpdesk Employee Finds Customer
using its name or address 2. The Helpdesk Employee enters the details
of the Ticket 3. …
![Page 44: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/44.jpg)
Use case inclusion
An inclusion is drawn as a dashed arrow from the higher-level to the lower-level use case
The lower-level use case should also be drawn lower to emphasize it is at a lower level
![Page 45: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/45.jpg)
Use case inclusion
![Page 46: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/46.jpg)
Use case extensions Recall that earlier on an extension has been defined as alternate
route to the main success scenario In general an extension use case is an extension of a main success
scenario that has been moved out of the originating use case into a use case of its own
The point at which it exists the originating use case is called an extension point like the point at which it returns is called the return point.
When moving out the extension, the exception to the main success scenario becomes the trigger of the extension use case
In the extension use case you refer to the originating use case by underlining its name, but not visa versa.
Suppose you would like to model the fact that a Car Driver can abort buying a parking ticket using an extension use case
The scenario of the originating use case does not change except for the fact that the alternate scenario is cut out of the extension part
The extension use case may look as follows:
![Page 47: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/47.jpg)
Use case extensions
Abort Transaction Trigger: any time in Buy Ticket the Car Driver
can abort the transaction Main Success Scenario 1. The Ticket Machine returns the coins that
have been entered
![Page 48: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/48.jpg)
Use case extensions
An extension is drawn using a dashed arrow from the extension use case to the originating one
The extension use case should be drawn lower than the originating use case, emphasizing that it is at a lower level
![Page 49: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/49.jpg)
Use case extensions
![Page 50: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/50.jpg)
Use case extensions
An extension to the main success scenario can be moved out to an extension use case, to prevent the use case from becoming too complex
Other reasons to create extension uses cases can be to add to fixed requirements or when a different development team implements the extension
![Page 51: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/51.jpg)
Use case extensions
There are a few situations in which you create extension use cases, being: To leave details out of the originating use case that
otherwise would clutter its scenario As a way to add to requirements that are fixed and you are
not allowed to change the originating use case When the extension concerns an isolated piece of
functionality that may be implemented by a different team In this case you may want to be able to estimate both use
cases separately
![Page 52: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/52.jpg)
Generalized Use Cases
You can also generalize use cases When use case A specializes use case B (or B
generalizes A) you express that A is “a kind of” B, implying that whatever applies to B also applies to A
A adds to or may override behavior of B Use case generalizations are drawn by drawing an
open arrow from the specialized use cases to the general one
The specialized use cases are drawn below the general one
![Page 53: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/53.jpg)
Generalized Use Cases
![Page 54: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/54.jpg)
Reading use cases
It is imperative that use cases are easy to read, while specializing some generic scenario is conceptually a difficult thing to understand
In practice you probably are best off by leaving the scenario of the generic use case empty and using generalization only to share common stakeholders, triggers, conditions or other properties between specialized use cases
However, the larger the system, the more advantageous using the mechanism of generalizing use cases may become
Actors can be specialized too, but that may also introduce confusion and should be done scarcely
There are not that many properties to share between actors anyway
![Page 55: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/55.jpg)
Organizing use cases
When there are more than just a few, organizing use cases becomes imperative for several reasons, among them to be able to find them back
As applies to many things giving a use case a proper name is a good start
A good name generally has the form “Do Something” (active verb phrase) and expresses the goal of the primary actor as clear as possible
Another good thing to do is to number the use cases In most situations a generic, hierarchical numbering will suit best For example, when the summary use case has number 1, use
cases that detail this are numbered as 1.1, 1.2 and so on.
![Page 56: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/56.jpg)
Use case organization
There are a couple of alternatives to organize use cases: By primary actor By summary use case By development team and release By subject area Combinations of the above
![Page 57: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/57.jpg)
Use case organization
Give use cases a name that expresses the goal clearly and number them
Use cases can be organized by primary actor, Summary use case, development team and release, or subject area
![Page 58: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/58.jpg)
Writing in iterations
Use cases are written in iterations A good way to start is with identifying all actors and their goals
consider setting it up as an Actor-Goal List that lists all actors with their named goals, a brief description of each goal and the priority it has
Actor-Goals List starts with naming the actors with their goals When you have the feeling the list is pretty complete, you start
adding Brief Descriptions You may find new goals and actors when doing so After the Actor-Goal List is verified and complete, it can be
prioritized Keep in mind that the priority of each goal should have been
determined by the customer
![Page 59: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/59.jpg)
Writing in iterations The next step is to create initial use cases out of the Actor-
Goal List Many of the goals be User Goal level use cases In many cases you can use the goal as name for the use case
and copy the Brief Description After that you write the main success scenario for all use cases Next you identify the exceptions there may be to the main
success scenario of each use case and you write extension to that
It is very important to work out these exceptions, as new actors, classes and business rules may be discovered
MoSCoW stands for Must Have, Should Have, Could Have and Won’t Have and is used to prioritize functionality You can find more about MoSCoW at
http://na.dsdm.org/en/about/moscow.asp.
![Page 60: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/60.jpg)
Use case recipe
The short recipe for creating use cases is as follows: 1. Identify the actors 2. List their goals 3. Add brief descriptions to the goals 4. Create an initial use case for each goal 5. Describe the main success scenario for each use case 6. Identify the exceptions to the main success scenarios and
work them out as extensions 7. Validate the use cases 8. Optimize the use cases
![Page 61: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/61.jpg)
“This is not a use case”
![Page 62: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/62.jpg)
RequirementsEngineering
Southern Methodist University
CSE 7316 – Step by step examples
![Page 63: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/63.jpg)
A use case tells a story of reaching a goal,or a set of stories of both getting and failing.
UC 4: “Place an order”“ 1. The clerk identifies the customer, each item and
quantity. 2. System accepts and queues the order.”
Extensions:“1a. Low credit: Clerk takes prepayment”“2a. Low on stock: Customer accepts reduced...”
Alistair Cockburn www.usecases.org
![Page 64: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/64.jpg)
Examining the Goals the system supports makes good functional requirements.
“Place an order.” “Get money from my bank account.”“Get a quote.”“Find the most attractive alternative.”“Set up an advertising program.”
Goals summarize system function in understandable, verifiable terms of use.
Alistair Cockburn www.usecases.org
![Page 65: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/65.jpg)
The use case pulls goal & scenarios together, Each scenario says how a condition unfolds.
The use case name is the goal statement:“ Order product from catalog”
Scenario (1): Everything works out well ...Scenario (2): Insufficient credit ...Scenario (3): Product out of stock ...
Use case is goal statement plus the scenarios.
(Note the grammar: active verb first)
Alistair Cockburn www.usecases.org
![Page 66: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/66.jpg)
How to do it:(1). Identify the actors and their goals.
What computers, subsystems and people will drive our system? An “actor” is anything with behavior.
What does each actor need our system to do? Each need shows up as a trigger to our system.
Result: a list of use cases, a sketch of the system. Short, fairly complete list of usable system function.
Alistair Cockburn www.usecases.org
![Page 67: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/67.jpg)
How to do it: For each use case...(2). Write the simple case: goal delivers.
The main success scenario, the happy day case. Easiest to read and understand. Everything else is a complication on this.
Capture each actor’s intent and responsibility, from trigger to goal delivery. Say what information passes between them. Number each line.
Result: readable description of system’s function.
Alistair Cockburn www.usecases.org
![Page 68: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/68.jpg)
How to do it:(3). Write failure conditions as extensions.
Usually, each step can fail. Note the failure condition separately, after the
main success scenario. Result: list of alternate scenarios.
Alistair Cockburn www.usecases.org
![Page 69: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/69.jpg)
How to do it: For each failure condition,(4). Follow the failure till it ends or rejoins.
Recoverable extensions rejoin main course. Non-recoverable extensions fail directly. Each scenario goes from trigger to
completion. “Extensions” are merely a writing shorthand. Can write “if” statements. Can write each scenario from beginning to end.
Result: Complete use case
Alistair Cockburn www.usecases.org
![Page 70: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/70.jpg)
How to do it:(5). Note the data variations.
Some extensions are too low-level to cover “here”. e.g. “Reimburse customer” Reimburse by cash, check, EFT, or purchase
credit? Deferred variations note cases that must be handled
eventually, by lower-level use cases. Useful for tracking requirements at high level.
Result: Feed-forward information, rolled up into an easy-to-track format.
Alistair Cockburn www.usecases.org
![Page 71: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/71.jpg)
The value of failure scenarios is detecting unusual situations, completeness
“What if their credit is too low?” “What if they run over the extended credit limit?” “What if we cannot deliver the quantity?” “What if data is corrupt in the database?”
(These are commonly overlooked situations)
Alistair Cockburn www.usecases.org
![Page 72: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/72.jpg)
Both recoverable and non-recoverable failures are part of requirements.
Ideal situation (s1):Good credit, items in stock -> accept order.
Recoverable situation (s2, s3):Low credit -> valued customer? -> accept.Low stock -> reduce quantity? -> accept.
Unrecoverable situations (s4, s5):Not a valued customer -> decline orderOut of stock -> decline order
Alistair Cockburn www.usecases.org
![Page 73: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/73.jpg)
Write the recoverable and failure scenarios as “extensions” to the ideal one.
UC 4: “Place an order”
“ 1. Clerk identifies the customer, each item and quantity.
2. System accepts and queues the order.”
Extensions:
“1a. Low credit: Customer is ‘Preferred’...”
“1b. Low credit & not Preferred customer: ...”
“2a. Low on stock: Customer accepts reduced...”
Alistair Cockburn www.usecases.org
![Page 74: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/74.jpg)
A scenario refers to lower-level goals: subordinate use cases or common functions.
UC 4: “Place an Order”1. Identify customer (UC 41) 2. ...
UC 41: “Identify Customer” 1. Operator enters name. 2. System finds near
matches. Extensions:
2a. No match found: ...
Alistair Cockburn www.usecases.org
![Page 75: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/75.jpg)
The outer use case only cares if the inner one succeeds, avoiding proliferation.
UC 4: “Place an Order”
1. Identify customer (assumes success)
2. ...
Extensions:
1a. Customer not found: (does not care why
it failed, only if it
is recoverable)
Alistair Cockburn www.usecases.org
![Page 76: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/76.jpg)
Every sentence at every level is a goal.Use cases are one sentence style repeated.
Goal: “Customer places an order.”
how why
Step: “Customer prepays for the order.”
how why
Substep: “Customer gives credit card number.”
Alistair Cockburn www.usecases.org
![Page 77: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/77.jpg)
Visit http://alistair.cockburn.us/Use+cases to read more on use cases.
1. Use cases hold functional requirements in an easy-to-read, easy-to-track, text format.
2. A use case collects how 1 goal succeeds or fails; a scenario shows one specific condition; scenarios / use cases nest inside each other.
3. Use cases show only the Functional req’ts.
4. They make a framework for non-functional requirements & project details.
5. Design is not done only in use case increments.
Alistair Cockburn www.usecases.org
![Page 78: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/78.jpg)
Example: Buy Product
The customer browses the catalog and adds desired items to the shopping basket. When the customer wishes to pay, the customer describes the shipping and credit card information and confirms the sale. The system checks authorization on the credit card and confirms the sale both immediately and with a follow-up email.
[ Fowler p.39]
![Page 79: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/79.jpg)
Example Use Case Text
UC 1: Buy a Product [ Fowler p.40]1. Customer browses through the catalog and selects items to buy2. Customer goes to check out3. Customer fills in shipping information (address, next-day or 3-day)4. System presents full pricing information, including shipping5. Customer fills in credit card information6. System authorized purchase7. System confirms sale immediately8. System send confirming emailExtension: Authorization Failure6a. System fails to authorize credit purchase. Allow customer to re-enter credit card
information and retryExtension: Regular Customer3a. System displays current shipping information, pricing information, and last four
digits of credit card information3b. Customer may accept or override these defaults. Return to primary at step 6.
![Page 80: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/80.jpg)
Use Case Diagram
Place phonecall
Retrievevoice mail
Receivephone call
Cellularnetwork
UserCellular telephone
![Page 81: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/81.jpg)
Use Case Diagram
Trackorder
Checkpassword
Validateuser
User
Retinalscan
<<include>>
![Page 82: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/82.jpg)
Top 10 Mistakes to Avoid When Writing Use Cases
10. Write functional requirements instead of usage scenario text. 9. Describe attributes and methods rather than usage. 8. Write use cases too tersely. 7. Divorce yourself completely from the user interface. 6. Avoid explicit names for your boundary objects. 5. Write using a perspective other than the user’s, in a passive
voice. 4. Describe only user interactions; ignore system responses. 3. Omit text for alternative courses of action. 2. Focus on something other than what’s “inside” a user case,
such as how you get there or what happens afterwards. 1. Spends a month deciding whether to use include or extends.
[Rosenburg p. 60]
![Page 83: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/83.jpg)
RequirementsEngineering
Southern Methodist University
CSE 7316 – More on Use cases in Software Development
![Page 84: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/84.jpg)
Defining the boundaries of the system Use context diagramming to understand the
system boundaries Describe interactions between the system
and the environment Begin with system, then add users and other
systems Actor can represent one or more users
![Page 85: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/85.jpg)
Identifying use cases
Examine each actor with the purpose of identifying each interaction
For each user, identify a discrete use of the system Examine all incoming and outgoing messages for
each system that interacts with your system Examine periodic and timed events
![Page 86: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/86.jpg)
![Page 87: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/87.jpg)
![Page 88: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/88.jpg)
88Spring 2005Specification and Analysis of Information Systems
Based on Eran Toch
http://www.technion.ac.il/~erant
Specifying Requirementswith Use Case Diagrams
![Page 89: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/89.jpg)
89
Outline
• Introduction
• Use Case Diagrams
• Writing Use Cases
• Guidelines for Effective Use Cases
![Page 90: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/90.jpg)
90
Illustration
Use Cases
• A use case is a contract of an interaction between the system and an actor.
• A full use-case model comprise of:– A diagram, describing relations between use-cases and
actors.– A document describing the use case in details
Register User
Use case in diagram Use Case in script
admin
Introduction | Diagrams | Writing | Guidelines
![Page 91: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/91.jpg)
91
Models: OO - Use Case DefinitionModels: OO - Use Case Definition
• Describes “what” (not “how”) the system will do at a high-level
• Has a user focus for the purpose of scoping the project and giving the application some structure
• Scenarios that identify a particular thread of system usage -- a written narrative
• Shifts the perspective to what users need to accomplish (in contrast to what users want the system to do)
• A discrete, stand-alone activity that an actor can perform to achieve some outcome of value.
![Page 92: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/92.jpg)
92
Models: OO - Use Case Definition, con’tModels: OO - Use Case Definition, con’t
• Use cases capture functional requirements of a system from the perspectives of the different users of the system
• Use cases are textual narratives describing the different kinds of scenarios in which the system will be used
• Use case diagrams help to visualize which actors are involved in which scenarios
• The functional requirements described in use cases will be realized by collaborations of objects in the design
• Non-functional (or qualitative) requirements are not depicted with use cases
![Page 93: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/93.jpg)
93
Models: OO - Use Case Definition, con’tModels: OO - Use Case Definition, con’t
A use case is a scenario that describes how software is to be used in a given situation
A use case is defined from an “actors” perspective
An actor is a role played by a person or device as it interacts with the software
An actor is anything that communicates with the system and that is external to the system itself
By creating use cases, you keep the focus of development on the user and the user’s perception of the system
A non-trivial system will often have many actors, each involved in multiple scenarios
![Page 94: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/94.jpg)
94
Models: OO Use CasesModels: OO Use CasesIdentifying Use CasesIdentifying Use Cases
The first step in identifying use cases is to identify the different people or devices that will interact with the product
Consider what each actor hopes to accomplish by using the product
This can lead to the discovery of new requirements
There can be overlap, in that different actors may expect to use the same system facilities
Be consistent
Look for opportunities to represent two similar scenarios with a more general one
![Page 95: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/95.jpg)
95
Models: OO Use CaseModels: OO Use CaseQuestions Answered by a Use CaseQuestions Answered by a Use Case
What main tasks or functions are performed by the actor?
What system information will the actor acquire, produce, or change?
Will the actor have to inform the system about changes in the external environment?
What information does the actor desire from the system?
Does the actor wish to be informed about unexpected changes?
![Page 96: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/96.jpg)
96
Use Case Diagram Objective
1. Create a semi-formal model of the functional requirements
2. Analyze and define:– Scope– External interfaces– Scenarios and reactions
Introduction | Diagrams | Writing | Guidelines
![Page 97: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/97.jpg)
97
What Makes Good Use-Case Specification?
• Lack of ambiguity– Each requirement must be interpreted in a single manner.
• Completeness– They should cater for all current demands of the system.
• Consistency– Requirements should not conflict with each other. If there
are, tradeoffs must be detected and discussed.
• Avoid design– Requirements should raise a need, not answer it. (Why?)
Introduction | Diagrams | Writing | Guidelines
![Page 98: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/98.jpg)
98
Outline
• Introduction
• Use Case Diagrams
• Writing Use Cases
• Guidelines for Effective Use Cases
![Page 99: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/99.jpg)
99
Example
A Simple Example
Handle Message
Cellular Phone
Customer
Bill Management
Handle CallExternal Phone
Company
ActorsUse CaseSystem
boundary
Introduction | Diagrams | Writing | Guidelines
Association
![Page 100: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/100.jpg)
100
Models: OO Use Case - ComponentsModels: OO Use Case - Components
• Actor– Outside the system model; but interacts
– Person, machine, information system . . .
• Use Case– Narrative text describing the sequence of events of an actor, using a
system
– “stories”
– Static model of functionality
• Use Case Diagram– What happens when an actor interacts with a system
– Represents a function that makes sense t an actor
– Actor initiates interactions with the system; and vice-versa
– No temporal sequencing
![Page 101: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/101.jpg)
101
Models: OO - Syntax for Use CasesModels: OO - Syntax for Use Cases
Library Customer
An actor is represented by a stick figurewith a label. The label describes the role of that actor
An actor is represented by a stick figurewith a label. The label describes the role of that actor
Borrow Book
A use case is represented by an oval. The name of the use case is provided inside the oval
A use case is represented by an oval. The name of the use case is provided inside the oval
![Page 102: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/102.jpg)
102
Use Case: Steps in CreatingUse Case: Steps in Creating
1. Identify who will use the system directly1. Identify who will use the system directly
2. Pick one of those actors2. Pick one of those actors
3. Define what the Actor wants to do with the system -- this becomes a Use Case
3. Define what the Actor wants to do with the system -- this becomes a Use Case
4. For each Use Case, determine what happens4. For each Use Case, determine what happens
5. Describe the “basic course”5. Describe the “basic course”
6. Consider alternatives6. Consider alternatives
7. Review for commonality7. Review for commonality
8. Repeat Steps 2 - 7 for each Actor8. Repeat Steps 2 - 7 for each Actor
![Page 103: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/103.jpg)
103
Models: Use Case - ActorsModels: Use Case - Actors
The ActorsWhat types of actors do you have in the factory control system?• You have two types of actorsThe failure monitors that inform the system of machine failures areactorsThe operators that oversee individual machines are actors• Note that factory machines are not (yet) actorsThe initial version of this application will not interact directly withfactory machines(Future versions will interact directly with machines)
The ActorsWhat types of actors do you have in the factory control system?• You have two types of actorsThe failure monitors that inform the system of machine failures areactorsThe operators that oversee individual machines are actors• Note that factory machines are not (yet) actorsThe initial version of this application will not interact directly withfactory machines(Future versions will interact directly with machines)
![Page 104: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/104.jpg)
104
Finding Actors
• External objects that produce/consume data:– Must serve as sources and destinations for data– Must be external to the system
Humans MachinesExternal systems Sensors
Database PrinterOrganizational Units
Introduction | Diagrams | Writing | Guidelines
![Page 105: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/105.jpg)
105
Example
Actors can be generalized
The child actor inherits all use-cases associations
Introduction | Diagrams | Writing | Guidelines
Should be used if (and only if), the specific actor has more responsibility than the generalized one (i.e., associated with more use-cases)
Register Client
Sales Person
Institutional Sales Person
Perform Sale
Perform Business Sale
Sales Manager
Cancel Sale
![Page 106: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/106.jpg)
106
Models: Use CasesModels: Use Cases
What use cases do you have in the factory control system?
• A failure monitor initiates one interaction with the system?It informs the system that a machine failure has occurred(The system in turn informs the operator that the machine’s state isnow unscheduled maintenance)
• The system initiates no interactions with a failure monitorThe system need not reset or otherwise interact with a failure Monitor
• An operator initiates one interaction with the systemAn operator asks the system to change a machine’s state(Changing a machine’s state to scheduled maintenance alsorequires recording today as the date of last maintenance)
• The system initiates four interactions with an operatorIt informs the operator that a machine has failed (noted above)It informs the operator that a running machine is now waitingIt informs the operator that a waiting machine is now runningIt informs the operator that scheduled maintenance on a machine is due
What use cases do you have in the factory control system?
• A failure monitor initiates one interaction with the system?It informs the system that a machine failure has occurred(The system in turn informs the operator that the machine’s state isnow unscheduled maintenance)
• The system initiates no interactions with a failure monitorThe system need not reset or otherwise interact with a failure Monitor
• An operator initiates one interaction with the systemAn operator asks the system to change a machine’s state(Changing a machine’s state to scheduled maintenance alsorequires recording today as the date of last maintenance)
• The system initiates four interactions with an operatorIt informs the operator that a machine has failed (noted above)It informs the operator that a running machine is now waitingIt informs the operator that a waiting machine is now runningIt informs the operator that scheduled maintenance on a machine is due
![Page 107: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/107.jpg)
107
Models: Use Cases - Models: Use Cases - Example Factory Control SystemExample Factory Control System
![Page 108: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/108.jpg)
108
Models: Use Case ScenarioModels: Use Case ScenarioA scenario is a use case instance
• It contains the same steps as does the use caseA scenario typically describes just one execution path (one outcome) through the use case
• It describes a sequence of actions and interactions of objects
The objects in the scenario are from the classes in the use caseE.g., a particular set of objects acting to cancel a catalog order
• The notation for a scenario is an interaction diagramIt may be either a sequence diagram or a collaboration diagramWe will discuss only sequence diagrams in this session
A scenario is a use case instance
• It contains the same steps as does the use caseA scenario typically describes just one execution path (one outcome) through the use case
• It describes a sequence of actions and interactions of objects
The objects in the scenario are from the classes in the use caseE.g., a particular set of objects acting to cancel a catalog order
• The notation for a scenario is an interaction diagramIt may be either a sequence diagram or a collaboration diagramWe will discuss only sequence diagrams in this session
![Page 109: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/109.jpg)
109
Models: Use Case-Models: Use Case-Railway ExampleRailway Example
ARRSSystem Administrator Use Cases
System Administrator
Sign InSign Out
Create User Accounts
Modify User Accounts
Activate/DeactiveUser Accounts
Create Roles
Delete User Accounts
Delete RolesManage Security
![Page 110: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/110.jpg)
110
ARRSTrain Conductor Use Cases
Train Conductor
Sign In
Sign Out
Passenger ListReport
Print StandingTickets
Inout TicketStub Info
Models: Use Case-Models: Use Case-Railway ExampleRailway Example
![Page 111: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/111.jpg)
111
Models: Use Case - Models: Use Case - Elevator ExampleElevator Example
1. Passenger pressed floor button
2. Elevator system detects floor button pressed
3. Elevator moves to the floor
4. Elevator doors open5. Passenger gets in and
presses elevator button6. Elevator doors closes7. Elevator moves to
required floor8. Elevator doors open9. Passenger gets out10.Elevator doors closes
![Page 112: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/112.jpg)
112
Models: Use Case ExampleModels: Use Case Example
Trading Manager
Trader
Salesperson
Accounting System
Set Limits
Analyze Risk
Price Deal
Capture Deal
Valuation
Update Accounts
Limits Exceeded
ĒincludeČ
ĒincludeČ
UML Distilled, Fowler, Martin and Kendall Scott, Second Edition, Addison-Wesley, 2000page 42.
UML Distilled, Fowler, Martin and Kendall Scott, Second Edition, Addison-Wesley, 2000page 42.
![Page 113: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/113.jpg)
113
Linking Use-Cases
• Linking enables flexibility in requirements specification– Isolating functionality– Enabling functionality sharing – Breaking functionality into manageable chunks
• Three mechanism are used:– Include– Extend– Inheritance
Introduction | Diagrams | Writing | Guidelines
![Page 114: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/114.jpg)
114
Use-Case Levels
User goals
Perform Sale
Choose Products
Fill-in billing info
Sub-functionality
Introduction | Diagrams | Writing | Guidelines
Base Use Case: Used directly by the user
Alistair Cockburn “Writing Effective Use Cases”
![Page 115: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/115.jpg)
115
The “Include” Construct
• Include is used when:– Decomposing complicated behavior– Centralizing common behavior
• The base use case explicitly incorporates the behavior of another use case at a location specified in the base.
Introduction | Diagrams | Writing | Guidelines
Perform Sale
Fill-in billing info
<<include>>
Example
![Page 116: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/116.jpg)
116
Extend – Graphical Representation
• The base use case can incorporate another use case at certain points, called extension points.
• Note the direction of the arrow– The base use-case does not know which use-case
extends it
Introduction | Diagrams | Writing | Guidelines
Perform SaleAfter checkout
Gift wrap Products
<<extend>>Product is a gift
Example
![Page 117: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/117.jpg)
117
Example: Amazon
Product Page
Review Writing
Shopping Cart
Introduction | Diagrams | Writing | Guidelines
![Page 118: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/118.jpg)
118
Example – cont’d
Introduction | Diagrams | Writing | Guidelines
Search Product
Navigate Deals
Checkout
Handle Order Status
Login Register
View Product Details Write
Review
Rank Supplier«include»
«include»
«include»
«include»
«extend»user is not a member
«extend»
«extend»
After page generation
Add to cart
«extend»
Customer
![Page 119: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/119.jpg)
119
Generalization between Use-Cases
• The child use case inherits the behavior parent use case:– The interaction (described in the textual description)– Use case links (associations, include, extend, generalization)
• Child use-case can substitute parent Use case
• Overriding occurs through the textual description
Introduction | Diagrams | Writing | Guidelines
Example
Handle Sale Call
Customer Representative
Tech Assistant Representative
Handle Call
Handle Technical Assistance Call
1. Transfer call to available representative2. Mark representative as busy3. Start record call4. Stop record call 5. Log call details6. Mark representative as free
![Page 120: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/120.jpg)
120
Generalization Hazards
• Combining generalizations of actors and use-cases can be dangerous
Undergrad Student
Graduate Student
Submit Exam
Submit Thesis
Undergrad Student
Graduate Student
Submit and Get Grade
Submit Thesis
Submit Exam
Bad: Undergrad can submit thesis
Good: Only graduate student can submit thesis
Introduction | Diagrams | Writing | Guidelines
![Page 121: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/121.jpg)
121
Example: Phone Company Operational System
The Cellular Phone
Who are the actors?
External Phone companies
Orange’s objective: Build a system that handles SMS messages, handles calls (for 2 and 3 generation phones), including conference calls and multiple calls from a single phone. The system must support users on the move.
Introduction | Diagrams | Writing | Guidelines
![Page 122: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/122.jpg)
122
Example: Cell Company System
Introduction | Diagrams | Writing | Guidelines
3G Phone
Handle SMS Message
Cellular Phone
while talking
Handle Call
External PhoneCompany
Handle Video Call
Handle Cell Migration
<<include>> <<include>>
Handle Multiple Calls
Handle Conference Call
<<extend>>{incoming call}
<<extend>>{phone initiate call}
Handle Voice Call
![Page 123: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/123.jpg)
123
Outline
• Introduction
• Use Case Diagrams
• Writing Use Cases
• Guidelines for Effective Use Cases
![Page 124: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/124.jpg)
124
Structure of a Use Case Specification
Name
Actors
Preconditions
Post conditions
Success Scenario
Alternatives flows
Introduction | Diagrams | Writing | Guidelines
Alistair Cockburn “Writing Effective Use Cases”
Trigger
![Page 125: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/125.jpg)
125
Triggers
• What starts the use-case?
• Examples:– Customer reports a claim– Customer inserts card– System clock is 10:00
Introduction | Diagrams | Writing | Guidelines
![Page 126: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/126.jpg)
126
Preconditions
• What the system needs to be true before running the use-case.
• Examples– User account exists– User has enough money in her account– There is enough disk space
Introduction | Diagrams | Writing | Guidelines
![Page 127: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/127.jpg)
127
Post-Conditions
• A post-condition is the outcome of the use-case.• Examples
– Money was transferred to the user account– User is logged in– The file is saved to the hard-disk
• Minimal guarantee– The minimal things a system can promise, holding even when
the use case execution ended in failure– Examples: Money is not transferred unless authorization is
granted by the user
• Success guarantee– What happens after a successful conclusion of the use-case.– Examples: The file is saved; Money is transferred
Introduction | Diagrams | Writing | Guidelines
![Page 128: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/128.jpg)
128
Success Scenario
• The success scenario is the main story-line of the use-case
• It is written under the assumption that everything is okay, no errors or problems occur, and it leads directly to the desired outcome of the use-case
• It is composed of a sequence of action steps • Example:
1. Administrator enters course name, code and description
2. System validates course code
3. System adds the course to the db and shows a confirmation message
Interaction step
Validation Step
Internal Change Step
(plus) Interaction Step
Introduction | Diagrams | Writing | Guidelines
![Page 129: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/129.jpg)
129
Guidelines for Effective Writing
• Use simple grammar
• Only one side (system or actor) is doing something in a single step
• Write from an “objective” point of view– Bad: “Get the amount from the user
and give him the money”
• Any step should lead to some progress– Bad: “User click the enter key”
System Actor
Actor asks for money
System asks for amount
Actor gives the amount
System produce the money
Introduction | Diagrams | Writing | Guidelines
![Page 130: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/130.jpg)
130
Steps – cont’d
• Branches:– If the user has more than 10000$ in her account, the system
presents a list of commercials– Otherwise…
• Repeats:1. User enters the name of the item he wishes to buy
2. System presents the items
3. User selects items to buy
4. Systems adds the item to the shopping cart
5. User repeats steps 1-4 until indicating he is done
Introduction | Diagrams | Writing | Guidelines
![Page 131: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/131.jpg)
131
Use-Cases – Common Mistakes
• Complex diagram
• No system
• No actor
• Too many user interface details– “User types ID and password, clicks OK or hits Enter”
• Very low goal details– User provides name– User provides address– User provides telephone number– …
Introduction | Diagrams | Writing | Guidelines
![Page 132: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/132.jpg)
132
Alternative Flows
Success Scenario
ShortcutsExceptions
Endpoints
• Used to describe exceptional functionality
• Examples:– Errors– Unusual or rare
cases– Failures– Starting points– Endpoints– Shortcuts
Starting points
Introduction | Diagrams | Writing | Guidelines
![Page 133: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/133.jpg)
133
Alternative Flows - Example
• Errors:– “Case did not eject properly”– “Any network error occurred during steps 4-7”– “Any type of error occurred”
• Unusual or rare cases– “Credit card is defined as stolen”– “User selects to add a new word to the dictionary”
• Endpoints– “The system detects no more open issues”
• Shortcuts:– “The user can leave the use-case by clicking on the “esc” key
Introduction | Diagrams | Writing | Guidelines
![Page 134: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/134.jpg)
134
Writing Include
• If a base use-case include another use-case, we will add a reference as a step:1. System presents homepage
2. User performs login to the systemOR
<include: login to the system>
Introduction | Diagrams | Writing | Guidelines
![Page 135: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/135.jpg)
135
Writing Extend
• Scenarios do not include direct references
• Instead, they include extension points, such as:User enters search string
System presents search results
Extension point: results presentations
OR
<extension point: results presentations>
• The extension use-case includes conditions in which the extension is being committed– Example: if the user belongs to the “rich clients” group– If more than two commercials were found
Introduction | Diagrams | Writing | Guidelines
![Page 136: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/136.jpg)
136
Outline
• Introduction
• Use Case Diagrams
• Writing Use Cases
• Guidelines for Effective Use Cases
![Page 137: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/137.jpg)
137
How to Model?
saveBullets format
loadSave
as
preview
File action
s
Formatting actions
Viewing Actions
Font forma
t
Paragraph format
Bottom-up Process Top-down Process
Starting with throwing all scenarios on the page, and then combining them:
Starting with an overview ofthe system, and then splittingUse-cases
![Page 138: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/138.jpg)
138
How to Model – cont’d
• Most of the analysis process are actually
Combined
![Page 139: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/139.jpg)
139
Combining Processes
• Number Limit:– The diagram should have between 3 to 10 base use-case. No
more than 15 use cases (base + included + extending).
• Abstraction:– All use-cases should be in similar abstraction levels.
• Size:– Use cases should be described in half a page or more.
• Interaction: – Use-cases which are carried out as part of the same interaction.
UCUC UC
Introduction | Diagrams | Writing | Guidelines
![Page 140: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/140.jpg)
140
Dividing Processes
• Size:– If a use-cases takes more than a page, consider
include/extend
• Weak dependency:– If the dependency between two parts of a use-case is weak,
they should be divided.
UC
Introduction | Diagrams | Writing | Guidelines
![Page 141: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/141.jpg)
141
More Guidelines
• Factor out common usages that are required by multiple use cases– If the usage is required use <<include>>– If the base use case is complete and the usage may be
optional, consider use <<extend>>
• A use case diagram should:– contain only use cases at the same level of abstraction– include only actors who are required
Introduction | Diagrams | Writing | Guidelines
![Page 142: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/142.jpg)
142
Scope
• A good way to decide on the scope is by in/out lists:
Alistair Cockburn “Writing Effective Use Cases”
Topic In Out
Any non-software parts of the system Statistical analysis of logs Interfacing with credit card systems Database cleaning processes Backup of logs …
Introduction | Diagrams | Writing | Guidelines
![Page 143: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/143.jpg)
143
When Are we Done?
• When every actor is specified.
• When every functional requirement has a use-case which satisfies it.
• A tractability matrix can help us determine it:
Use Cases
Requirements
Introduction | Diagrams | Writing | Guidelines
![Page 144: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/144.jpg)
144
Moving on
• Data entering and exiting the system is represented by data entities in structural diagrams.
• Behavior induced by use cases can be captured in behavioral diagrams.
Class AClass C
Class B
Class D
Use Case 1
Use Case 2Use Case 3
Introduction | Diagrams | Writing | Guidelines
![Page 145: Requirements Engineering Southern Methodist University, CSE 7316 – Use cases](https://reader035.vdocument.in/reader035/viewer/2022062304/56649f055503460f94c19a59/html5/thumbnails/145.jpg)
145
Summary
Introduction to the Unified Modeling Language (UML)
To Use Case Diagram
Use Case DiagramsDual presentation of use-cases
Include, Extend, Inheritance
Writing Use CasesPreconditions & Post-conditions
Main scenario vs. Alternative Flow
Guidelines for Effective Use Cases