SCOPING TECHNIQUE: USE CASES

A use case is a description of a cohesive set of possible dialogs (i.e., series of interactions) that an
individual actor initiates with a system. An actor is a role played by a user (i.e., an external entity
that interacts directly with the system). A use case is thus a general way of using some part of the
functionality of a system. A use case is a description of how a person who actually uses that process
or system will accomplish a goal. On the other hand, is a written description of how users will
perform tasks on your website. Each use case is represented as a sequence of simple steps,
beginning with a user's goal and ending when that goal is fulfilled. A use case diagram consists of
the system, the related use cases and actors and relates these to each other to visualize: what is
being described? (system), who is using the system? (actors) and what do the actors want to
achieve? (use cases), thus, use cases help ensure that the correct system is developed by capturing
the requirements from the user’s point of view.

Fig: The Primary Use Case Notations

ELEMENTS OF A USE CASE
Depending on how in depth and complex you want or need to get, use cases describe a
combination of the following elements:

1. Actor – anyone or anything that performs a behavior (who is using the system)
2. Stakeholder – someone or something with vested interests in the behavior of the system
under discussion (SUD)
3. Primary Actor – stakeholder who initiates an interaction with the system to achieve a goal
4. Preconditions – what must be true or happen before and after the use case runs.
5. Triggers – this is the event that causes the use case to be initiated.
6. Main success scenarios [Basic Flow] – use case in which nothing goes wrong.
7. Alternative paths [Alternative Flow] – these paths are a variation on the main theme.
These exceptions are what happen when things go wrong at the system level.

BENEFIT OF USING USE CASES

Use cases provide some very clear benefits to the Analysis Phase. The following are the benefits
of this scoping technique
1. One important benefit of use case driven analysis is that it helps manage complexity,
since it focuses on one specific usage aspect at a time. Use cases start from the very
simple viewpoint that a system is built first and foremost for its users.
2. Another benefit of use case is that they provide basic groundwork for the requirements
document, user manual and test cases.
3. Use cases also encourage designers to envision outcomes before attempting to specify
outcomes, and thereby they help to make requirements more proactive in system
development.
4. Use cases can help manage the complexity of large projects by decomposing the problem
into major functions (i.e., use cases) and by specifying applications from the users'
perspective.
 5. Use cases provide an objective means of project tracking in which earned value can be
defined in terms of use cases implemented, tested, and delivered.
6. Use cases can form the foundation on which to specify end-to-end timing requirements
for real-time applications.

RISK OF A USE CASES

There are some drawbacks and risks associated with use cases.
1. Use cases eschew description of user motivations and experiences, and do not address
usefulness and usability. Although quality issues are often crucial to the success of a
software system, there are no systematic way to handle nonfunctional requirements with
use cases.
2. Another drawback exists when trying to document interactions between requirements.
Use cases look at each requirement separately and does not document the interaction
between the requirements. Many developers often avoid use cases because of the time
required to prepare a complete set for an application. Depending on the size of the
system in question, it can take a significant amount of time to complete a set of use
cases. Others scorn the “boredom” of use cases, with their unnamed actors and dry,
generalized events. Finally use cases are criticized for not capturing all the off the wall
mishaps and events that can occur.

A USE CASE DIAGRAM

A use case diagram can summarize the details of your system's users (also known as actors) and
their interactions with the system. To build one, you'll use a set of specialized symbols and
connectors. An effective use case diagram can help your team discuss and represent:

1. Scenarios in which your system or application interacts with people, organizations, or

external systems

2. Goals that your system or application helps those entities (known as actors) achieve

3. The scope of your system

 4. Context and Functional requirements in a system

5. Basic flow of events in a use case

COMPONENT OF A USE CASES DIAGRAM

Common components include:

1. Actors: The users that interact with a system. An actor can be a person, an organization,
or an outside system that interacts with your application or system. They must be external
objects that produce or consume data.

2. System: A specific sequence of actions and interactions between actors and the system. A
system may also be referred to as a scenario.

3. Goals: The end result of most use cases. A successful diagram should describe the
activities and variants used to reach the goals

USE CASE DIAGRAM SYMBOLS AND NOTATIONS

The notation for a use case diagram is pretty straightforward and doesn't involve as many types of
symbols as other UML diagrams. You can use this guide to learn how to draw a use case diagram if
you need a refresher. Here are all the shapes you will be able to find in Lucid chart:

1. Use cases: Horizontally shaped ovals that represent the different uses that a user might
have.

2. Actors: Stick figures that represent the people actually employing the use cases.

3. Associations: A line between actors and use cases. In complex diagrams, it is important to
know which actors are associated with which use cases.
4. System boundary boxes: A box that sets a system scope to use cases. All use cases outside
the box would be considered outside the scope of that system. For example, Psycho Killer
is outside the scope of occupations in the chainsaw example found below.

5. Packages: A UML shape that allows you to put different elements into groups. Just as with
component diagrams, these groupings are represented as file folders.
 PROBLEM AND SOLUTION
ARUSO ONLINE VOTING SYSTEM
Ardhi University students conduct their general election for choosing members of Student
organization. They use to cast their vote using paper at voting station, which has become to be
seen as a problem to most of the students as it needs someone to move from where he or she is to
the voting station that led them to take long time in completing their voting right. Upon finding
and choosing the solution for this problem, ARUSO ONLINE VOTING SYSTEM is a solution
chosen as it would enable students under very secure voting platform to vote where they are by
using this system and hence save time.

REQUIREMENTS OF THE SYSTEM

The following is the way in which system requirements collected by the use of Use case technique.
Use case technique is used for describing a set of user scenarios for the purpose of capturing user
requirements.
ARUSO ONLINE VOTING SYSTEM

A use case diagram for Aruso online voting system

The following are the users with their requirements:

i. Admin
a. Login to system
b. Add, delete and modify candidates.
c. Add, delete and modify students.
d. Managing voting duration.
e. Generate results.
f. View results.
g. Logout from the system

ii. Student
a. Login to system.
b. Viewing all Candidates.
c. Cast and submit vote.
d. View results.
e. Provide comment.
f. Logout from the system.
CONCLUSION

Use cases clearly offer many important benefits and are powerful weapons that probably should
be in the arsenal of all software analysts, designers, and testers. Unfortunately, however, they are
functional rather than object-oriented and can significantly compromise the benefits of object
technology if blindly added at to the object-oriented development process. Fortunately, the risks
associated with use case modeling can be mitigated through knowledge, training, and avoiding an
over enthusiastic acceptance.

Use cases should be only one of several ways of capturing user requirements. The model of objects,
classes, and their semantic relationships should be consistent with, but not totally driven by, the
use cases. Designers should beware of and minimize scattering the features of a use case's objects
and classes, and they should exercise great care to avoid the creation of partial, redundant variants
of classes, especially on large projects involving multiple builds and releases.