|
When developing use cases
you should start with a functional partition—a listing of the major
functional categories of the application. This will help identify what areas
need to be focused on. (10) |
|
Step
1: Identify who is going to be using
the system directly. These are the Actors. The main component of use case development is actors. An actor is a
specific role played by a system user and represents a category of users that
demonstrates similar behaviors when using the system. The actors may be
people or computer systems. (10) A primary actor is one having a goal requiring
the assistance of the system. A secondary actor is one from which the system
needs assistance to satisfy its goal.
One of the actors is designated as the system under discussion. (6) A
person can play several roles and thereby represent several actors, such as
computer-system operator or end user. |
|
Step 2:
Pick one of those Actors. To identify a target
system’s use case, we identify the system actors. A good starting point is to
check the system design and identify who it is supposed to help. (12) |
|
Step 3: Define what that Actor wants to do with the
system. Each of these things that the actor wants to do with the system
become a Use Case. The things that the
actors want to do with the system become goals. The goal is the end outcome
of the actions of the user. There are two types of goals. The first type is a
rigid goal. This goal must be completely satisfied and describes a target
system’s minimum requirement. The second type of goal is a soft goal. This
usually describes a desired property for a target system and does not need to
be completely satisfied. (12) To identify use cases, we can read the
requirement specification from an actor’s perspective and carry on
discussions with those users who will function as actors. By defining
everything that every actor will be able to do in interaction with the
system, the complete functionality of the system is defined. (4) |
|
Step 4: For each of those Use Cases decide on the most
usual course when that Actor is using the system. What normally happens. A use case has one basic
course and several alternative courses. The basic course is the simplest
course, the one in which a request is delivered without any difficulty. (12)
There may be alternative courses that describe variants of the basic course
and the errors that can occur. These are documented as extensions to the use case. |
|
Step 5:
Describe that basic course in the description for the use case. The use scenario is
written from the user’s perspective in view in easy to understand language.
This step is very similar to documenting a process flow. The steps necessary
to achieve the identified goal are written out. |
|
Step 6: Once you’re happy with the basic course now
consider the alternatives and add those as extending use cases. The extensions are written in the same manner as
the original use case but they provide alternatives to the simplest path. |
|
When analyzing and describing use cases in detail it
is not unusual to uncover points that are not clear in the requirement
specification. Vague requirements thus become obvious at an early stage and
can be corrected before the Design Phase. Once the use cases are complete it
is important to discuss with the customer and make any necessary changes. It
is important to have user buy in before proceeding to the next step in the
process because these use cases will become the foundation of your user
requirements and design specifications. |