Vous êtes sur la page 1sur 17

Why it evolved?

Domain Analysis Generic Domain Model FODA Steps involved in FODA Advantages Disadvantages

Problem with previous requirement definition is


o o poor understanding of application domain 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.

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.

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.

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

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.

1. Context Analysis :

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

This

Context model represented using Structure diagrams and Context diagrams.

2. Domain Modeling :
The

products of this phase describe the problems addressed by software in the domain. 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

They

3. Architecture Modeling :
Also

called Operational model or behavioral model. the functions and their sequencing and forms base for developers to see how to provide the features needed by users.
terminology dictionary is another output of this step.

Structures

Domain

Main strength is that it focuses on understanding the domain and users 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.

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.

Vous aimerez peut-être aussi