Electronics Guide

Functional Requirements

Functional requirements describe what the system must do, the behaviors it must exhibit, and the transformations it must perform on inputs to produce outputs. These requirements specify the system's capabilities in terms of features, functions, and services it provides to users and other systems.

Examples of functional requirements include processing sensor data within specified accuracy bounds, controlling actuators in response to user commands, communicating with external systems using defined protocols, and storing configuration data persistently. Functional requirements should be specific enough to be testable and should avoid implementation details that constrain design freedom unnecessarily.

Performance Requirements

Performance requirements quantify how well the system must execute its functions. These include timing requirements such as response times, latency bounds, throughput rates, and update frequencies. For real-time embedded systems, timing requirements are often as critical as functional requirements, since a correct result delivered too late may be as useless as an incorrect result.

Performance requirements also encompass capacity specifications including memory usage limits, processing bandwidth, storage requirements, and communication bandwidth. Embedded systems typically operate with constrained resources, making these requirements essential for ensuring the design fits within available hardware capabilities.

Non-Functional Requirements

Non-functional requirements address qualities and constraints beyond basic functionality and performance. These include reliability requirements specifying acceptable failure rates, mean time between failures, and availability targets. Safety requirements define how the system must behave to prevent harm to people, property, or the environment. Security requirements address protection against unauthorized access, data integrity, and resistance to attacks.

Environmental requirements specify operating conditions including temperature ranges, humidity, vibration, electromagnetic compatibility, and exposure to dust, water, or chemicals. Power requirements constrain energy consumption, which may involve average power, peak power, and energy budget for battery-powered systems. Physical requirements address size, weight, and form factor constraints.

Interface Requirements

Interface requirements define how the system interacts with external entities including users, other systems, and the physical environment. User interface requirements specify how operators interact with the system through displays, controls, indicators, and feedback mechanisms. System interface requirements define communication protocols, data formats, timing relationships, and electrical characteristics for connections to other equipment.

Sensor and actuator interface requirements specify the characteristics of connections to the physical world, including signal types, ranges, accuracy, and response characteristics. These requirements bridge the gap between the digital system and the analog physical environment it monitors and controls.

Regulatory and Compliance Requirements

Many embedded systems must comply with industry standards, government regulations, or certification requirements. These may include the cross-industry functional safety standard IEC 61508, which grades safety functions by Safety Integrity Level (SIL 1 through SIL 4); its automotive adaptation ISO 26262, which uses Automotive Safety Integrity Levels (ASIL A through ASIL D); the medical device software lifecycle standard IEC 62304, which assigns each software item to Class A, B, or C according to whether failure can cause no injury, non-serious injury, or serious injury or death; or the airborne software standard DO-178C, whose Design Assurance Levels run from Level A (a failure condition judged catastrophic) to Level E (no effect on safety). Compliance requirements often impose constraints on development processes, documentation, verification methods, and traceability in addition to technical requirements, and the assigned integrity level dictates how rigorous those activities must be.

The practical consequence is that the integrity level is itself a requirement, and it must be established early. A function classified ASIL D or Level A carries obligations that ripple through the entire program, including independent review, structural coverage analysis, and evidence that every requirement traces to design, code, and test. Reclassifying a function upward late in development is among the most expensive changes a project can absorb. The functional safety standards article covers these frameworks in detail, and hazard analysis and risk assessment describes how safety requirements are derived from identified hazards.

Electromagnetic compatibility regulations, radio spectrum rules for products containing transmitters, environmental and materials regulations, and product safety certifications represent additional compliance categories that can significantly influence system design. These constraints reach hardware directly: shielding, filtering, board layout, enclosure materials, and antenna placement all follow from them. Understanding applicable regulations early in requirements engineering prevents costly redesigns when compliance issues are discovered late, when the remedy is often a board respin or a retooled enclosure.

Stakeholder Analysis

Identifying all stakeholders is the first step in elicitation. Stakeholders include not only end users but also operators, maintainers, manufacturing personnel, regulatory authorities, marketing teams, and others who have legitimate interests in the system. Each stakeholder group may have different requirements and priorities that must be understood and balanced.

Stakeholder analysis involves identifying who the stakeholders are, understanding their roles and responsibilities, determining their needs and expectations, and assessing their influence on project decisions. This analysis guides subsequent elicitation activities and helps prioritize potentially conflicting requirements.

Elicitation Techniques

Interviews: Direct conversations with stakeholders allow detailed exploration of needs, constraints, and priorities. Structured interviews follow predetermined questions while unstructured interviews allow topics to emerge organically. Both approaches have value depending on how well the requirements domain is understood.

Workshops: Facilitated sessions bringing together multiple stakeholders can efficiently gather diverse perspectives and resolve conflicting viewpoints. Workshops are particularly valuable for exploring system boundaries, identifying interfaces, and achieving consensus on priorities.

Observation: Watching users interact with existing systems or perform tasks that the new system will support reveals requirements that users may not articulate because they take them for granted. Observation is especially valuable for understanding operational contexts and workflows.

Document analysis: Reviewing existing documentation including specifications for predecessor systems, standards, regulations, and competitor products provides requirements that may not emerge from stakeholder discussions. Document analysis is essential for compliance-driven requirements.

Prototyping: Early prototypes, even simple mockups, help stakeholders visualize the system and identify requirements they could not express abstractly. Prototyping is particularly valuable for user interface requirements and for exploring novel concepts where stakeholders have limited prior experience.

Embedded Systems Considerations

Eliciting requirements for embedded systems requires attention to aspects that may be overlooked in purely software projects. Hardware constraints including processor capabilities, memory limitations, and power budgets must be understood early since they fundamentally shape what the system can achieve. Environmental conditions where the system will operate influence component selection, packaging, and reliability requirements.

Real-time requirements need careful elicitation since stakeholders may express timing needs imprecisely or may not fully understand their own timing constraints until confronted with specific scenarios. Safety and reliability requirements deserve particular attention since the consequences of embedded system failures can extend beyond software crashes to physical harm or damage.

Quality Attributes

High-quality requirements exhibit several essential attributes:

Completeness: Requirements should fully specify the needed capability without leaving gaps that implementers must fill with assumptions. Complete requirements address normal operation, error conditions, boundary cases, and startup and shutdown behaviors.

Consistency: Requirements should not conflict with each other or with applicable standards and regulations. Inconsistencies must be identified and resolved before proceeding to design, as conflicting requirements cannot be satisfied simultaneously.

Unambiguity: Requirements should have only one possible interpretation. Vague terms like fast, easy, or user-friendly should be replaced with measurable criteria. Ambiguous requirements lead to implementations that may satisfy the literal text while failing to meet actual needs.

Verifiability: Each requirement should be testable through inspection, analysis, demonstration, or test. Requirements that cannot be verified provide no basis for accepting or rejecting the implemented system. Verifiable requirements include specific, measurable criteria for compliance.

Traceability: Requirements should be traceable to their sources and to the design elements, code, and tests that implement and verify them. Traceability supports impact analysis for changes and provides evidence of completeness for certification.

Analysis Techniques

Requirements modeling: Creating models of the system from requirements helps visualize behavior and identify missing or inconsistent requirements. Use case diagrams, state machines, data flow diagrams, and sequence diagrams are common modeling techniques. For embedded systems, models may also include timing diagrams and physical interaction diagrams.

Requirements prioritization: Not all requirements have equal importance. Prioritization techniques such as MoSCoW (Must have, Should have, Could have, Won't have), numerical ranking, or pairwise comparison help focus development effort on the most critical capabilities and guide decisions when constraints force trade-offs.

Feasibility analysis: Technical feasibility analysis evaluates whether requirements can be satisfied with available technology, within schedule and budget constraints, and with acceptable risk. For embedded systems, feasibility often depends on hardware capabilities, power budgets, and real-time performance that must be analyzed before committing to implementation approaches.

Specification Documents

Requirements specifications typically follow hierarchical structures that organize requirements by system level, subsystem, and component. ISO/IEC/IEEE 29148 names a set of documents that reflects this hierarchy: an operational concept document describing how stakeholders will use the system in its intended environment, a stakeholder requirements specification recording what stakeholders need in their own terms, a system requirements specification translating those needs into technical requirements on the system as a whole, and a software requirements specification covering the software elements. Embedded programs commonly add a hardware requirements specification for electronic and mechanical elements, and requirements flow downward from each level to the next.

This layering matters because it separates the problem from the solution. Stakeholder requirements state the need without presupposing an architecture; system requirements state what the delivered system must do; and only at the software and hardware levels do requirements attach to specific elements. Each level traces to the one above it, so a change in stakeholder need has a visible path to the components it affects.

Each requirement statement typically includes a unique identifier for traceability, the requirement text itself, rationale explaining why the requirement exists, priority or criticality classification, verification method, and source identifying where the requirement originated. Additional attributes may include status, assigned owner, allocated integrity level, and links to related requirements. The verification method is conventionally drawn from a short list: inspection, analysis, demonstration, and test. Recording it alongside the requirement forces authors to confront, at authoring time, whether the statement can be verified at all.

Writing Effective Requirements

Effective requirement statements follow conventions that promote clarity and testability:

Use consistent terminology defined in a project glossary. Technical terms should have precise definitions that all stakeholders understand. Avoid synonyms that could introduce confusion about whether similar terms refer to the same or different concepts.

Express requirements in active voice with clear subjects. Statements like "The system shall..." identify responsibility clearly, while passive voice can obscure who or what must satisfy the requirement.

Include quantitative criteria wherever possible. Instead of "The system shall respond quickly," specify "The system shall respond within 100 milliseconds." Quantitative requirements enable objective verification and prevent disputes about whether requirements are satisfied.

Avoid combining multiple requirements in single statements. Compound requirements are harder to trace, test, and change. Each requirement should address a single capability or constraint that can be verified independently.

Structured Natural Language and EARS

Free-form prose invites ambiguity even when authors are careful. Structured natural language constrains sentence form without demanding a formal notation, capturing much of the precision of formal methods while remaining readable by non-specialist stakeholders. The best known of these conventions is EARS, the Easy Approach to Requirements Syntax, developed at Rolls-Royce and first presented at the IEEE International Requirements Engineering Conference in 2009 during work on jet engine control software.

EARS defines a general template built from optional preconditions and triggers: While some precondition holds, when some trigger occurs, the system shall produce some response. From this template it derives five patterns:

• Ubiquitous: a requirement that always applies, with no trigger or precondition ("The controller shall maintain a fault log").
• Event-driven: a response to a specific trigger, introduced by when ("When the operator presses the emergency stop, the controller shall de-energize the drive within 50 milliseconds").
• State-driven: a behavior that holds throughout a state, introduced by while ("While in calibration mode, the controller shall inhibit actuator output").
• Optional feature: behavior present only in configurations that include a feature, introduced by where ("Where the unit includes a cellular modem, the controller shall report faults to the fleet server").
• Unwanted behavior: the response to error and off-nominal conditions, introduced by if and then ("If the temperature sensor reading is invalid for more than three consecutive samples, then the controller shall enter degraded mode").

The unwanted-behavior pattern earns its place in embedded work. Prompting authors explicitly for what happens when a sensor fails, a message is lost, or a supply rail sags surfaces the error-handling requirements that free-form specifications routinely omit, and those omissions are a common source of field failures. Because each pattern maps cleanly onto a test case, EARS-formatted requirements also simplify the construction of a verification matrix.

Quantifying Timing, Memory, and Power Budgets

The requirements that most often fail verification in embedded projects are the quantitative ones, because they were written loosely. Three families deserve particular care.

Timing. A usable timing requirement names the stimulus, the response, the deadline, and the consequence of missing it. It also states the measurement conditions: worst case or typical, at what processor clock, under what load, and measured from which observable event. Distinguishing hard deadlines, where a miss constitutes system failure, from firm deadlines, where a late result has no value but causes no failure, and soft deadlines, where value degrades gradually, tells designers where they must schedule conservatively and where they may not. Periodic activities need a period and a jitter tolerance in addition to a deadline, since a control loop that runs at the right average rate but with irregular spacing can still destabilize the plant it controls. Requirements written this way feed directly into schedulability analysis and worst-case execution time budgets; see real-time software design.

Memory and processing. Microcontroller programs live inside fixed flash and RAM, and a build that does not fit is not a performance problem but a hard failure. Useful requirements allocate budgets per subsystem rather than for the program as a whole, cover static and dynamic memory separately, and state a worst-case stack depth. Because the code grows over the life of a product, budgets are typically set with headroom reserved for maintenance and future features. Processor utilization deserves the same treatment: a ceiling well below full occupancy leaves margin for interrupt bursts and for the load growth that later releases inevitably bring.

Power and energy. For battery-operated and energy-harvesting products, a single average-current figure is rarely sufficient. The requirement set should cover current in each operating mode, the duty cycle across a representative usage profile, peak current the supply must deliver without excessive droop, and the resulting energy per operating cycle. Peak current constrains the regulator, the battery chemistry, and the decoupling network, while average current determines service life. Stating the usage profile explicitly matters as much as stating the numbers, since a device that meets its battery-life target on one duty cycle may miss it badly on another.

Standards and Templates

Industry standards provide templates and guidance for requirements specifications. IEEE 830, long the most widely used template for software requirements specifications, focused narrowly on the structure, content, and quality characteristics of the specification document itself. It has been superseded by ISO/IEC/IEEE 29148, which absorbs and extends IEEE 830 along with IEEE 1233 on system requirements specifications and IEEE 1362 on concept-of-operations documents. The combined standard covers the full requirements engineering lifecycle, including elicitation, analysis, specification, and validation, and aligns with the broader ISO/IEC/IEEE 15288 and 12207 lifecycle process standards. The current edition, published in 2018, replaced the first edition of 2011.

Beyond the formal standards, the INCOSE Guide to Writing Requirements supplies a widely used catalog of rules and characteristics for individual requirement statements and for requirement sets, and it pairs naturally with the document structures that ISO/IEC/IEEE 29148 defines. Domain-specific standards such as DO-178C for airborne software and ISO 26262 for road vehicles impose additional obligations on specification content, on the derivation of requirements from higher levels, and on the evidence that must accompany them.

Using established templates and standards improves consistency, ensures completeness, and facilitates review by stakeholders familiar with standard formats. Organizations often adapt standard templates to address their specific needs while maintaining compatibility with industry practices. The adaptation should be deliberate and documented, because auditors and certification authorities will ask why a tailored process still satisfies the standard it claims to follow.

Change Control

Requirements changes are inevitable, but uncontrolled changes lead to scope creep, schedule delays, and products that satisfy no one. Change control processes evaluate proposed changes for necessity, impact, cost, and risk before approval. Formal change control boards review significant changes and make disposition decisions.

Change control begins with a baseline. Placing an approved requirements set under configuration management fixes a known reference against which every later proposal is evaluated and every design artifact is traced. Without a baseline there is no way to say what changed, when, or on whose authority, and certification evidence becomes impossible to assemble. The mechanics are the same ones applied to source code and are described in configuration management.

Impact analysis determines how proposed changes affect other requirements, design elements, code, tests, schedules, and costs. For embedded systems, changes may have cascading effects across hardware and software that must be fully understood before proceeding. Changes late in development are particularly costly when they affect hardware that has already been fabricated or tooled: a requirement that adds one more sensor input can mean a board respin, new qualification testing, and revised regulatory submissions. This asymmetry is the practical reason embedded programs freeze hardware-driving requirements earlier than software-only projects freeze theirs.

Traceability Management

Traceability establishes and maintains links between requirements and other project artifacts. Forward traceability links requirements to design elements, code modules, and test cases that implement and verify them. Backward traceability links requirements to their sources including stakeholder statements, standards, and higher-level requirements.

Traceability matrices or databases capture these relationships and support analysis activities. Coverage analysis uses traceability to identify requirements that lack corresponding design elements or tests. Impact analysis uses traceability to identify all artifacts affected by requirements changes. Compliance demonstration uses traceability to show that all requirements are implemented and verified.

Derived requirements deserve separate handling. These are requirements introduced by design decisions rather than flowed down from a higher level: a watchdog refresh interval chosen once a particular microcontroller is selected, or a buffer size implied by a protocol stack. Because they have no parent, they break backward traceability by construction, and safety standards therefore require that they be identified as derived and fed back into the safety assessment. The reason is direct: a design decision can introduce a hazard that the original hazard analysis never considered, and only a deliberate review catches it. Marking derived requirements also prevents reviewers from chasing missing parents that never existed.

Requirements Management Tools

Requirements management tools support the capture, organization, analysis, and tracking of requirements throughout the lifecycle. These tools provide structured storage for requirements with attributes and relationships, support for reviews and approvals, change control workflows, traceability management, and reporting capabilities.

Common tools range from simple spreadsheets for small projects to dedicated requirements management applications for complex systems. In regulated embedded domains the established products include IBM Engineering Requirements Management DOORS Next, Siemens Polarion, PTC Codebeamer, and Jama Connect, all of which support the traceability and audit evidence that ISO 26262, IEC 62304, and DO-178C programs must produce. Lighter-weight approaches, including requirements held as version-controlled text alongside the source code, work well for smaller projects and preserve the review and history mechanisms the team already uses.

Because requirements frequently cross organizational boundaries, particularly between vehicle manufacturers and their suppliers, exchange formats matter. The Requirements Interchange Format (ReqIF), an Object Management Group standard, allows requirement sets and their attributes and links to move between tools without loss, and it is widely used for supplier exchange in the automotive industry.

Tool selection depends on project complexity, team size, compliance needs, and integration with the rest of the toolchain. For safety-critical embedded systems, tool qualification may be required so that a tool malfunction cannot introduce an undetected error into requirements artifacts. ISO 26262 derives a Tool Confidence Level from the tool's potential impact and the likelihood that an error would be detected, and it requires qualification for tools that fall into the higher confidence levels. DO-330 provides the corresponding framework for airborne systems, assigning Tool Qualification Levels according to the tool's role and the software level of the product it supports. The relevant point for requirements engineering is that qualification effort is a program cost, so the toolchain should be chosen alongside the certification strategy rather than after it.

Requirements Reviews

Formal reviews of requirements documents identify defects before they propagate to design and implementation. Reviews check requirements for quality attributes including completeness, consistency, correctness, and verifiability. Review participants should include stakeholders who provided requirements, domain experts, designers who will implement requirements, and testers who will verify them.

Structured review techniques such as inspections follow defined processes that have been shown to find defects effectively. Checklist-based reviews ensure that common issues are systematically examined. Review findings are documented and tracked to closure.

Requirements Validation

Validation confirms that specified requirements actually represent stakeholder needs. Prototyping allows stakeholders to experience proposed capabilities and provide feedback before full implementation. Simulation models demonstrate system behavior in scenarios that help stakeholders evaluate whether requirements will produce satisfactory results.

Requirements walkthroughs present requirements to stakeholders in the context of operational scenarios, helping identify gaps or misunderstandings that might not be apparent from reviewing requirements in isolation. User acceptance criteria, defined early in the project, establish the basis for final validation that the delivered system meets actual needs.

Requirements-Based Testing

In certified domains, tests are derived from requirements rather than from the code, and the traceability between them is itself an audited artifact. Every requirement must have at least one test case, and every test case must trace back to a requirement. Tests without a parent requirement signal either an untraced requirement or unnecessary work; requirements without a test signal a verification gap.

Structural coverage analysis then measures how thoroughly the requirements-based tests exercised the code, and it is used as a check on the requirements rather than as a testing goal in its own right. Code reached by no test points to a missing requirement, dead code, or deactivated code that must be justified. DO-178C scales the rigor of this analysis with the Design Assurance Level, calling for statement coverage at Level C, decision coverage at Levels B and A, and modified condition/decision coverage at Level A. Because that analysis can only succeed if the requirements were complete and testable, coverage shortfalls are frequently traced back to requirements defects rather than to gaps in test design. Related practice is covered in testing and verification and system-level testing.