The importance of system architecture is frequently underestimated and misunderstood. Frequently it only consists of hardware component selection and definition of subsystem interaction in accordance with the Purdue Control System Model. Very seldom is it taken any further.
Specifications consisting of I/O lists and narratives are prepared for each of the subsystems without regard for software implementation. The result is that much of the information exchanged, between the end customer, mechanical supplier and automation supplier, is either not captured or captured in a form not easily translatable to hardware and software designs.
The problem is that lost information must be recreated or rediscovered in subsequent phases of the project. In addition inconsistencies and unasked questions must be resolved. The narrative must be re-interpreted and expressed in the form of a design. Not only is this process a duplication of effort and notoriously unreliable, it can also be enormously expensive.
We have perfected a methodology where information and other requirements are collected and organized into hierarchical structures and tabular forms. Items in the hierarchical structure have a close correlation with the hardware and software. Tabular data drastically reduces the amount of narrative required, reduces the likelihood that critical data will be omitted, and in many or most cases can be used directly by the underlying software components. Complexity is limited to linear increases as features and components are added. Project killing exponential increases in complexity are eliminated entirely.