USE CASE DIAGRAM:

(Reference link: https://www.youtube.com/watch?

v=59G_4TCpBEk&index=2&list=PLl6ALuxJG7T7I0TOwdCFGoCkv--w0-kPD)
https://www.youtube.com/watch?
v=59G_4TCpBEk&index=2&list=PLl6ALuxJG7T7I0TOwdCFGoCkv--w0-kPD

Requirement Analysis Phase:

-

Use cases are type of requirements documents,

Use cases are one type of requirement document (Requirement Analysis
phase)
After implementation, the SuD (System Under Discussion) could be tested by
following the use cases and checking its behavior. (Requirement Analysis
phase)

Use case:
-

The primary function of the use case is to describe how a SuD responds to
the interaction from a stakeholder in a system.
Specifies what the SuD is to do in different scenarios.
Level of the use case varies
a). Business Use cases(High Level): describe the process that SuD
implements, without specifying any technology-level details.
b). System Use cases(Low level): describe how the SuD will behave in specific
situations.

Scope of Use Cases:

-

Business use cases and many system use cases treat the system as a Black
Box
Black box specify the behavior of the SuD
Black box, has no knowledge of the internal operation of SuD
Some System Use cases may have a White Box perspective,
White box, specify the function and behavior of the SuD.
White box, will detail some aspects of internal operation, such as a specific
protocol that must be implemented.
White box, is useful for describing how different pieces of the SuD are
interoperable.

Elements of Use Cases:

Once after gathering with a no of pieces of information for a particular system, the
specific entries and the order of entries would vary with different organisation. In
many cases the one would follow a template to write a certain Use case,

Trigger: corresponds to the user wishing to perform some action using a SuD,
alternatively this trigger could convert into an event somewhere in the
system or outside system.
Actors (primary and supporting): external person, system or other entity that
interacts with SuD in some way.
Primary Actor: the actor who performs the action for a use case is called as
the Primary actor. In general the primary actor is the user of the system that
will be created. Thus, in other words the primary actor is the stakeholder for a
system.
Supporting Actor: actors that have a role in carrying out some operation of
the SuD, but which do not utilize the SuD directly. In business use cases, the
supporting actors play a crucial role bu they do utilize the SuD directly.
Preconditions: these are the prior conditions before the use case writing are
assumed to be true, these conditions are not checked anywhere. (simply
assumed to be true)
Steps in the process
Minimal Guarantees: smallest set of promises provided to the stakeholders
about the state of SuD at the end of the scenario.(successful or unsuccessful)
Success Guarantees
Quality requirements

Rules of Thumb:
-

Use case documents are narrative texts, like how a system is going to act
under different scenarios.
Use simple language with active voice and simple sentences
Example: user sits down near a keyboard, instead of keyboard is presented to
the user
Do not include elements of the user interface in use cases.
Every use case should end with atleast one guarantee about the state of the
system, for example if the process is successful how the system reacts or if
process fails how the system reacts.

UML Use case Diagrams:

Unified Model language will provide a graphical use case diagram, unfortunately
graphical usage would not provide much of the information of the system described.
The use a strict figure of primary actor executing a use case. However, the graphical
use case do not provide any detail description of the use case. Useful only as an
index to use cases in the system, a simple index would be easier to create.
Agile Methods:
-

Less emphasis on formal use cases due to the time investment required to
create them.

Agile methods include extreme programming, due to which they execute

short iterative times to maintain the due time.

Write a Use Case:

1.
2.
3.
4.
5.

6.
7.
8.

Trigger: The development team needs to write a use case.

Primary actor: Use case writer
Supporting actors: a). other team members b). the customer
Preconditions: a). the development team has been assembled b). the project
concept is known
Steps in the process: a). obtain a template b). number the use case for later
indexing c). name the use case according to the scenario that is been
described d). identify the actors involved in the use case e). determine the
minimal and success guarantees f). identify any applicable preconditions g).
Write the process steps in order h). specify the quality requirements for the
process, if any
Minimal guarantees: a use case document will exist.
Success guarantees: use case document will be clear, easy to read and be
useful in the development process
Quality requirements: a). text must be clear and simple b). user interface
descriptions should not be included c). minimum and success guarantees
must be included.

Use case Levels:

In the real world modeling , a UML diagram can have several use case levels, few ,of
them are sea level, fish level, kite level, cloud level, clam level
https://www.youtube.com/watch?
v=FNkuGEr1gB4&list=PLl6ALuxJG7T7I0TOwdCFGoCkv--w0-kPD

5-steps to draw a sequence diagram:

Step1: Define who will initiate the interaction
Step2: