Requirements Engineering and Traceability

Requirements engineering is the discipline that turns objectives, constraints, regulations, and stakeholder needs into a controlled technical basis for design, verification, validation, and certification.

For complex systems, the main difficulty is rarely writing individual requirements. It is maintaining coherence between thousands of requirements, interfaces, changes, tests, documents, and external obligations over time.

Traceability is therefore not administrative overhead. It is part of the technical architecture of the project.

Requirements may originate from several layers:

• customer needs;
• system and subsystem specifications;
• safety analyses;
• operating scenarios;
• interface definitions;
• standards and regulations;
• certification requirements;
• supplier constraints;
• design decisions;
• lessons from validation and operation.

These sources have different authority and different update processes.

A useful requirements baseline must preserve that distinction.

A requirement should be:

• necessary;
• unambiguous;
• verifiable;
• consistent with related requirements;
• sufficiently precise for its intended level;
• attributable to a source;
• assigned to the correct system level.

A statement can be technically plausible and still be a poor requirement if its acceptance criterion is unclear.

Words such as "sufficient", "appropriate", "rapid", or "robust" require an explicit interpretation if they are used as contractual or verifiable requirements.

Traceability links requirements to the engineering artifacts that justify, implement, verify, or constrain them.

A typical chain is:

Bidirectional traceability is important.

It should be possible to answer both:

• Why does this requirement exist?
• Which evidence demonstrates that it is satisfied?

A traceability matrix is useful only if the links are meaningful and maintained.

Certification projects introduce an additional requirements layer.

Regulatory texts contain obligations that must be interpreted and mapped to the project architecture.

The engineering task is not simply to copy regulatory paragraphs into a database.

It requires:

• identifying applicable clauses;
• interpreting their technical intent;
• determining project applicability;
• allocating obligations to systems or documents;
• linking them to project requirements;
• identifying the expected conformity evidence;
• controlling deviations and open points.

For railway projects, this may include Technical Specifications for Interoperability (TSIs), French national technical rules, and requirements agreed with conformity-assessment bodies and the operator.

IBM DOORS is commonly used to manage controlled requirement sets and traceability.

Typical engineering tasks include:

• importing and structuring requirement modules;
• defining attributes;
• linking requirements across levels;
• maintaining baselines;
• tracking changes;
• filtering by applicability or status;
• extracting review sets;
• comparing external requirements with project requirements.

The tool is useful because it preserves structure and traceability, but the quality of the result still depends on the engineering model behind the database.

A database full of links is not automatically a traceable system.

One recurring problem is checking whether a project requirement set correctly covers an external regulatory or contractual source.

A useful comparison workflow can contain:

1. normalisation of external requirements;
2. identification of candidate project requirements;
3. comparison of wording and technical intent;
4. classification of coverage;
5. review of missing or ambiguous mappings;
6. preservation of the result as auditable evidence.

Possible coverage states include:

• covered;
• partially covered;
• not covered;
• not applicable;
• covered indirectly;
• requires clarification.

The categories must be defined before automation is introduced.

Python can reduce the manual cost of requirements analysis.

Useful automation includes:

• extracting structured requirement data;
• normalising identifiers and text;
• detecting duplicates;
• comparing revisions;
• checking missing links;
• generating review tables;
• identifying suspicious changes;
• preparing reports;
• preselecting candidate mappings.

Automation should support engineering judgement rather than silently replace it.

A semantic similarity score, for example, can identify candidate matches. It cannot by itself demonstrate regulatory compliance.

Requirements are not static.

A change may affect:

• downstream requirements;
• interfaces;
• design assumptions;
• verification procedures;
• test results;
• certification evidence;
• supplier commitments.

The impact of a change therefore depends on the traceability graph.

A robust change process should identify affected artifacts before the new baseline is accepted.

A baseline defines a controlled project state.

Without baselines, statements such as "the requirement was verified" are ambiguous because the requirement may have changed after the test.

Each evidence item should be interpretable relative to a known version of:

• the requirement;
• the system configuration;
• the test procedure;
• the software or hardware under test;
• the applicable external reference.

Version control is therefore as important for requirements and evidence as it is for software.

Many system failures are interface failures.

Requirements engineering must make interfaces explicit:

• physical interfaces;
• electrical interfaces;
• communication interfaces;
• functional interfaces;
• organisational interfaces.

An interface requirement should specify not only what crosses the boundary but also the assumptions made by both sides.

This becomes especially important when several organisations develop different parts of the system.

A requirement should normally have an intended verification method.

Common methods include:

• test;
• analysis;
• inspection;
• demonstration;
• review of design evidence.

The verification method must be compatible with the wording of the requirement.

A requirement that cannot be verified using the proposed evidence should be reworked before the end of the project.

Requirements coverage is not equivalent to successful tests.

A complete evidence picture asks:

• Is every applicable requirement linked to evidence?
• Is the evidence valid for the current configuration?
• Does the evidence actually test or demonstrate the requirement?
• Are deviations closed?
• Are assumptions explicit?
• Are inherited or external evidence items controlled?

Coverage metrics are useful for completeness checks but cannot determine technical adequacy.

Independent review remains essential.

Useful review questions include:

• Is the source requirement interpreted correctly?
• Is applicability justified?
• Is the project requirement equivalent in intent?
• Is the evidence sufficient?
• Is the configuration controlled?
• Is a deviation hidden behind a status field?
• Has a requirement been marked complete only because a link exists?

These questions cannot be reduced to database consistency checks.

A requirements-analysis workflow should be reproducible.

For automated processing, this means preserving:

• input exports;
• scripts;
• configuration;
• mapping rules;
• output reports;
• review decisions;
• timestamps or baseline identifiers.

The objective is to make an analysis reviewable months or years later, not only repeatable on the engineer's workstation today.

The main principles I use are:

• preserve the source and authority of each requirement;
• make applicability explicit;
• maintain bidirectional traceability;
• distinguish text similarity from technical equivalence;
• link evidence to controlled baselines;
• automate completeness checks before interpretation;
• preserve human review for technical judgement;
• treat changes as graph-wide impacts rather than isolated edits;
• make every conformity conclusion auditable.