Requirements Engineering in Automotive Development

Daimler research

In the automotive industry- especially in the high-end market the complexity of electronic
components is increasing rapidly. Currently, about a third of all development
costs in high-end models go to electric and electronic system
development, and the cost continues to grow. At the same time, many
slightly different variations on components are each developed in a series
of prototyping phases on different schedules. Consequently, the
complexity of specification activities surpasses what conventional text-
processing systems can support in terms of management and tracing
functionality.

(see Figure 1).

Complex automotive systems yield complex requirements specifications and raise many
challenges along the way. Using real- world projects as a foundation, the authors describe
problems and solutions for requirements engineering in the automotive domain.

 What has Daimler done to address these challenges?

Piloting requirements engineering processes, methods, and tools in various development

projects
RE challenges, including those related to the software-based automotive systems domain,
which we describe briefly below, and those related to domain-independent requirements
administration and management.

The issues that are discussed here are not necessarily the current focus of RE research,
however, progress on these issues is needed for a widespread adoption of tool-supported
RE in the automotive domain.

Primary area of focus

Driver assistance and safety-critical systems

In both passenger cars and commercial vehicles, Daimler are developing more and more
systems that can intervene with the driver’s actions (examples include the electronic
stability program, the antilock braking system, and drive-by-wire). In such systems, failure
can cause severe accidents. Therefore, Daimler have a demanding development process:
system specification and system development must be completely comprehensible,
reproducible, and continuous.

Project size

Project sizes range from small efforts, with two to five developers working on a
requirements database that generates a few specification documents, to significantly larger
projects. Currently, our biggest project has a requirements database that is approximately 3
Gbytes (and growing) and generates more than 20 automotive component specification
documents. The project has about 160 users working on the database, along with 40 users
with read-only access.

RE tools

Dynamic Object-Oriented Requirements System

(Doors; see www.telelogic.com/products/doorsers/doors); RequisitePro
(www.rational.com/products/ reqpro),
Requirements Traceability and Management (RTM; see www.chipware. com).

Drawbacks

While all three support basic database management for individual requirements, their
attributes, and their history, the tools widely differ with respect to the user inter- face,
tracing and view management, distributed work, security concepts, extensibility
mechanisms, and import–export interfaces.
RE General Issues

some problems centered on technology, while others were focused on process.

1. Information models for requirements management

- Textual requirements are only part of the game—automotive development is too

com- plex for text alone to manage

when it comes to complex systems, controlling “just the textual requirements” is nearly
impossible. To reflect the characteristics and phases of the specification and development
processes, we need additional attributes, such as working state (initial, defined, and
released, for example) for the former, and due date (such as A- sample and B-sample) for
the latter.

Researchers now openly acknowledge the importance of such attributes, and use- ful
collections exist.1-6 The trick is to tailor the right set of attributes so that the effort to define
and maintain them is balanced by the benefits of better process control and specification
reuse. We must also handle the requirements’ history. In addition to record- ing the local
history of a single require- ment’s manipulation, engineers typically need a well-structured
global history of how a specific group of requirements was ma- nipulated relative to some
previous baseline.

we also must deal with a specification’s illustrations, tables, explanations about design
rationale or design decisions, test information, parameters, and accompanying background
information (such as excerpts from standards). This additional information often makes up
more than half of the overall specification.

Often, the complexity of these different objects, their attributes, and the relations between
them quickly confuses engineers. To remedy this situation, we formally de- fined all this
information using a metadata model. A requirements management infor- mation model
(RMI) is central to require- ments management projects: It forms the basis of discussions
with engineers about their needs and how they should systemati- cally manage their
specifications. Develop- ing an RMI with engineers has become our primary method for
successfully introduc- ing requirements management into proj- ects.7 To ensure consistency
and reusability, we introduced a company-wide, modular RMI that new projects can adapt
and tailor.

2. Requirements documents
 - Engineers live in a document-oriented world, and requirements management tools
must maintain its look and feel.

Tool support should retain the basic functionality of a standard text-processing user
interface while adding management and tracing functionality. Tools that deviate from basic
aspects of standard text processing are quickly discarded in real-life projects.

Tools must also contend with non-textual document information. For example, recording
the history of pictures is tricky because users typically record a picture’s change history only
on the picture level. Picture size also causes serious problems, and tools must support com-
pressed formats (which they typically don’t).
Also, because users will always have documents that contain information outside the
requirements management tool database, you should integrate requirements management
tools with document management systems. You can only achieve this at the granularity of
entire requirements management databases.

3. Problem and solution space

- There is no clear boundary between manufacturer requirements specifications and

supplier system specifications.

The user requirements document supposedly tells what the problem is, while the system
requirements document should de- scribe the solution. In the real world, however, things
are not that easy because customer demands are not limited to the problem space. In the
automotive domain particularly, there are several good reasons for customer descriptions to
go beyond the problem space:

- A system is typically divided into subsys- tems and components that different sup-
pliers provide. DaimlerChrysler must en- sure that different suppliers’ components
will work together to specify parts of an overall solution.
- When we try to separate software from hardware things get even harder. We must
specify a single component as two inter- active “problems”—a hardware problem
and a software problem.
- In many situations, DaimlerChrysler’s first-to-market strategy requires us to de- fine
certain specification document fea- tures in as much detail as possible, which may be
a concrete algorithm. Often, DaimlerChrysler must set the future stan- dard by
specifying solutions instead of problems.

4. Redundancy

- Redundancy causes good engineers to suffer, and the resulting systems will
probably suffer, too.
In large projects, such as automotive elec- trical system development, engineers simul-
taneously create several hundred lengthy specifications and related documents (of up to
several hundred pages each) under tight deadlines. It is not surprising that these doc-
uments typically contain redundant infor- mation. Furthermore, dependencies among such
documents are complex and remain partially opaque due to both the lack of time and the
number of documents and people in- volved. The disadvantages here are obvious: This form
of redundancy leads to inconsis- tencies and double work. In the worst case, specification
documents are derived from in- valid premises.

document structure typically mirrors the entire automotive business structure. Changing
document structure to remove redundancies is therefore difficult, and there is often a
negative trade-off be- tween effort and result.

getting an overview of project redundancies is a major step. Doing so makes engineers

aware of the parts of their documents that are used or elaborated somewhere else. They
can then decide to synchronize if necessary.

5. Content presentation

- Content does not cause suffering for good en- gineers, but content presentation
can create problems.

In the automotive domain, we typically build systems in increments, rather than from
scratch: A new car series inherits most functionality from existing ones, with various
adaptations, extensions, or innovations.
Consequently, at this level, there is no formal elicitation phase because developing a new
component version typically entails few related activities. We’ve found that good engineers
are premier league experts in their specialized domains and have deep insights into the
subtleties and pitfalls of requirements content. For them, content and domain knowledge is
not a significant problem.

However, content presentation and structuring offers challenges. Often, engineers describe
specifications in an unstructured way, which increases the communication ef- fort. A well-
defined RMI implemented by a requirements management tool, however, can help improve
content structure and presentation. For example, it can push engineers to break up long
specification para- graphs into atomic requirements.

Reuse is another point of improvement. Today, most specification reuse is ad hoc and
implicit, which affects efficiency and quality. The main problem with this approach,
however, is that a good specification depends completely on an engineer’s advanced
expertise in the domain. As an alternative, we propose systematically recycling existing
specifications as an explicit step in the specification process.
Finally, when you introduce a requirements management database, you must mi- grate
existing documents into the system so that they’re available for reuse in future projects.
Although requirements management tools support some automatic capturing, in our
experience, the migration process still requires significant manual work.

Process issues

process-related experiences included challenges with abstract specifications, non- functional

requirements, change, user- adaptable views, and specification reviews.

Abstract specification levels

Detailed specification typically covers only the leaves of the system decomposition tree.

Engineers cannot develop a complex system—such as an up-to-date telematics unit—solely

by talking about and dealing with the system requirements that make up the low-level,
detailed component specification. On the contrary, developing complex systems from the
top down in several layers of granularity is inevitable.

When it comes to RE, this observation still holds. Unfortunately, today systematic
processing and documentation of higher- level requirements and design decisions are
insufficient. However, if engineers don’t document these high-level requirements and
rationales, they build their detailed requirements on sand: Some will be challenged regularly
because they’re hard to justify (even though they might be of central importance); others
are completely superfluous but still exist

Last, but not least, well-structured requirements and design decisions at several layers of
abstraction are crucial for understanding a detailed specification document.

Description Techniques
- Goal trees
- Feature lists
- Use cases
- Message sequence charts
- State models

The challenge is defining a domain- or organization-specific model.

- focus on use cases.

Non-functional requirements, acceptance criteria, and test cases

Engineers fail to manage non-functional requirements, acceptance criteria, and test cases.

actual specification documents rarely meet the corresponding claims because it’s hard to
come up with reasonable acceptance criteria and appropriate test cases for functional
requirements. When it comes to non-functional requirements, the situation is even more
difficult.
writing good acceptance criteria is simply a matter of practice and personal experience.
Therefore, the best way to improve acceptance criteria is to provide concrete examples for
functional requirements and have engineers exploit and reuse these examples. Basically,
this is just another argument to foster systematic requirements recycling.
As for non-functional requirements, postulating a quality such as maintainability is hard to
substantiate. Generally, corresponding acceptance criteria and test cases are either non-
existent or too academic—“90 per- cent of all maintenance jobs should take less than five
minutes,” for example—so these requirements are practically meaningless. Whenever
possible, our experience indicates that you should stepwise refine non-functional
requirements until you can implement them as a set of functional requirements.

Change

Change and discussions about change are part of daily project life—and there’s no way to
change that.

Among the possible alterations in a project are changes in system, application, and
component requirements; changes in the RMI, the schedule, responsibilities, and sup-
pliers; and even changes in the processes and tool environment. A major underlying reason
for the frequency of change is the growing complexity, parallelization, and time restrictions
on development projects. These factors force developers to introduce more and more
assumptions about the system early in development. They then often challenge or rework
these assumptions as the system matures.

Limit RMI changes to essential ones by establishing standard RMIs across projects and
minimizing nonessential adaptations. We also found that change proposals occur far more
often than actual project changes (and they typically increase late in development). As
technical experts, engineers must quickly formulate opinions about change proposals. If RE
is based on an appropriate RMI, engineers can evaluate a proposed change’s potential
effects based on documentation of relations among requirements and corresponding
attributes.

Unfortunately, at upper levels of system decomposition, the lack of appropriate

specifications hinders the analysis and propagation of local changes introduced late in the
development process. This in turn re- duces specification reusability in subsequent projects.

User-adaptable views

User-adaptable views are a powerful instrument for guiding and managing the
specification process.

In a complex domain, RE is a complicated, continuously modified process with many

different activities. On most projects, people play various roles with complex dependencies,
and different people read, modify, review, accept, or release different aspects of the
specification at different times. By supplying both user- and situation-specific database
views, the requirements management tool lets you coordinate and sup- port the RE process
at a fundamental level.

Reviews

Well-organized specification reviews are essential for a successful manufacturer-supplier

relationship.

Informal and formal reviews occur frequently as specifications steadily evolve. These
reviews are important to assure both specification quality and subsystem compatibility and
sometimes represent the only measure to guarantee overall system compatibility and
integrity.

The automotive domain is complex, and engineers are typically responsible for several
component versions in different development phases. In such a setting, it’s both ambitious
and important to establish effective and efficient reviews.
In our experience, effective requirements management practices and appropriate tool
support are the key to successful specification reviews. The single source approach ensures
that every inspector reviews the same version of the review artifact. Role-specific views and
attributes ensure that everyone knows what to do and how to do it in each phase. In review
meetings, we document decisions online. We also provide project management with special
views to control the review process. Last, but not least, the requirements management
tool’s history features let us trace every decision and question them at any point.

Traceability
Traceability is a great feature, but the real challenge is deciding which traces to maintain.

Introducing explicit traceability promises big savings but achieving them requires a careful
tradeoff analysis. There are various potential links among objects. And, while linking
between requirements and related objects is essential, maintaining links requires effort that
should be balanced by traceability’s benefits.

Advice - to basically leave these decisions to engineers because they know what they want
and what they can accept. Generally speaking, engineers are initially keen to establish and
maintain all kinds of traces, but later they fall short on the discipline required to do so. With
this observation in mind, we recommend that you keep the number of explicit traces small.