#3 Are you considering entry into the autonomous vehicle industry?

I published this article because I receive hundreds of individual and startup inquiries about the autonomous vehicle industry, so I felt it was essential to write on this topic.

If you think this topic is not your cup of tea, please keep on reading. It is relevant to every company I have worked for.

What is inside?

• Here's a bit of personal background.

• The Best Practices and Standards

• The Process of Requirements Engineering

  • Customer Requirements (CRS)

  • Stakeholders’ requirements

  • RFI, RFQ and Gap Analiysis

  • Intelligent combining of CRS and Internal Stakehol …

  • System Requirement Specification (SRS)

  • Technical Requirements Specification (TRS)

  • Requirements Tools

  • The Change Control Board (CCB)

  • Legal Compliance across geographic markets

  • Privacy and customer protection laws

  • Summary

Here's a bit of personal background.

I have been a systems architect and consultant for a long time. That means I have worked with many organizations, from huge ones to startups, mentoring them and providing software solutions.

Today, in my position, I receive hundreds of inquiries from other companies and recruiters and interview individuals trying to work within the automotive industry, but many struggle to understand automotive needs.

I have always intended to write a book, but I never have time to finish it, and since retirement is a long way off, I decided to write a series of short articles instead.

I hope this article will help the candidates understand the “best practices” and “lingo” used in the automotive industry.

Why start with the requirements?

The topic of Automotive Requirements Management may not be exciting.
Trust me, I understand—but it is essential.

There is a very good reason why I decided to spend considerable time writing about it.

Requirements management is fundamental to the automotive industry; it is the backbone of automotive system design, development, and validation.

It’s a rigorous process that begins with meticulously defined atomic stakeholder requirements, which are transformed into the requirements of systems, software, hardware, and their components.

To use the lingo, there are High-level Design Documents (HDD) that describe system needs.

The Component-level Design Documents (CDD) describe the design details and their implementation to the lowest API or capacitor value you plan to use.

People might argue that implementation details should not be in the requirements, but trust me, they are, and after hundreds of conversations, I have concluded that they should be.

The key concept of bi-directional traceability

Crucially, car makers, called Original Equipment Manufacturers (OEMs), mandate a comprehensive, bidirectional pipeline of requirement traceability as a precondition for considering a supplier’s (that is you) entry into the automotive market.

This traceability illustrates the journey from requirements through design, development, and validation and cannot be retrospectively fabricated, underscoring how paramount well-structured atomic requirements are at the very outset.

A company’s credibility, market entry, and success hinge on its mastery of thorough, compliant, and efficient requirements management.

The Best Practices and Standards

Ensuring compliance with standards like ISO 26262 and ASPICE is indispensable in managing functional safety (FUSA) risks and enhancing the software development process.
Hint: you should have the above numbers on your resume.

ISO 26262, a standard for automotive functional safety, mitigates risks associated with potential malfunctions of electronic and electrical systems in vehicles.

Automotive Software Process Improvement and Capability Determination or ASPICE, on the other hand, provides a framework for hardware/software process assessment, improving quality and ensuring the development process is controlled and effective.
Hint: There will be interview questions about details of SPICE

The Process of Requirements Engineering

Customer Requirements (CRS)

Customer requirements (CRS) are the starting point, encompassing desires and expectations from the vehicle’s performance, safety, comfort, fuel efficiency, and more.

Stakeholders’ requirements

In addition to customer requirements, stakeholder requirements are crucial in automotive requirements management.

Stakeholder requirements entail expectations from the business development team, competitive market research, product management, and system architects establishing the baseline product requirements.

The team conducts comprehensive market analyses to comprehend competitor strategies, market trends, and consumer preferences. These findings influence requirement generation by ensuring the product can compete in the market.

Product management is responsible for the overall product strategy and defines key features and functionalities based on market research, technical feasibility, cost-effectiveness, and profitability. Their requirements align the product’s development with the business strategy.

Baseline product requirements refer to the essential specifications a product must fulfill to be deemed viable. These standards are typically set in the context of existing products, industry norms, legal requirements, and safety standards. They form the benchmark against which customer requirements are compared, ensuring the customer’s desires are feasible and align with the product’s fundamental capabilities.

RFI, RFQ and Gap Analiysis

The Customer Requirements from the “Request for Information” (RFI), “Request for Quote” (RFQ), and “contract award” are compared and analyzed against the baseline product requirements to establish the gap analysis, feasibility, and cost when responding to the client (OEM).

The suppliers’ team is expected to resolve the requirements gaps for a day or two every week for the project's lifetime (i.e., 3 to 4 years). A system architect and a field engineer are essential for this task.

Intelligent combining of CRS and Internal Stakeholder requirements

By integrating stakeholders’ requirements with customer requirements, an automotive company can effectively balance market competitiveness, strategic alignment, baseline product integrity, and customer satisfaction. This fusion of requirements is vital to designing, developing, and validating a product that meets market needs and maintains requirement traceability, a critical prerequisite for gaining OEM consideration and securing market entry.

System Requirement Specification (SRS)

Once these requirements are gathered, they are analyzed and distilled into high-level system requirements, which detail the technical specifications necessary for the vehicle or the subsystem (i.e., RADAR, cameras, LiDAR, ADAS) to meet customer needs.

Technical Requirements Specification (TRS)

Subsequently, these system requirements are broken down into component-level (mechanical, optical, electrical engineering, thermal, etc.) and software requirements. These dictate how the vehicle’s embedded sub-systems and software function. Therefore, these requirements contribute significantly to the vehicle’s performance, safety, Key Performance Indicators (KPI), and other features.

Requirements Tools

Tools like Polarion, DNG, and Windchill try to facilitate efficient and traceable management of these requirements throughout the product development lifecycle.

Several tools are commonly used to manage this process:

1. Polarion: A state-of-the-art tool that is the easiest for managing and consuming (reading) the requirements.

2. IBM’s Doors Next Generation (DNG) is commonly used in the industry.
   I have spent years using it, and I do not love it.

3. PTC Windchill is another option; some OEMs use it.
   However, I cannot recommend it.

4. JIRA does very well in terms of requirements management, team reviews, traceability, and ease of use.

The Change Control Board (CCB)

The autonomous automotive industry is marked by rapid technological advancements, evolving customer expectations, and changing regulatory landscapes (sometimes yearly), often leading to dynamic requirement changes. Managing these changes effectively is vital to maintaining product development consistency and relevance.