As far as requirements are concerned, the primary objective is to guarantee the continuity and consistency of representations of business objects and activities across processes, time, and locations. Setting apart standalone applications, it means that the primary objective of analysis is to align new applications with the functional architecture supporting existing ones.

Looking for Continuity and Consistencies (Benjamin Senior)

For that purpose analysis has to deal with a double hiatus of concerns and languages.

 Separation of Concerns

Whatever the terminology, enterprise governance has to balance opportunistic decisions with investment ones, the former dealing with short-term business value, the latter with long terms assets.

Analysis must distinguish between long-term assets and short-term business opportunities.

With regard to requirements and systems analysis, that distinction can be neatly associated with functional architecture and use cases, the former dealing with the continuity and consistency of symbolic representations (from business objects to classes), the latter with applications (from business views to classes’ aspects).


As illustrated by requirements capture, differences in language are often the first stumbling blocs for system engineering:

  • Business domains come with idiosyncrasies, even when they rely on shared subsets like maths or accounting.
  • By contrast, all systems can be described with a fairly consolidated set of concepts.

In-between modeling languages like BPM and UML try to bridge the gap, the former from a business perspective, the latter from a system one.

Use cases at the hub of UML diagrams

Whatever the language, analysis must first chart new applications with regard to he business objects already identified and determine the associated domain semantics, if any.

Once applications are anchored to functional architectures, the analysis of activities can proceed with users’ stories or use cases.

Conceptual vs Functional Categories

Trying to bridge the semantic gap between business and systems descriptions, on may look for some higher abstraction layer or meta-models; lest such endeavors turns into a flight for abstraction or a rainbow chase, the scope and purpose of shared concepts are to be clearly circumscribed:

  • Their footprint must be limited to their potential realization within business and system realms (no inroads into knowledge management).
  • They must be defined independently of their actual realization within business or system realms (no encroaching from system architecture).
Open concepts between business processes and functional architectures

Such concepts could be defined within the software open-source paradigm.

Further Reading

%d bloggers like this: