Question: What is the difference between a Primary and Secondary Actor in Use Case Modeling?

Use Case modeling is used to diagrammatically depict a system and those people or processes that interact with it.
This system can be a business system (a process) or an application system (computer or web based). To understand
the scope of the system under consideration a system boundary is used. Anything depicted within the system
boundary is part of the system under consideration, while anything outside of it is not. Use cases are then used to
define a group of user-system interactions that together deliver value to the user of the system. These users are
called actors.

Primary actors are people, or at times even other systems, that require the assistance of the system under
consideration to achieve their goal. They initiate the use cases of the system (business processes or application
functionality). A use case within the system may have more than one primary actor, since more than one type of role
may initiate the processes or functionality of the system.

The system, and its use cases, often relies on other people, business processes, or applications in order to obtain a
result or specific information required to achieve its goal. These are called Secondary Actors. A secondary actor is
one from which the system requires assistance to complete the use case. A secondary actor never initiates the use
case. It is invoked by the system’s use cases in order to obtain information or a result. There may also be many
secondary actors of a system.

Question: What is the difference between a use case alternative flow and an exception flow?

A use case specification describes the functionality of a system in terms of a sequence of user-system
interactions. The main flow of events describes a single path through the system. It represents the
most common way that the use case plays out successfully and contains the most popular sequence of
user-system interactions. Other scenarios or paths through the system are described in alternative
flows and exception flows. So what is the difference?

First, it’s worth saying that there are a number of opinions in this area since the Unified Modeling
Language has no standard for Use Case Specifications. Some authors mention only alternative flows
and use them for both optional flows and error flows. However, of those authors that do differentiate
between alternative flows and exception flows some agreement in definition has emerged.

An alternate flow describes a scenario other than the basic flow that results in a user completing his or
her goal. It is often considered to be an optional flow and implies that the user has chosen to take an
alternative path through the system. An exception flow is an unintended path through the system
usually as a result of missing information or system availability problems. Exception flows represent an
undesirable path to the user. However, even though the exception flow has occurred the system will
ideally react in a way that recovers the flow and provide some useful information to the user.

The primary benefit of differentiating between alternative flows and exception flows is the focus that
exception flows bring to error conditions. By capturing all of the ways that the system can fail or
produce an error, the business analyst can be sure to create a design which mitigates the impact of the
error.

Question: What are some of the limitations of use cases and use case specifications?

Use cases are a valuable tool available to the business analyst for documenting functional requirements of a system
or business, however they do have limitations.

 Use cases were not created to capture non-functional requirements (e.g performance, platform, scalability,
reliability of a system). While use case specification templates have been extended by some in an ad-hoc
fashion to list non-functional requirements, this strays from the intended purpose of a use case. Use cases
are functional in nature. It is this very organization by function that give use cases their many benefits.
Arbitrarily listing non-functional requirements in one use case specification or another can obfuscate the
cohesiveness and benefits of the use case specification.
 The non-sequential nature of a use case diagram is often difficult for some audiences to understand. When
one use case includes or extends another, the reader of the diagram often arrives at the incorrect conclusion
that the use case diagram is showing a sequence where the first use case is completed before the other
begins. Those who are familiar with use case diagrams know that an included or extended use case can
occur or be initiated at any point within the including or extending use case.
 Learning how to write use cases takes time. Many consider it to be more of an art than a science. This is
because there is no fully defined set of standards for how to write use cases, or what should be included
within a use cases specification. And while there have been many different views espoused by authors, still a
 great deal of commonality has emerged among them. Where this commonality exists there is little
disagreement among use case writers and those who consume or read use cases. However, in some areas
there are still a number of differing opinions creating confusion for new use case authors. Because of this, the
learning curve for use cases and use cases specifications is elongated. Still, over time, use case authors and
readers develop a more sophisticated understanding of those areas that are more ambiguous and open for
interpretation, such as the “extends” relationship.
 Use case specifications are not an appropriate tool for describing the user interface of the application. Use
cases should be left as UI independent as possible. Remember that a use case specification it intended to
capture the functional requirements of the system, or in other words, WHAT the system should do in response
to a user action. This is very different than HOW the system should do something. Any time an analyst
captures requirements, the focus should be on the WHAT not the HOW. This gives the system and UI
designer the freedom to develop the best solution possible. It also makes our use case specifications much
more maintainable since a change in screen design doesn’t impact the user-system interaction previously
defined.

Question: What is the difference between a use case specification and a use case realization ?

A Use Case Specification is a textual description of the functionality provided by the system. It captures actor-system
interaction. That is, it specifies how a user interacts with a system and how the system responds to the user actions. It
is often phrased in the form of a dialog between the actor and the system. The use case specification is represented in
the use case diagram by an oval, and is what most people think of when they hear the term use case.

A Use Case Realization describes how a use case, which is logically defined by the use case specification, is
physically implemented within a design model in terms of collaborating objects. It organizes the design model artifacts
related to the use case. It often comprises multiple design artifacts such as a class diagram, object diagram, sequence
diagram, etc. that describe how the physical design will implement the use case specification.

The purpose of use case realization is to separate the concerns of the system stakeholders, which are typically
captured by the use case model and system requirements, from the concerns of the system designers. In doing so,
the designers can choose to implement the use case specification without affecting the use case specification.

Question: Which project participants benefit from Use Cases?

The full benefit of use cases are not always understood by all. Use cases provide more benefit than
simply capturing functional requirements of the system, and therefore benefit more project participants
than just the commonly understood project stakeholders. Here are some of the beneficiaries of use
cases.

Project Stakeholders: For project stakeholders, use case models and use cases specify the
functionality and interaction that a user will have with the system. It is written in a simple to
understand form so that it can be understood by even the most diagram adverse individuals. By
reviewing and gaining signoff from the project stakeholders, use cases help analysts validate that the
system will meet the functional requirements expected by the stakeholders and will as a contract of
what will be delivered.

Developers: Use case models provide a high level overview of the system functionality to the
developers. The use cases and use case scenarios add the detail required for a clear understanding of
system functionality and provide a solid foundation for the developers to continue with detailed
design. By completing the detailed design with the use case model as a guide, the system design
remains user-centric ensuring that the final system delivers on the requirements and needs of the
stakeholders.

Analysis, Development, and QA Managers: Use case models are an excellent tool for estimating
the level of effort required to complete analysis, development, and testing of the application. The use
case model divides the system into logical pieces that can be assigned a complexity value and then
each use case can be estimated and aggregated to create a final effort estimation.

Project Managers: Use case models are a great tool for project mangers to plan and track the
progress of work. Use case models become especially useful in iterative development environments
where iterations are planned around the successful implementation of use cases. Use cases are often
used in this way because it is easy for stakeholders to see the value of each use case, and therefore
the value of each iteration of the application that has been implemented.

Integration and System Testers: Use cases and use case scenarios directly translate into test cases
and test scenarios that are used to validate and verify the successful implementation of the system
requirements.
Anyone Requiring System Knowledge: Any time someone needs to know what a system does, one
of the best places to start is the use case model. By reviewing the use case model, anyone can gain a
quick understanding of the functionality of the system. Once they find the use cases that reflect the
functionality that pertains to them, they can then look at the details of each use case and gain an
immediate understanding of the functionality supported.

Question: How do you identify your list of use case actors?

An actor is someone or something that interacts with the system by sending or receiving messages or
information to and from the system. Primary actors initiate the interaction with the system. Secondary
actors do not initiate the interaction with the system but participate in one or more use cases of the
system, often providing information back to the system.

Use case actors can be identified by asking a number of questions:

 Who will use the system to support their daily work?

 Who will maintain, administer, or configure the system?
 Who will use the output, information, or reports from the system?
 What systems or services will require information for the system?
 What systems or services will provide information to the system?

Question: What is use case generalization?

In the context of use case modeling the use case generalization refers to the relationship which can exist between
two use cases and which shows that one use case (child) inherits the structure, behavior, and relationships of another
actor (parent). The child use case is also referred to the more specialized use case while the parent is also referred to as
the more abstract use case of the relationship.

For those of you familiar with object oriented concepts: use cases in UML are classes and the generalization is simply the
inheritance relationship between two use cases by which one use case inherits all the properties and relationships of
another use case.

You can use the generalization relationship when you find two or more use cases which have common behavior/logic. In
this instance, you can describe the common parts in a separate use case (the parent) which then is specialized into two or
more specialized child use cases.

Example:

If you are creating a payment system which allows students of a training provider to pay for courses both on-line and by
phone, there will many things in common between the two scenarios: specifying personal info, specifying payment info,
etc. However, there would also be differences between the two. So, the best way to accomplish this is to create one use
case (the parent) which contains the common behavior and then create two specialized child use cases which inherit from
the parent and which contain the differences specific to registering on-line vs. by phone.

Question: What is actor generalization?

In the context of use case modeling the actor generalization refers to the relationship which can exist between two
actors and which shows that one actor (descendant) inherits the role and properties of another actor (ancestor). The
generalization relationship also implies that the descendant actor can use all the use cases that have been defined for its
ancestor.
For those of you familiar with object oriented concepts: actors in UML are classes and the generalization is simply the
inheritance relationship between two actors by which one actor inherits all the properties and relationships of another
actor.

Example 1:

When it comes to air travel, both a "Business Traveler" and a "Tourist" are "Passengers". The fact that they are
passengers allow them to have common behavior such as "Buy Ticket" but the fact that they are separate actors implies
they can also have differences. The "Business Traveler" might be able to "Redeem Business Miles" while the "Tourist"
cannot.

Example 2:

Another scenario often found in many systems is when the system administrator, who gets additional functionality, is
actually one of the normal users. So let's say that the system is an accounting system with the main actor being
"Accountant" and with another actor called "Administrator". In our scenarios the Administrator should be able to perform
all the normal accounting functions in addition to his/her administrator role.

The way to model this would be to show relationships between the Administrator actor and all the admin only use cases,
then show all the accounting specific use cases related to the "Accountant" actor. And now, the only other thing you
need to do for the "Administrator" to have access to the accounting features is to use the generalization relationship
between the "Accountant" and the "Administrator" with the Administrator actor (descendant) inheriting from the
Accountant actor (the ancestor).

Question: Are use cases the functional requirements or do you think functional requirements are different
from use cases?

It is generally accepted that use cases, specified in narrative form (also known as use case specifications), depict
functional requirements. This is because a use case, via the main and alternate flows, shows how a user interacts with a
system in order to achieve a desired result.

That's exactly the purpose of a "functional requirement" to describe the functions and behaviors that a system is or
should be capable of.

Therefore, if use cases are used and narrated in detail for a project, there is no need for separate documentation to
describe the functional requirements because the totality of all the use cases represent the set of functional requirements
for a given system/project.

Question: What type of information should be documented in a use case specification?

While use cases are included in the Object Management Group’s UML® Specification, the UML
specification does not define the form or content that should be included in a use case specification.
For this reason, there is no single standard. Precisely what information should be included varies
based the source you reference. Nevertheless, most methodologies and authors show a significant
degree of agreement regarding the information that should be included in a use case specification.

The most popular use case specification template is probably the Rational Unified Process Template. It
includes the following information.

 Use Case Name

 Brief Description
 Actors
 Triggers
 Flow of Events
 • Basic Flow
• Alternative Flows
 Special Requirements
 Pre-Conditions
 Post-Conditions
 Extension Points

In his book, Writing Effective Use Cases, Alistair Cockburn (2001) shows several examples of use
case specifications, most of which include the following information:

 Context of Use
 Scope
 Level
 Primary Actor
 Stakerholders and Interests
 Preconditions
 Minimal Guarantees
 Success Guarantees
 Trigger
 Main Success Scenario
 Extensions
 Technology and Data Variations list
 Special Requirements

Additionally, Scott Ambler (2004) offers a simplified template in The Object Primer that includes the
following information:

 Name
 Identifier
 Description
 Goal
 Pre-conditions
 Post-conditions
 Basic course of action
 Alternative course of action

Question: What is difference between an Essential Use Case and a System Use case?
“An essential use case is a structured narrative, expressed in
the language of the application domain and of users,
comprising a simplified, generalized, abstract, technology-free
and implementation independent description of one
task or interaction that is complete, meaningful, and well-defined
from the point of view of users in some role or roles
in relation to a system and that embodies the purpose or
intentions underlying the interaction” (Constantine and Lockwood (1999).

Said another way, an essential use case describes the interaction between the user and the system at a
high level of abstraction. The goal of an essential use case is to convey the most important aspects of
the user-system interaction by focusing on the user’s intent (avoiding any reference to an assumed UI
design or technological implementation) and on the observable result of the system (without specifying
the internal steps the system takes to achieve the result). Since an essential use case describes only
the most important information it represents a single success scenario.

In contrast, a system use case describes the interaction between the user and system in a more
detailed way than and essential use case. While still trying to avoid referencing any UI specific features
when possible, usually certain aspects of the technology to be used can be assumed. For instance,
when writing a system use case, it is usually known whether the user will interact with a telephonic
system, an internet application, or a piece of manufacturing equipment. Similarly, system use cases
provide more detailed description of the steps that the system will perform to fulfill the need of the
user. In order to avoid committing to a specific UI design, this detail should still be expressed in logical
terms. However, it paints a clearer picture of the requirements that the GUI must satisfy.
Question: What are some of the formats used for writing use cases?

To ensure that we understand what is meant by the term format, consider the following. Most authors and practitioners
do not clearly differentiate between style and level of detail when defining use case writing formats. Style refers to the
structure of the use case or how the use case information is presented. Level of detail refers to the state that a use case
is in as it evolves from nothing more than a use case name to a fully described or fully dressed use case. Most authors
and practitioners generically use the term format to describe some combination of these two concepts.

Alistair Cockburn (2001) defines the following types of use case writing formats in his book Writing Effective Use Cases:

 Brief - A use case brief is typically one paragraph which summarizes the main success scenario
and at times the main failures. It is written during early requirements analysis and only takes a
few minutes to create.
 Casual - A casual use case consists of multiple paragraphs which cover the main success
scenario and alternative success and failure scenarios. It is written in a narrative form without
the use of numbered steps.
 Fully Dressed - A fully dressed use case describes the main success scenario, alternative
scenarios, and failure scenarios in full detail. They typically use numbered steps to aid
readability of alternative scenarios that branch from the main scenario and to clearly convey
where a scenario that returns back to the main flow would continue.

Kurt Bittner and Ian Spence (2003) differentiate a bit further between style and level of detail. They describe a Use Case
Authoring Life Cycle as having 6 states (which describe the level of detail provided). The 6 states are:

 Discovered – The initial identification of the use case. At this state it is just a named use case.
 Briefly Described – A single paragraph description. It is usually between 2 to 6 sentences in
length.
 Bulleted Outline – This outline will typically cover the main success scenario in 5-10 steps and is
focused on the users intent. The outline will also cover the high level steps of the most
important alternative flows and exception flows.
 Essential Outline – This outline state is also focused on the user’s intent but begins to clearly
show the interaction between the user and system. It does not go into detail about how the
system internally accomplishes the goal.
 Detailed Description – The detailed description expands on the bulleted outline, describing steps
in greater detail using full descriptive sentences. At this state, it is determined whether to write
the use case in a narrative or conversational style.
 Fully Described –This is the final state and has a complete flow of events including the main
success scenario, all alternative scenarios, and exception scenarios. The terminology used is
usually defined in a supporting glossary. All preconditions and post-conditions have been
identified. A fully described use case is Testable, Understandable, Unambiguous, Correct,
Complete, and Attainable.

In addition, for the Detailed Description and Fully Described Use Cases, Bittner and Spence (2003) identify two popular
writing styles that are used:

 Conversational Form – The conversational form is written in a two column format. All user steps
are in one column and the system response is documented next to the user step in the second
column. The conversational form is often called the Dialog Form. It emphasizes user-system
interaction and works best for use cases where only one actor is interacting with the system.
 Narrative Form – The narrative form is written in a single column format. Each step consists of a
sentence or two and the use case is more of a narrative description or story. This style works
better for use cases that describe the interaction between a system and multiple users.

Question: What is a use case diagram?

Use Case is a textual description of interaction between the Actor and the system. It is used during the
analysis phase of the project to identify and partition the system functionality.

Use case describes the behaviour of the system when the actor sends an input.

Use case usually emphasizes on on WHAT a system should not on HOW it should do it.

Question: What is a use case?

A use case is a representation of an interaction between business worker and a business process or a user and an IT
system in order to achieve something of value (a goal). Use cases are the ovals that appear in a use case diagram. A use
case and a use case description or specification are different. While use cases represent an interaction (usually with a
simple verb-noun phrase) use case descriptions/specifications describe the interaction in detail form.

Use cases can be subdivided into business use cases and system use cases. Business use cases represent the interaction
between a business actor and a business process in order to achieve a goal, while system use cases represent the
interaction between a system actor, which can be a system user or another system, and an IT system in order to achieve
something of value.

Question: What is the difference between a business use case and a system use case?

A business use case describes the interaction between an actor and a business process with no mention of systems.
When writing a business use case, it is irrelevant whether the business process being described is completed by the actor
manually or by interfacing with a system. The focus is on the business process and how the actor interacts with it.

A system use case describes the interaction between an actor and an IT system.