Regular Paper

Application of Axiomatic
Design and Design
Structure Matrix to the
Decomposition of
Engineering Systems
M. D. Guenov* and S. G. Barker
Department of Power, Propulsion and Aerospace Engineering, School of Engineering, Cranfield University, Wharley End,
Bedfordshire, MK43 0AL, United Kingdom
DECOMPOSITION OF ENGINEERING SYSTEMS

Received 25 February 2004; Accepted 1 August 2004, after one or more revisions
Published online in Wiley InterScience (www.interscience.wiley.com).
DOI 10.1002/sys.20015

ABSTRACT
A design decomposition-integration model, named COPE, is proposed in which Axiomatic
Design Matrices (DM) map Functional Requirements to Design Parameters while Design
Structure Matrices (DSM) provide structured representation of the system development
context. In COPE, the DM and the DSM co-evolve. Traversing between the two types of
matrices allows for some control in the application of the system knowledge which surrounds
the decision making process and the definition of the system architecture. It is argued that
this approach describes better the design process of complex products which is constrained
by the need to utilise existing manufacturing processes, to apply discrete technological
innovations and to accommodate work-share and supply chain agreements. Presented is an
industrial case study which demonstrated the feasibility of the model. 2004 Wiley Periodicals, Inc. Syst Eng 8: 2940, 2005
Key words: axiomatic design, design structure matrix, systems decomposition, systems
integration

1. INTRODUCTION
*Author to whom all correspondence should be addressed (e-mail:
m.d.guenov@cranfield.ac.uk).

Standards for the engineering of systems such as EIA

632 and ISO/IEC 15288 support a seamless process of
converting customer needs into systems/technical requirements, which are subsequently transformed into
logical representations (architectural design) and fi-

Contract grant sponsor: UK EPSRC Research Grant GR/R37067

under the Systems Integration Initiative.
Systems Engineering, Vol. 8, No. 1, 2005
2004 Wiley Periodicals, Inc.

29

30

GUENOV AND BARKER

nally into physical solution representations. The process is iterative (see Fig. 1) due to the incomplete information available at the outset of the project and also the
large number of constraints involvedtechnical, economic and even political. The systems approach of
tackling the problem includes the deployment of Integrated Product Teams (IPT). These are composed of a
variety of specialists from different functional disciplines, ideally representing different phases of the product lifecycle to ensure that the design process will
consider, as early as possible, all relevant requirements
and constraints. IPTs are now a common practice in
industries such as the defense and aerospace. What
seems to be lacking, however, are high-level support
tools which could help the systems teams and architects
draw together consistently a vast amount of information
needed for the requirements and the design decomposition of the system. Currently there exist a number of
requirements management tools, which fulfill only partially this need. For instance, Acclaro [Suh, 2001;
Axiomatic Design Software Inc. website] is designed
to evolve the systems design in accordance with the
rules of Axiomatic Design Theory (ADT). The software
allows the systems designer to enter the top-level Functional Requirements (FRs) and Design Parameters
(DPs), and to decompose and map those in two tree
hierarchies and associated design matrices. However,
Acclaro is concerned primarily with functional decomposition, and not with explicit constraint mitigation and
control. SLATE, on the other hand [Talbott et al., 1994a,
1994b], now part of the EDS Team Center suite of
software, is a good example of a powerful requirements
management system. It provides constructs not only to
build requirements and product hierarchies, but also

allows the designer to attach constraints and text fragments to each item within each layer of the system
decomposition, and also provides a good level of traceability of nonfunctional requirements throughout the
design decomposition. SLATE, however, would only
produce results which reflect the experience of those
using it. Observations made during the industrial case
study suggest that, in practice, even experienced systems designers are too quick to follow a particular
solution path, relying heavily on existing knowledge
and past concepts.
There are also other methods of structuring the design process, such as the N2 chart [Lano, 1977, 1979],
and the Design Structure Matrix (DSM) approach
[Steward, 1967, 1981]. The latter approach provides the
ability to group related design elements. There are
software tools available which are based on the DSM.
These include DeMAID [Rogers, 1999], which was
developed by NASA to facilitate the decomposition and
sequencing of design activities, and more recently,
PlanWeaver (ADePT [Adept Management website])
which has been applied mainly in the construction
industry.
This paper presents work which has concentrated
particularly on the integration of ADT and DSM. The
conjecture is that ADT and DSM are complementary
parts of the decompositionintegration problem, where
the former is more concerned with mapping of functional requirements to design parameters, while the
latter is better suited to modeling the interactions and
the integration of the design parameters. The main
objective of the work is to investigate to what extent
those two methods can be integrated and to evaluate the
approach in a realistic industrial setting. The potential
value of this work is that it provides a means of relating
component integration to system functionality, which
otherwise is not available but is essential during the
early stages of the design process. The following two
sections present a brief summary of ADT and DSM,
respectively. Section 4 outlines the Methodology, while
Section 5 describes the industrial case study undertaken
to test and evaluate the approach. Finally conclusions
are drawn and future work outlined.

2. AXIOMATIC DESIGN THEORY (ADT)

Figure 1. High-level view of the systems engineering process

(adapted from ANSI/EIA-632-1998).

The underlying hypothesis of the Axiomatic Design

[Suh, 1990, 2001] is that there exist fundamental principles that govern good design practice. The main distinguishable components of the ADT are domains,
hierarchies, and design axioms. The foundation axioms
are:

DECOMPOSITION OF ENGINEERING SYSTEMS

31

Figure 2. Decomposition by zigzagging.

Axiom 1. Maintain the independence of the functional requirements.1

Axiom 2. Minimize the information content of the
design.
Axiom 1 requires that Functional Requirements
(FRs) be independent of one another, which enables
each FR to be satisfied without affecting any of the other
FRs. Thus there is no coupling of function where it can
be avoided, and the design remains as uncomplicated as
possible. Axiom 2 provides a quantitative measure of
the merits of a given design, and thus it is useful in
selecting the best among the designs which satisfy
axiom one [Suh, 2001]. Generally, the design that uses
the least information is superior. This is explained in
more detail later in this section. According to the ADT,
the design process takes place in four domains (Fig. 2,
adapted from Tate [1999] and Suh [2001]): Customer,
Functional, Physical and Process. Through a series of
iterations, the design process converts customers needs
(CNs) into Functional Requirements (FRs) and constraints (Cs), which in turn are embodied into Design
Parameters (DPs). Functional Requirements can be defined as a minimum set of independent requirements
that completely characterises the functional needs of the
product in the functional domain; Design Parameters
are the key physical variables in the physical domain
that characterise the design that specifies the FRs [Suh,
2001, p 14]. DPs determine (but also can be affected by)
the manufacturing or Process Variables (PVs). The decomposition process starts with the decomposition of
the overall functional requirementin practice this
should correspond to the top system requirement. Before decomposing a FR at a particular hierarchical level
in the functional domain, the corresponding DP must
1
It appears that software engineers realized this earlier, while
learning from some bad designs in the automotive industry [see
Stevens, Myers, and Constantine, 1974: 139].

be determined for the same hierarchical level in the

physical domain. This iterative process is called zigzagging (see also Tate [1999] for a more thorough treatment
of the decomposition problem).
Zigzagging also involves the other domains since
manufacturing considerations may constrain design decisions, while over-specified requirements could virtually prohibit the discovery of feasible design
solutions. At each level of the design hierarchy, the
relations (the dependencies) between the FRs and the
DPs can be represented in an equation of the form:
FR = [A]DP,

(1)

where each element of the design matrix [A] can be

expressed as Aij = FRi/DPj (i = 1,, m and j = 1,,
n). Equation (1) is called the design equation and can
be interpreted as choosing the right set of DPs to
satisfy given FRs. This is required by Axiom 1 (Independence). Each element Aij is represented as a partial
derivative to indicate dependency of a FRi on a DPj. For
simplicity the value of an element Aij can be expressed
as 0 (i.e., the functional requirement does not depend
on the particular design parameter), or otherwise X.
Depending on the type of resulting design matrix [A],
three types of designs exist: uncoupled, decoupled and
coupled (Fig. 3).
Uncoupled design occurs when each FR is satisfied
by exactly one DP. The resulting matrix is diagonal, and
the design equation has an exact solution; i.e., Axiom 1
is satisfied. When the design matrix is lower triangular,
the resulting design is decoupled, which means that a
sequence exists, where by adjusting DPs in a certain
order, the FRs can be satisfied. The design matrix of a
coupled design contains mostly nonzero elements, and
thus the FRs cannot be satisfied independently. A coupled design can be decoupled, for example, by adding
components to carry out specific functionshowever,
this comes at a price.

32

GUENOV AND BARKER

Figure 4. Probability distribution of a design parameter. The

solid line represents uniform distribution, the dotted line a
nonuniform distribution (adapted from Suh [1990]).
Figure 3. Examples of design types. From top to bottom:
Uncoupled, Decoupled, and Coupled Design.

One additional factor that affects coupling is the

number of FRs, m, relative to the number of DPs, n. If
m > n, then the design is either coupled or the FRs
cannot be satisfied. If m < n, then the design is redundant. (Note that in both cases the design matrix [A] is
not square.)
In addition to the design axioms, ADT is governed
by a set of rules, which are formalized into theorems
and corollaries. Of particularly relevance to this research are Corollary 3 and Theorem 5 which originate
from the first axiom (Independence):
Corollary 3 states: Integrate design features in a
single physical part if the functional requirements
(FRs) can be independently satisfied in the proposed solution.
Theorem 5 states: When a given set of FRs is
changed by the addition of a new FR, by substituting one of the FRs with a new one, or by
selection of a completely different set of FRs, the
design solution given by the original DPs cannot
satisfy the new set of FRs. Consequently, a new
design solution must be sought.
The Second Design Axiom states that minimizing the
information content of a DP increases the probability
of success of satisfying a function. The information
content is defined by the equation
system range
I = log
.
(2)
common
range

In Figure 4 design range is the tolerance within which

the DP can vary; system range is the capability of the

(manufacturing) system; common range is the overlap

between design and system ranges, and specifies the
range within which the FR(s) can be met [Suh, 2001].
The information content of a system can be computed
by summation of the individual information contents of
all DPs only if the latter are probabilistically independent. Frey, Jahangir, and Engelhard [2000] proved
that simple summation cannot be performed for decoupled designs and offered a method for computing information content. There is no exact method for computing
the information content of coupled designs.

3. DESIGN STRUCTURE MATRIX (DSM)

The DSM can be seen as a successor to the N2 chart
[Lano, 1977, 1979, Becker, Ben-Asher, and Ackerman,
2000], which was used for some years by the Systems
Engineering community, before the introduction of the
DSM. The DSM has become increasingly popular as a
means of planning product development, project planning and management, systems engineering, and organizational development [Browning, 2001, 2002]. The
concept dates back to the 1960s and was not actually
published until 1981 [Steward, 1981]. The Design
Structure Matrix (DSM) is a compact, matrix representation of a system/project. The matrix contains a list
of all constituent subsystems/activities and the corresponding information exchange and dependency patterns. That is, what information pieces (parameters) are
required to start a certain activity and where does the
information generated by the activity feed intoi.e.,
which other tasks within the matrix utilize the output
information [Design Structure Matrix website]. There
are three different configurations of the matrix (Fig. 5).
The simple, parallel configuration, in which the design

DECOMPOSITION OF ENGINEERING SYSTEMS

33

Figure 5. DSM configurations.

elements (e.g., design parameters or activities) are fully

independent of each other, the sequential, decoupled
configuration, in which the second parameter is dependent upon the output of the first, and the fully
coupled configuration, in which parameters are interdependent upon each other. Figure 6 shows how a DSM
may be used. The crosses below the diagonal in figure
6a represent a forward flow of information, while those
above the diagonal depict a feedback loop. The DSM
can be used to reorder, or partition design elements,
to minimize feedback loops (Fig. 6b). This is achieved
by a process of triangularization [Browning, 2002],
to render the matrix as lower-triangular as possible.
Sets of feedback loops can also be removed, by tearing them from the matrixin practice this means
producing a set of assumptions for the (as yet) unknown
information. The DSM must then be repartitioned.
DSMs can also be used to create and sequence modules
or clusters [Sharman and Yassine, 2004], which are
either mutually exclusive, or minimally interacting.
This absorbs any (remaining) iteration within the system. This is shown in Figure 6c.
There are two types of DSM in terms of application:
The static DSM, essentially a square matrix, used
for the representation of systems design architecture interface, design decomposition and modu-

larization, and planning of organizational topologies

The temporal DSM, which is primarily used for
mapping of design processes and for scheduling
and management of activities, over time
This research is concerned with the use of DSM to
model the integration and connectivity (logical and
physical) between design embodiments of system architectures, and to trace the effects of this integration
on the functionality of the system.
While DSM provides a powerful technique for the
analysis of design interactions within a complex development program, it appears to be less effective in innovative design. As Dong and Whitney [2001, p 11] point
out, it is not possible to obtain a DSM for a new
product that has never been designed before. Additionally, Dong and Whitney maintain that, although the
DSM captures the interactions between elements within
a system, it fails to record explicitly the reasons for
these interactions.

4. DECOMPOSITION-INTEGRATION
PROCESS USING ADT AND DSM
ADT postulates that a zigzagging process for FR-DP
mapping that takes place in a solution neutral envi-

Figure 6. Examples of DSM forms: (a) Basic, (b) Partitioned, (c) Clustered.

34

GUENOV AND BARKER

ronment ensures better design. This, however, can

rarely happen in practice, particularly in complex product environments, where economic considerations dictate maximum possible utilization of mature designs
and existing manufacturing processes [Guenov, 2002].
In addition, the design process must capture the interactions among the design parameters, including geometry, spatial layout, interfaces (e.g., logical and physical
connectivity), and so forth. As discussed in the previous
section, DSM is a mature method capable of capturing
the interaction between design parameters, but by definition, it is fully known only for products that have
already been designed.
These considerations led us to the idea that the
decomposition integration problem would be better
modeled as a co-evolution of ADT matrices and DSMs.
The generic representation of the process which we
named COPE (decomposition-integration of COmplex
Product Environments) is depicted in Figure 7. In
COPE, ADT is used to map the decomposition of
functional requirements to design parameters (FR-DP).
At each decomposition level various knowledge
sources are consulted in order to take into consideration
constraints originating from all stakeholders. The
knowledge sources include unstructured ones (e.g., employees tacit knowledge and various unpublished
documents) as well as structured/coded sources. Examples of the latter include government regulations, DSMs
of past designs (also processes), companys own design
standards, synthetic and analytical models, knowledge
bases, and so forth. Technology bricks is a generic

term which encompasses chunks of new technology

which is mature enough to be applied in the new product
with potential competitive advantage.
As the decomposition progresses, essential design
studies must be performed, including spatial layout,
performance and capacity constraints checks, and/or
more detailed design of particular, riskier aspects of the
product, resulting in more interactions between the
design parameters. As a consequence, Corollary 3 of
ADT may be violated or requirements may need to be
added or changed at a higher level, which would require
a repetition of the decomposition phase (see Theorem
5 of ADT).
The first step to linking ADT and DSM was made
by Dong and Whitney [2001], who showed that if the
Axiomatic design matrix (DM) can be expressed analytically and one design parameter (DP) is dominant in
satisfying a particular functional requirement (FR),
then the triangulated design matrix is equivalent to the
DSM of the design parameters. The algorithm consists
of three major steps:
1. Construct the Design Matrix (DM).
2. In each row of the DM choose the dominant (the
largest) entry.
3. Permute the matrix by exchanging rows and columns so that all dominant entries appear on the
main diagonal.
The authors show that choosing the dominant entries is
important as it ensures the convergence of the design
process.

Figure 7. Schematic representation of the COPE Decomposition-Integration process.

DECOMPOSITION OF ENGINEERING SYSTEMS

Unfortunately, when designing complex (physical

or software) systems the FRs are satisfied by modules
or other (sub)systems or components and therefore the
design matrix cannot be represented analytically; and it
may not necessarily be square either. In order to overcome this restriction, we have devised a decomposition
procedure (Fig. 8) in which the design and structure
matrices co-evolve.
The procedure starts with the construction of the DM
of the FR-DP hierarchy. At this level the dominant DPs
are identified. The DM is manipulated [see Dong and
Whitney, 2001] so that it becomes lower triangular with
dominant entries, X, on the main diagonal. The result

35

is the Architectural DSM, that is, a DSM derived only

from the functional view of the product. At this stage a
certain amount of layout/spatial design may need to be
done, including possible integration of components.
This will be subjected to considerations regarding innovation, cost, weight, capacity and other constraints,
which are taken into account by applying the knowledge sources, as discussed above (see also Fig. 4). The
resulting design may affect the functionality of the
systems, for example, grouping components together
may couple functions. If that is the case, requirements
may need to change or more design parameters may
need to be added. This means that the design decompo-

Figure 8. COPE decompositionintegration procedure.

36

GUENOV AND BARKER

sition has to be reconsidered from the highest level (see

Theorem 5). The decomposition ends when a leaf node
is encountered, that is, further decomposition will
change the subject of the requirement. In terms of
systems engineering standards (see, e.g., ANSI/EIA632), a leaf node can be approximately described as a
specified/assigned requirement.
Perhaps it is worth emphasising that the COPE procedure aims to retrace the AD-DSM connection at each
level of the decomposition rather than at reaching a leaf
node of the DP hierarchy. This is justified by the fact
that in practice one can be very restricted in performing
the entire decomposition in a solution neutral environment (as advocated by ADT)there are, for example, cost considerations at the outset of the project
which result in targets on reusability of components and
manufacturing processes from previous products and
/or targets on commonality of components with other
existing product lines. Furthermore, one sometimes
needs to decompose much deeper one branch of the
FR-DP hierarchy relative to other branches in order to
de-risk the solution. For example, one may need to
know if a particular material can be used before continuing further with the decomposition since this particular material may affect performance constraints or
interfaces with other components. Thus we see our
approach as compliant with the deeper localized studies
that need to be preformed in practice at the conceptual
and preliminary design stages before proceeding further with the development process.

5. CASE STUDY
In order to test our approach regarding ADT (and,
subsequently, DSM), a case study was undertaken in
conjunction with COPE Project sponsor BAE SYSTEMS. The chosen study concerns the upgrading of an
air defense system. The primary form taken by our
research was a series of interviews with key members
of the project. These ascertained the nature of the requirements, and the structure of the design. This information was then decomposed using axiomatic design
techniques to identify connectivity between requirements and design, and how each impacted the other.
This was known as the As Is solution. Impacting
factors, or constraints, both within the system of design,
and of an organizational nature, were studied to model
their effect on the process of system design. This was
validated with the BAE SYSTEMS Project. A parallel
analysis was conducted to determine how the system
could have been designed, had ADT [Suh, 1990, 2001]
and engineering design standards been applied. This
became the As Could Be solution. It was intended that

the comparison between As Is and As Could Be

would indicate any areas where the existing design
could have been improved, thus confirming (or not) our
initial hypothesis. Additionally, we expected that the
comparison would identify a set of potentially useful
features that have not yet been addressed by the existing
systems engineering tools.
The findings of the study noted that possibly the key
constraint was that this was an update rather than a new
system, and that any design was therefore constrained
by what already existed. However, the analysis of requirements by the BAE SYSTEMS Project appears to
have been relatively unstructuredand, indeed, an ongoing process. This, when coupled to a predominantly
bottom-up rather than top-down analysis technique, meant that the requirements were not decomposed fully, and therefore the relation of requirements
to design was not fully analyzed. This has the potential
for delay in the form of extended or unnecessary rework
or iterationthe need for which the Project admitted
was not accounted for. The work breakdown was described as being intuitive, and based largely on previous
experience. Thus work appeared to be assigned to teams
without consideration of how all of the modules could
be integrated together successfully.
The design of the system was forced down specific
avenues. This was mainly because it was time constrained and there was a history of rival bids, which,
through the prime contractor, led to decisions regarding
the design being taken that were beyond the control of
the BAE SYSTEMS team. Furthermore, the fact that
certain data was provided much later than scheduled,
has also placed certain restraints upon the system design
process. The organizational need requiring the design,
initially at least, to be planned in conjunction with two
specific suppliers, also applied certain constraints.
The need to trace and analyze design decisions and
changes has been a central requirement in the design of
complex products for quite some time [Guenov, 1996].
In the context of this case study, the DSM offered a
potential solution to the problem of tracing the effect of
contextual issues such as project scheduling, and event
sequencing, upon the system design (Pimmler and Eppinger, 1994; Ulrich and Eppinger, 1999). Through the
application of ADT and DSM, our case study research
discovered elements of the system design and its context which required integration to provide a successful
design solution. For example, given that the chosen
design utilized two sensors, one to track the position of
incoming targets, the other to track an outgoing missile,
with the outgoing missile potentially being able to be
seen by both sensors simultaneously, could be seen as
an integration issue which requires the application of

DECOMPOSITION OF ENGINEERING SYSTEMS

37

Figure 9. 2nd-level Design Matrix (DM).

Figure 10. 2nd-level Architectural DSM.

both ADT and DSM. An example of such an application

is described below.
The approach for deriving the DSM from the DM is
leveled so that each hierarchical level of the FR-DP
decomposition hierarchy is evaluated in turn. The first
step is to construct the Design Matrix (DM). For the
purposes of demonstrating the approach, a 2nd-level
abstraction of the ADT decomposition hierarchy will be
concentrated upon. A sample of the 2nd-level BAE
SYSTEMS DM is shown in Figure 9.
The design appears to be a redundant one as the
number of design parameters is greater than the number
of functional requirements. At this stage it is important
to identify the primary relationships between requirements and designi.e., if more than one design parameter is used to satisfy a requirement, identify the
dominant one, and where appropriate, secondary relationships if they exist (they do not in this example). This
is step two of the approach. The primary relationships
are marked with large Xs, while secondary relationships could be depicted with small xs. The DM now
describes the functional linkages between the Functional Requirements (FRs) and the Design Parameters
(DPs). This serves to define the manner in which the
DPs will satisfy the FRs. However, the effects of decisions relating to the system such as cost, capacity, and
physical integration are not dealt with particularly well.
As a result, a DSM structure can be generated to accommodate these issues. The next step of the approach
concerns the derivation of an Architectural DSM.
This is illustrated in Figure 10. A dummy FR, denoted
by ?, is added to make the matrix square. Asterisks
are used to denote blank cells on the diagonal.
The Architectural DSM is created through a combination of a method proposed by Dong and Whitney
[2001], and triangulation. Thus the rows and columns
are permuted to produce a (predominantly) lower triangular matrix. The vertical axis is renumbered according
to the DP order, and the Architectural DSM is the
result. This is the equivalent of the DM, in DSM form,
and provides the interface between the DM and DSM.
This stage of the case study analysis revealed a
problem with the design solution. Figure 10 shows a
feedback loop between DPs 2.2.3 and 2.2.2, and a

second between 2.2.4 and 2.2.3. However, these feedback loops had not been anticipated in the design.
Analysis of the model revealed that the likely reason for
their appearance in the structural DSM was a leveling
issue: DP 2.2.4 verifies that the output of previous DPs
is correct. But the corresponding FR for this DP occurs
at a lower level of decomposition in the DM. This raised
an issue with the As Is model (this being the existing
solution, modeled in Figs. 9 and 10). A review of the
requirements then led to the creation of an As Could
Be solution, which is shown in Figure 11a. This attempted to use axiomatic design method [Suh, 1990,
2001] to create a design independently of the existing
As Is model, to see if improvements were theoretically possible to the design. The main changes (the
original FR/DP nomenclature has been retained for ease
of comparison) are an additional FR, stating the need to
verify the output of processing tasks, and an additional
DP which enables a further verification task, that of
comparing successive outputs to enhance reliability of

Figure 11. (a) 2nd-level As Could Be Design Matrix; (b)

2nd-level As Could Be Architectural DSM.

38

GUENOV AND BARKER

missile/target detection, up from a lower level of the

decomposition.
This simplifies the FR-DP relationshipwhereas,
previously, FR 2.2.2 had been satisfied by three DPs
which embodied the verification algorithms at a lower
level of decomposition, the requirement can now be met
independently of processing operations. This may incur
a cost overhead, depending on the technology used to
implement it, but is representative of the ADT design
philosophy, being in accordance with corollary three of
axiomatic design [Suh, 1990, 2001]. Finally, FRs 2.2.1
and 2.3.1 of the As Is solution (Fig. 9) perform the
same operation. These have therefore been combined
into one. The design solution remains uncompromised
as the DPs can be scheduled to cater for the newly
compressed FR. It can be seen in Figure 11b that this
has resolved the feedback issue.
The effects of decision-making on the matrices now
need to be modeled. The decisions can regard a range
of criteria, such as constraints, physical and logical
connectivity, and software or hardware integration. In
the BAE SYSTEMS case, the need exists to combine
software functionality onto processor cards. The physical connectivity of the design and the interaction of the
functions across the processors are therefore relevant.
Using the As Is solution as a basis, the creation of
these DSM can be demonstrated by Figures 12 and 13.
For the physical connectivity (denoted by 0s), it can
be seen that of the processing DPs (2.2.1, 2.2.2, and
2.2.3), 2.2.3 operates independently, while 2.2.2 provides data to 2.2.1. DPs 2.2.1 and 2.2.3 then feed 2.2.5.
The verification DPs (2.2.4 and 2.2.5) also operate
independently, with both passing information to the
output channel (DP 2.2.6) on completion of the verification task. This completes an operational cycle.
The integration between software cards, shown in
Figure 13, is described by numbers. The numbers on the
diagonal indicate which of three processors the DP is
assigned to. Thereafter, numbers separated by a comma
indicates that two DPs communicate over separate

Figure 12. 2nd-level physical connectivity between design

parameters.

Figure 13. 2nd-level interaction between processor cards.

processors. The first number denotes the card from

which the communication is initiated, and the second
number indicates which card receives the communication.
An example is that DP 2.2.1, stationed on card 3,
communicates with DP 2.2.5, which appears on card 2.
The DSM can be separated out into layers (shown by
Figs. 12 and 13), to give the system engineer a filtered
view of how each of the design elements interacts with
each other in regard to a different design perspective.
This is illustrated in Figure 14.
So far, we have shown that the model can highlight
the effect of integration issues of a system design. This
is shown by the unbroken arrow in Figure 14. However,
it is also necessary to be able to understand how the
nature of the design is affected by these issues. This
necessitates backtracking from the layered DSM to the
DM, to understand changes which may have been
caused to the original FR-DP relationship. This is indicated by the dotted arrow to the right hand side of Figure
14, illustrating how the effect of a constraint or decision
regarding integration may alter the balance between
FRs and DPs on the original DM.
To provide an example, currently, the processing is
verified prior to output. This involves two DPs (2.2.5
and 2.2.4), which currently appear on processor cards
two and three, as shown in Figure 13. If, however, the
capacity and speed constraints of the processor cards
dictated that they be positioned on the same card, then
new physical connectivity would appear on the appropriate DSM, as both DPs would now be linked via the
same processor card. This is denoted by the shaded area
upon the layered DSM in Figure 14. This in turn would
dictate a new sequence in which the two DPs could be
executed, bringing about a coupling, and altering the
structural DSM/DM, as indicated by the dashed arrow
and letter A.
A further example of this is that an FR specified the
need to detect objects a, b, and c at range x in climate
condition y. To meet this requirement, a DP provides
the required capability. However, cost and capability
constraints applied to the DSM mean that it is not
possible to use the DP. The alternative is a DP which,

DECOMPOSITION OF ENGINEERING SYSTEMS

39

Figure 14. Layered DSM and its effect upon the DM.

unfortunately, can only detect objects a and c at range

x, and not in condition y. It can be seen that the process
of deriving the DSM to study constraints etc. and their
effects has now revealed that the FR on the original DM
cannot be met. Thus the FR must be changed to accommodate the DSM constraints, and this changes the design, as dictated by theorem five of ADT [Suh, 1990,
2001]. Consequently, a new design solution must be
sought.

6. CONCLUSIONS
A novel design decomposition model for complex
product environments (COPE) is presented. It combines Axiomatic Design with Design Structure Matrix
to accommodate the iterative nature of the decomposition-integration process. The research to date has demonstrated that this approach can bring significant
benefits. An industrial Case Study, conducted as part of
the research and reported here, has shown that the
DM-DSM arrangement can be used to identify the
existence of potential conflicts in the design solution,
and allows groups of design parameters to be explored
in greater detail. This approach also appears to provide
a level of control and transparency to the systems design
process, and gives the systems architect the opportunity
to study proposed changes before they are made, and to
understand how any such change(s) may produce a
knock-on effect throughout the design solution.
Despite the potential which COPE has demonstrated
so far, we have not yet solved completely the problem
of mixing various levels of details during the decomposition process. This is important since deeper localized
design studies cannot be avoided in practical situations,
it is a part of the de-risking process. Secondly, the
decomposition process forms only a subset of the engi-

neering life cycle and therefore COPE must be evaluated in a wider context. So far we have consulted and
tried to take into account the established standards for
engineering of systems, however, standards implementation is company dependent. In this view, further development, evaluation and validation of the method, as
well as a specification of the requirements for a decomposition tool form the scope of our future work. Currently we are experimenting with the integration of
ADT, DSM, and Requirements Management tools
[Guenov and Barker, 2004].

ACKNOWLEDGMENTS
This work is funded by UK EPSRC Research Grant
GR/R37067 under the Systems Integration Initiative.
We are indebted to BAE SYSTEMS for their help with
the Case Study. We thank the anonymous referees for
their helpful comments.

REFERENCES
Adept Management website: http://www.adeptmanagement.
com/
ANSI/EIA-632-1998, Processes for engineering a system,
Electronic Industries Alliance, Government Electronics
and Information Technology Association, Engineering
Department, Arlington, VA (approved January 7, 1999).
Axiomatic Design Software Incorporated website:
http://www.axiomaticdesign.com/index.cfm
O. Becker, J. Ben-Asher, and I. Ackerman, A method for
system interface reduction using N2 charts, Syst Eng 3(1)
(2000), 2737.
T.R. Browning, Applying the design structure matrix to system decomposition and integration problems: A review
and new directions, IEEE Trans Eng Management 48
(2001), 3, 292306.

40

GUENOV AND BARKER

T.R. Browning, Process integration using the design structure

matrix, Syst Eng 5(3) (2002), 180193.
Qi Dong and D. Whitney, Designing a requirement driven
product development process, Proc 13th Int Conf Des
Theory Methodol (DTM 2001), September 912, 2001,
1120, Pittsburgh, PA.
Design Structure Matrix website: http://www.dsmweb.org/
D.D. Frey, E. Jahangir, and F. Engelhard, Computing the
information content of decoupled designs, Res Eng Des
12 (2000), 90102.
M.D. Guenov and S. Barker, Requirements-driven design
decomposition: A method for exploring complex system
architecture, Proc ASME 2004 Int Des Eng Tech Conf
Comput Inform Eng Conf (DETC04), Salt Lake City, UT,
September 28October 2, 2004, to appear.
M.D. Guenov, Complexity and cost effectiveness measures
for systems design, Manufacturing Complexity Network
Conf, Downing College, Cambridge, UK, April 910,
2002, 455466.
M.D. Guenov, Modelling design change propagation in an
integrated design environment, Computer Model Simulation Eng 1 (1996), 353367.
ISO/IEC 15288 (System Life Cycle Processes), DPC:
01/647707, Version 6.0, Bsi, London, 2001.
R.J. Lano, The N2 Chart, Informational Report, TRW, 1977,
California.
R.J. Lano, A technique for software and systems design,
North-Holland, Amsterdam, 1979.
K.R. McCord and S.D. Eppinger, Managing the integration
problem in concurrent engineering, Working Paper 359493-MSA, MIT Sloan School of Management, Cambridge,
MA, 1993.
T.U. Pimmler and S.D. Eppinger, Integration analysis of
product decompositions, ASME Des Theory Methodol
Conf, Minneapolis, MN, September 1994, 343351.

J.L. Rogers, Tools and techniques for decomposing and managing complex design projects, J Aircraft 36(1) (1999),
266274.
D.M. Sharman and A. Yassine, Characterizing complex product architectures, Syst Eng 7(1) (2004), 3560.
W.P. Stevens, G.J. Myers, and L.L. Constantine, Structured
design, IBM Syst J 13(2) (1974), 115139.
D.V. Steward, The design structure system, Document
67APE6, General Electric, Schenectady, NY, September
1967.
D.V. Steward, The design structure system: A method for
managing the design of complex systems, IEEE Trans Eng
Management EM-28, 3 (August 1981), 7174.
N.P. Suh, The principles of design, Oxford University Press,
New York, 1990.
N.P. Suh, Axiomatic design: Advances and applications, Oxford University Press, New York, 2001.
M.T. Talbott, H.L. Burks, R.W. Shaw, M. Amundsen, K.K.
Hutchison, and D.D. Strasburg, Method and Apparatus for
System Design, U.S. Pat. No. 5,355,317, October 11,
1994(a).
M.T. Talbott, H.L. Burks, R.W. Shaw, M. Amundsen, K.K.
Hutchison, and D.D. Strasburg, Method and Apparatus for
Aiding System Design, U.S. Pat. No. 5,357,440, October
18, 1994(b).
D. Tate, A roadmap for decomposition: Activities, theories,
and tools for system design, Ph.D. Thesis, Department of
Mechanical Engineering, Massachusetts Institute of Technology, Cambridge, MA, February 1999.
K.T. Ulrich and S.D. Eppinger, Product design and development, 2nd edition, McGraw-Hill Education (ISE Editions), New York, 1999.

Marin D. Guenov is a Senior Lecturer (Advanced Engineering Methods) in the School of Engineering,
Department of Power Propulsion and Aerospace Engineering at Cranfield University, UK. He holds an
MEng in Mechanical Engineering and a Ph.D. in Materials Handling Systems and Operational Research.
Currently Dr. Guenov leads national and international multidisciplinary research projects supported by
the European aerospace industry in the areas of design of complex systems, modeling and simulation for
synthetic environments, multidisciplinary design analysis and optimization, and infrastructures for
collaborative design. Dr. Guenov is a member of the Royal Aeronautical Society and The Association of
Cost Engineers and is a Charted Engineer.

Stephen G. Barker is a Research Officer in the School of Engineering, Department of Power Propulsion
and Aerospace Engineering at Cranfield University, UK. Dr. Barker holds a BSc. (Hons.) in Computer
Studies, and researched Applied Engineering Process Management for his Ph.D. Currently, Dr. Barker is
part of the COPE (COmplex Product Environment) research team, which investigates DecompositionIntegration issues within Complex Product Development programs. Dr. Barker has previously worked
as a lecturer and tutor in the fields of Network Communications and Operations Management.