Use-case analysis

From Wikipedia, the free encyclopedia

A use case analysis is the most common technique used to identify the requirements of a system (normally associated with software/process design) and the information used to both define processes used and classes (which are a collection of actors and processes) which will be used both in the Use case diagram and the overall Use case in the development or redesign of a software system or program. The use case analysis is the foundation upon which the system will be built. ^[1]

Contents 1 Background 2 Walkthrough 2.1 Realization 2.2 Description 2.3 Analysis Classes 2.4 Responsibilities 2.5 Associations 2.6 Behavior 2.7 Describe Attributes 2.8 Mechanisms 3 References

[edit] Background

A use case analysis is the primary form for gathering usage requirements for a new software program or task to be completed. The primary goals of a use case analysis are: designing a system from the user’s perspective, communicating system behavior in the user’s terms, and specifying all externally visible behaviors. ^[2] Another set of goals for a use case analysis is to clearly communicate: system requirements, how the system is to be used, the roles the user plays in the system, what the system does in response to the user’s stimulus, what the user receives from the system, and what value the customer or user will receive from the system. ^[3]

[edit] Walkthrough

This walkthrough will set out one example of how to go about a use case analysis. There are many variations of how to develop a use case analysis, and finding the right method can take time. ^[4]

[edit] Realization

The Realization step sets up the framework within which an emerging system is analyzed. This is where the first, most general, outline of what is required by the system is documented. This entails rough breakdowns of the processes, actors, and data required for the system. These are what comprise the classes of the analysis. ^[4]

[edit] Description

Once the general outline is completed, the next step is to describe the behavior of the system that will be visible to the potential user of the system. While internal behaviors can be described as well, this is more related to designing a system rather than gathering requirements for it. The benefit of briefly describing internal behaviors would be to clarify with potential users that the system is not missing a vital component externally due to it being completed internally. The overall goal of this step is to provide just enough detail to understand what classes are required for the system. Too much detail can make it difficult to change the system later on. ^[4]

[edit] Analysis Classes

This step narrows down the class list into those classes that are capable of performing the behavior needed to make the system function successfully. If no classes yet exist for a system, they must be created before this step can be completed. Classes can be created in many ways from many sources. A few examples are: previous—but similar—systems, enterprise models, and data mining. Once classes are created and narrowed down, relationships must be developed between classes, now called analysis classes, which model the task of the system. ^[4]

[edit] Responsibilities

For each analysis class identified in the previous step, the responsibilities of the class must be detailed clearly. This will ensure that an individual class has a task to complete that no other class in the system is responsible for. The responsibilities of the different classes are not supposed to overlap. ^[4]

[edit] Associations

After detailing the responsibilities of each analysis class, the relationships between the classes must be clarified next. There are four parts of this step:
1. Identify the classes to be used.
2. Identify possible relationships between classes.
3. For those with relationships, describe the nature of the relationship.
4. If applicable, identify the multiplicity of the relationship, meaning determine how many of the first class correspond to one object in the second class of the relationship. ^[4]

View figure 1 for an example of associations between classes:

In this diagram, each box is a class and the lines linking them show which ones have relationships between them.

[edit] Behavior

Once the relationships between classes is understood, the next process is to detail the behavior the classes will exhibit and how they will interact in order to complete the system. This entails determining how the classes communicate and send messages along the timeline of the system process being developed. This is derived from the responsibilities of the classes previously identified. Determining what class the message goes to follows the associations set up in the previous step. ^[4]

[edit] Describe Attributes

Throughout the use case analysis so far, attributes of the classes and objects may have been discovered that are necessary for the classes to complete their tasks. These could be in the form of data variables or functions. Some of these attributes can be derived from the previous steps taken, while others are general assumptions from common knowledge (e.g. all computers have an operating system, a processor, and input/output devices). ^[4]

View figure 2 for an example on described attributes following the figure 1 diagram:

The attributes described in the diagram at this point are generally the items that become the data needed for the system/process to function properly.

[edit] Mechanisms

The final step is to identify components that provide a solution to the problem domain. This would include databases to hold the data, security, exception handling, and communication between processes or programs. ^[4]

[edit] References