The document provides an overview of elements that make up an analysis model, including: - Use case text, diagrams, activity diagrams, swim lane diagrams, and other modeling techniques. - The overall objectives of the analysis model are to describe customer requirements, establish a basis for software design, and define requirements that can be validated. - Scenario-based modeling represents the system from the user's perspective using use case text and diagrams. Elements of use cases and examples of use case diagrams are also described.

1. Analysis Model

2. A Bridge
2
system
description
analysis
model
design
model
Writing the Software Specification
Everyone knew exactly what
had to be done until someone
wrote it down!

3. Elements of the Analysis Model

4. Elements of the Analysis Model
Contd.
4
Use case text
Use case diagrams
Activity diagrams
Swim lane diagrams
Scenario-based
modeling
Class diagrams
Analysis packages
CRC models
Collaboration diagrams
Class-based
modeling
Data structure diagrams
Data flow diagrams
Control-flow diagrams
Processing narratives
Flow-oriented
modeling
State diagrams
Sequence diagrams
Behavioral
modeling
Structured AnalysisObject-oriented Analysis

5. Elements of the Analysis Model
Contd.
• Flow-oriented modeling – provides an indication of how data objects are
transformed by a set of processing functions
• Scenario-based modeling – represents the system from the user's point of
view
• Class-based modeling – defines objects, attributes, and relationships
• Behavioral modeling – depicts the states of the classes and the impact of
events on these states
5

6. Overall Objectives of Analysis
Model
• Three primary objectives
– To describe what the customer requires
– To establish a basis for the creation of a software design
– To define a set of requirements that can be validated once the software is
built
• All elements of an analysis model are directly traceable to parts of the
design model, and some parts overlap.
6

7. Scenario-based Modeling

8. Textual Use Cases
• Use cases are a type of textual requirements
specification that capture how a user will interact with a
solution to achieve a specific goal.
• They describe the step by step process a user goes through
to complete that goal using a software system.
• Use cases capture all the possible ways the user and
system can interact that result in the user achieving the
goal.
• They also capture all the things that can go wrong along
the way that prevent the user from achieving the goal.

9. Use cases elements
Use cases contain the following elements:
Name – A clear verb-noun descriptor that communicates the scope of the use
case.
Goal – A brief paragraph of text describing the scope of the use case.
Actors – A list of the types of users who can engage in the activities
described in the use case. Actor names should not correspond to job
titles.
– Primary Actor
– Supporting Actor/ Secondary Actor
– Off-Stage Actor / Secondary Actor
Precondition/s – Anything the solution can assume to be true when the use
case begins.

10. Use cases elements contd.
Basic Flow – The set of steps the actors take to
accomplish the goal of the use case. A clear description
of what the system does in response to each user
action.
Alternate Flows – Capture the less common user/system
interactions, such as being on a new computer and
answering a security question.
Exception Flows – The things that can happen that
prevent the user from achieving their goal, such as
providing an incorrect username and password.
Post Condition/s – Anything that must be true when the
use case is complete.

11. Golden Rule of Use-Case Names
• Each use case should have a name that indicates what value
(or goal) is achieved by the actor's interaction with the
system
• Here are some good questions to help you adhere to this
rule:
– Why would the actor initiate this interaction with the
system?
What goal does the actor have in mind when undertaking
these actions?
What value is achieved and for which actor?
11

12. Use Case Name Examples
• Excellent - Purchase Concert Ticket
• Very Good - Purchase Concert Tickets
• Good - Purchase Ticket (insufficient detail)
• Fair - Ticket Purchase (passive)
• Poor - Ticket Order (system view, not user)
• Unacceptable - Pay for Ticket (procedure, not
process)
12

13. Types of Actors
• Primary Actor
– Has goals to be fulfilled by system
• Supporting/Secondary Actor
– Provides service to the system
• Offstage Actor/Secondary
– Interested in the behavior, but no contribution
• In diagrams, Primary actors go on the left and others
on the right.
13

14. Descriptive Use-Case
UC-ID: 001
Use-case Name: Login
Goal: Librarian has to login the system to perform different transactions
Primary Actor: Librarian
Secondary Actor: University, Student
Pre-condition: System is working properly
Main Success Scenario:
Post condition: Librarian is able to perform different other transactions.
Actor Action System Response
1. User enters user name.
2. User enters password.
3. System validates the username and
password.

15. 15
USE CASE : Process Sale
(FULLY DRESSED VERSION)
• Primary Actor: Cashier
• Stakeholders and Interests:
 Cashier: Wants accurate and fast entry, no payment errors, …
 Salesperson: Wants sales commissions updated. …
• Preconditions: Cashier is identified and authenticated.

16. Main success scenario (or basic flow):
Actor Action System Response
1.The Customer arrives at a POS checkout
with items to purchase.
2.The cashier records the identifier for
each item. If there is more than one of
the same item, the Cashier can enter the
quantity as well.
3.The system determines the item price
and adds the item information to the
running sales transaction. The description
and the price of the current item are
presented.
4.On completion of item entry, the
Cashier indicates to the POS system that
item entry is complete.
5.The System calculates and presents the
sale total.
6.The Cashier tells the customer the total.
The Customer gives a cash payment
(“cash tendered”) possibly greater than

17. 17
Use case (contd…)
• Extensions (or alternative flows):
• Success Guarantee (Post conditions):
Sale is saved. Tax correctly calculated.…
Actor Action System Response
If invalid identifier entered. Indicate error.
If customer didn’t have
enough cash
cancel sales transaction.

18. Use Case Diagram

19. 19
Actor
• An actor is an idealized user
of a system.
• Actors can be users,
processes, and other
systems
• Many users can be one
actor, in a common role.
• One user can be different
actors, based on different
roles.
• An actor is labeled with the
name of the role

20. 20
Non-human Actor
• Actors can be users,
processes, and other
systems.
• Show non human actors in
a different manner, usually
as a rectangle
• Non human actors are
usually not primary users,
and thus are usually shown
on the right, not the left.
Inventory
System

21. 21
Use Case
• A use case is a coherent unit of
externally visible functionality
provided by a system and
expressed by a sequence of
messages
• Additional behavior can be
shown with parent-child,
extend and include use cases
• It is labeled with a name that
the user can understand

22. 22
System
• A system is shown as a
rectangle, labeled with the
system name
• Actors are outside the
system
• Use cases are inside the
system
• The rectangle shows the
scope or boundary of the
system
Don’t forget the boundary and the system name, unless you are using Rational Rose!

23. 23
Association Relationship
• An association is the
communication path between an
actor and the use case that it
participates in
• It is shown as a solid line
• It does not have an arrow, and is
normally read from left to right
• Here, the association is between a
Modeler and the Create Model
use case

24. 24
Relationships in Use Cases
• There are several Use
Case relationships:
• Association
• Extend
• Generalization
• Uses
• Include
Most Use Cases have only associations.
Use other relationships sparingly.

25. 25
Extend Relationship
• Extend puts additional
behavior in a use case that
does not know about it.
• It is shown as a dotted line
with an arrow point and
labeled <<extend>>
• In this case, a customer
can request a catalog when
placing an order

26. 26
Use Case Generalization
• Generalization is a
relationship between a
general use case and a
more specific use case that
inherits and extends
features to it
• It is shown as a solid line
with a closed arrow point
• Here, the payment process
is modified for cash and
charge cards

27. 27
Uses Relationship
• When a use case uses
another process, the
relationship can be shown
with the uses relationship
• This is shown as a solid line
with a closed arrow point
and the <<uses>> keyword
• Here different system
processes can use the
logon use case voucher

28. 28
Include Relationship
• Include relationships insert
additional behavior into a
base use case
• They are shown as a
dotted line with an open
arrow and the key word
<<include>>

29. 29
Use Case Example: Alarm Clock
This is a contrived
example, to show
many relations.
Your diagrams
should be simpler.

31. 31
Overview
• A use case
diagram
identifies
transactions
between actors
and a system as
individual use
cases