Understandi

ng UseCase
Inside The
Requirement
By : Najib Abd
Elwahed
 The
Objectives
Between Actors Specific Diagram use case
Use Case Approuch And Users for Specific system specification

Define difference Draw Explain

1 2 3 4
 The
Objectives
Functional
Normal Flows Requirement From
Between Pre And Alternative Flow Use
Post Conditions? And Exception Include And Extend Case Specification

Differentiat
Explain Describe Discuss
e

5 6 7 8
 Use Case
Approuch
As mentioned earlier, a use case describes a sequence of interactions between a
system and an external actor that results in some outcome that provides value to
the actor. An actor is a person (or sometimes another software system or a
hardware device) that interacts with the system to perform a use case. For
example, the Chemical Tracking System’s “Request a Chemical” use case involves
an actor named Requester. There is no CTS user class named Requester. Both
chemists and members of the chemical stockroom staff may request chemicals, so
members of either user class may perform the Requester role. Following are some
questions you might ask to help user representatives identify actors:

1. Who (or what) is notified when something occurs within the system?

2. Who (or what) provides information or services to the system?

3. Who (or what) helps the system respond to and complete a task?
 Users And
Actors

The main point of the text is that the

distinction between users and actors
can be confusing, but it can be
helpful to think of users as having
different "hats" representing
different roles that the system
recognizes during certain use cases.
Users are actual people or systems,
while actors are abstractions
Use Case
Diagram
 Use Case
Specification
A use case is a standalone activity that an actor can perform to achieve a specific outcome, while a
scenario is a description of a single instance of usage of the system. Use cases are a collection of related
usage scenarios, and a scenario is a specific instance of a use case. The use case template is a structure
to store information encountered during a use case discussion in an organized and consistent fashion.

The essential elements of a use case are the following:

1.A unique identifier and a succinct name that states the user goal

2.A brief textual description that describes the purpose of the use case

3.A trigger condition that initiates execution of the use case

4.Zero or more preconditions that must be satisfied before the use case can begin

5.One or more postconditions that describe the state of the system after the use case is successfully
completed

6.A numbered list of steps that shows the sequence of interactions between the actor and the system—a
dialog—that leads from the preconditions to the postconditions
Use Case
Specification
 Pre And Post Conditions
Essential elements in software system analysis and design are
preconditions, which are requirements that must be met before
executing a use case.

These conditions act as prerequisites, ensuring that the system

is in a suitable state to carry out the desired functionality.

By checking preconditions, developers can prevent errors and

potential issues that may arise during the execution of a use
case.

Postconditions, on the other hand, describe the state of the

system after a successful execution of a use case, including
observable outcomes for the user and internal system state
changes.

They are crucial for ensuring the correctness and consistency of

the system and provide a basis for verifying the correctness of
the system's behavior during testing and debugging processes.

Overall, considering and checking preconditions and

postconditions can enhance the robustness, reliability, and
correctness of software applications.
Normal Flows Alternative Flow
And Exception
The typical sequence of steps that a user follows to achieve a specific goal is known as the normal flow of a use case.
This flow represents the ideal path that the system should take to fulfill the user's needs. However, it is important to
recognize that not all user interactions will follow this ideal path. There may be alternative flows or less common
variations that deviate from the normal flow. These alternative flows represent different scenarios or user actions that
may occur during the execution of the use case.

It is crucial to identify and handle exceptions in order to ensure the software's robustness. Exceptions refer to
unexpected events or errors that may arise during the execution of a use case, such as invalid inputs or system
failures. By identifying and handling exceptions, developers can create software that is more resilient and less prone
to errors.

In agile projects, acceptance tests are commonly used to address exceptions. These tests consist of criteria or
scenarios that the software must meet in order to be considered acceptable or complete. By including exception
scenarios in acceptance tests, developers can ensure that the software handles unexpected events appropriately and
continues to function as intended.

To visually represent complex use cases, flowcharts and activity diagrams can be helpful tools. Flowcharts provide a
graphical representation of the steps and decision points involved in a use case, making it easier for stakeholders to
understand the flow of actions. Activity diagrams offer a more detailed view of the use case, showing the sequence of
activities and the flow of control between them. These visual representations can assist stakeholders, developers, and
testers in better understanding and communicating the complexities of a use case.
Normal Flows Alternative Flow
And Exception
 Include And
Extend
a use case diagram is a visual representation that illustrates the interactions between actors (users or external systems) and the system being developed. It helps to
identify the various use cases or functionalities of the system and how they are related to each other.

One way to depict relationships between use cases in a use case diagram is through the "extend" relationship. This relationship signifies that one use case can extend or
add additional functionality to another use case. It is used when a specific use case (the extending use case) can be optionally included in another use case (the extended
use case) based on certain conditions or scenarios.

For example, consider a banking system where a customer can withdraw money from an ATM. The basic use case would be "Withdraw Money," but there could be an
extended use case called "Withdraw Money with Overdraft" that allows the customer to withdraw money even if their account balance is insufficient, but with an overdraft
fee. In this case, the "Withdraw Money with Overdraft" use case extends the "Withdraw Money" use case, as it adds extra functionality to it.

Another way to depict relationships between use cases is through the "include" relationship. This relationship signifies that one use case includes the functionality of
another use case. It is used when a specific use case (the including use case) always incorporates or requires the functionality of another use case (the included use
case).

Continuing with the banking system example, there could be a use case called "Check Account Balance" that is always included in the "Withdraw Money" use case. Before
a customer can withdraw money, they need to check their account balance. Therefore, the "Check Account Balance" use case is included in the "Withdraw Money" use
case to ensure that the necessary functionality is performed.

To avoid repetition and promote reusability, a separate use case can be created to contain shared functionality that is included by other use cases. This use case is known
as a "common use case" or "shared use case." It encapsulates the common functionalities that are required by multiple use cases, reducing redundancy and promoting
modular design.

For instance, in the banking system, there could be a common use case called "Authenticate User" that handles the authentication process for various use cases like
"Withdraw Money," "Check Account Balance," and "Transfer Funds." Instead of duplicating the authentication steps in each use case, they can include the "Authenticate
User" use case, ensuring consistent and secure authentication across the system.

In conclusion, a use case diagram allows for the depiction of relationships between use cases through the "extend" and "include" relationships. Additionally, the use of a
separate use case to contain shared functionality helps to avoid repetition and promotes reusability in the system design.
 Functional Requirement
From Use
Case Specification
The typical sequence of steps that a user follows to achieve a specific goal is known as the normal flow of a use case.
This flow represents the ideal path that the system should take to fulfill the user's needs. However, it is important to
recognize that not all user interactions will follow this ideal path. There may be alternative flows or less common
variations that deviate from the normal flow. These alternative flows represent different scenarios or user actions that
may occur during the execution of the use case.

It is crucial to identify and handle exceptions in order to ensure the software's robustness. Exceptions refer to
unexpected events or errors that may arise during the execution of a use case, such as invalid inputs or system
failures. By identifying and handling exceptions, developers can create software that is more resilient and less prone
to errors.

In agile projects, acceptance tests are commonly used to address exceptions. These tests consist of criteria or
scenarios that the software must meet in order to be considered acceptable or complete. By including exception
scenarios in acceptance tests, developers can ensure that the software handles unexpected events appropriately and
continues to function as intended.

To visually represent complex use cases, flowcharts and activity diagrams can be helpful tools. Flowcharts provide a
graphical representation of the steps and decision points involved in a use case, making it easier for stakeholders to
understand the flow of actions. Activity diagrams offer a more detailed view of the use case, showing the sequence of
activities and the flow of control between them. These visual representations can assist stakeholders, developers, and
testers in better understanding and communicating the complexities of a use case.
 Than
ks
Any Questions

Refreneces :

1. Software Requirements, Third Edition By Karl Wiegers.

2. The Pragmatic Programmer By Karl Wiegers.