SYS.2 System Requirements Analysis

Involved in the challenges of Automotive SPICE, particularly system requirements analysis? Read on for a quick overview of key information on SYS.2, a key process from VDA Scope, including a video and our free white paper.

back to Automotive SPICE
Process ID
Process group
System Engineering

Automotive SPICE® is a trademark of VDA QMC.

The System Requirements Analysis process in Automotive SPICE® (also known as SYS.2) helps your organization to transform the defined stakeholder requirements into a set of system requirements that will guide the design of the system.

Why should you document the system requirements? As a rule, you already have customer requirements, so why invest time and effort to document additional system requirements? In a project, you want to deliver the agreed results on time, within budget, and in the quality required by the customer. If you do not document your system requirements, you may overlook the functionality or completely misinterpret your customers' expectations. This causes additional effort, costs and delays. You can also overlook aspects of your system that are essential to the functionality or non-functional aspects of your system. This can lead to false starts or even additional development cycles.

The following are the most important aspects of System Requirements Analysis in Automotive SPICE®.

Image   The SYS.2 process under VDA Scope
Your free white paper

Interested in finding out more about System Requirements Analysis (SYS.2), the Automotive SPICE® process from VDA Scope? Our free white paper provides you with a summary of all key information, including an extract from our book on Automotive SPICE® Essentials – ideal reading for anyone new to the topic of process improvements. 

Why do we need System Requirements and structure them?

An important reason for documenting system requirements is that you need to consider more than your customer's expectations. Most systems must meet standards, norms, and other regulations that increase the number of requirements. For this reason, the process describes them as stakeholder requirements. For documentation purposes, map the stakeholder requirements to your system requirements that reflect your internal view of the system. The system requirements in turn form the basis for the system qualification test and all downstream processes, e.g. system architecture. 

The system requirements describe the system as a black box, the "what". What should the system do, not "how" should it do something. So, when we develop an electronic control unit, an ECU, we identify the following:

  • They describe what the signals are that reach the pins of the connector, what the system should do with these signals, and what output signals we expect at the pins of the connector.
  • Part of this approach is also to structure the requirements in such a way that they are meaningful for the internal organization and support the distribution to different areas. 
  • This ensures that each organizational unit knows which requirements are relevant to it. These may be attributes, e.g. to classify requirements according to ISO 26262, it could be a functional structure to support distribution to function groups, etc.

Typically, requirements management is supported by appropriate tools such as a requirements database.

We're here for you

Need support with a key project? We’re your first port of call when it comes to management consulting and improvement programmes in electronics development.

Steffen Herrmann and the sales team

Staffing of this process.

A challenge can be how to find employees who can support the definition of system requirements. The reason why this is a challenge is that a systems engineer must be an all-rounder. If you want to develop a mechatronic system such as power steering, this engineer must have a deep understanding of mechanics, electronics and software development. This is almost impossible to combine in one person. If you do not have this type of personnel, a workaround would be to put together a cross-domain team responsible for jointly defining system requirements.

Why should you analyze the requirements?

Another aspect of this process, as the name suggests, is the analysis of requirements. The requirements should be analyzed for feasibility or risk. These two are closely linked. If you are not really sure about the feasibility of a requirement, there is an inherent risk, because it may take time to find a solution, or there may be no solution at all. Another topic to analyze is testability. Of course, the support of the testers can be used to ensure this. Often the testers are asked to review the requirements. The analysis should also cover the technical implications. This includes the assessment of dependencies between requirements. An example of this could be the "close" function of a window regulator ECU. The close function requires the window pane to slide upwards until the window is closed. However, there is a contradicting safety function, the so-called "anti-pinch" function, which is designed to prevent fingers from getting caught when the window is closed. There is an obvious interdependence and mutual technical implication between these requirements. This should be considered in the context of the analysis.

Last but not least, the analysis should also cover business aspects of the requirements. It should therefore be determined how the implementation of the various requirements effects costs and timeline. Now, you can say that you cannot document all this in the requirements database.

Note that Automotive SPICE does not say where you document this. For example, you could cover the first part of the analysis (feasibility and risks) in the requirements database, the technical implications in corresponding and linked change requests, and the impact on costs and schedule in your project management tools.

Why should you put effort into traceability and consistency?

This process also requires that you ensure traceability and consistency between your system requirements and stakeholder requirements.

Traceability can be established through hyperlinks such as DOORS, through specific traceability tools such as Rectify, through traceability matrices or through other manageable means which are supported your company's tool landscape.

The purpose of traceability is to 

  • to support consistency checks, i.e. to verify the completeness and accuracy of the system requirements. 
  • to support the impact assessment in case of change requests or deficiencies.
  • to support the reporting of stakeholder expectations.

The second part of this aspect is consistency.

Consistency means you have to ensure completeness and correctness of your system requirements against the stakeholder requirements. As this process is your entry into your development you want to ensure that your system requirements are covering the stakeholder requirements correctly. So, do not skip this review!

Nothing works without

As part of our strategy to systematically improve development processes in the automotive electronics sector, we are also an official licensee of Automotive SPICE® – a trademark of the Association of the German Automotive Industry (VDA QMC).

  • Using AUTOMOTIVE SPICE® to achieve the required maturity levels within your key processes in development
  • Systematically improving existing workflows and methods
  • Evaluating the status of your process improvements through formal assessments and gap analysis
  • Fulfilling the requirements of Automotive SPICE® in harmony with SECURITYFUNCTIONAL SAFETY and AGILE METHODS
  • Training your staff and assessors

Download Report