In Formal and Informal Aspects of Requirements
Tracing,
the author notes that the traces we document in requirements tracing are
produced during the actual processes of specification, implementation, and
verification. We can capture the trace in our records because the influences that
connect the artifacts themselves leaves traces. If you can automate the
production of these traces (i.e., automating the process of implementing a
spec), you can capture the trace while it is created.
The dead simple way to implement this is to have a command like
tracer impl TAG.1::FOO.1
Which initiates a workflow for implementing the spec (building a focused contex
(#41) for the implementer). This could be as simple as opening the users
preferred editor to the correct repo for implementation, or could be as fancy as
starting a PR setup and even generating some code annotated with the appropriate tag.
In Formal and Informal Aspects of Requirements Tracing, the author notes that the traces we document in requirements tracing are produced during the actual processes of specification, implementation, and verification. We can capture the trace in our records because the influences that connect the artifacts themselves leaves traces. If you can automate the production of these traces (i.e., automating the process of implementing a spec), you can capture the trace while it is created.
The dead simple way to implement this is to have a command like
Which initiates a workflow for implementing the spec (building a focused contex (#41) for the implementer). This could be as simple as opening the users preferred editor to the correct repo for implementation, or could be as fancy as starting a PR setup and even generating some code annotated with the appropriate tag.