Functional Analysis

5.3.1. Purpose

Functional analysis identifies functional commonalities and differences of the applications in a domain. It abstracts and structures the common functions in a model from which appli-cation specific functional models can be instantiated or derived with appropriate adaptation.

The feature model and entity-relationship model are used as guidelines in developing the functional model. The mandatory features and the entities are the basis for defining an ab-stract functional model. The alternative and optional features are embedded into the model during refinement. Also, any factors (other than features) that cause functional differences between the applications are defined as issues and decisions, which are used in the refine-ments for parameterization.

5.3.2. Model Description

Specifications of a functional model can be classified into two major categories: specifica-tions of funcspecifica-tions and specificaspecifica-tions of behavior. The specification of funcspecifica-tions describes the structural aspect of an application in terms of inputs, outputs, activities, internal data, logical structures of these, and data-flow relationships between them. The specification of behaviors describes how an application behaves in terms of events, inputs, states, con-ditions, and state transitions. (The sample domain analysis presented in Chapter 7 employs the Statemate Activitycharts and Statecharts to describe the functional and the behavioral aspects, respectively.)

An abstract model of the functionality of domain applications is defined at the top level. (Any difficulty in abstracting the functionality as a model might indicate that the selected domain is too broad.) During refinement of a model, there may be cases where an entity of a model can be refined in more than one way. For instance, in the case where there is more than one domain technology that can be selected, the selection of a particular technology can result in functional specifications that are different from others. The analyst must understand the implication of the selection of each technology and make a decision that is best for the

application. The major decision points and the alternative decisions at each decision point are captured as issues and decisions by the FODA method. (This concept is also supported by [Conklin 88], [Baldo 89], and [Bailin 89].) The rationale for each decision and any constraints or requirements derived from the decision are also recorded. The information that is collected for each issue and the related decisions is shown in a sample form found in Appendix A.

One thing that differentiates the FODA method from other domain analysis methods is parameterization through the use of features and issues/decisions. As an abstract model is refined, alternative and optional features are embedded into the model. Any issues raised during the analysis and the resolutions (i.e., decisions) of the issues are also incorporated into the model. There are generally three ways to incorporate the features and issues/decisions into the model:

1. By developing separate components (refinements) for every alternative, as il-lustrated by Case 1 of Figure 5-3.

2. By developing one component, but with parameterization for adaptation to each alternative, as illustrated by Case 2 of Figure 5-3.

3. By defining a general component and developing each alternative as an in-stantiation of the general component (with an inheritance mechanism) [Borgida 84], as illustrated by Case 3 of Figure 5-3.

Case 1 A

B

C A

B D

A B

C D

Feature A1 Feature A2

if A1 if A2

Case 2 Activity A1:

is-a AA perform C Activity AA:

perform A, B

Activity A2:

is-a AA perform D

Case 3 or

Activity AA:

perform A,B if A1 perform C if A2 perform D

Figure 5-3: Parameterization: An Illustration

Most of the requirements analysis techniques available today do not support the above

ap-CMU/SEI-90-TR-21 43

proaches, and it is especially difficult to extend them to support the second and third ap-proaches. Statemate conditions are used in the example domain analysis to parameterize specifications as illustrated by Case 2.

5.3.3. Model Usage

The primary uses of this model are to (1) understand the domain problems and (2) reuse models in the requirements analyses. The model represents the functionality of applications from an abstract level down to the detailed level. The decomposition structure and rationales associated with decompositions will help analysts understand the domain problems. Also, analysts can reuse the model at the level where it is most appropriate for the given appli-cation.

5.3.4. Process and Guidelines

The notion of generalization/specialization is adopted to define generic functions and ob-jects, and specifications of each system are made as specialization of the generic functions and objects. What to generalize/specialize can be determined as follows:

•Alternative features in the feature model may be used to identify generic func-tions. Alternative features are specializations of a more general feature, and the functionality corresponding to the general feature is defined as a generic function which is inherited by the functions implementing the alternative fea-tures.

•The generalization/specialization relationships (i.e., is-a relationships) of the entity-relationship model can be used to identify generic objects and the func-tionality associated with the generic objects.

•The context model identifies the external entities and the commonalities among the same type of entities, which can be used to define generalization/specialization of functions.

•Alternative domain technologies, with which different requirements decisions are made, can be a basis for defining generic functions. A generic function is defined based on the commonality of the alternatives, which is inherited by the functional definitions of specific technologies. This information is obtained by analyzing and comparing applications in the domain during the function anal-ysis phase.

The process of functional model development takes both re-engineering and reverse engi-neering approaches to specify the functionality of existing applications. If requirements doc-uments are available, the functional models are re-engineered from the docdoc-uments. Other-wise, the functional models are reverse engineered from the design documents and/or code.

In either case the functional models are specified using data flow and state transition modelling techniques (which is done in the Statemate notation for the feasibility study). The steps of the process are:

1. Gather and study the documents (e.g., requirements documents) describing the functionality of the applications. See if there is any standard model or if a model emerges as standard in the domain.

2. Produce data flow and finite state machine representations of the functional and behavioral aspects of each application used in the domain analysis.

While naming objects in the representations, be certain that the semantics of the names are consistent; resolve any conflicts.

3. Based on the understanding of the models, see if there is enough common-ality among the models to warrant a general model. If a general model cannot be readily abstracted because of structural differences, check if the entity-relationship model can serve as a basis for object-oriented modelling [Coad 89]. Check if the feature model or other real-world models such as the queu-ing network model, feedback control model, or decision support systems models can be used to represent the problem.

4. Refine the general model until all the problems represented in the application specific models are addressed. Embed features in the model to parameterize or to define alternative decompositions.

5. Check if all features are properly addressed in the model; document the map-pings between features and the objects of the model.

6. Have the model validated by domain experts. Demonstrate the applicability of the model by using the model to describe an application not included in the analysis.

CMU/SEI-90-TR-21 45