Abstract
Requirements traceability is usually treated as a process problem: teams are told to maintain links between requirements, work items, and tests, and failures are attributed to insufficient discipline. This paper argues that a large class of traceability failures is structural rather than behavioural. A requirements system involves four kinds of statements, the norm (how the system shall behave), the change (a record of one transition), the state (how the system behaves now), and the verification (a check of state against norm). These four have mutually incompatible lifecycles. Whenever two of them are carried by a single artefact, a specific and predictable failure follows, and the type of failure is determined by which pair has been conflated. We derive the necessary properties of a requirements artefact from the nature of a requirement as a normative statement, present a typology of six pairwise conflations plus one degenerate case concerning identity, associate each with an observable symptom, and illustrate the typology with an industrial case in which an organisation correctly removed one conflation and thereby created another. We close with an analysis of when conflation is a rational economy and when its cost exceeds its benefit.
1. Introduction
Every mature development organisation eventually faces a version of the same question: does the system actually do what the requirements say, and how would we know? The standard answer is traceability, a maintained web of links from requirements to design, code, work items, and tests. The research literature has treated traceability as a first-class problem for three decades, beginning with the analysis of Gotel and Finkelstein (1994), and an extensive body of work exists on link creation, link recovery, and link maintenance (Cleland-Huang, Gotel and Zisman, 2012). Industrial standards such as ISO/IEC/IEEE 29148 prescribe traceability as a quality attribute of requirements specifications.
Yet in practice traceability decays, and the decay is remarkably uniform across organisations that differ in tooling, domain, and process maturity. Teams that link tests to user stories discover, some releases later, that they cannot state what their regression suite covers. Teams that document current-system workarounds inside requirements discover that readers can no longer distinguish intent from description. Teams that renumber the steps of a specification discover that every external reference has silently shifted. These failures are usually diagnosed as lapses of discipline and answered with more process.
This paper proposes a different diagnosis. The failures above are not lapses; they are consequences. They follow deterministically from decisions about which artefact carries which kind of statement. A requirements system, whatever its tooling, must accommodate four kinds of statements with four incompatible lifecycles. An artefact can carry one of them safely. The moment it carries two, the mismatch between their lifecycles produces a specific failure mode, and that failure mode is predictable from the pair alone, before any project history exists. Traceability then fails by construction: no amount of discipline can maintain links whose anchor object is structurally unable to hold them.
The contribution of this paper is threefold. First, we derive the necessary properties of a requirements artefact from the nature of a requirement itself, rather than postulating them as best practice (Section 3). Second, we present a typology of lifecycle conflations, each with its failure mechanism and its observable symptom, which allows a practitioner to diagnose an artefact model by inspection (Section 5). Third, we present an industrial case demonstrating a non-obvious consequence of the typology: that removing one conflation, correctly and for good reasons, can create another if the underlying identity layer is not established (Section 6).
2. Related work and positioning
The traceability literature, from Gotel and Finkelstein (1994) onward, asks how links between artefacts can be created, recovered, and maintained. Its implicit premise is that the endpoints of the links are sound and the difficulty lies in the linking. This paper questions the premise: we argue that link decay is frequently caused not by weak linking practice but by endpoints whose lifecycle makes them unable to serve as stable anchors. In this sense the present work is upstream of the traceability literature, addressing the conditions under which its techniques can work at all.
The distinction between descriptive and prescriptive statements in requirements has a classical treatment in Zave and Jackson (1997), who separate indicative statements about the environment from optative statements about the desired system. We build on this mood distinction but extend it along the time axis: our four statement kinds differ not only in mood but in lifecycle, and it is the lifecycle incompatibility, not the mood difference, that generates the failure typology.
Agile methods, in dissolving the requirements document into the backlog, effectively merged the requirement into the work item; behaviour-driven development (North, 2006) proposed merging the requirement into the executable verification. Both moves are analysed here not as methodological positions to be argued for or against, but as instances of conflation whose costs and benefits can be stated precisely (Sections 5 and 7). Requirements management tooling in the DOORS tradition provides unique identifiers for requirement objects; we note in Section 4 that an identifier scheme does not by itself prevent conflation, since the failure lies in what the identified object carries, not in whether it has a name.
3. The nature of a requirement and its necessary properties
A requirement is a statement about system behaviour that claims validity without a time bound. It asserts how the system shall behave, not how it behaved during an iteration, and not until a date. It is a normative statement, in the sense that it can be violated by the system but not falsified by it: a discrepancy between system and requirement is a defect of the system or a decision point for the requirement’s owner, never automatically a correction of the requirement.
From this nature, several properties follow. They are not conventions and not best practices; each is entailed by what a requirement is.
First, a requirement must possess identity separate from its content. The statement is refined, reworded, and corrected over its life while remaining the same statement. If identity were bound to content, every editorial improvement would create a new requirement and orphan everything attached to the old one.
Second, that identity must be separate from position. Requirements live inside compositions, documents, flows, and hierarchies, and compositions are reorganised. If identity were positional, every reordering would silently retarget every external reference, which is a worse failure than breaking them, because it is undetectable.
Third, a requirement must have no terminal state. A norm does not close. An artefact that is sometimes finished, resolved, or done cannot carry a requirement, because at the moment of closure the requirement either dies with it or must migrate, and migration under deadline pressure does not happen.
Fourth, the granularity of the requirement artefact must match the granularity at which the system is changed and verified. Work items and test cases attach to requirements; if the requirement object is coarser than the unit of change or the unit of verification, the attachment is forced upward to an object that contains many behaviours, and precision is lost exactly where it is needed.
Fifth, the requirement must be segregated from statements of fact about the current system. The two have different truth conditions: the norm is violated by reality, the description is falsified by it. Housing them in one field is a category error whose practical consequence is documented in Section 5.
4. Four participants and one anchor
A requirements system in operation involves four kinds of statements. We name them for use throughout.
The norm: how the system shall behave. Prescriptive. Permanent, refined but never closed, exactly one valid formulation at any moment.
The change: a record of one transition from one intended or actual behaviour to another. Historical once executed. Finite: it opens, it is done, it closes, it accumulates. In most organisations this is the user story, the change request, or the defect fix.
The state: how the system behaves now. Descriptive. Permanent but mutable: it exists continuously and is rewritten by every deployment, including deployments that fail or partially succeed. Crucially, the state is not the sum of executed changes; changes are applied with defects, reverted, and overridden, so the state must be recorded, not derived.
The verification: a check of whether the state conforms to the norm. Repeatable. It exists as long as the norm exists and is re-executed indefinitely; a verification that runs once is a change acceptance, not a verification.
These four lifecycles are pairwise incompatible: permanent versus finite, prescriptive versus descriptive, once versus repeatedly. No artefact can carry two of them without one lifecycle deforming the other.
There is a fifth element, which is not a statement but an anchor: identity. Identity is a meaningless, never-reused referent to which all four statement kinds attach. The norm is the content of the identity; the change points at it; the state is recorded against it; the verification targets it. Identity must be reified as its own element with its own rules (meaningless, immutable, never recycled, longer-lived than anything referencing it).
The central observation of this paper is that identity cannot be left implicit. If it is not reified, its role is usurped by whatever is available, typically the position of a step within a document or the key of a work item, and both usurpers have lifecycles fatal to the role, as the typology shows.
A note on tooling: assigning unique identifiers to requirement objects, as requirements management tools have done for decades, establishes identity only if the identified object carries the norm alone. An identifier attached to an object that also carries the change inherits the change’s mortality; the identifier then names a closed historical record, not a living norm. Identifiers are necessary for identity, not sufficient.
5. A typology of conflations
Each pairwise conflation of the four statement kinds produces a distinct failure with an observable symptom. The symptoms are important: they can be detected in a project’s artefacts by inspection, without interviewing the team and without the team acknowledging a problem, which moves the typology from opinion to testable claim.
5.1 Norm with change
The requirement is written inside the work item: the user story is the specification. The norm inherits the change’s finite lifecycle. When behaviour must be modified, the author faces a dilemma with no good branch: rewrite the closed story, and the historical record of what was delivered is falsified; write a new story, and the currently valid formulation of the behaviour is scattered across the delta chain.
Symptom: to learn how a single field or function behaves, a reader must locate and chronologically read N closed work items, and the number N grows with every release. A secondary symptom is the appearance of annotations inside old items marking which parts are superseded.
5.2 Norm with state
Prescriptive and descriptive statements share one text without a marker distinguishing them. This typically begins innocently: a workaround is documented where the reader will look for it, inside the requirement. The category error compounds silently, because both statement kinds are individually legitimate and the text remains locally readable.
Symptom: lexical markers of temporality and factuality inside requirements text, “for the time being”, “currently the system”, “as a temporary solution”, “requires a big change”. After enough accumulation, a reader can no longer determine which sentences the system is obliged to satisfy and which merely report that it does not.
5.3 Norm with verification
The requirement exists only as its executable check, the position of specification by example taken to its limit. The norm inherits the verification’s constraint of executability.
Symptom: behaviours that are hard to automate are undocumented, and refactoring of the test suite silently amends the specification, since there is no second artefact against which the amendment could be noticed.
5.4 Change with state
The current state of the system is not recorded anywhere; it is derived on demand by replaying the change history. This works while the history is short and clean, and fails as soon as changes have been delivered partially, delivered with defects, or reverted, because the derivation assumes every closed change is fully and correctly in force.
Symptom: the question “does this work in production?” is answered by release archaeology, and after several waves the answers produced by different people diverge.
5.5 Change with verification
Tests attach to work items. The verification inherits the change’s mortality: when the story closes, the object the test points at becomes a historical record, and the test’s ongoing subject, the behaviour, has no representation.
Symptom: the regression suite is unmappable. Nobody can state which behaviours are covered, because coverage is expressed in terms of deliveries, and deliveries do not partition behaviour. Testers ask, repeatedly and legitimately, “what do I attach this test to?”, and the question has no answer inside the model.
5.6 State with verification
Test results are treated as the description of the system: what passed, works; what was not tested, does not exist in the description.
Symptom: absence of a failure is read as conformance. Gaps in test coverage become invisible gaps in the organisation’s knowledge of its own system, discovered only in production.
5.7 The degenerate case: identity with position
Not a pairwise conflation of statements but the usurpation of the anchor. No identity element is reified, and its role is taken by position in a composition: step 5 of the flow, section 3.2 of the document. Position has the wrong invariance class for identity, since compositions are reorganised as a normal editorial act.
Symptom: reference drift. After an insertion or reordering, every external reference to “step 5” points at different behaviour than before, the documents remain internally consistent, and nothing signals the shift. This is strictly worse than broken references, which at least announce themselves.
The typology supports a diagnostic method: given an artefact model, list which statement kinds each artefact carries; every artefact carrying two predicts its symptom; the symptoms can then be checked against the project’s actual artefacts. The prediction precedes the observation, which is what distinguishes a structural account from a post-hoc narrative.
6. Case: removing one conflation, creating another
The case concerns a large, long-lived regulatory information system developed for a public-sector client, with a specification corpus of several hundred documents and a change process driven by formal change requests. Details are anonymised; the structure of the episode is what matters.
In the organisation’s first model, the specification was assembled from work items. Each step of each behavioural flow was a user story in the tracking system; the specification document was generated by a query that collected the stories, selected by labels and epic membership, and ordered them by a business-identifier field. The document was therefore always current and required no manual assembly. The model conflated norm with change (Section 5.1) and, as a side effect, change with verification (5.5), since tests attached to the same stories.
The predicted symptoms appeared. Modifications to existing behaviour had nowhere to sit: the affected stories were closed, so changes were recorded as annotations inside them, second rule references appended beside original ones, developer notes marking which parts were impacted. Norm with state conflation (5.2) followed as a secondary infection: since no other location existed, descriptions of the current partial implementation, explicitly marked “for the time being”, were written into the requirement text itself. After several change waves, a reader could not determine from the specification which behaviour applied generally, which applied to a variant, and since when.
The organisation’s response was correct in its central move: the specification was separated from the work items. Behavioural flows became manually authored documents with numbered steps; stories reverted to being pure deltas, linked to the document but no longer constituting it. The norm-with-change conflation was removed, and with it the rewrite dilemma of Section 5.1.
But the identity layer was not reified. In the old model, identity had been carried, imperfectly but adequately, by the work item key and the business-identifier field. In the new model those disappeared with the stories, and nothing replaced them. The role of identity fell to step position within the document, producing the degenerate case of Section 5.7, and three statement kinds lost their target simultaneously: changes could reference only the whole document, the state of implementation could be recorded nowhere below document granularity, and verifications had nothing durable to attach to. The predicted symptoms appeared within months, most visibly as a stream of tester questions, “what do we attach tests to now?”, directed at the analysts, since only the analysts could answer by memory.
Two lessons generalise. First, a correct removal of one conflation can create another if identity is left implicit, because identity’s role does not disappear, it migrates to the nearest available structure. Second, the direction of reform matters less than its completeness: both the old and the new model failed, in opposite ways, for the same root cause, the absence of a reified, meaningless, closure-free referent at the granularity of change and verification.
It is worth recording what the eventual stabilisation required, because it was small: a stable reference column added to the flow tables, with three rules, references are never renumbered, never reused, and change only when the behaviour itself changes rather than its wording, the practical criterion for the last rule being whether an existing verification remains valid. No new tooling and no new artefact type were needed. The deficit was never technological.
7. When conflation is rational
The typology should not be read as a prohibition. Conflation is an economy: four separated elements cost four objects’ worth of authoring, linking, and maintenance, and for many systems the economy is sound. A short-lived product, a system with low change traffic on existing behaviour, or a team small enough that the state of the system fits in working memory, all of these can run norm-with-change, the story as the specification, indefinitely and never pay the price, because the price is only charged on the second modification of the same behaviour and on the first regression question.
The cost curve is driven by three variables: expected system lifetime, the rate of change to existing behaviour as opposed to addition of new behaviour, and the ratio of the verification corpus to team memory. Conflation costs grow with all three. A practical decision rule follows: separate the four elements, and reify identity, at the point where the same behaviour is expected to be modified more than once and verified indefinitely. Before that point, separation is ceremony; after it, conflation is debt with compound interest, paid in exactly the symptoms of Section 5.
The rule also explains the recurring industry oscillation between heavyweight requirements management and backlog-only specification. Both camps are right about the failure of the other, because each has observed a real conflation cost, and both are wrong to universalise, because the variables above differ across contexts. The question “is the user story a requirement?” has no general answer; it has a computable one.
8. Limitations and further work
The case evidence is a single organisation observed by a participant, which suffices to illustrate the typology but not to establish frequency. The symptoms of Section 5 are, however, designed to be detectable by artefact inspection: lexical temporality markers in requirements text (5.2), test-to-work-item link topology (5.5), reference drift across document versions (5.7). A natural next step is a multi-project audit applying these detectors to specification corpora, testing whether the predicted symptom, and only the predicted symptom, co-occurs with each conflation. A second direction is economic: operationalising the decision rule of Section 7 against measurable change-traffic data.
9. Conclusion
Traceability is usually prescribed as a discipline and fails as one. This paper has argued that the failure is frequently upstream of discipline: it is decided at the moment an artefact model assigns two of the four statement kinds, norm, change, state, verification, to a single artefact, or leaves identity to be usurped by position. Each such assignment carries a failure mode that is predictable in advance and observable in the artefacts. The practical corollary is compact enough to state in one sentence: give every behaviour a meaningless, immortal, never-reused referent at the granularity at which the system is changed and verified, attach everything else to that referent, and never let one artefact carry two lifecycles.
References
- Cleland-Huang, J., Gotel, O. & Zisman, A. (eds.) (2012). Software and Systems Traceability. Springer.
- Gotel, O. & Finkelstein, A. (1994). An analysis of the requirements traceability problem. In Proceedings of the First International Conference on Requirements Engineering. IEEE.
- ISO/IEC/IEEE 29148 (2018). Systems and software engineering, Life cycle processes, Requirements engineering.
- North, D. (2006). Introducing BDD. Better Software Magazine.
- Zave, P. & Jackson, M. (1997). Four dark corners of requirements engineering. ACM Transactions on Software Engineering and Methodology, 6(1), 1-30.