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.

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:

Use Cases Analysis Relationships using Video Store example

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:

Use Case Analysis Description of Video Store example

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]