How to Write Technical Requirements That Survive Verification

Requirements that can’t be verified don’t make themselves known at the writing stage. They surface at verification, when a test engineer needs a threshold nobody wrote down and the program absorbs the rework. Whether a technical requirement can be verified is decided at the moment it’s written, and no amount of test planning recovers that decision afterward.

The cost lands on the people furthest from the decision, the test engineers and quality leads who inherit the wording. This guide covers what a verifiable technical requirement looks like, the nine characteristics that make one well-formed, and the process that carries a set from elicitation to a controlled baseline.

What Are Technical Requirements?

Technical requirements are the system, functional, performance, interface, and quality statements that make up an engineering baseline. Engineers design and verify a product against it. They draw on functional, performance, interface, environmental, and safety sources, and they include the “ilities” such as reliability and producibility. That breadth is what makes the term an umbrella.

Perspective separates a technical requirement from a need the customer states. The need describes what customers and users expect from an external, black-box view in their own language. The technical requirement converts that into the systems engineer’s internal, white-box view of the same system.

Each view has its own specification document under ISO/IEC/IEEE 29148, the international requirements engineering standard. The Business Requirements Specification (BRS) records why the system exists, and the Stakeholder Requirements Specification (StRS) holds customer and user expectations with their acceptance criteria. The System Requirements Specification (SyRS) and Software Requirements Specification (SRS) carry the technical view.

What a Verifiable Technical Requirement Looks Like

A verifiable technical requirement names one actor, one obligation, and a pass criterion someone can measure, in the plain active-voice form “product ABC shall XYZ.” The table below pairs weak statements with rewrites a test engineer could work from.

Weak Statement	Verifiable Statement
“Temperature readings should be recorded periodically.”	“The system shall record temperature readings every 30 seconds.”
“Indicator for fail shall stand out.”	“The status flag shall be red, value FF0000, for every failed test step.”
“A 20 V supply shall be used.”	“The system shall use a 20 V electrical supply.”

Each rewrite gives a test engineer something to write a procedure against, which the weak version withholds.

Medical device teams have had the same instruction for decades. A catheter that gets flexed in use becomes a testable design input once the geometry and the count are named. The requirement forms it into a 50 mm diameter coil and straightens it out for a total of fifty times with no evidence of cracking or deformity. The 1997 FDA design control guidance carries that wording, and a lab can run the test straight from it.

Nine Characteristics Every Technical Requirement Must Meet

Nine characteristics define a well-formed individual requirement, and six more apply to the requirement set as a whole. The nine are necessary, appropriate to its level, unambiguous, complete, singular, feasible, verifiable, correct, and conforming to approved patterns. The nine characteristics come from the International Council on Systems Engineering (INCOSE) Guide for Writing Requirements.

Verifiability has to be settled while the requirement is still being written. Assessing it first is the fastest filter, because a requirement nobody can test rarely survives the other eight checks either. Teams pick the verification and validation methods as they draft, choosing among inspection, analysis, demonstration, and test, then record the method and the pass criterion with the requirement itself. Where the method isn’t knowable yet, the requirement says which decision it waits on.

A useful test is to hand the statement to someone who has never met you. If they can build exactly what you meant and prove they did, it passes. Software teams running AI coding agents hand requirements to that stranger constantly, which is why precise and current statements matter more than they did when every reader was a colleague.

Writing Technical Requirements With EARS Notation

The Easy Approach to Requirements Syntax (EARS) gives technical requirements a consistent clause order that reduces ambiguity without giving up natural language. EARS grew out of an analysis of airworthiness regulations for a Rolls-Royce aero engine control system and is now used worldwide across engineering domains. The generic syntax reads “While preconditions, when trigger, the system name shall system response,” with the clauses always in that order. EARS defines six patterns, five cued by keywords and one (ubiquitous) identified by the absence of any keyword.

Pattern	Keyword	Example
Ubiquitous	none	“The mobile phone shall have a mass of less than XX grams.”
State-driven	While	“While there is no card in the ATM, the ATM shall display ‘insert card to begin’.”
Event-driven	When	“When ‘mute’ is selected, the laptop shall suppress all audio output.”
Optional feature	Where	“Where the car has a sunroof, the car shall have a sunroof control panel on the driver door.”
Unwanted behavior	If / Then	“If an invalid credit card number is entered, then the website shall display ‘please re-enter credit card details’.”
Complex	Two or more keywords	“While the aircraft is on ground, when reverse thrust is commanded, the engine control system shall enable reverse thrust.”

Complex requirements combine more than one keyword and follow the same fixed clause order. Not every requirement needs the full structure, and a ubiquitous one with no trigger reads better without it.

How a Technical Requirement Reaches a Controlled Baseline

A technical requirement is only as stable as the process that carries it, and five stages stand between the first conversation about a need and a controlled baseline. The trace links created in the first two make the last three possible:

1. Elicitation: Interviews, workshops, use cases, and prototypes draw out customer and user needs and constraints. Teams record each need with its rationale and priority, plus a trace to the role that raised it.

2. Transformation: Teams turn needs into formal statements describing required system behavior, each at the level of the system element it applies to.

3. Review and validation: At a System Requirements Review (SRR), reviewers evaluate whether the functional and performance requirements respond to the program’s needs. Reviewers can only make that call with traceability back to the source needs.

4. Baselining: After approval, the team places the set under formal change control, which lets a program measure how a proposed change affects technical performance and the program’s cost or schedule.

5. Change control: A Configuration Control Board (CCB) assesses each change for cost and for its effect on performance and safety. The later a change lands in the life cycle, the more systems engineering effort it consumes, which is why the board’s assessment matters more late than early.

Every stage assumes the requirement was written well enough to review, and when it wasn’t, the defect travels through all five.

Common Mistakes That Undermine Technical Requirements

Defective technical requirements cluster into five recognizable categories, all of them cheap to fix at authoring and expensive anywhere else. A hardware engineer reads “the enclosure shall withstand normal shock loads” and sizes for one number while the test engineer plans for another, and neither finds out until the unit is on the shaker table. Each category produces a statement that reads as though it says something testable:

• Vague terms: Words such as “approximately,” “sufficiently,” “typically,” “flexible,” and “adequate” produce statements nobody can pass or fail. “The flight information system shall usually be online” can’t be verified, while a stated availability percentage over a defined period can.

• Escape clauses: Phrases like “so far as is possible,” “as appropriate,” and “to the extent practical” give a developer at a lower level an excuse to skip the requirement. From a contracting standpoint, they can also make it optional.

• Compound statements: A requirement containing multiple thoughts resists clean allocation and tracing, and one passing condition can mask a failing one at verification.

• Prescribed implementations: Specifying an implementation locks it in before the architecture work that should have selected it.

• Missing units of measure: Numeric values need explicit units. The Mars Climate Orbiter was lost because one ground program reported results in United States customary units while the navigation software expected metric.

All five share one property, they pass a review that isn’t looking for them. Rework can consume 30 to 50 percent of total development cost, a range Karl Wiegers published in 2013, and requirements errors account for most of that rework cost.

FDA investigators put the same point more bluntly. “If a design input is not well written in the first place, is not clearly defined, or is otherwise ambiguous, it’s going to be very difficult for anyone to be able to demonstrate that the design input is verified,” said Mary Millner, a senior operations officer in the FDA’s device inspectorate, speaking at MedCon 2025. Poor wording carries an engineering cost and a certification cost at once, because a reviewer’s evidence rests on it.

Why Regulated Programs Trace Technical Requirements in Both Directions

Bidirectional tracing exists because a reviewer needs to run the chain in either direction. Downward from a requirement, it shows verification evidence exists for what the team committed to build. Upward from a test result or a design element, it shows which approved requirement the artifact answers, and flags work that answers none.

Airborne software has to trace high-level and low-level requirements down to source code, with the source code traceable back up, under DO-178C. DO-178C is an accepted means of compliance for airborne software rather than the only one, and DO-254 places the same obligation on airborne electronic hardware. Automotive suppliers meet a parallel requirement in Automotive SPICE (ASPICE) 4.0, which names consistency and bidirectional traceability as base practices in software requirements analysis. Medical device teams meet it as design verification, where the question is whether design output meets design input.

None of that evidence holds up if the requirement it points at can’t be verified, and a trace link to a test that could never fail proves nothing to a reviewer.

How Jama Connect Supports Technical Requirements

A requirement that can’t be verified is easiest to catch seconds after it’s typed, and hardest once a hundred more sit on top of it. We built that check into the authoring workflow in Jama Connect®. Jama Connect Advisor™, an add-on available on Cloud deployments only, scores each statement against 36 INCOSE rules and 6 EARS syntax patterns before the engineer moves on, and the engineer sees the specific flag and a suggested rewrite, then accepts, edits, or rejects it. Advisor also drafts up to 10 test cases with steps from a single requirement once the engineer picks the test type and the industry vertical, which puts the verification method in front of the author during the transformation stage. Nothing is created or linked until someone accepts a suggestion, engineers can regenerate the set with more prompting when the first drafts miss, and both the original text and the revision stay in the audit trail.

The last three stages of that process run on the same trace links. Traceability Information Models™ (TIMs) define which item types have to connect, so a systems engineer sees a requirement with no verification evidence attached while there is still time to write one. Review Center carries an SRR as a formal package with named approvers and electronic signatures, and a baseline freezes the approved set so the team can compare any two versions afterward. Jama Connect flags every linked test case as suspect when a baselined requirement changes, so the engineer who owns the test reassesses it before the CCB weighs the cost.

Deciding Verifiability Before the Requirement Is Approved

Deciding verifiability at authoring doesn’t add a review stage. Moving the verification question earlier, out of the test phase and into the sentence being written, turns a change-board item into a single edit. A requirement that reaches verification with its method and pass criterion already attached is the one nobody has to renegotiate at the worst moment.

If your team is finding untestable requirements at integration instead of at authoring, Jama Connect Advisor can score a whole set in one pass and report which statements came back flagged, before that set goes to an SRR. You can start a free 30-day trial and see where the flags land on your own set.

Frequently Asked Questions About Technical Requirements

What is the difference between technical requirements and functional requirements?

Functional requirements describe observable behavior the system must perform, and they sit inside the technical requirements set as one of its types. A practical test asks whether the statement defines a capability, or constrains how well or under what conditions that capability occurs. A capability is functional, and the constraint is a performance, environmental, safety, or quality requirement. Both types live in the same system requirements specification and trace to the same parent need.

Do technical requirements always use the word “shall”?

Formal requirement statements always use “shall,” in the pattern “the product shall” followed by an action and a measurable description. Customer and user expectations stay in a needs format, such as “the customer needs the system to,” until someone converts them into binding engineering obligations. The switch to “shall” marks that conversion, which is why the conventions for writing requirements treat the two as different documents.

What is a technical requirements document?

A technical requirements document collects the system, functional, performance, interface, and quality statements for one product or subsystem, with the verification method and pass criterion recorded against each statement. ISO/IEC/IEEE 29148 separates the technical view from the business and customer views, so most programs maintain a technical specification alongside the documents recording why the system exists and what customers expect. Teams on complex products keep the content as a linked set of items in a product requirements document or a requirements management tool such as Jama Connect, where changing one statement flags the test cases that verify it, and export a formal document when a review or a submission calls for one.

How do you verify a technical requirement?

You verify a technical requirement by the method recorded with it, whether that is inspection, analysis, demonstration, or test, and against the pass criterion written beside it. When the requirement changes, the requirements traceability matrix tells you which executed tests are now stale. Requirements with no method recorded stall a verification campaign, because someone has to reconstruct the intent first.

This article was authored by Mario Maldari and published on September 3, 2026.