06 — Requirements and technical specifications

A requirement establishes an obligation that engineering must satisfy. Before choosing a radiator, releasing a bracket or asking a supplier to design a harness, the business needs to know the required outcome, the conditions under which it applies and how satisfaction will be judged. Otherwise teams can deliver technically competent work against different understandings of the product.

In the four-vehicle programme, customer requirements are captured in DOORS and continue to change during design. Capturing a request does not accept it. An agreed requirement revision, an approved technical solution and permission to amend a contract are separate decisions. Keeping them separate allows engineering to investigate alternatives without accidentally committing the business to an unassessed obligation.

From a request to an assessable obligation

“Operate in a hot climate” communicates a concern but does not yet define an acceptance basis. The requirements engineer works with the customer and technical specialists to establish the environment, duty, payload, operating modes, relevant limits and intended duration. No numerical values should be invented merely to make a requirement look complete. An unresolved value remains a named issue with an owner, required decision date and identified commitments that depend on it.

A useful requirement states the subject, required outcome or constraint and applicable conditions. Its associated record identifies source, rationale, owner, revision, applicability and verification approach. Rationale explains why the obligation exists without becoming an extra hidden obligation. Supporting assumptions should be explicit: an assumption that the vehicle is moving cannot silently underpin a cooling requirement intended to include stationary work.

Testability means that the programme can establish whether the obligation is met through an appropriate method. Not every requirement needs a physical test. Inspection may establish a defined characteristic; analysis may substantiate behaviour over a range of cases; demonstration may show an operational function. The method must be justified for the claim and evidence quality required. “Verified by analysis” is incomplete without the method, relevant inputs, acceptance criteria and review responsibility.

Requirements review should expose ambiguous terms, incompatible obligations, missing conditions, unnecessary solution constraints and acceptance methods that cannot distinguish success from failure. The customer or authorised contractual role resolves the external obligation. The technical authority judges technical feasibility and the engineering interpretation. Commercial authority resolves price, delivery and contractual consequences. A requirements engineer maintains the record and traceability but should not acquire all these authorities merely by editing the database.

Derivation, allocation and specifications

A customer requirement often needs decomposition before a discipline can act on it. A payload obligation drives consideration of structural loads, suspension, braking, powertrain performance and stability. These are engineering consequences requiring analysis; they are not evidence that every subsystem must change. Derived requirements express the obligations created by the chosen interpretation and architecture. Their records should retain both the parent source and the derivation argument.

Allocation assigns responsibility to an element or organisation. It may divide a performance budget, assign a function or establish an interface constraint. Where several elements jointly satisfy a requirement, the systems lead must explain how their contributions combine. Copying the complete vehicle requirement into every supplier specification creates apparent coverage without a coherent allocation.

A specification is a controlled package of requirements and related definition for a stated purpose. A cooling-module procurement specification might include performance obligations, vehicle interface inputs, deliverable definitions, change-notification requirements and the evidence required at acceptance. It should distinguish mandatory obligations from reference information and design assumptions. Its revision and applicable incorporated references form part of the supplier's basis.

The requirement states what must be achieved; architecture assigns responsibilities; analysis supports the chosen solution; product definition specifies the solution; manufacturing planning defines the work; execution records show what occurred. These information classes may be linked closely, but substituting one for another weakens control. A radiator drawing does not by itself preserve the rationale for a thermal requirement, and a requirement does not tell the shop every operation needed to install the radiator.

A controlled requirements record

Consider the illustrative logical record REQ-HOT-EX. It references a customer statement in an identified DOORS context, records the agreed operating case and vehicle applicability, and links to derived thermal and electrical constraints. Its verification plan identifies the evidence to be obtained. Its change history distinguishes clarification, accepted revision and rejected proposals. These are logical information needs, not an asserted DOORS schema.

Traceability relationships need a meaning and direction. “Derived from” explains the origin of an internal obligation. “Allocated to” assigns responsibility. “Assessed by” connects an obligation with a verification activity or result. Each relationship should resolve the relevant revision or baseline. A link to the latest editable requirement may help navigation while being inadequate to explain a test performed against an earlier agreement.

IBM documents standard, external and collaboration links for DOORS 9.7, including use of links in tracing change impact. This supports a limited capability claim for that documented product, not a conclusion about the programme's unspecified edition or its integration with engineering tools. IBM DOORS link documentation

DOORS and DOORS Next must not be treated as interchangeable deployment descriptions. Select the edition, version, permissions, configuration approach and exchange method before prescribing detailed tool operations. Until then, a controlled exchange can identify source records, versions, baseline context, applicability and the receiving authority without claiming automatic synchronisation. Reconciliation must detect missing records, obsolete copies and rejected updates. A successful transfer proves delivery of data, not acceptance of a changed obligation.

Change after purchasing and manufacture begin

The customer raises the required payload while Vehicle 01 is in build, Vehicle 02 has major equipment ordered and Vehicles 03 and 04 remain in planning. Preserve the existing agreed basis while opening a change request. Record the requested outcome and unresolved conditions, rather than editing the old requirement so that earlier work appears noncompliant retrospectively.

The systems lead scopes the technical assessment. Structure and suspension specialists assess loads and capacity; braking and powertrain specialists assess their consequences; cooling specialists examine any changed operating duty. Manufacturing identifies work already performed and work about to become costly to reverse. Procurement obtains supplier impacts and order positions. Verification identifies which existing arguments or results depend on the earlier payload case. Commercial staff establish the authority needed to change contractual obligations.

The assessment produces options with consequences, not just a list of affected documents. One option may incorporate a revised solution on future vehicles and retain the earlier agreement for Vehicle 01; another may require rework across all four. A negotiated limitation may be possible if the customer accepts it and the technical implications are justified. Engineering cannot assume either fleet-wide adoption or unrestricted retention of the old design.

The decision records a disposition for every vehicle. For Vehicle 01 this includes affected installed material, work in progress and additional evidence. For Vehicle 02 it includes supplier commitments and amendments. For Vehicles 03 and 04 it identifies the new baseline before relevant commitments. Technical approval and contractual authorisation must both be obtained where required. An unresolved commercial decision should remain visible even if the design team has selected a technically feasible option.

Implementation then follows the chain: agreed customer requirement, derived obligations, architecture and interfaces, analysis, product definition, supplier scope, manufacturing plans, orders, actual work and evidence. Close each branch through the evidence appropriate to its disposition. A “no change required” conclusion is also an engineering result: record its scope and reasoning so that it does not look like an overlooked item.

Supplier flow-down and acceptance

The cooling-module supplier needs a coherent package, including the relevant operating cases and controlled vehicle interfaces. The supplier may derive lower-level requirements within its design responsibility. The programme still needs visibility of the assumptions and boundary characteristics that affect vehicle integration. Requiring every internal supplier record can be disproportionate; requiring only a catalogue description can leave decisive assumptions hidden. The purchase and technical package should specify the deliverables and access rights needed for the actual assurance and support responsibilities.

Supplier compliance statements need an identified basis. Ask which specification revision, product definition and verification results the statement covers, together with exceptions. A supplier's successful component test does not automatically establish vehicle performance after installation. Airflow restrictions, wiring losses, controls and actual duty can alter the integrated result. The vehicle verification lead decides how supplier evidence contributes and what integration evidence remains necessary.

An acceptance record identifies the requirement revision, method, tested configuration, results and authorised disposition. Failed or incomplete evidence is retained with its resolution. A later requirement revision may invalidate only part of the existing evidence; the responsible engineer should identify the affected assumptions rather than repeat every test without analysis or retain every result without justification. Model-based systems engineering explains how model relationships support this argument; they do not supply the argument by themselves.

Scale and practical control

At major defence and infrastructure scale, thousands of people may manage requirements over years while millions of occurrences are realised against evolving baselines. Reviews need delegated ownership and bounded change packages. Supplier specifications need stable references, controlled exchanges and explicit acceptance of revisions. Completeness queries should expose unallocated requirements, unsupported derivations and missing verification dispositions without pretending that link counts measure engineering adequacy.

For four vehicles, the same logic can be administered with fewer roles and simpler packages. The irreducible information remains the obligation, its authority, applicable configuration, responsible contributor, decision history and evidence. The selected core platforms can carry parts of that chain, but their exact coverage depends on the deployed capabilities. DOORS holds customer requirements; NX and Capital contribute design definition; Teamcenter governs selected lifecycle information; SAP supports enterprise transactions. Derived-requirement ownership, verification tooling and interfaces between those responsibilities require explicit selection. Architecture and interfaces develops the compatibility decisions that make allocated requirements usable by separate teams.