Task: Define Use Cases
Description of requirements in use case view.
Disciplines: Requirements Engineering
Purpose

The purpose of this task is to represent the requirements and their variabilities in the Use Case view. Use Case (UC) is widely used in modern industrial development, so it seems natural trying to find an effective way to combine it with the SPL. However, it must be selected in situations where user-level information is essential for domain model John and Muthig (2002). In domains where non-functional requirements are majority, it is not recommendable to specify UCs.

The detail level and total specified use cases will depend of the SPL context. For example, in projects with constraints of time it might be more useful identify all use cases but detail only use cases that have variability, complexity or still unknown by team. This decision depends of the domain complexity and maturity, organizational constrains and team understanding. Whether domain is well understood, it can specify only use cases more complex or few understood.

In this approach, functional requirements are defined in terms of use cases and actors. An actor is a user of the system, i.e. they are external entities that interact with the system and can be human users or other systems. A use case defines a sequence of interactions between one or more actors and the system.

Relationships
RolesPrimary Performer: Additional Performers:
InputsMandatory:
    		Optional:
      Outputs
        Steps
        Identify

        The elicited functionalities can represent disordered information that need be organized in each view of the DRS, such as domain use cases. From requirements description are identified all SPL use cases, so use cases always are mapped to requirements (use case is always part of or correspond to a whole requirement). For this identification is important observe that the relationship between requirements and use cases is a many-to-many association, such that one requirement could encompass many use cases, whereas a use case could be encompassed by many requirements. Often a use case is encompassed by one requirement. However, for example, a use case could be a secondary functionality that is encompassed by several requirements (when reused).

        In the example of the requirement FR2 presented in Requirements Example, the requirement Fire detection can be break down in some use cases. Each variant could be a new use case. This decision will depend of the functional complexity of each variant, which is discussed in next section. Thus, it could have the following use cases: 1) Fire detect, 2) Alarm activate, 3) Window shut, 4) Gas valve close, 5)  Power outlet deactivate, 6) Light switch, and 7)  Door unlock.

        After identifying use cases, it is necessary document them according to their elements, which are presented in next section. Information (e.g. actors, interaction between actor  and system, preconditions) still does not elicited must be gathering according to guidelines of the Task Elicit.



        Detail

        When utilizing use cases for product line modeling, they should be extended with variability mechanism. In this context, several elements may potentially be a variant, such as use case as whole, actors, dependency, rationale, precondition, postcondition, and event flows. An actor is a variant, for example, if a certain user class is not supported by a product. A use case as whole is a variant if it is not supported by some products in the SPL.

        The use case variability type is defined from the requirements variability type. This definition must be based on the following rules:  

        1. Whether use case corresponds to whole requirement, thus its variability type is the same of the requirement.
        2. Otherwise, whether use case is common part (non-variant) of a mandatory requirement, then it is mandatory.
        3. Otherwise, whether use case is variant part of any requirement, then it is variant.
        4. Otherwise, whether use case is common part only of variant use cases, then it is variant.

        The following attributes must be describes for each use case:

        • Id. All requirements have unique identifier and represented as UCX, where X is a sequential number.
        • Name. The name that better represent the use case.
        • Variability Type. Mandatory or Variant.
        • Binding time. It is defined when variability type is variant. It decides when variant is bound to the member of the SPL. The variants will be bound at certain phase of the product life cycle, such as scoping time (when select the requirements of the product), run time, compile time and load time. The scoping time is the default value, so whether it section is not defined, the default value is assumed.
        • Rationale. It defines the basis for existence of the use case. Its description is optional.
        • Actors. It defines the actors that participate in the use case. There is always a primary actor that initiates the use case. In addition, secondary actors may participate in the use case.
        • Dependency. This optional section describes whether the use case includes or extends another use case.
        • Preconditions. States, what must be true before the Use Case starts.
        • Main Flow.  It describes in narrative manner a typical run of the use case, i.e. the most usual sequence of interactions between the actors and the system, where nothing goes wrong. The description is in the form of the input from the actor, followed by the response of the system. The system is treated as a black box - that is, dealing with what the system does in response to the actor’s inputs, not the internals of how it does it.
        • Alternative Flow. It describes a different path from the main flow, but where nothing goes wrong. There may be several alternative paths, i.e. a use case can have one or more alternative flows, which must be identified by an identifier (e.g. AF1).
        • Exception Flow. It describes what happens when things go wrong at the system level, occuring deviation in the Main or Alternative Flow. There may be several Exception Flows, which must be identified by an unique identifier (e.g. EF1).
        • Postconditions. This section identifies the condition that is always true at the end of the use case if the main flow has been followed.
        • Implication. It presents dependency relationship between use case and another variant object (UC or UC element). It occurs when one must make a choice about the value of variability B only if a particular value of variability A is chosen.
        • Exclusion. It means that a use case cannot exist in presence of another object (UC or VP).

        Variability found in the use case element is represented by Variation Point (VP). A UC can have 0 to n VPs. For each VP should be identified the following attributes:

        • Id. All VPs have unique identifier to assure traceability between objects. The identifier can be standardized as Y.VPX, where Y is the identifier of the use case that VP is part, and X represents a sequential number of the VPs in the requirement (e.g. UC1.VP1).
        • Description. Characterization about VP. It can inform the basis to make choice between the variants. It is optional.
        • Cardinality. Cardinality indicates how many variants can be applied to the variation point and are given by pairs [min, max]. This attribute is required when there are two or more variants. Some examples of cardinality are:

        [1, 1]: Exactly one variant should be selected for a variation point. The variants are mutually exclusive. 

        [1, n] At least one variant should be selected for a variation point. The variants are not mutually exclusive. 

        [0, 1] One variant may or may not be selected for a variation point. 

        [0, n] Zero or more variants may be selected for a variation point.

        • Variant. A variation point can have 1 to n variants. These variants are options of the variation point. Each variant also have a unique identifier that must be standardized as Y.X.VZ, where Y and X are respectively the identifiers of the use case and VP that the variant is part, and Z represents a sequential number of the variant in the VP (e.g. UC1.VP1.V1).
        • Binding time. It decides when variants are bound to the member of the SPL. The variants of the variation point will be bound at certain phase of the product life cycle, such as scoping time (when select the requirements of the product), run time, compile time, installation time and load time. The scoping time is the default value, so whether it section is omitted, the default value is assumed.
        • Implication. It presents dependency relationship between variations. It occurs when a variation (variation point or variant) requires another variation.
        • Exclusion. It means that a variation cannot exist in presence of another.

        The domain use cases elements are analyzed according to needs of each product. Thus, its behavior should be observed to identify common interactions between actors and systems. This information can be found with existing systems and assets, domain experts, end-users and so. Thus, the following guideline must be applied in the Task Elicit:

        1. Identify the following elements for all products: actors, interaction between actors and system, preconditions and postconditions, rationale.
        2. Identify synonyms and homonyms elements. For example, actors with different names but the same role (e.g. client and customer). This information must be described in the glossary.
        3. Identify common responsibilities between similar actors and become them in an abstract actor (e.g. configuration manager and webmaster become an abstract administrator actor) Griss et al. (1998).
        4. Identify common and variable elements between products. The variabilities found are represented according to VP notation presented.

        Use cases are represented with different relationship with the objective of maximize their extensibility and reuse. An extend relationship indicates that an instance of a use case may be increased by the behavior specified by another use case and the include relationship indicates that an instance of a use case will contain the behavior of another use case.

        The variability modeling in use cases is based on PLUS [Gomma2004]. Variation points in use cases can be handled in one of two ways: small and complex variations. For small variations, the VP is described in the use case itself, identifying the place in the use case where the change can occur (see Example of the UC1: Use Cases Example ). When a use case becomes too complex because has too many variant and exceptional sequences of interactions, dependencies between use cases can be defined by include and extend relationships. Both relationships can vary for different products, so it can be represented with variation point.

        According to [Gomma2004], using include and extend relationships to handle variations in a product line works best when the use case contains a block of functionality that can be described as a sequence of interactions between an actor and the system. In some situations, however, a small variation affects only one or two lines in the use case descriptions. Trying to address those situations in separate use cases is liable to fragment the use case model, leading to several small use cases.

        Extend Relationship. For complex use cases an extend relationship can be created splitting variations into a separate use case. The purpose of this new use case is to extend the old use case, if the appropriate conditions hold. The use case that is extended is referred to as the base use case, and the use case that does the extending is referred to as the extension use case. Under certain conditions, a base use case can be extended by a description given in the extension use case. It is important to note that the base use case does not depend on the extension use case and can function independently. The extension use case, on the other hand, executes only if the condition in the base use case that causes it to execute is true. The extension use case cannot function without the presence of a base use case. For representing the precise place in the base use case where extensions can be added, an extension point is used with the tag extension-point. The use cases UC2 and UC3 in  Use Cases examples present extend relationship in a domain of sales. Another domain example is presented because it is of easy understanding.

        Include Relationship. Interactions sequences can reflect functionality that is common to more than one use case. A common interaction sequence can be extracted from several use cases and made into a new use case that can then be reused. This new use case, which is called inclusion use case, is usually abstract, i.e. it cannot be executed on its own. An abstract use case must be executed as part of a concrete, i.e. executable use case. An abstract use case might not have a specific actor. The actor is in fact the actor of the concrete use case that includes the abstract use case, so it is possible for an abstract use case to be used by different actors from different concrete use cases. An example of include relationship between abstract and concrete use case is presented in UC4 and UC5 in Use Cases Example.

        Dependencies can occur between different objects, such as UC-UC, UC-VP, VP-VP, VP-variant, UC-variant and variant-variant. However, a mandatory object cannot depend of a variant object.

        Links must be established to explicitly interrelationships among information in the different work product that are direct linked with use cases (see Traceability Guideline).

        After requirements description is necessary to verify the use cases to assure consistency, accuracy and completeness. During the verification process, if necessary, a set of use cases may be added, deleted, or refined. Changes in domain requirements and feature model also can occur.