AXIOMATIC DESIGN IN SOFTWARE DESIGN FOR SIX SIGMA (DFSS) - Software Design for Six-Sigma: A Roadmap for Excellence - page 330

CAs CAs FRs DPs CAs PVs CAs QFD

{FR}=[A]{DP} {DP}=[B]{PV}

Customer Mapping Physical Mapping Process Mapping

FIGURE 13.1 The design mapping process.

application of quality function deployment (QFD). Once the minimum set of FRs is
defined, the physical mapping may be started. This mapping involves the FRs domain
and the design parameter codomain (DPs). It represents the product development
activities and can be depicted by design matrices; hence, the term “mapping” is
used. This mapping is conducted over design hierarchy as the high-level set of FRs,
defined earlier, is cascaded down to the lowest hierarchical level. Design matrices
reveal coupling, a conceptual vulnerability (El-Haik, 2005: Chapter 2), and provides
a means to track the chain of effects of design changes as they propagate across the
design structure.
The process mapping is the last mapping of axiomatic design and involves the DPs
domain and the process variables (PVs) codomain. This mapping can be represented
formally by matrices as well and provides the process elements needed to translate the
DPs to PVs in manufacturing and production domains. A conceptual design structure
called the physical structure usually is used as a graphical representation of the design
mappings.
Before proceeding further, we would like to define the following terminology
relative to axiom 1 and to ground the readers about terminology and concepts that
already vaguely are grasped from the previous sections. They are:

Functional requirements (FRs) are a minimum set of independent requirements
that completely characterize the functional needs of the design solution in the
functional domain within the constraints of safety, economy, reliability, and
quality.
How to define the functional requirements?
In the context of the Figure 13.1 first mapping, customers define the prod-
uct using some features or attributes that are saturated by some or all kinds
of linguistic uncertainty. For example, in an automotive product design, cus-
tomers use the term quiet, stylish, comfortable, and easy to drive in describing
the features of their dream car. The challenge is how to translate these features
into functional requirements and then into solution entities. QFD is the tool
adopted here to accomplish an actionable set of the FRs.
In defining their wants and needs, customers use some vague and fuzzy
terms that are hard to interpret or attribute to specific engineering terminol-
ogy, in particular, the FRs. In general, functional requirements are technical
terms extracted from the voice of the customer. Customer expressions are
not dichotomous or crisp in nature. It is something in between. As a result,