Conceptual Thesaurus: Typical Use Cases


The crumbling of traditional fences between enterprises and their environment as well as between actual and digital realms brings up the need of models encompassing the whole of business flows, whatever scope and nature. Given the open-ended diversity of semantics domains potentially involved, a conceptual thesaurus is arguably the order of the day.


Putting concepts in perspective (Giorgio de Chirico)

But thesaurus are just tools and will be of little use without a modeling paradigm. As already noted, the core issue is to find some common concepts to be shared across business entities without curbing their specificity and their ability to innovate. That objective is to govern a thesaurus’ user interface and typical use cases.

User Interface

Typically, the UI of a conceptual thesaurus should distinguish between textual requirements (bottom left), concepts (bottom center), and the system capabilities meant to support concepts actualization (bottom right and top).

Concepts (bottom) can be associated to actual categories (top left) and their symbolic representation (top right)

With regard to concepts, a distinction should be made between domain-specific concepts and the ones open to shared semantics and realization.

With regard to capabilities, a thesaurus should prevent any confusion between actual (top left) and symbolic ones (top right).

For instance Patient inherits from Person and appears as a physical object (e.g for geo-localization purposes), role (actor in UML parlance) and business entity.

Concepts and capabilities can then be combined in models (middle) describing enterprise, systems (functional architecture), and platforms (technical architecture). Structures are defined uniformly using Boolean operators (middle right)

Typical Use Cases

A conceptual thesaurus is meant to support declarative and iterative as well as procedural and phased development models. That can only be achieved if use cases are defined with regard to artifacts’ status and users needs:

  • Business requirements: identification, classification, and description of business entities and activities.
  • Conceptual analysis: validation of business requirements and consolidation across domains.
  • Functional requirements: specification of supporting system functionalities.
  • Functional analysis: validation of functional requirements and consolidation of supporting system functionalities.
A conceptual and functional thesaurus can support iterative as well as phased development models

A conceptual and functional thesaurus can support iterative as well as phased development models

It must be noted again that use cases are not to be confused with tasks, even if they sometimes coincides: the former are defined with regard to the status of artifacts, the latter are defined as steps within procedures.

UC: Business Requirement Capture

Whatever the domain or methodology, requirements are to be captured through language, formal, specific, or natural. A preliminary objective is therefore to eliminate linguistic ambiguities and list the options without preempting analysis decisions. To mention a frequent issue, nouns in requirements may denote agents, their roles (aka actors), or the records, possibly distinct for the persons and their roles. Similarly, verbs may refer to activities (business logic), states (execution), or events (accomplishment).

Actor: business analyst

Input: requirement item.

Outcome: nouns and verbs are accounted for as concepts and mapped to corresponding capabilities depending on semantics. Capabilities can be defined manually or based on blueprints.

Example: the term “mechanics” is registered as a domain specific concept Mechanic, and its features are documented (screenshot below).

Depending on methodology the corresponding UC can be performed iteratively (e.g users’ stories) or independently (e.g use cases & activities).

UC: Business Requirement Conceptual Analysis

Since it’s safe to assume that new business processes doesn’t necessarily come with self-contained domains, new identified objects and activities have to be compared to existing ones. When shared features are observed, decisions have to be made with regard to specialization and generalization.

Actor: business analyst

Input: requirement item, from requirements capture or directly.

Outcome: concepts are checked against existing open concepts and possibly consolidated together with associated capabilities. Capabilities can be defined manually or based on blueprints.

Example: domain-specific concept Patient inherits its structure and identification mechanism from the Person open concept, and functional aspects from Customer. Capabilities include authentication of physical agent (from Person), actor, and Nurse entity. Links are suggested to symbolic containers (HMO, Hospital, etc).

The concept of HMO is mapped to symbolic container and business object, with suggested links to patients as actors and physical individuals.

Assuming that the primary intent of conceptual analysis is to factor out the footprint of concepts defined externally (e.g Person), the responsibility of these concepts (aka open concepts) should be given to thesaurus administrators.

UC: Domain Conceptual Validation

Before considering the part played by supporting systems, business analysts must check for the continuity and consistency of overlapping business domains (aka bounded contexts).

Actor: business analyst or thesaurus administrator

Input: domain, from requirements capture or directly.

Outcome: structural and functional inheritance by the targeted domain (or context) have been checked for consistency.

Example: Nurse can directly inherits identification from one and only one source: either it comes directly from Person, or indirectly through Staff.

It must be noted that the formal constraints set for open concepts open the door to a wide range of rigorous tests for models.

UC: Functional Requirement Capture

Compared to business requirements, which are meant to focus on business objects and logic independently of the role played by supporting systems, the purpose of functional requirements is to specify what happens between business processes and systems. Depending on projects and methodologies, business and functional requirements may be carried out separately (phased project management) or jointly (agile project management); both approaches can be supported by the same use case.

Actor: functional or business analyst.

Input: requirements item, possibly checked for conceptual analysis.

Outcome: concepts and associated features are consistently mapped to capabilities.

Example: the relevant features of the Patient concept are to be mapped to system capabilities according to their functional justification, e.g: bio-metric (physical boundary capability) or logical (recorded features) authentication, staff authorizations and confidentiality (actors), and management (business entity).

UC: Functional Requirement Analysis

As for business processes with regard to domains, new functional requirements often rely on existing systems functionalities. When potential overlapping is observed, decisions have to be made with regard to specialization and generalization.

Actor: functional analyst and architect.

Input: functional requirements item, checked for conceptual analysis.

Outcome: new capabilities are fully documented, checked against current functional architecture, and possibly consolidated. That can be done manually or in line with functional patterns.

Example: bio-metric authentication requires specific capabilities for system boundaries that may or may not be already supported, and when they are some extensions may be necessary.

Set within a phased project the use case will typically produce a functional specifications document. When applied iteratively by agile teams it will help to mark out functional features from backlog items.

UC: Functional Validation

Just like business domains, systems capabilities cannot be assessed independently as cross dependencies may cripple capabilities of a system as a whole despite attested local feasibility.

Actor: functional analyst, system architect, and quality manager.

Input: functional requirements and architecture capabilities.

Outcome: expected individual capabilities are checked as a whole, both for functional and non functional requirements.

Example: apart from specific capabilities of a number of system boundaries, bio-metric authentication may also requires encryption and real-time capabilities at system level.

Set within a phased project the use case will typically finalize a detailed feasibility study. When applied iteratively by agile teams it will help to prioritize backlog items with regard to system features. In the broader perspective of a scaled approach, the use case will further incremental development of system features.

Further Readings


%d bloggers like this: