Traceability

Preamble

As “native” trackers can tell, traceability is all about identifying the origin of the footprint and keeping on with the individuals involved.

Applied to software engineering, that would entail a stable and unambiguous taxonomy of requirements (for categories of business objects and activities) and built-in mechanisms (for individuals artifacts).

Objectives

The primary objective of traceability is to manage dependencies along system engineering processes. For that purpose dependencies should first be classified with regard to their imprint on architectures, namely their origin (environment or enterprise) and abstraction level (actual or symbolic):

• Dependencies rooted in the environment are said to be deontic as they are to be necessary sustained. Synchronic ones directly link changes in actual contexts to the description of their symbolic counterpart (e.g for real-time events acquisition), as compared to diachronic ones which are taken into account logically (e.g the impact of regulations on business rules).
• Dependencies originated within the enterprise are said to be alethic as are contingent on  governance policies. Synchronic ones are supposed to be immediately carried out from their source (enterprise) to their target (environment), e.g the control of business processes, as compared to diachronic ones (aka symbolic) with target set within the enterprise (e.g changes in computation rules).

On that basis, traceability is meant to support four main purposes:

• To begin with, system requirements must be justified and traced back to business goals and stakeholders.
• Then, project planning will use dependencies to set development schedules and allocate resources.
• One step further, quality planning will need traceability to design tests and prevent regression.
• Finally, traceability will be necessary to support maintenance and change management.

If these different concerns are to be met, the requirements taxonomy should be layered along the corresponding responsibilities: business, architectures, development, operations. That is best achieved within a basic model based systems engineering (MBSE) framework, e.g MDA:

• Business domains and processes described by computation independent models (CIMs)
• Systems functional architecture, described by platform independent models (PIMs)
• Software components, described by platform specific models (PSMs).

Traceability can then be managed with regard to the nature of artifacts (layers) and the nature of connections: business, architectures, development, or deployment.

Individuals & Connections

While layered traceability is clearly helpful, it remains a curative policy which doesn’t address the source of the spaghetti syndrome, namely the onset of cross individual variants and the consequent exponential growth of complexity. Ideally, the only effective preventive policy would be to eliminate manually-defined dependencies altogether and fully rely on built-in mechanisms to manage tracks and decisions across layers, from requirements to components. That is arguably a very ambitious objective that can only be achieved through a staged approach. A first step would be to classify dependencies depending on their nature:

• Reference dependencies (functional or structural) are derived from models and can therefore be managed by built-in mechanisms.
• Inheritance dependencies are the result of modeling decisions (generalization or specialization) and their traceability through built-in mechanisms depends on the rationale supporting abstractions.
• Engineering dependencies are set along development flows, either by transformation or by decision (analysis or design). The former can be fully documented by the parameters or inputs utilized; the latter must also include the rationale supporting the decision.

Yet, the real prize of layered dependencies would be to manage tiered supports (requirements, models, tests, software, etc) on a need-to-know basis and by so doing support lean and fit engineering processes.

From Tiered Requirements To Lean Engineering Processes

Lean systems engineering can be broadly defined with regard to time and inventories:

• Time: delays between identification of business needs and applications delivery is to be minimized.
• Inventories: managed intermediate products or documentation should be justified by governance needs, e.g like regulations or risk management.

Both aims are to be significantly furthered by managing traceability along two perspectives, one is synchronic as it must keep business and system models in sync, the other is diachronic as it is only concerned with the design and implementation of symbolic artifacts.

Synchronic traceability

The aim of synchronic traceability is to map business processes to systems components independently of engineering considerations, e.g customers profiles have to take a new parameter into account.

With regard to categories, synchronic traceability can be achieved using functional stereotypes bridging the two realms beyond the intrinsic differences of concerns. e.g change in non structural features.

With regard to the continuity of individual identities across layers, synchronic traceability can be achieved using structural stereotypes: containment, representation units, connectors, and artifacts use and reuse.

• Containment dependencies are set by organization (responsibility for symbolic descriptions of objects and activities) and location (for actual entry points and control units).
• Representation dependencies describe how actual anchors (objects and processes) are mapped to their system counterpart, persistency units, execution units, roles, and events. That will be used to trace requirements to functional architecture.
• Connection dependencies are about links between independently identified units: channels (=), references (#), flows (), state transitions (//). Since connectors can be structured using the same set of standard operators used for targeted anchors, transparency and traceability are not hampered.

Diachronic traceability

While synchronic  dependencies take roots in business requirements and bind actual objects and processes with their symbolic counterpart (a), diachronic ones are defined between artifacts and introduced at model level:

• Processing states use events and symbolic activities (b).
• Processing states are used to describe the behavior of actual or symbolic objects (c).
• Types and semantics: once identified, persistency and execution units are associated with features and operations whose semantics is defined independently, usually at domain level. Their use can therefore be traced to their different contexts, persistent or transient (d).
• Structure: persistency and execution units can be structured using the same set of standard operators, enabling transparency across objects and processes structures.
• Generalization/Specialization.
• Constraints and rules.

Given the distinction between core syntactic constructs and  layered semantics, those dependencies can be directly supported by UML# modeling tools, providing a built-in traceability of requirements.

Built-in Requirements Traceability

Built-in traceability is a by-product of layered modeling and the stereotyped connectors applied uniformly. With model semantics set under a common roof, from requirements to deployments, dependencies can be weaved within model fabric using the same syntactic constructs and semantic stereotypes.

One step further, assuming object oriented concepts are consolidated all along the engineering process, traceability may be applied selectively to architectural components on one hand, aspects on the second one:

• Architectural components are identified by business processes (a) and their implementation (d) must support continuity and consistency across architecture layers.
• Aspects are identified by use cases (b) and their design is best-managed independently of structures identified (#) at enterprise architecture level (c).

IT Governance and Traceability

Traceability is only a means to an end, namely the governance of information systems, and that should be done according two criteria: architecture level (enterprise, systems, platforms) and type of risk and dependency (decision-making, development, operational contexts).

Decisions entail knowledge and authority. At enterprise level it’s about requirements, business or otherwise; at system level it’s about design; and at platform level it’s about deployment.

Development entails information and responsibility. At enterprise level it’s about the way systems are used to support business processes; at system level it’s about the (re)use of software assets; at platform level it’s about transformations and the use of automated tools.

Operational dependencies are about regulations (enterprise level), standards (system level) and interoperability (platform level).

Further Reading

• Architectures
• Models, Architectures, Perspectives (MAPs)
• Architecture Capabilities
• Relating to Functions
• Capabilities vs Processes
• Enterprise Governance & Knowledge
• Enterprise Architectures & Separation of Concerns
• From Processes to Services
• EA & MDA
• EA Documentation: Taking Words for Systems
• Alignment for Dummies
• Alignment: from Entropy to Abstraction