Use-case analysis

This article provides insufficient context for those unfamiliar with the subject. Please help improve the article by providing more context for the reader. (November 2020) (Learn how and when to remove this message)

Use case analysis is a 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]

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. 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 stimulus, what the user receives from the system, and what value the customer or user will receive from the system.^[2]

There are several steps involved in a use-case analysis.

A Use-case realization describes how a particular use case was realized within the design model, in terms of collaborating objects.^[3]

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

Once the general outline is completed, the next step is to describe the behavior of the system 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]

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]

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 for which no other class in the system will also perform. The responsibilities of the different classes should not overlap.^[4]

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.

Once the relationships between classes are 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]

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, while others are general assumptions from common knowledge (e.g. all operational modern-day 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.

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]