Requirements & Requirements Management

Webinar Recap: Achieving Automotive Engineering Excellence Without Requirements Management Frustration

By |

Automotive EngineeringWhile industry regulations provide some guidance when it comes to requirements management, every organization has to develop their own processes that match the product they are developing. An automotive engineering team’s requirements management process and the tools they use must also meet the everyday needs of engineers working on the product in order to support them, rather than hinder them.

In our recent webinar, automotive experts Adrian Rolufs (Automotive Solutions Lead at Jama Software) and Fabian Koark (CEO  at INVENSITY) shared best practices for establishing cutting edge requirements engineering for the automotive industry. This webinar enables you to improve your requirements management and engineering process, no matter which regulations you follow or software you use.

Watch the recording – or read part of the below transcript – of this webinar to learn how to:

– Measure the performance of your existing requirements management and engineering activities
– Find the right requirements management strategy for your organization
– Analyze the needs and use-cases of the different engineering roles
– Define and establish the right engineering layers and links to promote fast decomposition and transparent traceability

Fabian Koark: I think we can talk about high complex environments and systems and processes, but in the end, it comes down to a very simple process. And what I see today, and we’ve seen in the past that we as engineering leaders often underestimate the first two steps. The considerably simple tasks of reading and understanding a requirement. And I think these first two steps are still very important. And we have to make sure that we give our engineers the right time, the right tool to do these things. And when I say understanding, I really mean achieve a level of comprehension. That also means in a lot of different areas that we might disagree, we might know better, and we need to develop a space where engineers can exchange their disagreement because for everybody who has been in product development a long time, disagreement is a fantastic source for innovation. And therefore, if we agree or disagree on requirement, we can move the project really forward.

And also, I don’t believe with the existing budget restrictions that we see in this project. We can fulfill a certain requirement. It also means we might need to give the engineering team the power to reject something. And in whatever the outcome of this step of understanding comprehension is, it moves the project further. No matter if we reject something and then initiate an escalation and then discussion about a specific requirement, maybe initiate a renegotiation of an engineering budget. This all is a very productive activity, and we should not underestimate that.

And then moving forward in the other steps and also understanding that comprehension of a requirement is not the same as analyzing the impact of the requirement. Especially we will come back to this a little bit later, but we really have to understand how difficult or complex is this requirement? How challenging will it be for us to implement it and to achieve the performance targets that certain requirement brings with it? And in the case of especially in an automotive system, we have multiple levels of requirements and system design from a feature level subsystems to a component part level. So, there are very different teams involved and different supplier levels involved. We need to make a good job in the decomposition and provide an environment and a good process that can support that.

And then this process will not stop. In the end, we build and implement the product and we verify the implementation and then we learn something. We learn in testing and in other verification techniques such as design verification or inspections of a design that our requirement was too loose or our requirements was too strict or we missed something completely, and then we have to start the cycle again with this feedback. And as we see here, it can be a very dependent, be a very fast cycle or can be very slow cycle. It just depends how much agility we want to give our organization.

But requirements engineering and management does not look the same for every role in a product development team. It will be depending on the domain when a mechanical engineer or software engineer, or systems engineer, or the project manager, or the validation and test engineer, I have very different needs. As a project manager, I want to plan things and I always want to track an overview. So, the requirements management part is more interesting for me. I want to get KPIs of this. How much traceability do we have today? How much do we already have analyzed? Are we falling behind? Do we have a bottleneck on writing requirements or do we have a bottleneck of analyzing requirements? I want to know the bottlenecks because if I know the bottlenecks as a project manager, I can allocate more resources.

As a mechanical engineer, I’m not so interested in too many functional and software requirement, but I’m very interested in all the environmental conditions my system has to survive. And what are the right requirements that are allocated to my bearings, to my SEOs, to my housing? These are things that are really relevant. I don’t want to be overwhelmed by 10,000 software requirements, and I have to find the needle in the haystack for the requirements that are really relevant for me. So, I really filter function and focusing on location is super important for me maybe as a mechanical engineer.

As a software engineer, I would like to have requirements but at the same time, I live in a very Agile environment. I work from sprint to sprint, and I have scrum meetings in between and I pick up new requirements every week. So, I need a good integration of my requirements in my backlogs so that the one thing cannot be disconnected to the other thing. And as a validation engineer, I enjoy the most to be on the road and to test my features and my performance in the AutomotiveSPICE in a vehicle. And sometimes with WiFi, sometimes without. So, I need to have my test specification by hand, no matter if a complex IT system is working or a service available or not. So, I want in the end also be able to work through my test specifications also type of requirement on a clipboard. And the requirements manager sits in between and needs to organize that all these different opinions and requests are fulfilled. So, we already see that can be kind of challenging, but I believe it starts with awareness of what the different roles in the engineering project need.

RELATED: ASPICE 101: What is Automotive SPICE?

One thing we need to give ourselves some transparency is a structure. A structure of what kind of levels and what kind of types of artifacts of specification and requirements do we want to establish in our program and that need to look different in every organization. Entirely depending on the industry. It’s depending on not just the industry and not just the tier one, tier two, tier three supplier level, but it’s also depending what type of product I provide. Is it safety-critical? Is it cybersecurity critical? Has it a lot of feature or has it a lot of mechanical interface? And that will determine what are the levels of design that really need and here the key is, the leaner the better, but leaner does not always mean to skip certain steps. I will come back to that a little bit later. I always suggest to separate specification from requirement. Incoming requirements on every level are the things that are requested from the other team or the outside organization. And specification gives me as an engineer the chance to specify how I will fulfill these requirements before I implement that and it gives me a lot of power, the negotiation power, and protects my back.

And I always suggest to not see requirements as an independent thing or specification. It’s highly connected to architectures. It’s highly connected to concepts. It’s also connected to design verification analysis topics like an FMEA, like a fault tree analysis, like a software criticality analysis, no matter on what kind of level. And I need to make sure that I keep this sometimes called engineering entity model together and relationship model together. I need something like that.

Watch our full webinar here: Achieving Automotive Engineering Success Without Requirements Management Frustration.


Jama Software
Latest posts by Jama Software (see all)