- model entity (e.g., a UML object or package) and/or a code-construct (e.g., a class, method, or module)
2nd Order Traceability goes beyond mere content and structure to provide contextual awareness. Not only are there links, but there is also contextual information (typically in the form of metadata) giving a clue as to the events that transpired to create it: who authored the content, when they did it, where they did it (physically or virtually)
This type of historical/log information assists in auditing and recovery, and is typically most-suited for automatic capture/recording by the application used to create/modify and store the information (perhaps using a mechanism like dynamic event-based traceability ). The information might also include application integration data (for example, recording the identifier of a requirement or a change-request and associating it with the corresponding portion of the design, code, or tests when it is created or updated).
3rd Order Traceability is the "nirvana" of traceability for many. Not only do we have structure and context, but we have additional associations and attributes (e.g., metalinks between [meta]data) that capture the causal connection between related pieces of knowledge in the value chain. Some call this " rich traceability " and there are some high-end requirements management tools capable of doing this.
Still, tracing all the way through to design models, and code remains very effort-intensive unless all knowledge artifacts are captured in the same repository (requirements, models, code, tests, project-activities, change-requests) where these advanced "rich tracing" capabilities exist.[ MKS claims to have taken a step toward achieving this with its new RM tool that tracks requirements in the same repository as the source-code version control system].
With 3rd order traceability, we are effectively capturing important decisions, criteria, constraints, and rationale at the various points in the knowledge creation lifecycle where one form of knowledge (e.g., prose, model, code) is being either transformed into another form of knowledge, or is being elaborated to another level of decomposition within the same form of knowledge.
4th Order Traceability is meta-traceability, or tracking of knowledge about the five orders of traceability within or across systems. (Sorry - I couldn't come up with anything better that is analogous to Armour's 5th order of ignorance - a.k.a. meta-ignorance. If you have a different idea of what 4th order traceability should be, feel free to comment.)
These five “orders” gives some more fundamental insight into the depth and breadth of knowledge that needs to be traceably structured and visibly organized to transparently communicate to the system’s stakeholders. What about the depth and breadth of the stakeholders we need to communicate with and the communication structures into which they are organized?
The Four Rings of Stakeholder Visibility
In the Feb 2005 ObjectWatch Newsletter , Roger Sessions describes the Rings of the Enterprise for service-oriented enterprise architectures as:
- Ring 0: Individual Applications (and Projects/Teams)
- Ring 1: Enterprise Systems (and IT Programs/Portfolios)
- Ring 2: Collaborative Partners
- Ring 3: Everybody Else
Sessions is author of the book Software Fortresses: Modeling Enterprise Architectures . In the software fortresses model:
Enterprise architecture is viewed as a series of self-contained, mutually suspicious, marginally cooperating software fortresses (each with their own “guards” and “walls”) interacting with each other through “drawbridges” carefully crafted and meticulously managed via treaty or “trust” relationships.
Each one of these rings of enterprise-scope corresponds to a boundary between stakeholders that must be bridged with communication and trust. Every development team and project manager must build bridges across these fortresses by successfully managing the expectations and interfaces between them ! And traceability is often used as a means of enabling transparent communications