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.


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 ?

  • 5
    This definitely sounds like someone's Doctoral Thesis, and not something based in the reality of building real systems. In order for this to even work, you would have to define your features at a very high level and assume the feature contains all the functionality for every usage path. In reality, we have a base feature, and then treat each error handling path as its own feature. Jan 23, 2020 at 15:07
  • A design parameter would be some external influence that impacts your functional requirements. In reality, there are several design parameters: performance (particularly for real-time or near-real-time systems), security, data consistency, etc. Without actually reading the book, I can only provide my impressions on the terminology you are presenting here. The author may have something else in mind for design parameters. Jan 23, 2020 at 15:09
  • 1
    I would have to dig deeper into axiomatic design, but on the surface it seems like this takes the concepts of cohesion and consistency (in the context of good requirements) to the next level.
    – Thomas Owens
    Jan 23, 2020 at 15:24

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

  • I’m not versed in Axiomatic Design either, but having read a couple if articles I came to the same understanding: it’s common swe concepts expressed in a very mathematical language. Probably to justify with mathematic means the properties of the design base on the properties of the requirement, which is a more elegant way to say “garbage in, garbage out” ;-) Thank you for this very nicely worded answer!
    – Christophe
    Jan 24, 2020 at 7:26
  • Yes, what the book also tries to do it to define mathematical measurements for any non functional requirement, as you mentioned. For example, this ideal design formula is used to measure system complexity. I am not saying it is the best way but I like the fact that there were mathematical formulas for every system attribute.. And the formulas seemed rather simple. Jan 24, 2020 at 8:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.