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.
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.
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.
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.
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).
Such concepts could be defined within the software open-source paradigm.
- Objects with Attitudes
- Objects & Aspects
- Business Processes & Use Cases
- Use Cases are Agile Tools
- Focus: Business Processes & Abstraction
- Focus: Business Cases for Use Cases
- Models, Architectures, Perspectives (MAPs)
- On Pies and Skies: Abstraction in Models
- Conceptual Models & Abstraction Scales
- Models & Meta-models
- Open Concepts
- Focus: Analysis vs Design