Feature-Oriented Domain Analysis(FODA)

Why it evolved? Domain Analysis Generic Domain Model FODA Steps involved in FODA Advantages Disadvantages

Problem with previous requirement definition iso poor understanding of application domaino lack of common terminology between users and

analysts

Domain aspect is the focus of a set of approaches called “domain analysis”.

Looking at requirement from domain point of view.

Why it evolved?

Domain :- A set of current and future

applications which share a set of common capabilities and data.

By modeling the domain of application and using it to define the system boundaries and features, a good understanding of requirements can be obtained.

Any application domain is characterized by common problems or functions that they solve.

Process of identifying, collecting, organizing, and representing the relevant information in a domain.

Based on the study of existing systems and their development histories, knowledge captured from domain experts, underlying theory, and emerging technology within the domain.

Domain Analysis

Analysis of domain is performed to obtain model that represents entities and processes within the domain.

Domain model:- definition of the functions, objects, data, and relationships in a domain.

A Generic domain model is an abstraction of the functionality, features and design of applications of that domain.

Generic Domain Model

Use of generic domain model is relevant for understanding requirements since requirements are expressed in terms of features typical to that domain and uses terminology pertinent to domain.

Starting with generic domain model, developing different applications makes re-use simpler.

A well known domain analysis methodology.

The Software Engineering Institute (SEI) introduced it in 1990.

Intent is to support functional and architectural reuse.

Objective is to create a domain model which represents a family of systems which can then be refined into the particular desired system within the domain.

FODA

Consists of 3 basic phases:-

1. Context Analysis: defining the extent (bounds)of a domain for analysis.

2. Domain Modeling: describing the problems within the domain that are addressed by software.

- uses three techniques and results in ⦁ Information Model ⦁ Features Model ⦁ Functional Model

3. Architecture modeling: gives software for implementing solutions.

Steps involved in FODA

1. Context Analysis :

Provides the scope of the domain.

This requires representing the primary inputs and outputs of software in the domain as well as identifying other software interfaces.

Context model represented using Structure diagrams and Context diagrams.

Domain Analysis Products

2. Domain Modeling :

The products of this phase describe the problems addressed by software in the domain.

They provide:• features of software in the domain• standard vocabulary of domain experts• documentation of the entities embodied in software• generic software requirements via

control flow, data flow, and other specification techniques

3. Architecture Modeling :

Also called Operational model or behavioral model.

Structures the functions and their sequencing and forms base for developers to see how to provide the features needed by users.

Domain terminology dictionary is another output of this step.

In FODA, designers work along with domain analysts and users to obtain requirement definition.

Main strength is that it focuses on understanding the domain and user’s perspective.

Approach is relevant since all requirements are requirements of the users and are relevant to application domain.

By identifying alternate solutions possible and making clear choices (documentation of rationale), requirements obtained are more reliable.

Advantages

Makes communication more structured and enables structured conflict resolution.

Domain approach encourages thinking at problem level and thus avoids the common trap designers get caught in – they tend to focus on how to implement instead of focusing on actual requirement.

By using generic models and domain terminology, communication gaps are avoided.

Re-use of expertise and of available software on domain is possible.

Domain modeling is however not possible or relevant for domain that are immature or evolving rapidly.

Focus on domain modeling act as inhibitor to having more complex requirement definition because of feeling that requirements need to be confined to the bounds of typical application domain, instead of having freedom to explore extensions to the domain.

Disadvantages