Content uploaded by Mike Ryan
Author content
All content in this area was uploaded by Mike Ryan on Apr 08, 2015
Content may be subject to copyright.
On Sufficiency and Elegance in System
Design
Michael J. Ryan and Mahmoud Efatmaneshnik
UNSW Canberra, Northcott Drive, CANBERRA ACT 2600
Telephone: 02 62688200. E-mail: m.ryan@adfa.edu.au and m.efatmaneshnik@adfa.edu.au
Abstract. Despite elegance being universally recognized as a goal for system design, there is little
guidance in the related research and literature that is relevant to the development of elegant systems.
This paper begins by reviewing the rather loose usage of elegance as a property of a system and shows
that there are both abstract and practical views. Further, from analysis of the practical views of
elegance in systems, it is clear that most current definitions of elegance are focused on the sufficiency
of the system as a solution to the stated problem, rather than on elegance, per se. This paper
disambiguates the usage of sufficiency and elegance, offers a formal definition of the two terms, and
then provides two simple examples by way of illustration. Elegance and sufficiency must be
considered as separate properties of a system, if only because the essential act of validation is an
examination of the sufficiency of a solution, not its elegance. Sufficiency is shown to be binary—a
solution is either sufficient or it is not—and there may be more than one sufficient solution. Elegance
is then defined to be the simplest sufficient solution. Furthermore, an elegant solution must be
sufficient, but a sufficient system does not have to be elegant.
1. INTRODUCTION
Elegance in design has long been a significant goal for both engineering and system engineering
communities. Yet, despite acknowledging the desirability of elegance in design, the related research
and literature provides few clues to aid in the production of methodologies for the systemic
development of elegant solutions. Most commonly, researchers conclude that designing for elegance
requires creativity because it is an ill-structured process where solutions are not defined or definable in
advance, and the path to the solution is open (Madni, 2012). In order to provide a useful measure, this
paper does not attempt to address any creative process by which an elegant solution is produced, but
rather focuses on the criteria by which an elegant solution may be distinguished from other candidate
solutions. In particular, we are interested in disambiguating elegance from sufficiency because it is
common for the two system properties to be inappropriately combined into the one property of
elegance.
Prior to defining elegance in a formal fashion, this paper identifies that the term has been used rather
loosely in the relevant literature. First, it is shown that the dictionary definitions have both abstract and
practical meanings. It is then shown that most practical uses in the literature of the term ‘elegance’ in
conjunction with systems design include the notion of sufficiency as part of the definition—in fact,
most definitions of elegance are simply definitions of sufficiency. Here we disambiguate the terms,
note that sufficiency is binary and is a prerequisite of elegance, offer a formal definition of the two
terms, and then illustrate the definitions with two simple examples.
2. ELEGANCE IN REVIEW
The word ‘elegance’ has a very broad usage. As noted earlier, it is often identified as a design goal or
at least a desirable system attribute, but it does not have any precise, universally agreed definition in
the context of design and there is little relevant literature (and only a couple of papers from recent
times). This section provides a brief review of that published work that is relevant but, since there are
so few, a summary is provided by way of a table.
Dictionary definitions of the word ‘elegance’ have both abstract and practical connotations. The
abstract view is perhaps best summed up by Griffin (2010) as “…an ineluctable concept in that it is
immediately apparent when it exists, and yet it is difficult to define, impossible to quantify, and so far,
incapable of being taught.”. This notion is therefore not useful in determining rigorous ways of
developing and assessing elegant systems—a system property does not have much value if it is
impossible to quantify. Fortunately, most of the sources also offer practical definitions of elegance that
are of more use as guides to system design.
Table 1 illustrates the two principal usages (abstract and practical) of the word ‘elegance’ based on a
review of extant literature in a range of contexts, including systems design.
Table 1: Definitions of elegance from the literature, identified by context and separated into
abstract and practical definitions.
SourceContextAbstractDefinitionsPracticalDefinitions
Oxford
Dictionary
Vocabulary“1:thequalityofbeing
gracefulandstylishin
appearanceormanner:a
slenderwomanwithgrace
andelegance”
“2.thequalityofbeing
pleasinglyingeniousand
simple;neatness:the
simplicityandeleganceof
thesolution”
Merriam‐
Webster
Dictionary
Vocabulary“1.refinedgraceor
dignifiedpropriety:
urbanity
2.tastefulrichnessof
designorornamentation
<thesumptuouselegance
ofthefurnishings>
3.dignifiedgracefulnessor
restrainedbeautyofstyle:
polish<theessayismarked
bylucidity,wit,and
elegance>”
“4.scientificprecision,
neatness,andsimplicity
<theeleganceofa
mathematicalproof>”
Kellow(1988) Theorybuilding,
philosophyof
science,policy
making
“Ofaccuratepredictions,
buttheyshouldalsobe
important,parsimonious,
andcomprehensive”
O’Connor
(1990)
Design,consumer
products
“pleasingtocontemplate” “correct,efficient”
Rubinsteinand
Firstenberg
(1994)
Problemsolving,
modeling,design
Anelegantdesignisone
thattakesacreative
approachtocopingwith
complexity.
Meyerand
Lehnerd(1997)
Productdesign,
productplatform
design,process
design
“Lowlevelsofcomplexityin
productandprocessdesign
aretangiblemeasuresof
elegance.”
“…oneinwhichall
subsystems,takenasa
whole,createthegreatest
outputperformanceforthe
leastinputs.”
Gelernter
(1998)
Hardwareand
softwaredesign
“…aneffectivemarriageof
simplicityandpower”.
Billows(1999)Productdesign “Tobeconsideredelegant,a
systemmustmeettwo
criteria:1.thesystemmust
functionaccordingtoits
statedpurpose,and2.the
designpressures
constrainingthesystem
designmustbe
simultaneouslyrelieved.”
May(2007)Designmanagement,
innovation
management
“Eleganceisaboutfinding
theahasolutiontoa
problemwiththegreatest
parsimonyofeffortand
expense.”
Griffin(2010) Systemsengineering,
projectmanagement
“Eleganceisanineluctable
conceptinthatitis
immediatelyapparent
whenitexists,andyetitis
difficulttodefine,
impossibletoquantify,and
sofar,incapableofbeing
taught.”
“…anelegantsolutionisone
whichproducestheend
result,isbothrobustand
efficient,andgeneratesa
minimumofunintended
consequences.”
Lewis(2012) Problemsolving,
mechanicaldesign
“However,inengineering
design,thepreferredroute,
Ipostulatemustbeoneof
elegantcomplexitywhere
simpleanswersprovide
elegantinsightstocomplex
problems.”
Madni(2012) Systemdesign,
problemsolving
“…invariablyanewwayof
lookingataknown
problem.”
“…acreativesolutionin
responsetoahitherto
unrecognizedneed.”
“Amarriageofbeautyand
“Atrulyelegantdesignis
onethatdoesawaywith
havingtomakeperformance
andcapabilitylimiting
tradeoffsamongdesirable
systemcharacteristics.”
Madniprovidesanelegance
metricthathas12elements:
technology,anelegant
designbuildsanemotional
connectionwiththeuser
…”
“Itoftenembodiesa
capabilitythathumans
wereunawarethey
needed,andnowcannot
dowithout.”
“Elegantdesigncanshape
ourfuturebycreating
culturalvalueswhich,in
turn,influenceourfuture.”
purpositivity,parsimony,
transparency,scalability,
sustainability,bonding,
efficiency,evolvability,
affordability,usability,
utility,andpredictability.
Simonsand
Parmee(2012)
Objectoriented
softwaredesign
“Symmetricaleleganceis
sexy”,“whatisbeautifulis
useable”.
Symmetryofoverall
softwarestructure,“three
elegancemeasuresassess
theevennessofdistribution
of(a)attributesand
methodsamongclasses,(b)
externalcouplesbetween
classes,and(c)theratioof
attributestomethods.”
The definitions identified in Table 1 show two distinct views of elegance. The abstract definitions of
elegance use qualitative terms such as “grace”, “style”, “pleasing” and “creative” and tend to be
romantic perceptions of the qualities that either are related to elegance (such as beauty, gracefulness,
and usability) or result from elegance (such as creativity). Practical definitions include more
quantifiable terms such as “simple”, “neat”, “parsimonious”, “correct”, and “efficient”.
We are interested here in practical steps to guide systems design, so we focus on the practical
definitions since the other descriptions, like beauty, tend to be in the eye of the beholder. The practical
definitions of Table 1 are much more useful to a designer and can readily be synthesized into a
common view in which an elegant system is one that provides the simplest sufficient solution to a
defined problem.
It should also be noted before leaving this introductory section, that the literature is limited to
definitions of the terms sufficiency and elegance—none of the works propose how such attributes
should be measured, nor do they provide any guidance that might be used in any form of design
methodology.
3. A SIMPLE MODEL OF SYSTEM DESIGN
As illustrated in Figure 1, a simple model of system design can be considered to involve the
development, in the solution domain, of a solution space that contains a range of candidate solutions to
a problem that has been defined in the problem domain by the deliberate articulation, within a broad
problem space, of selected problem elements (which for convenience we call here requirements)
through the definition of a problem boundary to define a problem of interest.
Figure 1. An illustration of design as the development of a set of candidate solutions in the
solution domain, to the set of requirements in the problem domain.
Since a system comprises a set of elements interconnected to achieve a common purpose (ISO/IEC
15288, 2008) (which invariably is to provide a solution to a stated problem), the set of solutions in
Figure 1 can be considered to be a set of systems, each of which provides a solution to the problem of
interest. It does not follow that there is only one solution sufficient to solve any given problem, so
there may be a number of candidate systems that provide (noticeably different) solutions that are
sufficient to solve the problem. The means by which a system is deemed to provide a sufficient
solution is called validation.
It should be noted, of course, that design is iterative so that the definition of the boundary may be as
the result of iteration between the problem space and the solution space—Figure 1 illustrates a single
iteration. When the problem space is poorly defined initially, it is common for the problem boundary
to be defined through an iterative development approach such as incremental (Davis, Bersoff, &
Comer, 1988), evolutionary (Dorfman & Thayer, 2000), or spiral (Boehm, 1988) development.
Further, as a consequence of design iteration, the selected set of problem elements may have to be
adjusted in some manner if there is initially no sufficient solution or the sufficient solutions are
undesirable for some reason (excessive cost, perhaps).
2.2 Sufficient Solutions
If a system is to be a solution to a problem, it is a necessary (but not sufficient) condition that a
solution satisfies each of the individual problem elements; the sufficient condition is met when the
solution satisfies the complete set of problem elements (requirements).
As illustrated in Figure 1, assume that the problem domain contains a problem space, within which a
particular problem of interest is defined by a set of requirements and a solution space containing a
number of viable solutions, each containing a number of solution elements.
Ensuring that a solution satisfies the set of requirements is called validation. It is a necessary, but not
sufficient, condition that a solution satisfies each of the problem elements. Further, the complete set of
necessary conditions (that is, the conjunction of individually necessary conditions) comprises a
condition for a solution to be a sufficient solution to the requirements.
Note that, in the above analysis, there is no necessary direct relationship between any single problem
element and any single solution element. That is, a single solution element may satisfy a single
problem element, or it may satisfy a number of problem elements, or it may even satisfy all problem
elements. Conversely, a single problem element may be satisfied by a single solution element, by a
number of solution elements, or perhaps by all solution elements.
Sufficiency and validation are axiomatic in system design and highlight the importance of the
appropriate selection of problem elements and the definition of the associated problem boundary. It is
clear from Figure 1 that the nomination of the problem elements (that is, the definition of requirements
within the problem boundary) is an essential precursor to the identification of sufficient solutions.
Perhaps the most significant difficulty in system design is that the sufficiency of solutions in the
solution space can be very sensitive to changes in the problem boundary—the inclusion or exclusion
of a single element within the problem boundary can change a solution from being sufficient to being
insufficient, or vice versa. For example, if the problem is defined to include the need to operate in
space (in a vacuum), all sufficient solutions must be able to survive in space. If the need to operate in
space is removed, previous solutions may well become insufficient (poor designs) because they are
most likely to be over-engineered, too complex, and therefore too expensive. On the other hand, a
sufficient solution to a problem boundary that includes the need to operate only within a particular
country (which can be satisfied by the ability to operate on the designated domestic power supply) will
not be sufficient if the problem boundary is extended to include the need to operate in all countries
(and therefore to operate on all international power supplies).
2.3 Minimum Sufficient Solution
The obligation of a system designer is to satisfy all requirements within the defined problem boundary
but not address any of the elements in the problem space that are outside the boundary, unless such
elements can be accommodated with the customer’s permission (which presumably would be granted
when such additional elements are able to be included at negligible cost/time to the project, or the
customer is prepared to pay for the additional inclusions). This is in keeping with the Project
Management Institute’s definition of project management in the Project Management Body of
Knowledge (PMBOK®) (Project-Management-Institute, 2013), which is focused on ‘meeting’ project
requirements, not ‘meeting and exceeding’ as originally defined in the 1987 and 1996 versions of the
PMBOK®—an increased emphasis on project scope management as one of the ten knowledge areas
of the project management body of knowledge meant that “exceeding requirements” became
oxymoronic in a project setting. Consequently, the system designer is obliged to ensure that the system
does not contain any more solution elements than are necessary to satisfy the problem. In other words,
it is of considerable interest to the designer to reduce the number of elements in the solution to the
minimum required for the solution to remain a sufficient solution.
The minimum sufficient solution is defined such that it is the solution with the minimum solution
elements that still satisfy the requirements. It follows that, if any of the solution elements are removed
from the minimum sufficient solution then the solution is no longer sufficient.
4. DISAMBIGUATING ELEGANCE AND SUFFICIENCY
We noted in Section 2 that the term elegance has abstract and practical definitions. It is also evident in
Table 1 that even the practical definitions tend to confuse the level of simplicity of a solution (that is,
its elegance) and the degree to which it meets the problem elements (that is, its sufficiency). For a
system to offer an ideal solution that satisfies the defined problem, it must:
provide a solution that satisfies all problem elements—we call this property sufficiency; and
be the least-complex, sufficient solution available—we call this property elegance.
In the following section we use these two definitions of sufficiency and elegance to re-examine the
definitions in Table 1. Before doing so, however, some additional observations can be offered on these
working definitions:
In logic terms, sufficiency is binary—a solution is either sufficient or it is not.
A solution is sufficient if it can meet the problem elements (and no more) within the problem
boundary (in which case it is a minimum sufficient solution)—or it may be sufficient if can
satisfy more problem elements than those within the problem boundary. Either way, a
sufficient solution satisfies at least the problem elements within the problem boundary.
As observed earlier, a solution must be sufficient before it can be elegant. Elegance is not a
matter of satisfying the problem elements, but is rather a measure of the relative complexity of
those sufficient solutions that do satisfy all problem elements.
Validation of solutions is a matter of the provision of formal proof of sufficiency (not
elegance). To confuse sufficiency with elegance is to obfuscate the essential function of
validation.
Note that, even though there may be a number of sufficient solutions to the selected problem
elements, the problem owner must choose the most suitable sufficient solution—perhaps in
terms of cost, or perhaps in terms of excess performance (that is, in terms of how much better
a given solution’s performance compared to the sufficiency criteria). While it follows that a
solution must be sufficient for a problem to be solved, the most suitable solution does not have
to be elegant—when applying a cost-benefit analysis, the ‘quick and dirty’ sufficient solution
may be preferred by the stakeholders (perhaps because it is cheapest, or the most expedient, or
because, even though it does much more than required to be sufficient, it is readily available).
A solution is not elegant just because it is simple—that is, the most simple is not the most
elegant. An elegant system must provide a sufficient solution to the problem, so there is a limit
to which the complexity of a candidate solution can be reduced before it is no longer
sufficient. Since candidate solutions will have a range of complexities, it is more useful to
refer to the complexity of the candidate solutions—favouring, of course, the solution with the
lower complexity (rather than simplicity, per se).
An elegant solution does not have to be to a complex problem. Just as it is not useful to
imagine that an elegant solution is simple, it does not help to assume that all problems are
complex. That is, the elegance of a system is related to the complexity of solution it provides
to a given problem (which may be of any degree of complexity).
Since the candidate solutions available to a given problem will vary in the degree of their
complexity (simplicity), there must be a range of values of elegance such that one solution can
be determined to be, by some measure, more elegant than the others. Consequently it is clear
that, for a given problem, the most elegant solution is the sufficient solution that is the least
complex.
Revisiting the practical definitions in Table 1, Table 2 offers a disambiguation of the common usage in
system design of the generic use of the word elegance into more formal properties of sufficiency and
elegance. Of those definitions that do use the term elegance, the descriptions correlate with the
definition offered above.
It is notable that, when defining elegance, many of authors refer principally to sufficiency—for
example, of Madni’s twelve elements in an elegance metric (see Tables 1 and 2), eleven are
sufficiency metrics and only one (parsimony) is actually an elegance metric. Scalability, for example,
is only desired in a solution if the problem is defined to include that system attribute. By way of
further example, consider the system attribute of resilience, which is commonly achieved in products
through the use (among many other techniques) of redundancy. Note that, while we would aspire to
resilience as an attribute of many systems, there are also many products in which such a property is
undesirable. For example, in a light bulb, built-in redundancy would result in a product that was much
larger than desired at far greater cost (with a significant loss in aesthetics). It is a much more elegant
solution to achieve resilience by having the user change the light bulb than it is to attempt to design
redundancy into the product itself. Similarly, a pencil is a very elegant solution to the need for a robust
writing element, but an individual pencil is not scalable nor evolvable, nor is it designed for
sustainability, nor for a long life.
Table 2: Disambiguation of the literature definitions of elegance into sufficiency and elegance.
SourceSufficiencyElegance
OxfordDictionary “2.thequalityofbeingpleasinglyingenious
andsimple;neatness:thesimplicityand
eleganceofthesolution”
Merriam‐Webster
Dictionary
“4.scientificprecision,neatness,and
simplicity<theeleganceofamathematical
proof>”
Kellow(1988)“Ofaccuratepredictions,…
importantand
comprehensive…”
“…buttheyshouldalsobeparsimonious,”
O'Connor(1990) “correct,efficient…”“…andpleasingtocontemplate”
MeyerandLehnerd
(1997)
“Lowlevelsofcomplexityinproductand
processdesignaretangiblemeasuresof
elegance.”
“…oneinwhichallsubsystems,takenasa
whole,createthegreatestoutput
performancefortheleastinputs.”
Gelernter(1998) “…aneffectivemarriageofsimplicityand
power”.
Billow(1999)“…thesystemmust
functionaccordingtoits
statedpurpose,…
“…andthedesignpressuresconstrainingthe
systemdesignmustbesimultaneously
relieved.”
May(2007)“Eleganceisaboutfinding
theahasolutiontoa
problem…”
“…withthegreatestparsimonyofeffortand
expense.”
Griffin(2010)“…anelegantsolutionis
onewhichproducesthe
endresult,isbothrobust
andefficient,and
generatesaminimumof
unintended
consequences.”
Lewis(2012) “…simpleanswersprovideelegantinsightsto
complexproblems.”
Madni(2012)OfMadni’s12elegance
metrics11relateto
sufficiency:purpositivity,
transparency,scalability,
sustainability,bonding,
efficiency,evolvability,
affordability,usability,
utility,andpredictability.
“Atrulyelegantdesignisonethatdoesaway
withhavingtomakeperformanceand
capabilitylimitingtradeoffsamongdesirable
systemcharacteristics.”
OfMadni’s12elegancemetricsonlyone
relatestoelegance:parsimony.
Simonsand
Parmee(2012)
Symmetryandeven
distributionofstructural
attributes
Based on the preceding review and analysis of discussions in the literature on sufficiency and
elegance, the following sections offer formal definitions of the two terms along with some
observations on their application.
5. A FORMAL DEFINITION OF ELEGANCE
Based on the preceding discussion, the following formal definition for elegance can be offered for use
in system design: An elegant system provides the least-complex, sufficient solution to a given
problem.
The elegance (Ei) of the ith (sufficient) solution to a given problem is therefore the ratio of the
complexity of the problem (CP) and the complexity of the ith sufficient solution (CSi).
Ei = CP / CSi (1)
From this simple relationship it can be observed that the relative elegance of the sufficient solutions to
a given problem (that is, one of fixed complexity) is directly related to the relative complexity of those
solutions. The most elegant solution to a given problem is therefore that sufficient solution which has
the lowest complexity.
Elegance (Ei) is therefore a relative measure which can take values greater than unity (assuming the
same complexity measure has been used for both the problem and solution space). At E=1, the
complexity of the solution matches the complexity of the problem—obviously, higher values of E are
desired.
Note that (1) does not rely on any particular measure of complexity, nor of any particular view. While
there is some considerable potential to a common measure of complexity, there are many such
measures (mostly domain-specific) in the literature (Bashir & Thomson, 1999; Braha & Maimon,
1998; Chen & Li, 2005; Dierneder & Scheidl, 2001; Edmonds, 1999; Efatmaneshnik, Reidsema,
Marczyk, & Balaei, 2010; McCabe, 1976; Suh, 2005; Summers & Shah, 2003), with the usefulness of
each measure tending to be context-specific. Notwithstanding the large variety in types of complexity
measures, the definition of elegance in (1) is a relative measure that simply requires that similar
complexity measures are used for the ratio. In fact, if the candidate solution systems have been
validated to be sufficient, elegance is simply a measure of the relative order of merit of the
complexities of the solutions, so that the only requirement is that a similar complexity measure is
applied to each solution. Of course it is possible for a certain solution to remain an elegant solution to
a more complex problem that it was initially considered for (providing it meets the sufficiency
criteria). Further, because of the relative nature of the elegance measure presented here, it is possible
to use the same definition for both the abstract and practical definitions in Table 1.
6. AN ILLUSTRATIVE EXAMPLE
As an illustration of the use of sufficiency and elegance as formally defined in previous sections, an
example is useful. Peterson, Mocko, and Summers (2012) calculated the normalized die complexity of
three potential hair-cutting solutions to the problem of shaving facial hair: hand razor (complexity of
2.22); nose-hair trimmers (complexity of 6.25); and electric razor (complexity of 20.36). Such solution
complexities are intuitively appropriate given the increasing number of components in each device,
from the hand-held to the electric razor. On the assumption that each is a sufficient solution to the
same number of problem elements with the same complexity, the relative complexities of the solutions
is also the relative elegance—a hand-held razor is therefore the most elegant (which is also intuitive).
Once the relative elegance of the solutions has been identified, potential customers can then undertake
their own cost-benefit analysis in order to choose one of the sufficient solutions as the preferred
solution.
Returning to sufficiency, however, as observed in Section 3, it is necessary (but not sufficient) that a
solution satisfies each of the problem elements; a solution is sufficient when the solution satisfies all
of the problem elements. It is unlikely, therefore, that nose trimmers can meet the problem space
element for a minimum closeness of shave so, practically, only the hand-held razor and electric razor
are sufficient solutions; with the hand-held still being the more elegant of the two.
Further, regardless of which of the current solutions may be deemed to be the most elegant, as
observed in Section 5, even a small change in one or more of the problem elements may mean that the
current, most-elegant solution is in fact no longer sufficient, let alone elegant. For example, if the razor
problem boundary is defined to include the ability to operate in harsh environments as part of a
mountain climber’s equipment, the hand-held razor would be the only sufficient solution because the
electric razor may require the carriage of too many batteries, which may not even operate in sub-zero
temperatures. It should also be noted that the sufficiency of a solution further depends on whether the
problem boundary includes or excludes such aspects as the potential for cuts to the user’s face, the
desirability of the need for lubrication of the skin, the desired closeness of the shave, the time taken to
complete the shave, and so on.
As discussed in Section 5, the notion of sufficiency must also be accompanied by a process by which
the most suitable sufficient solution is selected. In the case of the choice between the two sufficient
solutions in the razor example—the hand-held razor and the electric razor—the choice may be based
on cost, on preference, on comfort, or any other factor or combination of factors. It should also be
noted that, had these criteria been included in the problem elements, the range of sufficient solutions
would have been much narrower—that is, had a cost constraint of “less than or equal to $5” been
included, the electric razor would have not been considered sufficient and only the hand-held razor
would have remained as a solution.
Finally, the razor example demonstrates that elegance is not always necessarily desirable—at least, not
in its own right. If elegance was desirable, in and of itself, only hand-held razors would be used since
they are much more elegant (at least as a solution to a minimalist set of problem elements) and also
much lower cost than any electric solution.
7. CONCLUSION
Elegance is universally recognized as a goal in system design. The absence of formal definitions has
meant, however, that most uses of the term have confused the elegance of a system with its
sufficiency. The two terms must be separated so that the sufficiency of candidate solutions can be
validated before the relative elegance of the sufficient solutions can be determined. It is a necessary
(but not sufficient) condition that a solution satisfies each of the individual problem elements within
the problem boundary, but a system is sufficient when it provides a solution that satisfies all the
problem elements within the defined problem boundary (and does not satisfy any elements outside that
boundary). Just as necessity is binary, so too is sufficiency—a solution is either sufficient or it is not.
An elegant system provides the least-complex, sufficient solution. An elegant solution must be
sufficient, but a sufficient system does not have to be elegant.
REFERENCES
Bashir, H. A., and Thomson, V. (1999). Metrics for design projects: a review. Design Studies, 20(3),
263-277.
Billow, S. A. (1999). The role of elegance in system architecture and design. S.M. Thesis,
Massachusetts Institute of Technology.
Boehm, B. W. (1988). A spiral model of software development and enhancement. Computer, 21(5),
61-72.
Braha, D., and Maimon, O. (1998). The measurement of a design structural and functional complexity.
IEEE Transactions on Systems, Man, and Cybernetics-Part A, 28(4), 527-535.
Chen, L., and Li, S. (2005). Analysis of decomposability and complexity for design problems in the
context of decomposition. Journal of Mechanical Design, 127(4), 545-557.
Davis, A. M., Bersoff, E. H., and Comer, E. R. (1988). A strategy for comparing alternative software
development life cycle models. Software Engineering, IEEE Transactions on, 14(10), 1453-1461.
Dick, J., and Jones, B. (2012). On the complexity of requirements flow-down structures. INCOSE
International Symposium, Rome, Italy.
Dierneder, S., and Scheidl, R. (2001). Complexity analysis of systems from a functional and technical
viewpoint. R. Moreno-Díaz, B. Buchberger & J. Luis Freire (Eds.), Computer Aided Systems
Theory — EUROCAST 2001 (Vol. 2178, pp. 223-232): Springer Berlin Heidelberg.
Dorfman, M., and Thayer, R. H. (2000). Software requirements engineering. IEEE Computer Society
Press.
Edmonds, B. (1999). Syntactic measures of complexity. PhD, University of Manchester, Manchester,
UK.
Efatmaneshnik, M., Reidsema, C., Marczyk, J., and Balaei, A. (2010). Immune Decomposition and
Decomposability Analysis of Complex Design Problems with a Graph Theoretic Complexity In E.
Szczerbicki & N. Nguyen (Eds.), Measure Smart Information and Knowledge Management (Vol.
260, pp. 27-52): Springer Berlin / Heidelberg.
Gelernter, D. H. (1998). Machine beauty: Elegance and the heart of technology: Basic Books.
Griffin, M. D. (2010). How do we fix system engineering? 61st Annual International Congress,
Prague, Czech Republic.
Kellow, A. (1988). Promoting elegance in policy theory: simplifying Lowi's arenas of power. Policy
Studies Journal, 16(4), 713-724.
Lewis, K. (2012). Making Sense of Elegant Complexity in Design. Journal of Mechanical Design,
134(12).
Madni, A. M. (2012). Elegant systems design: Creative fusion of simplicity and power. Systems
Engineering, 15(3), 347-354.
Mager, R. F. (1975). Preparing instructional objectives. Belmont, CA: Pitman Learning.
May, M. E. (2007). The elegant solution: Toyota's formula for mastering innovation: Simon and
Schuster.
McCabe, T. (1976). A Complexity Measure. IEEE Transactions on Software Engineering, 2(4), 308-
320.
Meyer, M. H., & Lehnerd, A. P. (1997). The power of product platforms: building value and cost
leadership. New York, NY: The free press.
O'Connor, J. (1990). Elegant design for everyday life. Harvard Business Review, 68, 134-139.
Peterson, M., Mocko, G. M., and Summers, J. D. (2012). Evaluating and comparing functional and
geometric complexity of products. International Design Engineering Technical Conferences and
Computers and Information in Engineering Conference.
Project-Management-Institute. (2013). A guide to the project management body of knowledge
(PMBOK guide), Upper Darby, PA.
Simons, C. L., and Parmee, I. C. (2012). Elegant object-oriented software design via interactive,
evolutionary computation. Systems, Man, and Cybernetics, Part C: Applications and Reviews,
IEEE Transactions on, 42(6), 1797-1805.
Suh, N. P. (2005). Complexity: theory and applications: Oxford University Press.
Summers, J. D., and Shah, J. ( 2003). Developing measures of complexity for engineering design.
International Design Engineering Technical Conference DETC’03, Chicago, Illinois.
Dr Mike Ryan is a Senior Lecturer with the School of Information Technology and Electrical
Engineering, University of New South Wales, Canberra, at the Australian Defence Force Academy.
He holds Bachelor, Masters, and Doctor of Philosophy degrees in electrical engineering as well as a
Graduate Diploma in Management Studies. He lectures and regularly consults in a range of subjects
including communications and information systems, systems engineering, requirements engineering,
and project management. He is the conference chair of two annual international conferences, he is the
editor-in-chief of the Journal of Battlefield Technology, and is chair of the Requirements Working
Group in the International Council on Systems Engineering (INCOSE). He is the author or co-author
of ten books, three book chapters, and over one hundred technical papers and reports.
Dr Mahmoud Efatmaneshnik is a Research Associate with the School of Information Technology
and Electrical Engineering, University of New South Wales, Canberra, at the Australian Defence
Force Academy.