Suspect links

When a requirement is suspect

A requirement written from a story keeps the story's text as it was then. When the story is edited later, the requirement may no longer say what the story asks, so Entalpa marks it: the link to the story is suspect. The requirement is not wrong; it needs a second look.

• A rejected or superseded requirement is never suspect.
• A subsystem requirement traces to stories through its parent, so the mark falls on the parent.

Where you see it

• In the requirements table, the changed story's chip under Source Stories turns amber, with a warning sign.
• In the requirement's details, Story changed beside its sources names the stories.
• In the stories list, a changed story shows how many of its requirements are outdated.
• On the Overview, a next step to revisit the requirements whose stories changed.

Clearing it

• Still valid. In the requirement's details, beside Story changed: it holds for the story as it reads now. This works on a locked requirement too, and can be undone.
• Rewrite it. Editing its statement or its acceptance criteria clears the mark. Changing its status does not.
• Re-propagate the story. The outdated chip, or Re-propagate on the Overview, has AI revisit each of the story's unlocked requirements: keep it, rewrite it or drop it, as suggestions you review. Accepting a keep or a rewrite clears the mark. This uses credits.

In the Spec score

A suspect requirement counts for less in the Requirements area, unless its changed story is a Won't. It never caps the score.

For experts: traceability and change

A trace from a requirement back to its source is what lets a change be followed to what it affects. Gotel and Finkelstein (1994) call it pre-requirements-specification traceability, and found most traceability problems there. Keeping it current is the hard part: Cleland-Huang, Chang and Christensen (2003) observed that practitioners fail to update the artifacts a change affects, and proposed links that notify the artifacts depending on the one that changed. Requirements management tools call such links suspect.

Processes that have to show their changes ask for the same:

• ISO/IEC/IEEE 29148:2018 makes change management part of managing requirements (6.6.2).
• ISO 26262-8:2018, for road vehicles, has clauses on managing safety requirements (6) and on change management (8).
• Automotive SPICE 4.1 asks each level of requirements to ensure consistency and establish bidirectional traceability (SYS.2.BP5, SWE.1.BP5), noting that traceability eases the impact analysis of change requests.

Where Entalpa departs from these sources, it says so:

• Only a story's change marks a requirement. A changed system requirement does not mark the subsystem requirements under it, nor a changed subsystem its contracts.
• Any change to the story's text counts, a typo fixed included. Still valid clears the mark in one step, and changing the story back clears it too.

References

• Gotel, O. C. Z. and Finkelstein, A. C. W. (1994). An analysis of the requirements traceability problem. Proceedings of the First International Conference on Requirements Engineering (ICRE '94), 94–101.
• Cleland-Huang, J., Chang, C. K. and Christensen, M. (2003). Event-based traceability for managing evolutionary change. IEEE Transactions on Software Engineering 29(9), 796–810.
• ISO/IEC/IEEE 29148:2018. Systems and software engineering: Life cycle processes, Requirements engineering.
• ISO 26262-8:2018. Road vehicles: Functional safety, Part 8: Supporting processes.
• VDA QMC (2026). Automotive SPICE Process Assessment Model, version 4.1.