Professional Documents
Culture Documents
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.
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.
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.
Less emphasis on formal use cases due to the time investment required to
create them.
6.
7.
8.