Requirements traceability and change impact: link needs, requirements, design and tests

What requirements traceability is

A requirement rarely stands alone. It answers a stakeholder need, it may be developed into lower-level requirements, a function or component carries it out, and a test or analysis checks it. Traceability is the set of explicit, recorded links between those items. Each link names its two ends and says what the relationship is: "3.1 Orbit Average Power is satisfied by 1.3.1 Solar Arrays" is a trace; a sentence in a design report that mentions the arrays is not.

The links form a web that runs from stakeholder needs, through system and subsystem requirements, to the architecture and to verification. ISO/IEC/IEEE 15288 asks for this web in several technical processes: stakeholder needs are traced to the requirements that formalize them, system requirements are traced to the architecture elements they are allocated to, and every requirement is traced to the activity that verifies it. The INCOSEInternational Council on Systems Engineering The professional society for systems engineering. It publishes the Systems Engineering Handbook. Systems Engineering Handbook treats traceability as a property that a good requirement set has as a whole, not as a separate document produced at the end.

Why trace requirements: change impact first

Links take effort to create and more effort to keep correct, so it helps to know what they pay for. Four uses carry most of the value, and the first one is the reason most teams start.

• Change impact. Before a change, the links show what it reaches: which lower-level requirements, functions, components, analyses and tests depend on the item being changed. After the change, the same links tell the team what to check again. Without them, the answer depends on who remembers the design.
• Coverage. Every requirement should be fulfilled by something in the design and checked by something in verification. Links make the missing ones visible, long before an integration test or a customer finds them.
• Compliance and justification. Contracts, safety standards and reviews ask for evidence that each requirement is met and that nothing in the design exists without a reason. A trace from need to requirement to design to test is that evidence.
• Change control. When a requirement changes after it was agreed, the items linked to it must be reviewed, and the review must be recorded. Links tell the change board what to re-review and let the team show that the review happened.

A team that traces only for an audit at the end of a phase gets the cost without most of the benefit. Links made while the requirements and the design are written are cheaper to create and are there when a change arrives. A change-impact answer is also only as complete as the links: an item that should be linked and is not is invisible to it, as the worked example shows.

Needs and requirements

Traceability starts above the requirements. A need is what a stakeholder expects of the system, in the stakeholder's terms: "Farm customers need fresh imagery of their fields at least twice a week in the growing season." A requirement is the engineering statement that the system will be built and verified against: "The mission shall revisit each target region within 72 hours."

The two differ in purpose and in form:

The first trace links each need to the requirements that formalize them. A need with no requirement is a stakeholder expectation the design will not address. A requirement with no need, at the top level, is either a hidden assumption that should be written down as a need or a requirement nobody asked for.

The kinds of trace links

Most methods and tools use a small set of link types. The names differ between them, but the meanings are stable. Each type answers a different question, and using the most specific type that is true makes the links useful to reports and checks. The examples come from the CubeSat used later in this guide.

Three notes on the table. A derived requirement is a new statement that the parent makes necessary; a decomposed one is a part of the parent, and the parent is met when its parts are. Allocation and satisfaction are often used as synonyms; some methods allocate a requirement to a component and then say the component's design satisfies it, which is a distinction worth keeping only if the team actually reviews the two separately. And a plain trace is the weakest link: it says the two items are related, not how. It suits need-to-requirement links and early, unsettled allocations; replace it with a specific type once the relationship is decided.

Direction

Every link has a direction, and the convention most teams use points from the item that drives to the item that responds: from need to requirement, from parent requirement to derived requirement, from requirement to the design element and to the test. A link can be read from either end ("3.1 is satisfied by the solar arrays", "the solar arrays satisfy 3.1"), but it is one link, recorded once.

The direction is what makes change impact work. A change at the upstream end puts every item downstream of it in question; a change at the downstream end usually does not invalidate the requirement above it, although it may mean the design no longer satisfies it. Tools that flag links after a change rely on this direction to decide which end to flag.

SysMLSystems Modeling Language A graphical modeling language for systems engineering, based on UML, with block, activity, state machine and parametric diagrams. users will know these links as stereotyped dependencies: «deriveReqt», «refine», «satisfy», «verify» and «trace». In SysML the arrow is drawn from the dependent element to the requirement (the test case points to the requirement it verifies), which is the reverse of the reading above. The meaning is the same; only the drawing convention differs. The SysML v2 tutorial shows how satisfy and verify are written in the textual notation.

Forward and backward traceability

Traceability is checked in two directions.

• Forward (downward): from each need to the requirements that cover it, from each requirement to the design elements that satisfy it and the tests that verify it. Forward tracing answers "is everything we were asked for built and checked?"
• Backward (upward): from each test, function or component back to the requirement it serves, and from each requirement back to a need or a parent requirement. Backward tracing answers "does everything we built have a reason?"

A requirement set is bidirectionally traceable when both hold. In practice, forward gaps show missing work and backward gaps show extra work: gold plating, design elements kept from an earlier product, tests that check nothing anyone asked for, or a requirement that someone added without a source.

Coverage gaps and orphans

The two failures of a trace web have names.

• A coverage gap is a requirement without a link it should have: a leaf requirement satisfied by nothing, or verified by nothing. Check leaf requirements, the ones with no child requirements. A parent is covered through its children, and requiring a direct link on the parent produces duplicate links.
• An orphan is an item without an upstream link: a function, component or analysis that satisfies no requirement, a test case that verifies none, or a derived requirement with no parent. An orphan is not always wrong. A flight spare exists for the integration campaign, and the fix may then be a missing requirement, not a deleted item. Either way, an orphan is a question the team has to answer.

Coverage numbers ("94 percent of leaf requirements allocated") are useful for tracking progress, but the list of uncovered items is what the team works from. A gap is closed by adding the missing link, by deciding that the requirement is not a leaf, or by deleting a requirement that is not needed.

Orphans matter for change impact too. An item that should answer to a requirement but has no link will not be flagged when that requirement changes. The example below has one.

Suspect links after a change

A link records a judgement made at a point in time: "this component, as designed, fulfills this requirement, as written." When the requirement's text or its values change, that judgement may no longer hold. A suspect link is a link whose upstream end changed after the link was last reviewed. The link is not deleted or assumed broken; it is flagged until someone looks at the item at its other end and decides.

Clearing a suspect link is a small review:

1. Read what changed: the old and new text, or the attribute that moved.
2. Check the item at the downstream end. Does the derived requirement still follow? Does the component still fulfill the requirement? Does the test still check the new value?
3. If it still holds, clear the flag and record why, for example "Function text has no power value; no change needed."
4. If it no longer holds, change the downstream item (or raise a change against it), then clear the flag. If the link itself is no longer true, remove it.

The record matters as much as the decision. A cleared suspect link with a comment and a name is evidence for the next review that the change was followed through; a flag cleared in bulk without a look is worse than no flag, because it claims a review that did not happen.

Not every edit needs to raise flags. Fixing a typo in a requirement's name should not send twenty items into review, while changing a power level from 28 W to 30 W must. Tools draw that line differently; the useful question is whether a change could make a downstream judgement wrong.

The traceability matrix

A traceability matrix shows the links between two sets of items as a grid: requirements in the rows, for example, and functions, components or test cases in the columns. A mark in a cell means the row and column are linked. A table with one row per requirement and a column listing its linked items is often called a traceability matrix too (the download below has that form); the grid form is easier to scan for gaps, because an empty row or column stands out.

Reading a matrix:

• An empty row is a coverage gap: a requirement linked to nothing in the columns.
• An empty column is an orphan: a function, component or test that no row links to.
• A row with many marks may be a requirement that is too broad and should be split.
• A column with many marks is a design element that many requirements depend on; a change to it has a wide impact.

A matrix is a view of the links, not where they live. Teams that keep the links in a spreadsheet maintained by hand find that the spreadsheet and the design drift apart; a matrix generated from a model is always as current as the model.

A requirements verification matrix is a related view that lists each requirement with its verification method, the verifying activity and its result. It is the verification side of the same links; the requirements verification matrix (RVTM) guide covers it on the same CubeSat.

Worked example: the EO-1 CubeSat

The example is EO-1, a fictional 6U CubeSat that images farmland in four spectral bands. It is the same model as the end-to-end MBSE example project, built in Holarch as an LMLLifecycle Modeling Language An open modeling language with a small set of classes and relationships that covers a system's whole lifecycle. Holarch models are LML models. project: requirements are Requirements in the specification SRS-001 EO-1 System Requirements Specification (32 of them), functions are Actions numbered F1 to F11 with subfunctions, components are Assets, and tests are Test Cases TC-01 to TC-20. The functions come from the functional analysis of the same mission.

Needs and requirements

The demo records where each requirement came from in a Source attribute: Customer Needs Statement CNS-1, Mission Concept Review or Derived (systems analysis). An attribute names a document; it cannot be followed, counted or flagged. For this guide, three stakeholder needs from the customer workshop were added to the model as Statements and traced to the requirements that formalize them. N1 to N3 are the only items added; everything else is the demo as built.

Below the needs, the specification uses all three requirement-to-requirement links. 1.6 Revisit Time is decomposed into 1.6.1 Ground Track Repeat (3 days) and 1.6.2 Off-Nadir Imaging (25 degrees): together they deliver the 72 hour revisit. 3.1 Orbit Average Power is derived from 1.5 Daily Collection Volume, and 3.3 Depth of Discharge from 1.7 Mission Lifetime: no customer asked for a power level or a battery limit, but the imaging volume and the 730-day life cannot be met without them. A requirement such as 3.1 therefore has no need above it, and that is correct: its parent is another requirement.

The links of the power requirements

Section 3, Electrical Power, is a good slice to read closely. The table lists what satisfies and verifies each requirement, from the model:

F3 Generate and Store Power satisfies four requirements, and its subfunctions F3.1 to F3.3 split them between the arrays, the battery and the power distribution unit. The power lines that satisfy 3.4 are interfaces; the interface control document guide follows them into the ICDInterface Control Document The agreed definition of an interface between two systems: what crosses it, how, and who owns it. Holarch also has an Interface Control Diagram..

Reading the matrix: a gap and an orphan

With the six power requirements in the rows and the design and test items in the columns, the matrix (6 rows, 17 columns, 21 links) shows at a glance:

• 3.5 Battery Thermal Control is a coverage gap: its row is empty. Nothing in the design keeps the battery warm and no test checks it. The requirement is also weak ("keep the battery warm enough (TBDTo Be Determined A requirement value or detail that is not known yet. Holarch tracks TBDs with an owner and a due date.)"), and the two problems are linked: a requirement without a value is hard to allocate and impossible to test. The checklist below rewrites it.
• EQ-1.3 Orbit-Average Array Power is an orphan: its column is empty. It computes the orbit-average array output from the peak power, the sunlit fraction and the power path efficiency, which is exactly the quantity 3.1 constrains, yet it satisfies no requirement. Its sibling EQ-1.4 Power Margin Check is linked to 3.1; EQ-1.3 was missed.
• F3 Generate and Store Power carries four requirements, so a change to it reaches all four. TC-07 verifies two (3.2 and 3.3).
• The verification cells show test status: TC-06, TC-07 and TC-18 passed, TC-19 has not run. Coverage and verification status are different questions: 3.6 is covered by a test that has not been run yet.

Across the whole specification, the same check finds six leaf requirements with gaps: 2.5 Safe Mode Recovery, 3.5 and 6.4 Operator Interface are neither satisfied nor verified, and 1.5 Daily Collection Volume, 4.4 Downlink Encryption and 6.5 Planning Cycle Time are satisfied but not verified. 1.6 Revisit Time has no test of its own and is not a gap: it is a parent, covered through 1.6.1 and 1.6.2. Outside the power slice, S-1 Spare Reaction Wheel has no links at all, a typical orphan with a good reason (a flight spare for integration) that still deserves a decision on the record. The parts 1.2.1 Reaction Wheel Assembly and 1.2.2 Star Tracker satisfy no requirement directly but perform functions that do, so they trace indirectly; a check that looks only at direct links would call them orphans by mistake.

Change impact: 3.1 goes from 28 W to 30 W

After the Preliminary Design Review, the orbit-average load grew from 24 W to 26 W. To keep the same 15 percent margin, requirement 3.1 changes from "at least 28 W" to "at least 30 W orbit-average power at end of life", with the rationale "Orbit-average load grew to 26 W after PDRPreliminary Design Review A milestone review that confirms the preliminary design meets the requirements and is ready for detailed design.; 30 W keeps 15% margin." (26 W × 1.15 = 29.9 W, rounded up to 30 W; the old value was 24 W × 1.15 = 27.6 W, rounded up to 28 W.) The same change runs through the MBSE example project.

Follow the links from 3.1 in the direction of the change. Everything that satisfies or verifies 3.1 was judged against 28 W, so six links become suspect. The link to 1.5 Daily Collection Volume does not: 1.5 is upstream (3.1 was derived from it) and did not change.

In the matrix, the six cells on the 3.1 row now show the suspect mark instead of a dot or a test result, so a reader of the matrix cannot mistake TC-06's old "Passed" for evidence against the new value.

Each suspect link is then reviewed, and the TC-06 review shows why the flags exist. TC-06 measured 75.1 W peak power on the solar simulator and passed against its 72 W limit. The model converts peak power to orbit average with EQ-1.3: P_oa = P_gen × F_sun × K_path, with a sunlit fraction of 0.62 and a power path efficiency of 0.6. That gives 75.1 W × 0.62 × 0.6 = 27.9 W orbit average, below the new 30 W. To show 30 W, the arrays need about 30 / (0.62 × 0.6) = 80.6 W peak. The old "Passed" cannot carry over to the new value, so the TC-06 link is not cleared. It stays suspect, with the comment "75.1 W peak gives 27.9 W orbit average by EQ-1.3; 30 W needs about 80.6 W peak. Re-test or re-analyse at the new value before clearing." The same arithmetic shows the original pass was marginal: 27.9 W is also just under the old 28 W.

The rest follows from that finding. The solar arrays (75.4 W peak in the model, 28.0 W orbit average by the same formula) and EQ-1.1 stay flagged until the array sizing is re-done; the team may need more cell area, better cells or a relaxed requirement, and that is a decision for the change board, not for the person clearing flags. F3 and F3.1 are cleared once the team confirms the function descriptions hold no power value. Meanwhile 3.1, which was Approved, goes back to In Review because its text changed after approval. Without the suspect flag, TC-06 would still read "Passed" next to a requirement it no longer proves.

Now look at what the flags missed. EQ-1.3 Orbit-Average Array Power computes the very quantity that changed, and it is the equation that exposed the TC-06 shortfall, but it has no link to 3.1, so nothing flagged it. A reviewer who looked only at the flagged items could have cleared TC-06 against its 72 W peak limit and never run the conversion. That is the engineering consequence of an orphan: change impact is computed from the links, and a missing link is a blind spot. The fix is one link, EQ-1.3 satisfies 3.1, made before the next change.

The same set can be found before a change is approved: an impact analysis from 3.1 one level out shows the six items, which is how a change board sizes the review work before it says yes.

Download the traceability table and the checklist

• EO-1 requirements traceability matrix (CSV): all 32 requirements of SRS-001 after the change, one row each, with status, source, parent and children, derived from and derived by, refined by (unused in this model), satisfied by (functions, components, other), verified by with the test status, a coverage verdict, and the six suspect links on 3.1. It was generated from the demo model, so it matches the matrix above. The needs N1 to N3 added for this guide are not in it.
• Requirement quality checklist with EO-1 before-and-after examples (CSV): the checklist below, for use in a review.

Requirement quality checklist

Traceability depends on the quality of the statements at each end. A vague requirement cannot be allocated or verified, so it shows up as a coverage gap; a requirement without a rationale cannot be judged when a suspect flag asks whether the downstream item still holds. The EO-1 specification has three weak requirements on purpose (2.5, 3.5 and 6.4); the rewrites below show the fix. Values marked illustrative are examples of the form, not values from the EO-1 analyses.

Common mistakes

A word on verification

A verify link answers whether a requirement is covered by a verification activity; it does not say whether the requirement is met. That comes from the activity's result: TC-04 Pointing Accuracy Test verifies 2.1 and failed. Planning the method for each requirement (test, analysis, inspection or demonstration), running the activities and rolling the results up the requirement hierarchy is the job of a requirements verification matrix. A verifying activity can also be an analysis or a simulation; the MBSEModel-Based Systems Engineering Systems engineering that keeps requirements, behavior, structure and tests in one connected model instead of separate documents. example estimates 6.5 Planning Cycle Time with a simulation of the imaging pass, and the Monte Carlo guide explains how such a result is read. The trace links described here are its input.

Try it in Holarch

In an LMLLifecycle Modeling Language An open modeling language with a small set of classes and relationships that covers a system's whole lifecycle. Holarch models are LML models. project, every trace is a relationship between two entities, and a link made in one place shows in the inspector, the matrix, the Spider and Requirement diagrams and the RVTMRequirements Verification Traceability Matrix A table of each requirement with how it is verified, the tests that verify it and their latest result..

1. Create the demo with Manage Projects → Project Files ▾ → New Demo Project. Its specification already holds the change to 3.1 and the six suspect links.
2. Open Verification → Traceability Matrix. Click the Rows chip and set the query class:Requirement AND number:3.*; click the Columns chip and set a query such as class:Action OR class:TestCase.
3. Tick Gaps only to see the rows without links. Choose a relationship such as satisfied by and click an empty cell to create a link, for example EQ-1.3 to 3.1.
4. Open Needs & Requirements → Suspect Links, click Diff on a row, then Clear… with a comment.
5. Click Export… in the matrix for the grid as Excel or CSV.

Verification → Model Checks lists leaf requirements that are not allocated or not verified, and an entity's Open in ▾ → Spider runs an impact analysis before a change. The full reference is in Traceability, and the suspect-link rules in suspect links.

Where to go next

• Needs and requirements in Holarch: documents, quality checks, baselines and traceability in one model.
• Traceability docs: relationship types, the Traceability Matrix, the Spider diagram and coverage checks.
• Requirements docs: writing, approving and baselining requirements, and the Suspect Links page.