Selection of our books indexed in the Book Citation Index in Web of Science™ Core Collection (bkci)

A UseCase is a user
’
s business goal, which he wants to achieve as quickly as
possible for the least amount of effort expended.
UseCase should always be written from the
user
’
s point of view
. It is written from
the perspective of the
user
’
s expectations!
It is necessary to distinguish between the user
’
s
expectation
and the
demand
.
The difference between the two words is crucial and should be in the ratio of 80
(expected) : 20 (required) in UCD and UX documents.
This is because UseCases are created (written) at a time when the form of the
application is unknown (or mostly unknown). It lacks its controls, which must be
derived from UseCases. If a button was required for every desired user action already
in the UseCase (e.g., printing a report), then it may be that the controls are designed
differently in 1000 UseCases.
There is a risk that each software analyst and designer who creates them may have
a different idea of the final implementation of the operation. Consequently, identical
operations will differ in implementation. This is another common mistake due to
improperly created UseCases.
After all, this is common today. Different parts of the applications have different
controls (although they are in accordance with the prescribed Look and Feel of the
operating system). Usually, a huge mental burden is put on the programmer in the
end, because he then has to implement it.
UseCase is therefore written in terms of user expectations, and it is necessary to
avoid defining graphical controls.
For example: the user
expects
to enter the name of the print report and the
number of pages, and sets the printer type. The user confirms the request (
it doesn
’