As I mentioned when we started talking about use cases, use
cases are fundamental in UML, and in general. So, now I
would like to discuss why they're so important and what are
the different roles that use cases can play. The first obvious one
is for requirements elicitation. It is much easier to describe what
the system should do if we think about the system in
terms of scenarios of usage. Rather than trying to describe the
whole functionality of the system at once. So, use cases can help
performing a more effective requirement solicitation. As we will
see when we discuss the unified software process, they can
be used for architectural analysis. So, use cases are the
starting point for the analysis of the architecture of the
system that can help identify the main blocks of
the system. And therefore, can help define in the initial
architecture. And as I said, we'll talk more extensively about
that. They can be used for user prioritization. For example,
imagine to have multiple actors in the system, and you
might want to prioritize some of them. For instance, using
again the banking system example, we might want to first
provide functionality for the administrators of the bank. And only
in a second time provide functionality for the customers, because
of course, if the administrator cannot perform any operation, the
customers cannot use the system. So again, they can be
used to prioritize the users. Or the actors, and therefore
define which part of the system should be built in which order.
Related to this point, they can be used for planning. If I
know which pieces of functionality I need to build and in which
order, I can better plan the development of my system. And again,
we will see how this becomes very important in many different software
life cycles. So, both in the unified software process, for instance, but
also in more agile development processes. And finally, use cases can be
used for testing. If I have an early description of what the
system should do, what are the main pieces of functionality of the system. And I
know how the interaction between the actors and
the system is, I can easily define test
cases, even before writing the code, even before
defining my system. And when we discuss testing,
we will get back to this and talk a little more extensively about this, as well.