8. The ‘Design does not impact Function’ principle:

Design, by definition only impacts performance and cost attributes. It has no impact on the fundamental function of a system. Nor does Function impact design. But design must fit function!

Implications;

• Function requirements must not contain ‘design’ (they too often do !)
   

• Design must be appropriate to the function of a system; meaning we cannot design in ignorance of the functions, to reach some abstract performance levels
   

• To classify design as a function requirement is bad practice, since it robs us of freedom to address the real performance requirements, and it probably obscures the real performance requirements themselves. Real performance requirements often don’t get defined because the design, called falsely a function, is all there is to represent them

Architecture is the highest level of design for a given system. It is the framework and control over all other more-specialized design in the system. But Architecture follows all principles of design.

Implications:

• architecture must have more authority and power than the narrower disciplines
   
• architecture needs to be settled before serious engineering design can proceed
   
• architecture is the same discipline as design, but controls a higher level of the system, and consequently has different abstractions of information to handle

Design, at all levels needs to evolve in small steps of confrontation with reality, analysis and re-design. It cannot adapt to the inevitable continuous stream of information from different sources, different timings, experience feedback, problem solving insight, economic change, political change, and technical change in any other reasonable way.

Design cannot be simply and correctly completed at once, any more than a child can be mature, or a new business perfectly designed.

Implications: the design process must be taught and practiced as an iterative process

• the design process must know how to collect data about design performance, and how to adjust design itself to better meet the real needs of stakeholders
   
• the design specifications must not be prematurely frozen
   
• but design specifications must neither be changed without clear logical and profitable reason

• designers need formal training and leadership in these principles
   
• design as practiced today is too often failing to systematically address the multiple stakeholder needs
   
• these principles apply more, the larger and more critical the system at stake
   
• we can ignore these principles if the risks we thus incur are more tolerable than the cost of such systematic engineering

Right now the failure rate of projects is so uncomfortably high that we need to look at the option of investing more in the systems engineering intellectual processes.

_____________________________

© Tom@Gilb.com 2005 
 

About the author: Tom Gilb

Related articles: Basic Requirements Structure, Rich Requirement Specifications, Quantifying Qualitative Requirements

Books: For complete coverage of Design Principle techniques and the Planning Language 'Planguage', take a look at Competitive Engineering.

The comprehensive glossary of terms and concepts accompanying the Competitive Engineering book can be accessed online at CE Glossary (N. America) or CE Glossary (outside N. America).

For general background: Btt principles

Attend a seminar or training course: more...

To raise questions or discuss the subjects further...  questions.