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
proﬁle, 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
deﬁned manner is central to all engineering disciplines and should be central to
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 deﬁnition, and predictive
analysis similar to those available in other disciplines. Furthermore, we need that
language to address the speciﬁc needs of systems engineering. For this reason,
Rosetta was developed.
How do we deﬁne a language that supports systems engineering decision mak-
ing? What basic features must this language have? In answer to these questions, we