Site temporairement indisponible. Praxeme Wiki | Thesaurus / {$:Def_Name_EN} (definition)
Recent Changes - Search:

News & Events Calendar Trainings Ecosystem Stay informed Recent Changes


  • [[Modus.Modus|Modus|:

Modus, the method

More pages...:]]

  • [[Opus.Opus|Opus|:

Opus, the product

More pages...:]]

  • [[Thesaurus.Thesaurus|Thesaurus|:

Thesaurus, the terminology

More pages...:]]

  • [[Syllabus.Syllabus|Syllabus|:

Syllabus, the spreading

More pages...:]]

  • [[Corpus.Corpus|Corpus|:

Corpus, the library

More pages...:]]

  • [[Focus.Focus|Focus|:

Focus, the objectives and the organization

More pages...:]]

  • [[Chorus.Chorus|Chorus|:

Chorus, the community

More pages...:]]

  • [[Apparatus.Apparatus|Apparatus|:

Apparatus, the tooling

More pages...:]]

  • [[Opera.Opera|Opera|:

Opera, the operations

More pages...:]]


{$:Def_Name_EN} (definition)

Introduction to the notion

Source: White paper - Introducing Praxeme; page 26

To analyze is to observe.

The term evokes breaking down the subject into its finer grained elements and paying attention to details. The posture of a modeler during analysis is characterized by:

  • Passivity (she/he does not take initiatives; she/he is content with documenting what she/he observes).
  • Attention to detail and exhaustiveness.
  • Ability to trace dysfunctions with the aim of providing input for reviews (as-is analysis, auditing).

Analysis versus Design
The “analysis/design” dichotomy is very familiar in software engineering (and to engineering on the whole). However, recent evolutions (notably in the widespread use of iterative approaches) have led to a blurring of this simple contrast.

Traditional development approaches identified activities (analysis or design) with phases (separation of tasks into units). They respected the waterfall model which arranges activities into specific sequences. Now, it is necessary to distinguish between the two notions, as the same phase can contain both types of activities. Iterative development cycles, often, include both analysis and design in a single iteration. The RUP methodology distinguishes the notions of phases from types of activities, or “disciplines”.

Having said this, it is necessary to eliminate the troublesome connotations that these terms drag along with them. Analysis is perceived to be work that is considered generic or functional, whereas design dives into the details. This is not our approach. Before taking steps in a life cycle, analysis and design reflect alternative behaviors of the same reality.


  1. Analysis and Design activities apply to all aspects of the System. The “business” or upstream aspects (semantic, organizational and geographical) are just as likely to be candidates for design proposals as are the more technical aspects.
  2. Be it analysis or design, a model is not complete until it has been described in detail. This does not forbid the production of generic or incomplete models which correspond to a particular intention (sketches, architecture decisions, etc.).


To observe


This is not really a definition but more a reminder about the importance of the posture and the fact that it applies to all aspects of the Enterprise System.


Edit - History - Print - Recent Changes - Search
Page last modified on September 15, 2015, at 12:35 PM EST