Capturing the
Requirements as Usecases
ANALYSIS
REQUIREMENT
TEST
DESIGN
IMPLEMENTATION
Introduction
 Major


effort in requirements :
Develop a Model of the System to be built.
Employ usecases to build such a model.
 Functional
Reqs are structured as usecases.
 Non Functional Requirements are specific to a
single usecase.
 Remaining Non-Functional requirements are kept
in a separate document called the supplementary
requirements.
Importance of Usecase
 Offers
a systematic and intuitive way to
capture the functional requirements.
 By using usecases the analysts are forced to
think in terms of who users are and what
business or mission needs can be fulfilled
through them.
 It drives the entire development process.
The Requirements Workflow
The artifacts created in the requirements
workflow.
 The
artifacts created in the requirements workflow.
 The workers participating in the requirements workflow.
 The requirements capture workflow, including each activity
in more details
Artifacts
 Use
Case Model
 Actors
 Use cases


Flow of Events
Special Requirements
 Architecture
 Glossary
Description
The Use Case Model
1
Use Case
System
Use Case
Model
*
Actor
*
Use Case
Artifact - The Use Case Model





Agreement on requirements between developers and
customers, i.e, the condition or capability to which the
system must conform..
Provides essential input for analysis, design and testing.
A use-case model is the model of the system containing
actors and their usecases and their relationships.
For large number of usecases in a system, packages may be
introduced in the model to manage its size.
Presents Model in diagrams that presents the actor and
usecases from different viewpoint and different purpose.
Artifact - Actor





Parties outside the system that collaborate with the system
Often corresponds to workers in a business.
An actor plays one role for each case with it collaborates.
Each time a specific user interacts with the system, the
corresponding actor instance is playing the role.
An instance of an actor is thus a specific user interacting
with the system.
Any entity that conforms to an actor can act as an instance
of the actor.
Artifact - Actor
(TQ – Pg21)
 Actors
are not a part of the system.
 Anyone or anything that must interact with the
system.
 An Actor may



Only input information to the system.
Only receive information from the system.
Input & receive information to and from the system.
Artifact - Identifying Actors



(TQ – Pg21)
Typically found in the problem statement.
Conversation with the customers or Domain Experts.
By asking the following questions :









Who is interested in a certain requirement?
Where in the organization is the system used?
Who will benefit from the use of the system?
Who will supply, use and remove the information from the system?
Who will support and maintain the system.
Does the system use an external resource.
Does one person play several different roles?
Do several people play the same role.
Does the system interact with a legacy system?
Artifact - Usecase




Each way a actor uses the system is represented as a
usecase.
Are “chunks” of functionality that the system offers to add
a result of value to its actors.
Sequence of actions, including alternatives of the
sequence, that the system can perform, interacting with
actors of the system.
Specification of the behavior of the dynamics of the
system.
Artifact - Usecase
is a classifier – It has attributes and
operations.
 Usecase description include the following:
 Usecase




State Chart Diagrams
Activity Diagrams
Collaboration Diagrams
Sequence Diagrams.
Usecase Instance
 Execution
of usecase.
 Interacts with the actor instance and performs a
sequence of actions as specified by the usecase.
 This sequence is specified by a state chart or
activity diagram..
 Many paths are possible through a usecase and
many are very similar. These are the alternatives
through the Usecase.
Path in a usecase
Path through a use case looks as follows:
 The Use-Case is instantiated and put in a start state.
 Invoked by external message from actor.
 It transitions to another state by performing a sequence
of actions. Such a sequence contains internal
computations, selection of path and message output.
 It awaits, in its new state, another message from an
actor.
 It is invoked again by a new message and so on.
 It goes over many states until the usecase is terminated.
Usecase instance - Characteristics





Have attributes that is manipulated during usecase execution.
Usecase instance is atomic.
A Usecase instance does not interact with other instances.
The only interaction that happens in a Usecase is between
Actor instances & Usecase instances.
The interference issues between different uses of a system is
resolved in the Analysis and design phase when we realize
these usecases as collaboration classes and subsystems.
Usecases - Flow of Events
Describes what the system does when a specified
usecase is performed.
 Also specifies how the system interacts with actors
when the usecase is performed.
 Flow of events for each usecase can be captured as a
separate textual description of the use-case's sequence
of action.
 Description includes a set of sequence of actions that
are suitable to modify, review, design, implement and
test together and to describe as a section or subsection
in the user manual.

Usecase – Special Reqmnts.
 Textual
description that collects all
requirements on a usecase.
 Primarily non-functional requirements that
are related to the usecase and that are
needed to be handled in subsequent
workflows such as analysis, design or
implementation.
Usecase – How to identify?
The following question may be used to help identify the
usecases of the system.







What are the task of each actor?
Will any actor create, store, change, remove or read values from the
system?
What usecases will create, store, change, remove or read values from the
system.
Will any actor need to be informed of certain occurrences in the
system?
Will any actor need to inform the system of any external occurrences?
What usecases will support and maintain the system?
Can all functional requirements be performed by the usecases?
Artifact - Architectural Description
 Architectural
View of the usecase model depicting
the architecturally significant usecases.
 Should contain all usecases that describe some
important and critical functionality or that
involves certain requirements that must be
developed early in the software cycle.
 This view is used as an input when the usecases
are prioritized to be developed within an iteration.
Artifact - Glossary




Used to define important and common terms. Used by the
analysts when they describe the system.
Is useful in reaching a consensus among developers
regarding the definition of various concepts and notations
to reduce the risk of misunderstandings in general.
Can often be derived from a business model or domain
model, but because it is less formal it is easier to maintain
and more intuitive to discuss with users and customers.
Tends to be more focused on the system to be built instead
of system’s context.
Artifact – User Interface Prototype
 Helps
during requirements capture to
understand and specify the interaction
between human actors and system.
 Helps us in developing a better user
interface and to understand usecases better.
Workers – System analyst
System
Analyst
Usecase
Model
Actor
Glossary
Workers – Usecase specifier
Usecase
Specifier
Use Cases
Workers – User Interface Designer
User Interface
Designer
User Interface
Prototype
Workers – Architect
Architect
Architectural View
Architecture
Description
Usecase
Model
WORKFLOW
 A Sequence
of activities which are ordered
so that one activity produced output that is
used as an input for the next activity.
 When workers perform activities they create
and modify artifacts.
 An activity may be revisited several times
and each visit may entail carrying out only a
fraction of the activity.
Workflow – Sequence
 Perform
Find Actors and usecases.
 Find architecturally significant usecases to
provide input to the prioritization of
usecases to be developed in the current
iteration.
 Detail the usecases.
 Suggest suitable user interface for each
actor based on the usecases.
Find Actors & Usecases - Why
 Delimit
our system from its environment.
 Outline who and what will interact with the
system and what functionality is expected
from the system.
 Capture and define a glossary of common
terms that are essential for creating a
detailed description of the system’s
functionality.
Find Actors & Usecases - Activity
 Finding
the actors
 Finding the usecases
 Briefly describing the usecase
 Describing the usecase model as a whole.
The above steps are performed concurrently.
Find Actors & Usecases - Activity
System Analyst
Business Model
Use-Case
Model
[Outlined]
Supplementary
Requirements
Find Actors
and Use Cases
Glossary
Feature List
Find Actors and Usecases - Example
Find Actors and Usecases - Example
Briefly describing each usecase
 Identify
the usecases and explain them in a
few words.
 Later describe each usecase briefly in a few
sentences.
 Later a step by step description of what the
system needs to do when interacting with its
actors.
Refer to Page 150 of the book for an Example.
Describing the usecase model as a whole
 Prepare
diagrams and descriptions to explain
the use case model as a whole, particularly how
the usecase relate to each other and the actors.
 To ensure consistency while describing several
usecases concurrently, it is practical to develop
some glossary of terms.
 Terms are derived from classes in domain or
business model.
Refer to Page 151 of the book for an Example.
Prioritizing Usecases
 Determine
which one needs to be developed
in earlier iterations and which can be
developed in later iterations.
 The results are captured in architectural
view of the usecase model.
Prioritizing Usecases
Architect
Business Model
Supplementary
Requirements
Prioritizing
Feature List
Architectural
Description
view of the
usecase model
Detailing a Usecase
 Describe
flow of events in details including how
the usecase starts, ends and interacts with actors.
 With usecase model and associated usecase
diagrams as starting point, the individual usecase
specifiers can now describe each usecase in
details.
 Detail the step-by-step description of each usecase
into a precise specification of the sequence of
actions.
Detailing a Usecase
 How
to structure the description to specify
all the alternative paths to the usecase.
 What to include in a usecase description.
 How to formalize the use-case description
when necessary.
Detailing a Usecase
Use-Case
Model
Use-Case
Specifier
Supplementary
Requirements
Use Case
[Detailed]
Detail a
Usecase
Glossary
Structuring a Usecase Desc.
 Defines
the state that use-case instances
may enter and possible transition between
those states.
 Each such transition is a sequence of actions
that are performed by a usecase instance
when triggered by an event such as a
Message.
 Artifact – State Transition Diagram.
What to include in Usecase Desc.










Start State as Pre-condition
How and When the use-case starts
Required order in which order must be performed.
How and when the usecase ends.
Post Conditions or End States.
Paths of execution that are not allowed.
Alternative Paths.
System Interaction with the actors and what they exchange.
Usage of objects, values and resources in the system.
Describe what the system & actors do.
Formalizing the Usecase Desc
 When
describing a usecase, ensure that we cover
all possible cases.
 When usecases become very complex, a structured
description technique may be needed.



State Charts
Activity Diagrams
Interaction Diagrams
Prototype User Interface




Build a prototype of the User Interface.
Start with a use case and try to discern what is needed from
the user interfaces to enable usecases for each actor
(Logical User-Interface Design).
Then Create Physical User Interface design and develop
prototypes that illustrates how how users can use the
system to perform the usecases.
Result of this activity is a set of user-interface sketches and
user-interface prototypes that specify the look and feel of
the user Interface for actors.
Structuring Use Case Model
 To
Extract general and shared descriptions
of functionality that can be used by more
specific use-case descriptions.
 Extract additional and optional description
of functionality that can extend more
specific use-case description.