At the top, conceptual, level, there is the following square diagram: \[\begin{array}{} \text{Requirements} & \longrightarrow & \text{Implementations} \\ \big\downarrow && \big\downarrow \\ \text{Reqt-Phases} & \longrightarrow & \text{Impl-Phases} \\ \end{array}\] All nodes are at the very least categories.
The two lower nodes are categories representing the various phases or stages that requirements and implementations pass through as they evolve.
In the simplest case that would be a linear ordering: Version 1, Version 2, etc., but more complex orderings are allowed.
The internal arrows of those “temporal” categories indicate dependency relationships.
The actual requirements and implementations are fibred over those temporal categories.
Thus the fibre over "requirement-phase-1" would be the requirements for, or at, that phase.
And similarly for the implementations.
Each fibre is itself a category, e.g., the requirements at a given time might be a hierarchical document, with a requirement document for each subsystem, represented as a category, with the arrows of the category showing relations between the subsystems.
Arrows between objects in different fibers show how requirements and implementation components evolve from one phase to another.
The vertical arrows are bifibrations, allowing for requirements and implementations to be rolled forward and backward between phases.
The horizontal arrow show how requirements are implemented.
Both horizontal arrows are some form of equivalence. For the top one,
going forward associates with a given requirement that which implements it;
going backward associates with a given implementation component the requirements that it satisfies.
