Engineering

Engineering is the construction of justified confidence under constraints. A system is not acceptable because its design appears plausible or because a test campaign produced many documents. The relevant question is whether the available evidence supports the claims made about the system, within a clearly defined configuration and domain of use.

From needs to evidence

A useful engineering chain connects:

  1. stakeholder needs and operational context;
  2. system requirements and interfaces;
  3. architecture and implementation decisions;
  4. verification and validation activities;
  5. anomalies, assumptions, and residual limitations;
  6. evidence supporting acceptance or certification.

Weakness in one link cannot be repaired by adding volume elsewhere. A precise test report does not compensate for an ambiguous requirement, and complete traceability does not prove that the traced items are correct.

Requirements and traceability

A requirement should identify an observable obligation and the conditions under which it applies. Traceability then records relationships between needs, requirements, design elements, tests, results, and changes.

Traceability is valuable when it supports impact analysis and review. It becomes bureaucratic when links are created only to satisfy a metric. The quality of the relationship matters more than the percentage of populated cells.

Verification and validation

Verification asks whether the specified solution was implemented correctly. Validation asks whether the resulting system addresses the intended use and operational need. The distinction is simple in theory but easily blurred in large projects, especially when contractual, regulatory, and technical acceptance activities overlap.

Certification

Certification is a structured demonstration against an applicable framework, not a final proofreading exercise. Evidence must be consistent with the declared configuration, produced by controlled processes, and reviewed with an appropriate degree of independence.

My professional experience in railway projects has made documentation itself a technical object: identifiers, baselines, interfaces, anomalies, versions, and approval states affect the validity of the argument.

Pages