Fig 1 - uploaded by Mary Kathryn Thompson
Content may be subject to copyright.
Design domains of an artifact, its parent system and its components.
Source publication
Axiomatic Design (AD) Theory describes the design process as a mapping of ‘what’ to ‘how’ across four design domains. Every decision during this process is made deliberately, from the highest-level functional requirements to the lowest level process variables. However, it is unclear how and where to document that information within the AD framework...
Context in source publication
Context 1
... investment (i.e. profit). Different artifacts could be chosen to satisfy this FR, each with different customers, customer needs, and functional requirements. In these cases, the highest-level 'why' cannot be defined at the artifact level. Instead, the design domains must be viewed as a continuum that extend beyond the boundaries of the artifact (Fig. 1). This allows the designer to see that highest-level 'why' is often defined by the FRs of a higher- level (parent) entity. This is consistent with Thompson's [2013a] assertion that many procedural errors in the definition of functional requirements stem from a conflation of the FRs of the artifact and of related higher-level systems. ...
Citations
... A system might satisfy a given function, but that do not automatically translate to satisfy a set of performance parameters related to the given function and vice versa. There have been previous attempt to improve the process of requirement management in axiomatic design [21,22] through the generation of a stakeholder spreadsheet. In a model-based environment, the functional and non-functional requirements need to exist in the same environment with a traceable relationship established between both types of requirements and the corresponding functions and logical relations. ...
... However, this needs to be accomplished without the benefit of any closely aligned prior art and its documentation. In reverse-engineering any given product, the iterative, top-down, forward flow between FR→DP is reversed into an iterative, bottom-up, FR←DP reverse flow [24][25][26]. In the case of nature's designs, the fundamental problem that exists in regard to the above reverse engineering exercise is that of hydrating natures FR←DP hierarchies in a bottom-up sense. ...
... However, this needs to be accomplished without the benefit of any closely aligned prior art and its documentation. In reverse-engineering any given product, the iterative, top-down, forward flow between FR→DP is reversed into an iterative, bottom-up, FR←DP reverse flow [24][25][26]. In the case of nature's designs, the fundamental problem that exists in regard to the above reverse engineering exercise is that of hydrating natures FR←DP hierarchies in a bottom-up sense. ...
Life has existed on earth for at least 3.95 billion years. All along, the flame of life has been successfully passed on from generation to generation, and species to species across an immense temporal span. This includes at least five mass-extinction events that wiped out over 70% of all species in each such biotic crisis. Against such immense odds, life has learned to thrive despite repeat assaults. And the ingenuity embedded within natures designs has been an integral part of this inspiring story. For example, the ancient bacterial flagellum is powered by the Mot Complex which is part of a perfectly circular nanoscale rotary engine. It is obvious that nature came upon the wheel much before human arrival (i.e., at least as far back as 2.7 billion years). Many are the design lessons that may be gleaned from studying nature. This paper looks at the immense evolutionary design-laboratory that nature evolves its designs within, and frames it along side an Axiomatic/Complex-Adaptive/Stigmergic Systems perspective.
... Thus, the ability to rapidly scale up or down a certain web site based on the seasonal load at hand is most definitely a functional requirementexcept that instead of it being at a final user level, it is now at a system-wide/population-wide level. It is, therefore, a failure in the design community to understand the functional domain when it asserts that the above list of requirements is somehow non-functional [66,67]. ...
Modern cloud computing makes available a plethora of scalable cloud computing offerings. The cloud is increasingly becoming the backbone of the highly complex modern knowledge-economy that includes Social, Mobile, IoT, Big-Data and AI. Knowledge-based products and services follow fat-tail distributions such as the power-law that poses major opportunities and challenges for the designer. The Axiomatic Designer is uniquely positioned in designing for the de-novo situations that the fat-tailed distributions expose. Also, the cloud frees-up the architectural decision-making away from the legacy compatibility-burden, and towards various cloud-native (i.e., de-novo/solution-neutral) as well as hybrid (on-prem/cloud & cloud/cloud) architectures. Further more, the competitive landscape around the cloud is not static; it is adaptive and evolving rapidly. Here again, Axiomatic Design (AD) is uniquely positioned in rising upto the various de-novo challenges This, however, requires contributions from frameworks such as Knowledge-as-Heterarchically-Hierarchical (KA|h|H), Stigmergy, Complex Adaptive Systems (CAS), Cynefin, Boyd’s OODA-Loop Theory of asymmetric fast-transients, Axiomatic-Maturity-Diagram (AMD), as well as Weick’s Loose-Coupling approach to help unify and strengthen the Axiomatic approach. This paper unifies the above approaches in order to tackle the architectural challenges of cloud computing.
... Thirdly, decomposition can include non-essential functions, which aim to increase attractive qualities of a product [18]. For instance, primary functions of a mobile phone are to send and receive phone calls, provide access to the Internet, take photos etc., but adding additional features to the camera can make the mobile phone more desirable. ...
The main objective of this paper is to propose a modified methodology for concept evaluation by applying Axiomatic Design principles. Several drawbacks were recognised during the literature review and application of established Axiomatic Design principles that limit its use for concept evaluation. These drawbacks include the lack of analysis of concepts that violate the Independence Axiom, the application to concepts that are not generated with Axiomatic Design and inclusion of constraints and requirements in the evaluation process. The proposed methodology consists of four steps of which the first one is to analyse the compliance of concepts with a set of functional requirements. Afterwards, to determine the possible violation of the Independence Axiom, non-diagonal elements need to be examined and reangularity and semiangularity values calculated for each concept. Finally, concepts are evaluated in terms of Information Axiom to include requirements, criteria and constraints other than functional requirements. Applying Information Axiom to all concepts regardless of Independence Axiom violation provides insight into the complexity of concepts. The proposed methodology was applied to mobility scooter conceptual design conducted in cooperation with an industrial partner. The partner company provided input and system constraints at the beginning of the project and guidelines for concept development. Constraints were taken into consideration by applying the Information Axiom in which constraints are compared with values measured on prototypes.
... Thirdly, decomposition can include non-essential functions, which aim to increase attractive qualities of a product [18]. For instance, primary functions of a mobile phone are to send and receive phone calls, provide access to the Internet, take photos etc., but adding additional features to the camera can make the mobile phone more desirable. ...
The main objective of this paper is to propose a modified methodology for concept evaluation by applying Axiomatic Design principles. Several drawbacks were recognised during the literature review and application of established Axiomatic Design principles that limit its use for concept evaluation. These drawbacks include the lack of analysis of concepts that violate the Independence Axiom, the application to concepts that are not generated with Axiomatic Design and inclusion of constraints and requirements in the evaluation process. The proposed methodology consists of four steps of which the first one is to analyse the compliance of concepts with a set of functional requirements. Afterwards, to determine the possible violation of the Independence Axiom, non-diagonal elements need to be examined and reangularity and semiangularity values calculated for each concept. Finally, concepts are evaluated in terms of Information Axiom to include requirements, criteria and constraints other than functional requirements. Applying Information Axiom to all concepts regardless of Independence Axiom violation provides insight into the complexity of concepts. The proposed methodology was applied to mobility scooter conceptual design conducted in cooperation with an industrial partner. The partner company provided input and system constraints at the beginning of the project and guidelines for concept development. Constraints were taken into consideration by applying the Information Axiom in which constraints are compared with values measured on prototypes.
... The zig process corresponds to the process that flows from "what" to "how". The hierarchical decomposition includes a reverse process, the zag that flows from "what I achieved" to "why" [4]. D. Tate proposed a "roadmap of activities in decomposition" concerning the process of the zig [5, p. 42] and the process of zag [5, p. 40]. Figure 2 depicts the diagram proposed by D. Tate for the zig process, showing two main tasks: "defining and selecting sub-DP", and "setting DP parameter values". ...
... In the AD theory the zig process is a synthesis process that expresses the "what" to "how" and the zag process that goes from "what" to "why" in the next level of decomposition [4]. In the end of the zag, the design process achieves the children FRs that have to be CEME. ...
The AD's design equation depicts the relationship between the functional requirements (FR) and the design parameters (DP) by the design matrix (DM), through a unique zigzag decomposition path. At the “zig part” of each level of the zigzag decomposition, the designer needs to find out the DPs that can fulfil the given FRs. This paper proposes that the designer has to perform three main actions in a zig process in order to define the design equation: to define the DPs at a nominal condition and its magnitude; to evaluate the interactions of the DP with the system at actual conditions; and to check back the set of FRs verifying if they fit inside the design range. The purpose of this paper is to illustrate the actions performed on a zig, emphasising the changes that may occur in the arrangement of the design during the synthesis of the DM at any level of the decomposition. At each level of decomposition, the estimation of the DPs that fulfil the FRs allows the designer to define a subset of the DM, making it possible to evaluate afterwards the DM with all the interactions of the system. Moreover, in what concerns to the information content, it is possible to evaluate the probability of success of the system taking into account the interactions of the system and the tolerances of the DPs. This paper presents an example regarding the evaluation of the DM using the equations of the design for a variable air volume (VAV) air conditioning system.
The design of modern cloud computing makes available a plethora of scalable cloud computing offerings. The cloud is increasingly becoming the backbone of the highly complex modern knowledge economy that includes social, mobile, IoT, Big Data, and AI. Knowledge-based products and services follow fat-tail distributions such as the power law that poses major opportunities and challenges for the designer. The Axiomatic Designer is uniquely positioned in designing for the de novo situations that the fat-tailed distributions expose. Also, the cloud frees up the architectural decision-making away from the legacy compatibility-burden, and toward various cloud-native (i.e., de novo/solution-neutral) as well as hybrid (on-prem/cloud and cloud/cloud) architectures. Furthermore, the competitive landscape around the cloud is not static; it is adaptive and evolving rapidly. Here again, Axiomatic Design (AD) is uniquely positioned in rising up to the various de novo challenges. This, however, requires contributions from frameworks such as knowledge as heterarchically hierarchical (KA|h|H), stigmergy, complex adaptive systems (CAS), Cynefin, Boyd’s OODA loop theory of asymmetric fast transients, axiomatic maturity diagram (AMD), as well as Weick’s loose-coupling approach to help unify and strengthen the axiomatic approach. This chapter unifies the above approaches in order to tackle the architectural challenges of cloud computing.
