Developing a Use Case



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.


Sample Use Case and Extension


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.



Table of Contents