Hi folks! Let us talk about another Automotive SPICE process, System Requirements Analysis or SYS.2. I will explain system requirements and you will learn about the 4 most important aspects for most organizations. You are in the right place. Just keep watching. My name is Bhaskar Vanamali, and I am Principal Assessor and Trainer for Automotive SPICE. I have performed more than 140 formal assessments and trained more than 250 assessors. Additionally, I also support improvement projects so I also have the practical know-how. As I have a lot of experience and I like to share it I have the feeling that these videos will help to disseminate know-how on Automotive SPICE. Okay. Let's get started. 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. Aspect One: 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, for instance system architecture or other processes. 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 resch 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. Aspect two: 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. Aspect three: 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 a 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. Aspect four: why should you put effort into traceability and consistency. Well, 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 a) to support consistency checks, like for instance to verify the completeness and accuracy of the system requirements. b) to support the impact assessment in case of change requests or deficiencies. c) 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! You want to learn more about System Requirements Analysis? We have prepared a more detailed white paper, that you can download for free by clicking on the link below. If you are interested in Automotive SPICE, you might consider subscribing to this channel. We are providing expert knowledge on a regular basis. And don't forget to share this video with your colleagues!! Finally: Thanks for watching! Good luck and goodbye!