Solving Software and Business Problems with Axiomatic Design
Software iterations are costlier than doing the job right in the first place. If new programming staff has to first learn the code to implement a change, then a software function that would have taken a couple minutes to implement in the original development might take days of study, code fixes, unit tests, and QA regression tests.
The following functions of the Axiomatic Design process frequently do NOT occur in traditional software design processes, but reduce iteration risk:
Separate the business process design solution from the coding solution
Input requirements are usually business process use cases, sequence diagrams, and feature lists. Programmers implement both the business process design and the coding design simultaneously, which creates complexity.
Software programmers are often not the right people to be making business process design decisions.
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 coding
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.
Traditional software design usually skips early failure and fault analysis and simply fixes problems when found during test or deployment.
Prototype to capture problems before coding
Functional requirements analysis provides a complete set of use cases and data fields which define the business process and which then can be modeled and tested before the coding effort. This finds problems before the problems are coded into the solution.
Traditional software design processes do not test the business process design and will require iterations to fix problems later in the development process.
Design leaner with top-down functional decomposition
Most software business designs are bottom-up processes that generate requirements full of excess features. Programmers 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 and software design.