Requirements & Use Case

Presentation TitleRequirements
&
Use Cases
- Manohar Prasad

Agenda:
• What do you mean by requirements
• Requirements roles and responsibilities
• Requirements classifications
• Business requirements
• Stakeholder requirements
• Solution requirements
• Transition requirements
• Use case
• Elements of use case
• Use case diagram
• Use Case description
2Requirements & Use Cases by Manohar Prasad

Requirements
What do you mean by Requirements?
A requirement is:
• A condition or capability needed by a stakeholder
to solve a problem or achieve an objective.
• A condition or capability that must be met or
possessed by a solution or solution component to
satisfy a contract , standard, specification, or other
formally imposed documents.
• A documented representation of a condition or
capability as mentioned above.

Slide Title
• Make Effective Presentations
• Using Awesome Backgrounds
• Engage your Audience
• Capture Audience Attention
Requirements
A requirement may be unstated, implied by or derived
from other requirements or directly stated or managed.
One of the key objectives of business analysis is to ensure
that requirements are visible to and understood by all
stakeholders.
The requirements serve as the foundation for the
software solution to the business needs. It is essential
that the requirements must be complete, clear, correct
and consistent.
Typically, requirements are identified throughout the
elicitation, analysis, verification and validation activities.

Requirements
For example, requirements may be elicited in
interviews or requirements workshops. Later, when
those requirements are used to build and verify
model(s), gaps in the requirements may be
discovered. This will then require eliciting details of
those newly identified requirements.

Slide Title
Product A
• Feature 1
• Feature 2
• Feature 3
• Feature 4
Product B
• Feature 1
• Feature 2
• Feature 3
• Feature 4
Requirement Roles to People
Roles of Requirements
• Customers: Show what should be delivered;
• Managers: A scheduling / progress indicator
• Designers: Provide a spec to design
• Programmers: List a range of acceptable
implementations / output
• QA / Testers: Provide a basis for testing, validation,
and verification

Requirements Classification
A classic way to categorize requirements are :
• Business Requirements
• Stakeholder Requirements
• Solution Requirements
Functional Requirements
Non-functional Requirements
• Transition Requirements

Business Requirements
Business requirements are higher-level statement of the
goals, objectives, or needs of the enterprise.
It describes the reasons why a project has been initiated,
the objectives that the project will achieve, and the
metrics that will be used to measure its success.
Business requirements describe needs of the organization
as a whole and not groups or stakeholders within it. They
are developed and defined through Enterprise Analysis.

Stakeholder Requirements
Stakeholder requirements are statements of the needs of a
particular stakeholder or class of stakeholders.
They describe the needs that a given stakeholder has and
how that stakeholder will interact with a solution.
Stakeholder requirements serve as a bridge between
business requirements and the various classes of solution
requirements. They are developed and defined through
requirements analysis.

Solution Requirements
Solution requirements describe the characteristics of a
solution that meet business requirements and stakeholder
requirements.
They are developed and defined through requirement
analysis. They are further divided into sub-categories,
particularly when the requirements describe a software
solution:
• Functional Requirements
• Non-functional Requirements

Functional Requirements
Functional requirements describe the behavior and
information that the solution will manage. They describe
capabilities the system will be able to perform in terms of
behaviors or operations – specific information technology
application actions or responses.
Example of functional requirements:
The user shall be able to search either all of the initial
set of databases or select a subset from it.

Non-functional requirements
Non-functional requirements covers the conditions that do
not directly relate to the behavior or functionality of the
solution, but rather describe environmental conditions
under which the solution must remain effective or qualities
that the system must have.
Non-functional requirements include requirements related
to Capacity, Performance, Security, Speed and the
information architecture and presentation of the user
interface.
Example of non-functional requirements:
The system shall not disclose any personal information of the
customers apart from their name and reference number to the
operators of the system.

Transition Requirements
Transition requirements describe capabilities that the
solution must have in order to facilitate transition from the
current state of the enterprise to a desired future state,
but that will not be needed once that transition is
complete.
Transition requirements are always temporary in nature.
They typically cover data conversion from existing systems,
skill gaps that must be addressed, and other related
changes to reach the desired future state.
They are developed and defined through Solution
Assessment and Validation.

Use Cases
A use case is a description of a set of interactions between
a system and one or more actors (where actor can be
people or other systems. Ex. Both online shoppers and
PayPal can be actors).
A use case describes the possible outcomes of an attempt
to accomplish a particular goal that the solution will
support. It is created as a Use Case document.
Use cases describe the interactions between the primary
actor, the solution, and any secondary actors needed to
achieve the primary actor’s goal.

Use Cases
Use Cases are written from the point of view of the actor
and avoid describing the internal workings of the solution.
Use Case Diagram
A use case diagram is a graphical representation of the
relationships between actors and one or more use cases
supported by the solution.
A use case diagram visually depicts the scope of the
solution, by showing the actors who interact with the
solution, which use cases they interact with, and any
relationships between the use cases.

Use Case Diagram

Actors
What is an actor?
An actor is any person or system external to the solution
that interacts with that solution. Each actor is given a
unique name that represents the role they play in
interactions with the solution.
A use case is started by an actor, referred to as the
primary actor for that use case. Other actors who
participate in the use case in a supporting role are called
secondary actors.

18
Use Case: Name & Goal
Name: The use case has a unique name. The name
generally includes a verb that describes the action taken
by the actor and a noun that describes either what is
being done or the target of action.
Goal: The goal is a brief description of a successful
outcome of the use case from the perspective of the
primary actor. This acts as a summary of the use case.
Requirements & Use Cases by Manohar Prasad

19
Use Case: Preconditions, Trigger
Preconditions: A precondition is any fact that must be
true before the use case can begin. The precondition is
not tested in the use case but acts as a constraint on its
execution.
Trigger: A trigger is an event that initiates the flow of
events for a use case. The most common trigger is an
action taken by the primary actor.

Use Case: Flow of Events
The flow of events is the set of steps performed by the
actor and the solution during the execution of the use
case.
Most use case descriptions separate out a basic, primary,
or main success flow that represents the shortest or
simplest successful path that accomplishes the goal of the
actor.
Use cases may also include alternative and exception flows.
Alternative flows describe other paths that may be
followed to allow the actor to successfully achieve the goal
of the use case. Exception flows describe the desired
response by the solution when the goal is unachievable
and the use case cannot be successfully completed.

Use Case: Post-conditions
The post-condition is any fact that must be true when the
use case is complete. The post conditions must be true for
all possible flows through the use case, including both the
primary and alternative flows.
The use case may describe separate post-conditions that
are true for successful and unsuccessful executions of the
use case. These can be called guarantees; the success
guarantee describes the post-conditions for success.

Qualities of a good Use Case
A good use case:
• Starts with a request from an actor to the system
• Ends with the production of all the answers to the
request.
• Defines the interactions (between system and actors)
related to the function
• Takes into account the actor's point of view, not the
system's
• Focuses on interaction, not internal system activities
• Doesn't describe the GUI in detail
• Has 3-9 steps in the main success scenario
• Is easy to read

Styles of Use Cases
1. Actor / Goal list or UML use case diagram
shows all use cases in system
2. Informal use case
3. Formal use case
Let's examine each of these in detail...

1. Actor / Goal List
It can be useful to create a list or table of actors and their
"goals" (use cases they start):
ACTORS USE CASE
Club Member Initiates Submit Promotion Order
Submit Regular Order
Potential Member Initiates Submit New Subscription
Past Member Initiates Submit Subscription Renewal
Membership Services Dept. Initiates Request Membership
Marketing Department Initiates Create New Monthly Promotion
Create New Seasonal Promotion
Create New Subscription Program
Request Promotion Reports
Request Sales Reports
Membership Services System Initiates Send New Subscription Offer
Send Club Promotion
Send Subscription Renewal
24

Use Case Summary Diagrams
The overall list of your system's use cases can be drawn as
high-level diagrams, with:
actors as stick-men, with their names below
use cases as ellipses with their names below or inside
association indicated by lines, connecting an actor to a
use case in which that actor participates
use cases can be connected to other cases that they
use / rely on

Use Case Summary Diagram

Use Case Summary Diagram 2

Use Case Summary: Diagram 3

Example use case
Use Case 12. Buy stocks over the web
Primary Actor: Purchaser (user) Scope: PAF
Level: user goal Precondition: User already has PAF open.
Guarantees: sufficient log information exists that PAF can detect what went wrong.
Success Guarantees: remote web site acknowledged purchase, user's portfolio updated.
Main success scenario:
1. User selects to buy stocks over the web.
2. PAF gets name of web site to use (E*Trade, Schwabb, etc.)
3. PAF opens web connection to the site, retaining control.
4. User browses and buys stock from the web site.
5. PAF intercepts responses from the web site, and updates the user's portfolio.
6. PAF shows the user the new portfolio standing.
Extensions:
2a. User wants a web site PAF does not support:
2a1. System gets new suggestion from user, with option to cancel use case.

Use case tables
Formal use cases can also be written as a table:
USE CASE NAME Submit Promotion Order
ACTOR Club Member
DESCRIPTION Describes the process when a club member submits a club promotion order to either
indicate the products they are interested in ordering or declining to order during this
promotion
Normal Course 1. This use is initiated when the club member submits the promotion order to be
proceeded
2. The club member's personal information such as address is validated against what is
currently recorded in member services
3. The promotion order is verified to see if product is being ordered
4. The club member's credit status is checked with Accounts Receivable to make sure no
payments are outstanding
5. For each product being ordered, validate the product number
6. For each product being ordered, check the availability in inventory and record the
ordered information which includes "quantity being ordered" and give each ordered
product a status of "open"
7. Create a Picking Ticket for the promotion order containing all ordered products which
have a status "open"
8. Route the picking ticket to the warehouse
PRECONDITION Use case send club promotion has been processed
POST CONDITION Promotion order has been recorded and the picking ticket has been routed to the
warehouse
ASSUMPTIONS

Use case exercises
Consider the case of a video store that wants a kiosk
with intelligent software that can replace human
checkout workers. A customer with an account can
simply use their membership and credit card with a
reader at the kiosk to check out a video.
Come up with 5 use case names for such
software, and draw a UML use case diagram of
these cases and their actors.
Write a formal (complete) use case for the
Customer Checks Out a Movie scenario.

How do use cases fit in?
"Hub and spokes" model puts use cases as central to all
requirements
Adolph's "Discovering" Requirements in New Territory
What do you think?
use cases help us
discover functional
requirements in our
system and
document them
Do use cases affect
UI design decisions?

Pros and Cons of Use Cases
Pros:
• They hold functional requirements in an easy-to-read text
format
• They make a good framework for non-functional
requirements & scheduling
Cons:
• They show only the functional requirements
• Design is not done only in use case units

4. Describe failure-handling
Recoverable extensions rejoin main course
example: low credit + valued customer -> accept
example: low stock + reduce quantity -> accept
Non-recoverable extensions fail directly
not a valued customer -> decline order
out of stock -> decline order
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
Exercise: Let's do this for the
Customer Returns a Movie scenario.

3. List the failure extensions
Usually, almost every step can fail
example: customer has bad credit
example: item is not in stock in desired quantity
Note the failure condition separately, after the
main success scenario

2. Write the success scenario
Main success scenario is the preferred "happy" case
example: customer=good credit and item=in stock
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

1. Identify actors and goals
Ask oneself the following questions:
what computers, subsystems and people will drive our
system? (actors)
examples: Customer, Clerk, Corporate Mainframe
what does each actor need our system to do?
each need may show up as a trigger to a use case
result: a list of use cases, a sketch of the system
short, fairly complete list of usable system function
can now draw UML use case diagram for reference
37
Requirements & Use Cases by Manohar
Prasad

One method to do use cases
Now that we know the syntax for doing use cases,
what 4 steps does Cockburn recommend
when actually brainstorming and writing our
use cases?
1. identify actors and their goals
2. write the main success scenario
3. identify and list possible failure extensions
4. describe how the system handles each failure
Let's look at each step in detail...
38
Prasad

Identify actors/goals example
Exercise:
Together, let's identify some major actors and their
goals for software for a video store kiosk system.
The software can be used for looking up movies and
actors by keywords, as well as usable to check out
movies from the kiosk to known customers, without
a cashier present.
A customer can check out up to 3 movies at a time,
for up to 5 days each.
If a movie is returned late, late fees can be paid at
the time of return or time of next checkout.
39
Prasad

Requirements & Use Case

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Requirements & Use Case

Similar to Requirements & Use Case (20)

More from Manohar Prasad, PgMP®, PMP®, PMI-ACP®, CAL®, ACC®, CSP®

More from Manohar Prasad, PgMP®, PMP®, PMI-ACP®, CAL®, ACC®, CSP® (12)

Recently uploaded

Recently uploaded (20)

Requirements & Use Case