SYS.2 System Requirements Analysis

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.

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.

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.