First, we need to clarify how automotive industry requirements management differs from other industries. Why treat automotive requirements management separately?

Based on the automotive industry's characteristics (reducing per-unit cost through higher production volume) and product characteristics (related to driving safety, hence subject to many regulatory requirements like functional safety ISO 26262 and cybersecurity ISO/SAE 21434), the automotive industry differs significantly from other industries in at least 6 aspects of requirements management.

Requirements Classification Management

Automotive requirements management has a long tradition of classification. In the V-model, requirements are divided into at least 3 types: market requirements, system requirements, and software requirements (sometimes also hardware requirements, with system requirements encompassing both hardware and software requirements). This is very different from Agile's Epic-Feature-Story classification (some teams also have Requirement). Automotive classification is based more on requirement source and the carrier entity. Agile classification is based mainly on size and scope. An Epic is a large requirement set (its Chinese translation "epic" implies broad scope), a Feature is a product characteristic, and a Story is understood as a user story or user scenario.

The first hurdle in fusing the V-model with Agile is: how to make automotive engineers understand Agile language—understand Epic, Feature, Story—and converse with internet engineers.

Simply forcing Agile requirement types onto the automotive industry doesn't work. First, getting automotive engineers to understand what Epic, Feature, and Story mean is already difficult. I worked at NIO for 3 years and found very divergent understandings of these three requirement types. What counts as a Feature versus a Story is very subjective. More often, these three types aren't enough, so more custom requirement types are introduced. Getting everyone aligned is even harder. Meetings often argue about what type a requirement belongs to.

At the time, our vehicle R&D department had an Excel file called FDS (Function Definition Specification). In this document, vehicle-level requirements were broken down layer by layer. Vehicle requirements were divided into 8 major blocks, including autonomous driving, smart cockpit, connected vehicles, and so on. Each major block was further divided into countless sub-blocks, layer after layer. Each requirement had multiple fields: ID, name, description, owner, related department, current status, notes, and so on. Anyone who used this FDS table back then will remember it vividly—it was better than any online tool at the time. Each level could be infinitely subdivided, collapsed, and expanded. You could grasp requirement completion from the vehicle level, or understand context from more detailed levels. Its biggest advantage: engineers had maximum freedom in requirement granularity. No rigid Epic-Feature-Story model to argue about granularity—instead, it was divided completely based on business needs and requirement complexity. Some complex requirements with many scenarios might be divided into 5-6 layers; simpler requirements might be clear in just 2 layers.

But this table had a significant drawback: it was flat and 2D. It wasn't good at linking architecture, test cases, and bugs on top of requirements—you could do it, but table complexity grows exponentially. So on top of that, we used Jira for task management and bug tracking. Later, smart cockpit requirements were managed entirely in Jira. Then we hit the "force-fitting" problem described above: to adapt to Agile management tool characteristics, we sacrificed freedom in requirement granularity.

To help automotive requirements engineers do their work better, we developed an R&D management tool specifically for the automotive industry called MappingSpace. In MappingSpace, requirements are managed as mind maps, where each node corresponds to one requirement. Mind maps' natural characteristic means requirements have varying granularity: root nodes are coarsest, outer nodes are finest. Engineers continuously decompose requirements based on product characteristics and team needs, until descriptions are clear enough and can be assigned to individual owners. Requirements engineers no longer need to wonder what counts as a Story versus a Feature.

Requirement Linking and Traceability

In the automotive industry, architecture typically accompanies requirements. In the V-model: system requirements correspond to system architecture; software requirements correspond to software architecture.

A picture is worth a thousand words—diagrams cause far less misunderstanding than text. Architecture diagrams are generally mandatory, especially when teams need to pass ASPICE, functional safety, or cybersecurity. Architecture diagrams include static architecture diagrams (module diagrams, component diagrams) and dynamic architecture diagrams (software sequence diagrams).

In the automotive industry, every requirement needs to be linked to its corresponding architecture.

This is a more rigorous approach to requirements management. In MappingSpace, architecture documents are also written as mind maps. Based on mind maps, we can decompose architecture layer by layer. The root node of an architecture document can have an overall architecture diagram; each child node can also have its own detailed architecture diagram.

With a native drawio third-party plugin, architecture drawing has significant advantages.

Every requirement also needs to be linked to test cases. Every industry has similar requirements, but in the automotive industry this requirement is particularly strict—you need to measure requirement coverage. In MappingSpace, you can view coverage from two places: the mind map page, and test reports.

Requirements Review

After requirements are written, they need review. Many industries do requirements review, but in the automotive industry, requirements review is even stricter. The system must explicitly contain the review process, review items, and the modification process after review—with process records. Many teams know review's importance. Through review, many potential defects are found before product development (automotive FMEA analysis shares the same spirit as requirements review). Solving problems at this stage is obviously more agile, efficient, and less costly than fixing them after product release.

The most efficient review is face-to-face discussion. But in many cases, discussion processes can't be accurately recorded. Review typically requires multiple roles: requirements engineers, developers, testers, architects, and so on. It's hard to gather everyone at the same time for a long, effective meeting. These are the two biggest difficulties in the review process: recording improvement points and tracking follow-up, and frequent absences from review meetings.

In MappingSpace, we also provide a review tool. We can easily select requirements to review from a requirements mind map, then send review requests including fixed reviewers plus user-specified reviewers for this round.

It's an online, non-real-time review mechanism. Before the review task ends, reviewing can happen at any time. After everyone reviews, the system determines the final result based on user-preset approval rules. The approve/reject conclusion also appears on each requirement's detail page. For rejected requirements, users can further modify until the requirement passes next time.

Requirements Baseline

In Agile development, requirements change very fast, and the concept of baseline is very weak. Requirements keep changing; the whole team develops based on the latest requirements. No need to know the starting point of each version's development. But this approach doesn't work well in the automotive industry.

The automotive industry needs a clear baseline concept. If a version is developed based on the May 1 requirement version, it might mean that between May 1 and May 30 release, the whole team develops based on the May 1 requirement version, without accepting frequent mid-cycle changes. Can't we just lock the May 1 requirements? Some teams do this—through process or tool restrictions, like pulling an SVN copy. The team develops based on this copy. But we must acknowledge: requirements change is inevitable. This approach closes the channel for rapid response to changes. If you know a requirement is wrong but still have to develop based on it until next version, that's obviously inefficient. An SVN copy also can't handle task assignment, status changes, and so on—that's another drawback.

How can we both preserve a baseline for team reference when needed, and quickly respond to requirement changes?

In MappingSpace, we provide a baseline page. This gives the whole team a baseline reference page. Baseline content is locked—you can't modify requirement content—but status progression, task assignment, and other operations are still allowed. When requirements need changes, a change review process must be followed, and the baseline page clearly shows what changed or what requirements were added.

Requirements Change Management

Change management is particularly important. If change management isn't done well, it consumes a lot of time and energy, lowering team efficiency. There are two common approaches. One: after pulling a baseline, no more changes are allowed until the current version development ends. Obviously, this isn't agile enough.

The other approach: after pulling a baseline, if there are changes, follow a change process reviewed by a change control board; after approval, add to the baseline. The change board might include architects, project managers, test engineers, and so on. If this process is done offline, or if online tools are misused, it causes significant difficulties. For example, changes generally happen after pulling a baseline; many tools have no baseline concept, so when to make change requests becomes hard to gauge. Another example: change review meetings require multiple stakeholders—how to gather everyone for discussion is also a challenge. Simply sending everyone an email doesn't truly identify change risks.

In MappingSpace, after a baseline starts, requirements are locked. After locking, you can't directly change them—instead, you pull a copy from the requirement, modify it on the copy, then initiate a change request. Reviewers are invited; the review process is also non-real-time and online. Invited reviewers' decisions (approve or reject) are all recorded in the system.

Requirements Reuse

In internet industry development, reuse is basically a non-issue. After a software product is developed, other product lines are generally different, and requirements are rarely reused.

The automotive industry is clearly a volume-driven, cost-amortizing process. Model refreshes across different vehicle models—especially hardware refreshes—are very expensive. You need maximum reuse to reduce design, mold, process optimization, and production equipment debugging costs. Tesla's development history clearly demonstrates this.

In the current era, cars increasingly value software. While software changes quickly between models and has more freedom, it's undeniable that automotive software is embedded software that needs to work with hardware. If hardware needs to stay relatively stable, it necessarily constrains software changes. Overall, whether software or hardware requirements, automotive reuse ratios are much higher than in the internet industry.

In MappingSpace, universal requirements across each vehicle model can be quickly and batch-imported into an enterprise-level requirements pool via mind maps. When new vehicle projects arrive, those requirements can easily be moved from the pool into the new project. This advantage is even more pronounced for hardware requirements management.