Improving the requirements process in Axiomatic Design Theory

Thompson, Mary Kathryn

doi:10.1016/j.cirp.2013.03.114

Cited by 44 publications

(22 citation statements)

References 14 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Conversely, Thomson [7], starting from a set of case studies observed in academia (but common also in the industrial world), described a method for stratifying customers' needs into four classes in order to avoid errors and create a well-balanced list of requirements.…”

Section: Translating Customers Needs: the Qfd Approachmentioning

confidence: 98%

Ordering the Chaos: A Guided Translation of Needs into Product Requirements

et al. 2014

View full text Add to dashboard Cite

The organization of customers' needs and technical requirements in a QFD (Quality Function Deployment) often generates sparse relationship matrices. This entails several difficulties during early design process and collides with general design concepts as good balancing, order and symmetry. The diagonality of the matrix is, in fact, an index of the effectiveness of effective decomposition of needs and CTQs (Critical To Qualities) at an appropriate level of detail. The paper presents a step-by-step procedure aimed at guiding the designer for a correct translation of needs into product requirements. The peculiarity is that the method intervenes at the very early stage of VOC (Voice Of the Customer) translation into CTQs, unlike classical approaches that occurs in successive steps. The procedure consists of an iterative elaboration and re-organization of the information related to the radical innovation of complex products. A validation case, performed in collaboration with a manufacturing company operating in the automotive field, allowed to test the effectiveness of the procedure

show abstract

Section: Translating Customers Needs: the Qfd Approachmentioning

confidence: 98%

Ordering the Chaos: A Guided Translation of Needs into Product Requirements

et al. 2014

View full text Add to dashboard Cite

show abstract

“…After identifying the needs of the stakeholders, it is possible to define the requirements of the product, respecting the constrains of the design [9].…”

Section: Literature Reviewmentioning

confidence: 99%

The Iterative Nature of the “Zig” and How to Define the “Hows”

et al. 2017

View full text Add to dashboard Cite

Abstract. 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.

show abstract

“…Viewing this in a larger context of induction with design to define the future of man-machine interactions and decoupling of historical relationships, such mappings could help sensitize us to our advantage. [7] Pulverizing of intellectual streams has been rare, not only while considering predominantly top-down (Axiomatic design) and bottom-up (Design Patterns) approaches [3], requirements processes [4], but also horizontally between interdisciplinar domains of legal research and Axiomatic design. The latter theme is depicted in this paper in context of cloud sourcing with application to a manufacturing SME.…”

Section: The Engineering Aspects Of Requirements Process For Top-downmentioning

confidence: 99%

“…A tool such as the stakeholder spreadsheet was found to be cumbersome, and limited in facilitating interdisciplinary communication. [4] Nevertheless, the CORAS tool [6] proved beneficial while communication legal risk within the non-legal team members. Such a graphical modelling tool does suffer from the limitation that it is limited in capturing complex legal issues and when interpreting laws that are drafted on an abstract level, which requires legal expert judgement.…”

Section: Casementioning

confidence: 99%

Legal Requirements Process for Compliance and Risk Assessment using Axiomatic Design

Wadhwa¹

2017

IJCSI

View full text Add to dashboard Cite

The paper proposes a model integrating regulatory compliance and risk requirements with the top-down axiomatic design/Complexity theory (AD/CT) theory for cloud contracts. The issue of proper division of tasks between man and machine is discussed. The integrated approach is illustrated addressing legal compliance by design and legal contract risk assessment within the realm of cloud computing for manufacturing small to medium sized enterprise (SME).

show abstract

Improving the requirements process in Axiomatic Design Theory

Cited by 44 publications

References 14 publications

Ordering the Chaos: A Guided Translation of Needs into Product Requirements

Ordering the Chaos: A Guided Translation of Needs into Product Requirements

The Iterative Nature of the “Zig” and How to Define the “Hows”

Legal Requirements Process for Compliance and Risk Assessment using Axiomatic Design

Contact Info

Product

Resources

About