I define artifact as a synonym for work product, I use this term in requirements engineering, and I mean any document, model, diagram, role record, or code piece that I create or manage. First, an artifact stores information. Next, an artifact supports decisions. For example, a requirement statement is an artifact. Also, a use case, a test case, and an architecture diagram are artifacts.
I explain traceability with artifacts. I link artifacts to show relationships. For example, I link a test case to a requirement. Then I label that link is_tested_by. In addition, I link a software component to a requirement. Then I label that link is_realized_by. Moreover, I link implementation items to requirements. Then I label that link is_implemented_by. Therefore, artifacts form a network. Consequently, I can follow a requirement from source to implementation.
I classify traceability relationship types for artifacts. First, I use condition relationships. For example, I mark a requirement as a precondition for another requirement. Also, I mark a design constraint as a limitation for a requirement. Next, I use content relationships. For instance, I mark two artifacts as equal with an equality link. However, I also mark contradictions and conflicts. For example, I tag one requirement as in conflict with another. Thus, I detect inconsistencies early.
In addition, I use documentation relationships. For example, I link a scenario as an example_for a solution-based requirement. Also, I link a test case as test_case_for a requirement. Moreover, I record responsibility with responsible_for. For example, I link the role Customer Support as responsible_for the scenario Cancel Account. Furthermore, I link guidelines as background for requirements. For instance, a security policy can provide background for an authentication requirement.
I also use abstraction relationships among artifacts. For example, I classify a scenario under a class with classification. In addition, I group smaller scenarios into a larger scenario with aggregation. For instance, Authenticate Customer can aggregate Customer Login and Mobile TAN. Moreover, I create generalization links when I group similar artifacts. For example, multiple retrieval scenarios can generalize under Retrieve Postings.
I track evolution with artifacts. First, I link a technology trend as is_the_basis_for a quality requirement. Next, I formalize a textual scenario with an activity diagram and mark that relationship formalizes. Also, I refine a functional requirement into a quality requirement and mark that relationship refines. As a result, I maintain the development history of requirements.
I stress that literature offers many relationship types. However, no single set fits all projects. Therefore, I design my traceability plan to match my project goals. In addition, I keep relationships simple when possible. For example, I document who verifies a requirement with is_tested_by and who implements it with is_implemented_by. Finally, I use clear artifact names, consistent links, and traceable records. Thus, I improve requirements management and lower risk.