Introduction

As we previously discussed, a key aspect of determining the requirements for the new system is
understanding the user requirements: the things the users Introduction 125 need to accomplish
with the new system.

Use Cases--Means of expressing user requirements

Use cases help us understand and clarify the users’ required interactions with the system and
can help us more fully understand the functional requirements of the new system.

Use Case: represents how a system interacts with its environment by illustrating the activities
that are performed by the users of the system and the system’s responses.

How it helps the analysis phase:

First, the use cases will help the analysts develop a more detailed understanding of the new
system’s functional requirements

Second, use cases are very helpful in understanding exceptions, special cases, and error
handling requirements in the new system

Finally, the text-based use case is easy for the users to understand and flows easily into the
creation of process models (Chapter 5) and the data model (Chapter 6), which are used by the
analysts to more fully define the software that will be developed in the new system

What is a Use Case

A use case depicts a set of activities performed to produce some output result. Each use case
describes how an event triggers actions performed by the system and the user. With this type of
event-driven modeling, everything in the system can be thought of as a response to some
trigger event.

The use Case concept in a Nutshell

User System Dialog

Explains what the user does to complete the task

More fully understand the users perspective on the system

Shows background to existing functional requirements and gives new functional requirements
from the use case
Main purpose: to define the expected interaction between user and system and use that
interaction to clarify and more fully describe the system's functional requirements

Use Case Formats and Elements

Casual Case format

Basic Information

Each use case has a name and a number. The name should be simple as possible yet as
descriptive as possible. The number is simply a sequential number

The description briefly conveys the use case's purpose

Priotty: assigned to indicate the relative significance in the overall system-useful when the
methodology that implements the system in a series of versions sot jat the most essential
system features can be targeted first

Actor: refers to a person, another software system or hardware device that interacts with the
system to achieve a useful goal

User role: can be used instead of actor

External trigger: cutsoomter placing an order

Temporal order: eve is time based

Preconditions

Use cases are often performed in a sequence in order to accomplish an overall business task.

Need to clearly define what needs to be accomplished before each case begins

Preconditions: define the state the system must be in before the use case commences

Normal Course:

Use Case Structure:

Major sections include the description of steps, inputs, and outputs.
Steps in the Normal Course:

List of steps performed when everything flows smoothly in the system.

Sometimes referred to as the "happy path."
Understanding User-System Interactions:

Reading through the steps provides a clear understanding of interactions.

Steps are listed in the order of performance.
Illustrates a "bird’s-eye" perspective of user-system interaction.
Branching Logical Condition (Step 2):

Occurs when a selected drone is out of stock.

Customers have the option to accept future availability dates and continue the order.
Rejection leads the customer back to step 1 to select a different drone model.

Post Conditions:

Post conditions: able to serve to define the preconditions for the next use case in the series

Define the final products

Exceptions

Describe any error conditions or exceptions that may occur as the use case steps are
performed.
Will lead to unsuccessful result

Use Cases in Sequence

Smaller more focussed use cases breaking the whole process down into parts

Take advantage of reusing a use case

Fully Dressed Use Case Format

Shows information that flows in or out

Inputs and outputs to the steps are clarified

Helps to more fully explain the user system interactions outlined in previous steps
Conditional steps go to alternative courses

Alternative Courses
The steps followed for the alternative path through the use case are outlined

The location where the brand in going from the normal course occurred is clearly stated

Summary inputs and outputs

Summarizes the set of major inputs and outputs to the steps of the use case

Additional Use Case Issues

Some organizations may choose to include additional sections on their use case forms. If
appropriate, it may be helpful to include sections devoted to: • Frequency of use • Business
rules • Special requirements • Assumptions • Notes and issues

Fully dressed use cases are especially value when

• User representatives are not closely engaged with the development team throughout the
project. • The application is complex and has a high risk associated with system failures. •
Comprehensive test cases will be based on the user requirements. • Collaborating remote
teams need a detailed, shared understanding of the user requirements.

Applying Use Cases

Essential Use Cases:

Depict user–system interactions as abstract, technology-independent steps.

Example - First Step in Normal Course (Figure 4-1):

"The customer selects the base model drone from a list of models."
No specifics on how this is done to keep implementation options open.
Phrasing Strategy:

Abstract and technology-independent descriptions used.

Avoid specifics in the analysis phase.
Rationale:

Maintains flexibility in system implementation.

Prevents early limitations on thinking about system functionality.
Analysis Phase Perspective:

The correct approach during the analysis phase.

Encourages open-ended exploration of system functionalities.

Use Case Practical Tips

It is important, however, to create use cases whenever we are reengineering processes or

making any changes to business processes that will significantly alter the way people work.
Remember that the use case describes what the system will do from the user’s perspective.

Use Cases and Functional Requirements

Be sure to write functional requirements to support the use case so that the developers actually
can code the system or it doesn't provide enough information for them

Use Cases and Testing

By studying the use cases and the functional requirements derived from them, the testing
personnel can readily identify elements of the tests they will want to perform when the system
enters testing.

Creating Use Cases

The most common ways to gather information for the use cases are through the same
requirement determination techniques discussed in the previous chapter, especially interviews
and JAD sessions. Observation also is sometimes used for as-is use cases.

Identify the Major Use Cases

document one or more functional requirements outlined in the requirements definition.

Process oriented functional requirements-- suggest a direct action resulting from an external or
temporal event

'information oriented functional requirements--content the sysytem must have-suggest things

that happen