One of the most important functions achieved by today’s requirements
management tools is traceability between requirements. According to
the ANSI/IEEE Standard 830-1984 standard:
“a software requirement is traceable if (i) the origin of each of its
requirements is clear and if (ii) it facilitates the referencing of each
requirement in future development or enhancement documentation”.
Gotel & Finkelstein (1995) recognise two types of tracing:
1. Pre-requirements tracing, which includes aspects of requirements
which arise prior to inclusion of requirements in the specification;
2. Post-requirements tracing, which links the requirements to aspects
which arise after inclusion in the specification, for example to design,
implementation and test plans.
Current requirements management tools provide a number of simple
methods and technologies to handle traceability, as the RequisitePro
demonstration will show. Different forms of matrices with typed links can
be used to manage requirements traceability links. Indeed, traceability
links are specialised relationships between objects/entities in the
requirements data base, hence technological solutions are dependent
on the underlying data base technologies.
Gotel O. & Finkelstein A.C.W., 1995, ‘Contribution Structures’, Proceedings 2nd International Symposium on
Requirements Engineering, IEEE Computer Society Press, 100-107
Gotel & Finkelstein (1995) claim that it is hard to locate and access
human sources of requirements, requirements-related information, and
requirements-related work. To resolve this problem they propose
contribution structures which indicate an underlying social structure for
requirements tracing.
These contribution structures depend on the identification of three core
stakeholder roles in the requirements engineering process: the
principal, the author and the documentor. Furthermore, each of the
roles can be undertaken by the same individual, so that it is possible to
identify composite roles, as shown in the “venn diagram” on the slide.
Gotel and Finkelstein (1995) discuss this different roles at length in their
paper.
The attempt to understand the underlying social structure for
requirements traceability is an interesting one. However, the
implications of this work to improve requirements traceability practice
are less clear. It is possible for a cynic to say that traceability relations
are no more than relationships in a data base. However, the social
structure can be used to focus change notifications to relevant
stakeholders, to refine the types of traceability links which exist, and to
guide the requirements engineering process more widely
Another paper, this time by Ramesh et al. (1995), reports case studies
of introducing and use requirements tracing in a real project to manage
requirements for control software for an aricraft. One of the interesting
things to note from this paper is the meta-model. This model identifies
all the basic kinds of information that needs to be stored in the data
base to enable traceability. It includes information about not only
requirements, but also about stakeholders, change proposals, rationale,
constraints and designs. This is a typical meta-model for requirements
traceability which stood the test of time.
Ramesh B., Powers T. & Stubbs C., 1995, ‘Implementing Requirements Traceability: A Case Study’,
Proceedings 2nd International Symposium on Requirements Engineering, IEEE Computer Society Press,
89-95.
Reference: Neil Maiden (2011) Requirements Engineering Lecture Notes
UX Apprentice 