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
organies the design model artifacts related to the use case. It often comprises multiple design
artifacts such as a class diagram, object diagram, se!uence diagram, etc. that describe how the
physical design will implement the use case specification.
The purpose of use case realiation is to separate the concerns of the system stakeholders,
which are typically captured by the use case model and system re!uirements, 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.
Which project participants benefit from Use Cases?
The full beneft of use cases are not always understood by all. Use cases provide
more beneft than simply capturing functional requirements of the system, and
therefore beneft more project participants than just the commonly understood
project stakeholders. Here are some of the benefciaries of use cases.

Project Stakeholders: or project stakeholders, use case models and use cases
specify the functionality and interaction that a user will have with the system. !t is
written in a simple to understand form so that it can be understood by even the most
diagram adverse individuals. "y reviewing and gaining signo# from the project
stakeholders, use cases help analysts validate that the system will meet the
functional requirements e$pected 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. "y completing the
detailed design with the use case model as a guide, the system design remains user%
centric ensuring that the fnal system delivers on the requirements and needs of the
stakeholders.

Analysis, Development, and QA Managers: Use case models are an e$cellent
tool for estimating the level of e#ort 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 comple$ity value and then each use case can be estimated
and aggregated to create a fnal e#ort 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 Re!iring System "no#ledge: &ny time someone needs to know what a
system does, one of the best places to start is the use case model. "y reviewing the
use case model, anyone can gain a quick understanding of the functionality of the
system. 'nce they fnd the use cases that re(ect 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.
&n actor is someone or something that interacts with the system by sending or
receiving messages or information to and from the system. )rimary actors initiate the
interaction with the system. *econdary 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.
$o# do yo! identi%y yo!r list o% !se case actors&
Use case actors can be identifed by asking a number of questions+
,ho will use the system to support their daily work-
,ho will maintain, administer, or confgure the system-
,ho will use the output, information, or reports from the system-
,hat systems or services will require information for the system-
,hat systems or services will provide information to the system-
'hat is !se case generali(ation&
!n the conte$t of use case modeling the !se case generali(ation refers to the
relationship which can e$ist 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 speciali0ed use case while
the parent is also referred to as the more abstract use case of the relationship.
or those of you familiar with object oriented concepts+ use cases in U12 are classes
and the generali0ation is simply the inheritance relationship between two use
cases by which one use case inherits all the properties and relationships of another
use case.
3ou can use the generali0ation relationship when you fnd two or more use cases
which have common behavior4logic. !n this instance, you can describe the common
parts in a separate use case .the parent/ which then is speciali0ed into two or more
speciali0ed child use cases.
)*ample+
!f 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 di#erences between the two. *o, the best way to
accomplish this is to create one use case .the parent/ which contains the common
behavior and then create two speciali0ed child use cases which inherit from the
parent and which contain the di#erences specifc to registering on%line vs. by phone.
&ctor generali0ation
!n the conte$t of use case modeling the actor generali(ation refers to the relationship which can e$ist
between two actors and which shows that one actor .descendant/ inherits the role and properties of
another actor .ancestor/. The generali0ation relationship also implies that the descendant actor can use all
the use cases that have been defned for its ancestor.
or those of you familiar with object oriented concepts+ actors in U12 are classes and the generali0ation is
simply the inheritance relationship between two actors by which one actor inherits all the properties and
relationships of another actor.
)*ample +:
,hen it comes to air travel, both a 5"usiness Traveler5 and a 5Tourist5 are 5)assengers5. The fact that they
are passengers allow them to have common behavior such as 5"uy Ticket5 but the fact that they are
separate actors implies they can also have di#erences. The 5"usiness Traveler5 might be able to 56edeem
"usiness 1iles5 while the 5Tourist5 cannot.
)*ample ,:
&nother scenario often found in many systems is when the system administrator, who gets additional
functionality, is actually one of the normal users. *o let7s say that the system is an accounting system with
the main actor being 5&ccountant5 and with another actor called 5&dministrator5. !n our scenarios the
&dministrator should be able to perform all the normal accounting functions in addition to his4her
administrator role.
The way to model this would be to show relationships between the &dministrator actor and all the admin
only use cases, then show all the accounting specifc use cases related to the 5&ccountant5 actor. &nd
now, the only other thing you need to do for the 5&dministrator5 to have access to the accounting features
is to use the generali0ation relationship between the 5&ccountant5 and the 5&dministrator5 with the
&dministrator actor .descendant/ inheriting from the &ccountant actor .the ancestor/.
Are !se cases the %!nctional re!irements or do yo! think %!nctional re!irements are
di-erent %rom !se cases&
!t is generally accepted that use cases, specifed in narrative form .also known as use case
specifcations/, depict functional requirements. This is because a use case, via the main and alternate
(ows, shows how a user interacts with a system in order to achieve a desired result.
That7s e$actly the purpose of a 5functional requirement5 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 system4project.
Additional Ans#ers./omments
Use cases serve their purpose well when their synta$ describes the 8required9
functionality from the system in response to the user interaction, without getting
into the details of 8how9 to e$ecute this functionality. !n other words, the system
is a black bo$ from the use case perspective.
Using the above style, every use case line that states 8system does :;
something<9, is a function that the system is e$pected to perform and therefore
can be a potential unctional *pecifcation.
!n the famous &T1 e$ample, the use case considers the system that operates
the &T1 machine as a black bo$. & typical scenario would be+
=% User inserts the &T1 card
>% *ystem validates the inserted card is valid to e$ecute fnancial transactions
on this &T1 machine
?% *ystem prompts the user to enter )!@ number
A% User enters )!@ number
B% *ystem validates the )!@ number
..
..
!n the above e$ample, steps >, ? and B represents a functionality that the use
case author is requesting the system to perform. 'r, in the 8formal9 functional
specifcations synta$, steps >, ? and B are translated to+
The system shall validate the inserted card is valid for fnancial transactions on
this &T1 machine
The *ystem shall prompt the user to enter )!@ number
The *ystem shall validate the )!@ number entered by the user
However, there may be cases where a use case line will not qualify to be a
unctional *pecifcation, although it starts with 8*ystem does something:9.
Can you come up with any e$amples-
Dssential use case and system use case E di#erence
&n essential use case is a structured narrative, e$pressed in
the language of the application domain and of users,
comprising a simplifed, generali0ed, abstract, technology%free
and implementation independent description of one
task or interaction that is complete, meaningful, and well%defned
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 interaction9 .Constantine and 2ockwood .=FFF/.

*aid 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
userGs intent .avoiding any reference to an assumed U! design or technological
implementation/ and on the observable result of the system .without specifying the
internal steps the system takes to achieve the result/. *ince an essential use case
describes only the most important information it represents a single success
scenario.

!n contrast, a system use case describes the interaction between the user and
system in a more detailed way than and essential use case. ,hile still trying to avoid
referencing any U! specifc features when possible, usually certain aspects of the
technology to be used can be assumed. or 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. *imilarly, system use
cases provide more detailed description of the steps that the system will perform to
fulfll the need of the user. !n order to avoid committing to a specifc U! design, this
detail should still be e$pressed in logical terms. However, it paints a clearer picture of
the requirements that the HU! must satisfy.
"a and technical analyst
The role of a "usiness &nalyst is a broad and encompassing role with many di#erent
speciali0ations. "usiness &nalysts may speciali0e in the areas of "usiness )rocess
&nalysis, *ystems &nalysis, 6equirements Dngineer, Iata &nalyst, unctional
&rchitect, )roduct 1anager, Usability4User D$perience &nalyst, and at times Technical
,riter. However, while a "usiness &nalyst may perform the role of a technical writer
at times the profession of technical writer can stand on its own.

& technical writerGs role is a collaborative and interactive one. Their primary
deliverables are+
Technical manuals that describe the specifc features of a product or
application
)roducing online step%by%step tutorials with illustrative graphics and images to
aid the reader
)roducing web%based training and other forms of training materials
To produce these deliverables the technical writer must acquire a detailed knowledge
and understanding of the product or application for which they are producing the
deliverable. This requires them to work with analysts and developers of the system,
end users of the systems, and often to test certain features of the system
themselves.

Hiven the skills required to perform this role, the most common academic
backgrounds for this profession are Dnglish, technical communication, science or
engineering, computer science and journalism according to the *ociety for Technical
Communication
&ctivity diagram
&n &ctivity Iiagram is a behavioral diagram that shows the (ow or sequence of
activities through a system. The terms activity diagram and process (ow are often
used interchangeably. However, the term activity diagram is typically more
restrictive as it refers to one of thirteen standard Unifed 1odel 2anguage .U12/
diagrams. &ctivity Iiagrams are one of the most commonly used diagrams since its
notation and origin are based on the widely known (owchart notation.
U12 defnes a specifc notation and set of rules for creating &ctivity Iiagrams. The
following are the most commonly used+
Initial 0ode % The initial node represents the starting point of the activity
diagram.
Activity 1inal 0ode % The activity fnal node represents the termination point
of the activity.
Action 0ode % &n action node is a type of activity node that represents a
single action or behavior of the activity being modeled.
Activity )dge % &n activity edge creates a directed connection between two
activity nodes. !t represents the path that a token can take between two
activity nodes.
Decision % & decision has one (ow entering and several e$iting. The e$iting
(ows each have a condition that must be met in order to traverse the (ow.
Merge % & merge has several (ows entering and one e$iting. The merge
denotes that multiple parallel (ows are merging at a single point. 'nly one
(ow must reach the merge point in order to continue to traverse the (ow to
the ne$t activity.
1ork % & fork has one (ow entering and several e$iting. & fork denotes that
several processes are occurring in parallel.
2oin % & join has several (ows entering it and one e$iting it. & join denotes
that multiple parallel (ows are merging at a single point. &ll (ows going into
the join must be completed before the ne$t activity can start.
There are others, but these eight symbols constitute the basic notation used by
nearly every &ctivity Iiagram.