When developing safety-critical systems, software requirements are not just an item on a checklist — they are the foundation for everything that follows. From design and verification through certification to maintenance: the clarity and correctness of your requirements can determine whether your product succeeds or fails, especially when lives depend on how the system behaves.

Whether you are developing an insulin pump or a pressure regulator for a nuclear power plant, writing software requirements for safety-critical applications demands a disciplined approach. This article shows how to formulate precise, unambiguous and verifiable requirements that satisfy industry standards and support certification.

Writing High-Quality Requirements

Most requirements are still written in natural language (NL). NL is flexible and easy to understand, but prone to ambiguity. A phrase like "when needed" can be interpreted in multiple ways — and thereby cause critical defects. Safety-related development therefore needs rules and structure even in NL. A good software requirement is:

• correct and clear
• consistent and non-contradictory
• testable and verifiable — it must define measurable criteria
• free from conjunctions and exceptions
• role-specific — it names the user type

Example structure:

The operator shall be able to [action] on the [object] in order to achieve [desired state].

Every requirement should define:

• Who performs the action (user role)
• What is done (task and object)
• Why, or what result is expected
• Who receives or uses the result

Style and Structure

A well-formulated requirement typically follows a Subject–Predicate–Object (S-P-O) pattern:

ISO/IEC/IEEE 29148:2018 describes how to write clear and testable requirements and standardises the use of modal verbs:

• Shall: Identifies a mandatory requirement.
• Will: Describes a fact or intention, not a requirement.
• Should: A recommended requirement; not mandatory, but deviations must be justified.
• Must: Sometimes used for laws of nature or unavoidable consequences; should not be used in place of "shall" for requirements.

Best practice: use "shall" only once per requirement. Avoid compound requirements joined with "and", "or" or "with". Combining actions makes the requirement untestable and creates multiple requirements in one. Words like "is", "are", "was" or "must" are suitable for descriptive or introductory sections.

Every requirement should describe what the system must do, not how it is to be implemented. This is crucial for testability and traceability. Example:

The system shall use a MySQL database to store ECG data.

This describes the how, not the what. The choice of database is a design decision that belongs in downstream documents such as the Software Architecture Document (SAD) or Detailed Design Document (DDD).

Improving Requirements Through Controlled Language

One way to reduce ambiguity is to introduce a controlled language — a simplified subset of English for technical documentation. In aerospace, for example, ASD-STE100 (Simplified Technical English) is used.

Controlled language enforces:

• a defined vocabulary
• simple sentence structures
• avoidance of synonyms or ambiguous terms

A style guide for controlled language enables consistent and easily verifiable requirements across multiple documents and roles.

Avoiding Ambiguity

Ambiguity can arise from lexical, syntactic or semantic issues:

• Lexical ambiguity: A word has multiple meanings. Example: "bank" can mean a financial institution or a river bank.
• Syntactic ambiguity: A sentence admits multiple grammatical structures with different meanings. Example: "medical history database" — is it a database for medical histories, or a historical database?
• Attachment ambiguity: A phrase (often prepositional) can attach to different parts of the sentence. Example: "The state machine can be implemented as part of the driver for communication with the watchdog CPU." Meanings:
  • The driver handles communication and the state machine is part of it.
  • The state machine controls the communication.
• Semantic ambiguity: A sentence is unclear in context, even without lexical or syntactic problems. Example: "The system shall stop the motor before it overheats." — Does "it" refer to the system or the motor?

Ambiguity often creeps in through vague terms, passive constructions or unclear references. Example:

"The system shall activate the warning signal shortly after fault detection."

What does "shortly" mean? Who activates the signal? Questions like these are red flags in a safety-critical context.

Avoid:

• Relative terms: powerful, acceptable, fast, reliable
• Unclear quantifiers: all, most, some, any
• Passive voice: "is activated" vs. "the controller activates"
• Temporal vagueness: soon, periodically, later
• Compound requirements: two "shall" clauses joined with "and/or"

Every requirement must be atomic, verifiable and unambiguous.

Formalising Requirements

For higher safety integrity levels it becomes necessary to formalise requirements — translating them into a formal language such as PSL (Property Specification Language) or LTL (Linear Temporal Logic) that tools can check and simulate.

Formalisation enables:

• complete analysis of boundary cases
• traceability from high-level requirements to implementation
• automated verification in safety audits

Practical Examples

Infusion Pump — Flow Rate Control

Natural Language (NL SR)

"The system should deliver the correct dose at the correct rate."

Problems: vague terms such as "correct dose" and "correct rate". No subject defined. Not testable.

Controlled Natural Language (cNL SR)

"When the infusion programme is started, the control unit shall deliver the programmed medication volume at a flow rate between 0.1 and 10.0 ml/h with an accuracy of ±5 %."

• Subject: control unit
• Action: shall deliver
• Parameters: flow rate, dose, accuracy
• Trigger: start of infusion programme

Heart Rate Monitor — Triggering an Alarm

Natural Language (NL SR)

"The system must trigger an alarm when the heart rate is abnormal."

Problems: what does "abnormal" mean? How loud or fast must the alarm be? When exactly should it trigger?

Controlled Natural Language (cNL SR)

"When the patient's heart rate falls below 40 bpm or exceeds 180 bpm and this condition persists for more than 3 seconds, the alarm controller shall activate a 90 dB alarm within 1 second."

• Clear thresholds: 40 and 180 bpm
• Time condition: more than 3 seconds
• Action: activate 90 dB alarm
• Time limit: within 1 second

Radiation Beam Activation with Hardware Interlock

Natural Language (NL SR)

"The system shall activate the beam when the operator starts treatment."

Problems: no mention of safety interlocks or conditions. "Activate" is unclear — switch on physically or merely prepare?

Controlled Natural Language (cNL SR)

"The system shall activate the radiation beam only when the gantry is in the correct position, the hardware interlock is closed, and the treatment console receives a valid 'Start' command from the operator."

• Multiple necessary preconditions
• Unambiguous subject and trigger
• "Only when" logic accounts for safety

Requirements Review

Developing a safety-critical product is rarely the work of a single person. Before proceeding to the next steps in the V-model, the software requirements must be reviewed. But that is a topic for another time.

Further Reading

• From Contract Drafting to Software Specification — AmbiguityHandbook.pdf
• ASD-STE100 — www.asd-ste100.org