Use-case analysis


Use-case analysis

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. [Taylor, Art. "Analysis, Design, and Development Techniques with J2EE." InformIT. 6 June 2003. 22 Mar. 2008 ]

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. ["Use Cases." Software Studio. 24 July 2001. 22 Mar. 2008 ] 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. [Shacklette, Mark. 22 Mar. 2008 ]


=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. Evans, Gary. "Getting From Use Cases to Code, Part 1: Use-Case Analysis." IBM. 16 July 2004. 22 Mar. 2008 ]

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.

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.

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.

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.

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.

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.

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.

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).

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.

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.

References


Wikimedia Foundation. 2010.

Look at other dictionaries:

  • Use case — A use case is a description of a system’s behaviour as it responds to a request that originates from outside of that system.The use case technique is used in software and systems engineering to capture the functional requirements of a system. Use …   Wikipedia

  • Use case diagram — A use case diagram is a type of behavioral diagram defined by the Unified Modeling Language (UML) and created from a Use case analysis. Its purpose is to present a graphical overview of the functionality provided by a system in terms of actors,… …   Wikipedia

  • Use case survey — is a list of names and perhaps brief descriptions of use cases associated with a system, component, or other logical or physical entity. This artifact is short and inexpensive to produce early in the analysis or envisioning stages of a software… …   Wikipedia

  • Case — may refer to:Academia* Case analysis, division of a problem into separate cases * Case study, examination of a single instance or event * Center for Social and Economic ResearchBusiness* Business case, captures the reasoning for initiating a… …   Wikipedia

  • case history — n a record of an individual s personal or family history and environment for use in analysis or instructive illustration * * * case his·to·ry (kāsґ hisґtə re) the collected data concerning an individual, his family, and environment,… …   Medical dictionary

  • Case study — This article is about the method of doing research. For the teaching method, see Case method. For the method of teaching law, see Casebook method. A case study is an intensive analysis of an individual unit (e.g., a person, group, or event)… …   Wikipedia

  • case history — noun Date: 1894 a record of history, environment, and relevant details of a case especially for use in analysis or illustration …   New Collegiate Dictionary

  • Case-control — is a type of epidemiological study design. Case control studies are used to identify factors that may contribute to a medical condition by comparing subjects who have that condition (the cases ) with patients who do not have the condition but are …   Wikipedia

  • Analysis — (from Greek ἀνάλυσις , a breaking up ) is the process of breaking a complex topic or substance into smaller parts to gain a better understanding of it. The technique has been applied in the study of mathematics and logic since before Aristotle,… …   Wikipedia

  • Use of Free and Open Source Software (FOSS) in the U.S. Department of Defense — is a 2003 report by The MITRE Corporation that documented widespread use of and reliance on free software (termed FOSS ) within the United States Department of Defense (DoD). The report helped end a debate about whether FOSS should be banned from …   Wikipedia


We are using cookies for the best presentation of our site. Continuing to use this site, you agree with this.