4 Chapter 1 Introduction
The systems engineers are the general contractors for complex designs. They
understand where all the parts go and how to talk to the domain engineers. Just as
the general contractor must make certain a water line does not get routed through
the circuit box, the systems engineer must make sure a software change doesn’t
result in excessive changes in power consumption. Just as the general contrac-
tor must extract information from the plumbing plans and electrical diagrams,
the systems engineer must understand the software design, power consumption
profile, and constraints. The systems engineer’s task is characterized by the need
to understand the relationship between design decisions local to a domain and
system-level goals and requirements.
1.2 Rosetta’s Design Goals
Many systems are simply too complex for even the best systems engineer to man-
age without specialized support. It is impossible to model systems with thousands
of interrelated design facets manually or using general-purpose computer tools.
The systems engineer needs a way to predict how a change in one component
of the system affects the overall properties of the system. Having a way to express
relationships and interactions between components and disciplines is a major step
forward in doing this analysis.
Natural language and graphical descriptions are not reliably interpretable by
computers or human engineers. Such representations are inherently ambiguous
and subject to incorrect interpretation by both computers and humans. This
assumes, of course, that the chosen representations can be interpreted by com-
puters at all. Having a way to express requirements in an unambiguous, formally
defined manner is central to all engineering disciplines and should be central to
systems engineering.
The systems engineer also needs an unambiguous way to tell the domain spe-
cialists on the product team what needs to be designed. This is analogous to
the way an architect uses blueprints to control the systems designed by plumb-
ing, electrical, and heating, ventilation, and air conditioning specialists. Products
largely fail or have to be redesigned due to an engineer designing the wrong thing
because of misunderstood requirements, as opposed to designing the thing wrong
because of a design error.
We have seen these issues before in other engineering and business disciplines,
where they are addressed by specialized representation languages and analysis
tools precisely the motivation for Rosetta. We need a language that supports
computer and human interpretation, unambiguous definition, and predictive
analysis similar to those available in other disciplines. Furthermore, we need that
language to address the specific needs of systems engineering. For this reason,
Rosetta was developed.
How do we define a language that supports systems engineering decision mak-
ing? What basic features must this language have? In answer to these questions, we

Get System Level Design with Rosetta now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.