Best Practices for Writing Requirements for Safety-Critical Systems 

Safety-critical systems operate in environments where software or hardware failure can lead to serious consequences, including equipment damage, operational disruption, financial loss, or risks to human safety. These systems are common in industries such as automotive, aerospace, defence, medical devices, railways, industrial automation, and embedded systems. 

In these environments, requirements are more than statements of expected functionality. They define what the system must do, the conditions under which it must operate, how it should respond to failures, and how its behaviour will be verified. 

Poorly written requirements can create ambiguity, introduce design errors, complicate testing, and weaken traceability. Clear and structured requirements, on the other hand, help engineering teams reduce uncertainty, improve collaboration, and establish a reliable foundation for safety-critical development. 

A structured approach to requirements management in automotive software development helps teams organise requirements from initial stakeholder needs through system design, implementation, testing, and maintenance. 

Why Requirements Quality Matters in Safety-Critical Systems 

Requirements influence almost every stage of the development lifecycle. They guide architecture decisions, software design, implementation, test planning, validation, safety analysis, and compliance activities. 

According to research published by the Carnegie Mellon University Software Engineering Institute, requirements and architecture design defects can account for approximately 70% of defects in safety-critical software-reliant systems. The same research indicates that a significant proportion of these defects are discovered late in the development lifecycle, when correction is more expensive and disruptive. 

These findings highlight why requirements should be reviewed and validated before implementation begins. 

Poor requirements can result in: 

• Misinterpretation between business, systems, and software teams 

• Incomplete functionality 

• Incorrect architectural decisions 

• Difficult or subjective testing 

• Unclear safety responsibilities 

• Weak traceability 

• Increased rework 

• Delayed verification and validation 

• Difficulties during audits and assessments 

For safety-critical projects, requirements should be clear, complete, consistent, feasible, verifiable, and traceable. 

17 Best Practices for Writing Requirements for Safety-Critical Systems

1. Use Clear and Unambiguous Language

Every requirement should communicate one intended meaning. Avoid vague words and phrases such as: 

• Fast 

• User-friendly 

• Adequate 

• As soon as possible 

• Normally 

• Sufficient 

• Appropriate 

• Minimise 

• Optimise 

These expressions can be interpreted differently by different stakeholders. 

Instead of writing: 

The braking system shall respond quickly when the driver applies the brake. 

Write: 

The braking control unit shall initiate braking pressure within 50 milliseconds of receiving a valid brake application signal. 

The second requirement defines a measurable response time and reduces interpretation differences. 

Use direct language and avoid unnecessary complexity. A useful structure is: 

The system shall + action + object + condition + measurable limit. 

For additional guidance on structuring and documenting requirements, refer to this requirements management guide.

2. Make Each Requirement Atomic

An atomic requirement expresses one distinct obligation. Combining multiple obligations in one statement makes it difficult to verify, trace, and manage changes. 

Avoid writing: 

The controller shall detect an overtemperature condition, notify the operator, record the event, and activate the cooling system. 

This sentence contains several separate requirements: 

Detect the overtemperature condition 

Notify the operator 

Record the event 

Activate the cooling system 

Each obligation should be documented separately where appropriate. 

Atomic requirements make it easier to: 

• Assign ownership 

• Define verification methods 

• Link requirements to design and test artefacts 

• Identify changes 

• Analyse impact 

• Track implementation status 

3. Use a Consistent Requirement Structure

A consistent structure improves readability and reduces ambiguity across large requirement sets. 

A common format is: 

The [system or component] shall [perform an action] under [defined condition] within [specified limit]. 

For example: 

The battery management system shall disconnect the charging circuit when cell voltage exceeds the defined upper voltage threshold. 

A standard structure should be supported by requirement templates, naming conventions, unique identifiers, and defined metadata fields. 

Useful metadata may include: 

• Requirement ID 

• Requirement title 

• Requirement statement 

• Requirement type 

• Source 

• Priority 

• Safety classification 

• Verification method 

• Owner 

• Status 

• Version 

• Rationale 

• Traceability links 

4. Define Measurable Acceptance Criteria

A requirement should be written so that its fulfilment can be objectively determined. 

Avoid: 

The system shall provide reliable communication. 

Instead, define measurable criteria: 

The communication interface shall successfully transmit 99.9% of valid messages during a continuous 8-hour operating period under the specified network conditions. 

Measurable requirements help teams determine: 

• What must be tested 

• What constitutes pass or fail 

• Which test conditions are required 

• What evidence must be recorded 

• Whether the requirement has been satisfied 

Each requirement should have an identifiable verification approach, such as: 

• Inspection 

• Analysis 

• Demonstration 

• Test 

This principle is also reflected in NASA requirements engineering guidance, which emphasises that requirements should be clear, precise, verifiable, testable, feasible, and traceable. 

5. Specify Operating Conditions and Boundaries

Safety-critical systems rarely operate under only ideal conditions. Requirements should define the operating environment and the boundaries within which the system must function. 

Consider specifying: 

• Temperature range 

• Voltage range 

• Pressure range 

• Speed range 

• Load conditions 

• Environmental conditions 

• Communication availability 

• Power supply conditions 

• Hardware states 

• Timing constraints 

• Operating modes 

• Start-up and shutdown conditions 

For example: 

The sensor interface shall provide valid measurements between -40°C and 125°C with an accuracy of ±2°C. 

Without defined boundaries, teams may implement and test the system under conditions that do not represent actual operational use. 

6. Separate Requirements from Design Solutions

Requirements should describe what the system must achieve rather than prematurely prescribing how the solution must be implemented. 

For example: 

The system shall detect wheel-speed inconsistencies within 100 milliseconds. 

This describes the required behaviour. 

A design-specific statement such as: 

The system shall use a specific algorithm implemented in C++ to compare four wheel-speed sensors. 

may be appropriate at the design level, but it should not replace the higher-level requirement unless the implementation constraint is genuinely necessary. 

Separating requirements from design solutions: 

• Preserves design flexibility 

• Supports alternative architectures 

• Reduces unnecessary constraints 

• Makes requirements easier to reuse 

• Helps distinguish stakeholder needs from implementation decisions 

Design constraints should be documented when they are required for safety, performance, compatibility, regulation, or system integration. 

7. Define Failure and Abnormal Conditions

Safety-critical requirements must address more than normal operation. The system should also have clearly defined behaviour for failures, faults, abnormal inputs, and unexpected operating conditions. 

Consider scenarios such as: 

• Sensor failure 

• Communication loss 

• Invalid data 

• Power interruption 

• Memory corruption 

• Hardware malfunction 

• Timing violation 

• Overtemperature 

• Overvoltage 

• Unexpected user input 

• Loss of an external dependency 

For example: 

If the primary pressure sensor provides an invalid signal for more than 20 milliseconds, the control unit shall use the redundant sensor and record a diagnostic event. 

Specifying off-nominal behaviour helps prevent gaps between functional requirements and safety expectations. It also supports failure analysis, fault injection testing, and safety validation. 

8. Define Safe-State and DegradedBehaviour

A safety-critical system may not always be able to continue normal operation. Requirements should define how the system transitions to a safe state or degraded operating mode. 

A safe-state requirement may specify: 

• The conditions that trigger the transition 

• The required system response 

• The maximum transition time 

• Which functions remain available 

• Which functions must be disabled 

• What information must be communicated 

• How recovery is handled 

For example: 

When a critical actuator fault is detected, the system shall enter the defined degraded operating mode within 100 milliseconds and prevent further commands to the affected actuator. 

The safe state should be defined according to the system hazard analysis, safety goals, and operational context. 

9. Distinguish Functional and Non-Functional Requirements

Functional requirements describe what the system must do. 

Examples include: 

• Detect an input signal 

• Calculate a value 

• Activate an actuator 

• Store a diagnostic code 

• Send a message 

• Transition between operating modes 

Non-functional requirements define qualities or constraints related to system behaviour. 

Examples include: 

• Performance 

• Reliability 

• Availability 

• Safety 

• Security 

• Maintainability 

• Usability 

• Timing 

• Resource consumption 

• Scalability 

For example: 

Functional requirement: 

The control unit shall calculate vehicle speed from the wheel-speed signals. 

Non-functional requirement: 

The control unit shall calculate and update vehicle speed at least every 10 milliseconds. 

Both types are important. Functional requirements define system behaviour, while non-functional requirements establish the conditions and quality levels that behaviour must meet. 

10. Make Requirements Complete Without Overloading Them

Requirements should contain enough information to be understood and verified, but they should not become unnecessarily long or difficult to maintain. 

A requirement may need to include: 

• Trigger condition 

• Required action 

• Operating context 

• Timing constraint 

• Performance limit 

• Exception condition 

• Verification criteria 

However, avoid combining several independent behaviours into one complex paragraph. 

If a requirement requires extensive explanation, separate the requirement statement from supporting information such as: 

• Rationale 

• Assumptions 

• Examples 

• Design notes 

• Safety justification 

• Verification guidance 

This keeps the requirement concise while preserving the context needed by engineering teams. 

11. Use Consistent Terminology

Inconsistent terminology can create confusion across systems, software, hardware, safety, testing, and quality teams. 

For example, if one document uses “controller,” another uses “control unit,” and a third uses “ECU” to refer to the same component, the relationship should be explicitly defined. 

Create and maintain a project glossary covering: 

• System components 

• Interfaces 

• Operating modes 

• Signals 

• Faults 

• Events 

• States 

• Safety terms 

• Abbreviations 

• Units of measurement 

Use the same term consistently unless there is a meaningful distinction. 

Terminology should also align with relevant system architecture documents, interface specifications, test cases, and safety analyses. 

12. Define Interfaces and Dependencies

Many safety-critical failures occur at the boundaries between components or subsystems. Requirements should clearly identify interfaces and dependencies. 

Interface-related requirements may define: 

• Input and output signals 

• Data formats 

• Communication protocols 

• Timing 

• Units 

• Valid ranges 

• Error handling 

• Data freshness 

• Synchronisation 

• Ownership 

• Dependency behaviour 

For example: 

The braking control unit shall reject wheel-speed messages that contain an invalid checksum or a timestamp older than 20 milliseconds. 

Interface requirements should be traceable to system architecture, interface control documents, software components, and integration tests. 

13. EstablishEnd-to-End Traceability 

Traceability allows teams to understand where each requirement originated, how it is implemented, and how it is verified. 

A typical traceability chain may connect: 

Stakeholder needs → Safety goals → System requirements → Software requirements → Architecture → Design → Code → Test cases → Test results → Defects 

Traceability helps teams: 

• Demonstrate coverage 

• Identify missing implementation links 

• Detect unverified requirements 

• Analyse change impact 

• Support audits 

• Improve defect investigation 

• Maintain compliance evidence 

For a detailed explanation of traceability and its role in process assessments, read requirements traceability for ASPICE compliance. 

A structured requirements management guide can also help teams establish requirement hierarchies, ownership models, baselines, and traceability relationships. 

14. Conduct Multidisciplinary Requirements Reviews

Requirements should not be reviewed only by the person who wrote them. Safety-critical development requires input from multiple disciplines. 

Depending on the project, reviewers may include: 

• Systems engineers 

• Software engineers 

• Hardware engineers 

• Safety engineers 

• Cybersecurity engineers 

• Test and validation engineers 

• Quality engineers 

• Product owners 

• Domain specialists 

• Manufacturing or operations representatives 

Each discipline may identify different issues. For example: 

• Systems engineers may identify missing interactions. 

• Safety engineers may identify incomplete fault behaviour. 

• Software engineers may identify implementation constraints. 

• Test engineers may identify requirements that cannot be objectively verified. 

• Hardware engineers may identify interface limitations. 

Review comments should be recorded, resolved, and linked to the relevant requirement versions. 

15. Validate Requirements Before Implementation 

Requirements validation checks whether the documented requirements describe the right system and reflect stakeholder, operational, safety, and regulatory needs. 

Validation should ask: 

• Does the requirement reflect the intended system behaviour? 

• Is the requirement necessary? 

• Is it feasible? 

• Is it consistent with other requirements? 

• Can it be verified? 

• Does it address relevant operating conditions? 

• Does it cover abnormal and failure conditions? 

• Does it support the defined safety goals? 

• Is the requirement allocated to the correct system element? 

Validation should continue throughout the lifecycle because requirements may change as the system, environment, risks, and stakeholder expectations evolve. 

Early validation helps prevent incorrect assumptions from becoming embedded in architecture and implementation. 

16. Manage Baselines and Perform Impact Analysis

Safety-critical projects often involve changing requirements, evolving designs, updated safety analyses, and revised test strategies. 

Requirements should be baselined at defined milestones so that teams can identify: 

• Which version was approved 

• What changed 

• Who approved the change 

• Why the change was introduced 

• Which design elements are affected 

• Which test cases must be updated 

• Whether safety analysis must be revisited 

Impact analysis should consider relationships between requirements, architecture, design, code, tests, defects, and compliance evidence. 

For example, changing a timing requirement may affect: 

• Software architecture 

• Task scheduling 

• Processor utilisation 

• Communication interfaces 

• Test conditions 

• Safety analysis 

• Verification evidence 

Organisations evaluating lifecycle management platforms can compare IBM DOORS vs PTC Codebeamer for automotive requirements management. 

17. Use Requirements Management Tools

Spreadsheets and disconnected documents may be sufficient for small projects, but they become difficult to maintain as requirements, teams, dependencies, and verification evidence increase. 

A requirements management or application lifecycle management platform can support: 

• Unique requirement identifiers 

• Version control 

• Baseline management 

• Approval workflows 

• Change history 

• Traceability 

• Impact analysis 

• Requirement reviews 

• Verification status 

• Reporting 

• Collaboration 

• Integration with development and testing tools 

Tool support can improve consistency and visibility, but implementing a tool alone is not enough. Organisations also need defined workflows, roles, review practices, governance, and quality criteria. 

Learn more about how to implement requirements management in embedded projects. 

Using IBM Engineering Lifecycle Management for Requirements Management 

IBM Engineering Lifecycle Management helps organisations manage requirements, development activities, testing, and lifecycle relationships in a connected environment. 

For safety-critical and regulated engineering projects, an integrated lifecycle approach can support: 

• Requirements capture and organisation 

• Requirement reviews and approvals 

• Traceability across lifecycle artefacts 

• Change and configuration management 

• Impact analysis 

• Verification planning 

• Test management 

• Compliance reporting 

• Collaboration across engineering teams 

IBM Engineering Requirements Management DOORS Next can be used to manage structured requirements and relationships, while other IBM ELM capabilities support broader lifecycle processes. 

To learn more, explore IBM Engineering Lifecycle Management services. 

Practical Checklist for Safety-Critical Requirements 

Before approving a requirement, ask the following questions: 

How MicroGenesis Supports Safety-Critical Requirements Management 

MicroGenesis helps automotive and embedded engineering organisations establish structured requirements management processes across the product development lifecycle. 

Our support can include: 

• Safety-critical requirements assessment 

• Requirements quality improvement 

• Requirements templates and governance 

• Requirements traceability model development 

• ASPICE-oriented process improvement 

• ALM implementation and integration 

• IBM Engineering Lifecycle Management consulting 

• Requirements migration and lifecycle optimisation 

• Requirements review and validation support 

• Change and configuration management 

• Verification and test traceability 

• Engineering workflow improvement 

Our ALM services help organisations improve collaboration, traceability, lifecycle visibility, and engineering process control. 

For teams working with IBM platforms, our IBM Engineering Lifecycle Management services support requirements management, lifecycle integration, migration, configuration, and process improvement. 

Conclusion 

Writing requirements for safety-critical systems requires more than documenting expected functionality. Requirements must define behaviour precisely, address operating and failure conditions, support objective verification, and remain connected to the wider engineering lifecycle. 

The most effective approach combines: 

• Clear and unambiguous language 

• Atomic and measurable statements 

• Defined operating conditions 

• Explicit failure and safe-state behaviour 

• Consistent terminology 

• Interface clarity 

• Multidisciplinary reviews 

• Continuous validation 

• End-to-end traceability 

• Controlled baselines 

• Appropriate tool support 

When these practices are applied consistently, engineering teams can reduce ambiguity, identify defects earlier, improve collaboration, and strengthen the evidence needed for safety-critical development and process assessments. 

For further guidance, read our requirements management guide and learn how structured requirements practices support automotive and embedded software development. 

Improve the Quality and Traceability of Your Safety-Critical Requirements 

Writing clear requirements is only the first step. Automotive and embedded engineering teams also need structured processes for requirements review, version control, traceability, change management, verification, and compliance evidence. 

MicroGenesis helps organisations improve their requirements engineering practices through: 

• Safety-critical requirements assessment 

• Requirements quality improvement 

• Requirements templates and governance 

• Requirements traceability model development 

• ASPICE-oriented process improvement 

• ALM implementation and integration 

• IBM Engineering Lifecycle Management consulting 

• Requirements migration and lifecycle optimisation 

Explore our ALM services or learn more about IBM Engineering Lifecycle Management services. 

For additional guidance, read our requirements management guide. 

Ready to improve requirements quality, strengthen traceability, and support safety-critical development with greater confidence? Contact MicroGenesis to discuss your requirements management and ALM goals.