Requirements Engineering for Clearly Defined and Verifiable Systems

Clarifying, aligning and managing requirements throughout development
Electronic control unit with cable connections alongside a technical drawing and a digital requirements diagram for system development.

Turning expectations into technical requirements

“The control unit should detect a fault” describes an intention. For development, however, key information is still missing: Which fault is meant? Under what conditions and within what time must it be detected? How should the system respond, and how will this be verified?

Silver Atena addresses questions like these before differing expectations turn into technical decisions. We identify, analyse and document requirements for electronic systems and maintain traceable links to architecture, development and testing. If a requirement changes, these documented relationships help identify potential impacts on development results and verification activities.

Discuss requirements
 

When unclear requirements become a development issue

Requirements come from different sources: customers and other stakeholders, the intended application, and technical or regulatory specifications. They are not always available at the same level of detail. Some describe a function, others a constraint. Individual statements may contradict one another or leave essential information open.

What initially appears to be a wording detail can later affect an architectural decision. Hardware and software may then implement different assumptions. During testing, there may be no clear criterion for assessing the result.

Requirements Engineering clarifies the meaning and scope of requirements and their relationships to other specifications. This clarification starts early and continues throughout development.

  • A common understanding
    Terms, conditions and expected behaviour are described so that all teams involved work from the same requirement.
  • Make contradictions visible
    Requirements are not considered in isolation. Their relationships show where statements conflict or where a decision is still outstanding.
  • Establish verifiability early
    When a requirement is formulated, we already consider how its fulfilment can later be demonstrated.
  • Assess changes in context
    If a requirement is revised, documented relationships help identify the affected requirements, development results and verification activities.
Two Silver Atena employees discussing printed circuit boards (PCBs) and their integration into an open control unit housing.
Three Silver Atena employees working together at a computer workstation and discussing technical project details.

What Silver Atena provides in Requirements Engineering

Silver Atena combines requirements analysis with the development of electronic systems and control units. Our systems development teams work closely with architecture, hardware, software, safety and testing. Questions from these disciplines feed back into the clarification of requirements.

The focus is on functional and non-functional requirements: What should the system do? Which properties and constraints must it meet? The results are structured across the requirement levels needed for the project and maintained throughout development.

Requirements management: capturing, structuring and maintaining requirements

  • Analyse stakeholder requirements

    We examine the expectations and specifications for a system and clarify which technical requirements can be derived from them. Incomplete or ambiguous information is fed back for alignment.

  • Structure system, hardware and software requirements

    Requirements are assigned to the appropriate levels and placed in a clear context. Depending on the project, this results in requirement specifications at stakeholder, system, hardware and software level. Whether these are managed as customer requirements specifications, system specifications or in a requirements management tool depends on the project.
    The requirements describe the required behaviour and applicable constraints. How functions are allocated to components and implemented technically is addressed by the system architecture and the respective development disciplines.

  • Establish traceability

    We document relationships between requirements at different levels and link them to architecture, implementation and planned verification evidence.
    This traceability helps determine where a requirement originates, which development results are based on it and how its fulfilment is to be verified.

  • Manage changes and versions

    Requirements do not necessarily remain unchanged throughout a project. We support the documentation of new revisions and assess their impact together with the affected specialist disciplines.

  • Support verification and validation

    We formulate technical requirements so that their fulfilment can be verified using appropriate methods. To achieve this, we align them with the teams planning tests, analyses, inspections or demonstrations. Testing the developed product and validating it against its intended use are carried out in cooperation with test and validation.

How requirements evolve throughout a project

Requirements Engineering is not a one-off documentation task at the start of a project. Requirements are clarified early and refined as new findings or changes emerge.

  1. Gather information
    Which expectations, technical specifications and constraints are available? We capture the statements relevant to the system and identify open questions.
  2. Clarify statements
    Requirements are checked for clarity and contradictions. Ambiguous terms and missing conditions are clarified with the relevant stakeholders.
  3. Build a requirements structure
    The agreed specifications are distributed across the required levels and documented. This gives systems development, hardware, software and other disciplines a structured requirements baseline to work from.
  4. Link relationships and evidence
    We document the relationships between requirements and, as development progresses, link them to results and planned verification activities. This also makes it clear where suitable verification evidence has not yet been defined for a requirement.
  5. Incorporate new findings
    If changes arise during development, the requirements baseline is updated. The affected relationships are reviewed so that the change is not limited to the source document.
  6. Maintain the baseline through to verification
    As architecture, hardware and software are developed, requirements continue to be aligned. Results from development and testing can raise new questions that need to be resolved within Requirements Engineering.
Silver Atena employee explaining technical requirements during a meeting with a colleague.

Methods, tools and standards in Requirements Engineering

Key methods include requirements analysis, structuring requirements across different levels, maintaining relationships between requirements and controlled change management. Tool-supported requirements management can support this work, particularly when several teams and requirement baselines are involved.

The applicable framework depends on the project. In the automotive sector, Automotive SPICE is used as a model for assessing development processes. ISO 26262 may be relevant for safety-related electrical and electronic vehicle systems. SAE ARP4754B may provide guidance for the development of civil aircraft systems. The applicable requirements depend on the project and its certification context.

Requirements in Automotive, Aerospace and Defence

Documentation and evidence requirements vary depending on the product. What the three sectors have in common is that technical requirements must be understood and implemented across several development disciplines.

Automotive

In electronic vehicle systems, requirements for system functions, control units, hardware and software are closely interconnected. Depending on the application, requirements from functional safety and cyber security may also apply. Changes must be assessed across these levels.

Aerospace

For electronic aerospace systems, the link between system requirements, technical implementation and verification is essential. Requirements must be structured so that the required evidence can be built upon them.

Defence

For electronic systems used in defence applications, functions and constraints must be described in line with the intended use. The required documentation and evidence depend on the project.

Your advantages with clear Requirements Engineering

  • Fewer unresolved assumptions
    Open points become visible before multiple teams continue working on different interpretations.
  • Assess changes with context
    Traceability shows which parts of the development may be affected by a changed requirement.
  • Prepare tests more precisely
    If requirements are clear and verifiable, suitable verification methods can be planned.
  • Trace decisions back to requirements
    Architecture and development remain linked to the requirements on which they are based.
Two Silver Atena employees jointly examining an electronic assembly with measurement cables in the development laboratory.

Requirements Engineering in combination with other competences

Requirements engineering provides a foundation for development, but it also receives feedback from it. An architectural decision may show that a requirement needs to be refined. A test may reveal that the expected behaviour has not yet been described clearly enough.

System architecture and system integration turn requirements into a technical structure and define how the system elements interact. Hardware development, embedded software, and control and function development specify the implementation within their respective disciplines.

Functional safety and cyber security add further requirements depending on the application. Quality and configuration management is closely involved in managing versions and changes. Test and validation verify the developed product and document the results of the planned verification activities.

Why Silver Atena for Requirements Engineering?

Silver Atena works with requirements as part of its own system and product development activities. Our teams understand the questions that arise during implementation: Is an interface described clearly? Is the required behaviour technically unambiguous? Can testing later determine whether the requirement has been fulfilled?

Close coordination with architecture, hardware, software, safety and testing helps resolve these questions within the project and refine the requirements accordingly. Silver Atena contributes experience from the development of electronic systems and control units for Automotive, Aerospace and Defence.

Two Silver Atena employees discussing technical topics at a workstation in the electronics laboratory.

Let us clarify your requirements

Are you starting a new system development project, or do existing requirements need to be aligned with architecture, development and testing? Silver Atena supports you in clarifying and structuring technical requirements and maintaining traceability throughout the development process.

 Discuss requirements