Solving Product Development Problems with Axiomatic Design
The following functions of the Axiomatic Design process frequently do NOT occur in traditional product development processes, but reduce iteration risk:
Differentiate the design process from the solution space
Designers generally jump to a solution, and complete the design within the limiting framework of their initial solution space. Alternative creative solutions are never considered. By completing a requirements analysis in the function space, innovation is not stifled.
Find missing requirements
How does a person find out if a puzzle is missing pieces? By assembling the puzzle, the missing pieces become obvious.
An Axiomatic Design decomposition of functional requirements has a dependency structure, like a puzzle. All requirements must fit into the dependency structure, showing the missing functions like holes in a puzzle.
Addressing the missing requirements BEFORE coding avoids iterations.
Assess risk before the bulk of design work
Fault Tree Analysis (FTA), Failure Mode and Effects Analysis (FMEA), and project risk assessment can be systematically performed on the functional requirements analysis of the business process design. This is an efficient process to identify and avoid problems before the design is generated.
Traditional design processes assess failure modes and fault analysis AFTER the design has been generated, creating considerable iteration and rework.
Design using logical and rational thought processes
Ad hoc brainstorming of designs in the solution space generates many concepts that are compared and quickly rejected. Instead, proceed systematically to develop a functional performance requirements model of working solutions.
Design leaner with top-down functional decomposition
Most requirement lists are generated from bottom-up processes that result in requirements full of excess features. Designers commonly add features for additional functionality under the false assumption of adding value.
Functional requirements analysis demands that any wasteful features that do not support a higher function must be removed. This results in leaner designs.
Verify top-level functional requirements with a DFSS quality function
Top-level functions are formally traced to a stakeholder’s analysis and document the business requirements for the system under design.
Traditionally, there is no validation of the business function of the software system which causes unclear relationships and misalignments between business goals in many development projects.