Independence axiom and ideal design explained

Question

I am studying a book about software design called: Nonfunctional Requirements in Systems Analysis and Design which talks about the Axiomatic Design Methodology.

This methodology has two axioms. One of them is the Independence axiom.

There is something however I did not manage to understand. It says about this methodology :

Each functional requirement should be satisfied without affecting any other functional requirement. During the conceptualization process the functional requirements are transformed from the functional domain where they state what, to the physical domain where they will be met by how. The mapping should be one design parameter (DP) to one functional requirement (FR).

The relevance of the independence axiom has additional utility in that individual designs may be evaluated, not qualitatively, but quantitatively, based on the relationship to an ideal design. The ideal design is one where the number of DPs are equal to the number of FRs, where the FRs are kept independent of one another. All design alternatives may be evaluated against the concept of an ideal design.

Question

The book suggests the ideal design has one design parameter to one functional requirement. But what exactly is considered a design parameter within the software engineering scope and this methodology ?

Answer 1

Having a short look into Axiomatic Design Technology, when I got this right, I think it is pretty simple:

• a "design parameter" is simply a module or component in a software system which has the purpose of implementing a specific functionality or feature within the application

• the idea of "one design parameter to one functional requirement" is simply called orthogonality in software design. It means one can change one component within the system without affecting the others. One popular approach to achieve this kind of orthogonality is following the SOLID principles.

So the ideas presented there are not really new in software engineering, we just use different terms for them. This is not really astonishing, since the "inventor" of Axiomatic Design comes from a different field: production and design processes for physical things.

Let me add I am sceptical about the usage of mathematical terms and symbols in this context. The term "axiomatic", or the "matrix multiplication" presented in the Wikipedia article give me the impression the people who came up with this are trying to pretend this methodology is "mathematically founded". But there is actually no real math in it, and the "new scientific ideas" debunk themselves as old, long existing software engineering knowledge hidden behind fancy terms taken from other disciplines.