Systems Engineering, Interfaces and the effects of System change

A System Engineer’s role is to understand the customer’s need, unambiguously document the intention and use, including validating it with the customer, and then define and describe an ‘optimal’ solution in terms of components that can be engineered independently, yet will integrate to deliver the required capability.

Obviously an ‘optimal’ system is subjective and needs further definition of the qualities of the system and at the same time respond to the constraints that the physical manifestation of the system solution will impose. Lots of experience or Crystal Ball gazing required! Finding a balance that will satisfy the customer is considered success.

 

A recurring theme, then, is “understanding the customer”, including immersion in his world; and playing the proxy customer for the development team during design, integration of components into the system, and validation. (We will deal with Verification, Validation and Integration in a later instalment.)

The customer may not be singular, but a series of ‘actors’ (human or machine) on the system who present different interfaces and needs. In large, or long-lived, systems these needs (and interfaces) may change and those changes may need to be accommodated. If this is the expectation, then the system engineer will also have to deal with the necessary future-proofing, and pass that flexibility into the component definitions.

System change is the single most disruptive attribute to Software Systems development; almost all cost and schedule overruns can be traced back to this root cause. System change (especially change that crosses system component boundaries) must cause system re-evaluation to understand the impact, or opportunity to contain, component changes and the influence on the overall capability.

In order to mitigate such change by design, system architects (a particular role within system engineering) will use techniques such as interface standardisation, modularisation and layering to partition components, create propagation boundaries and separate concerns; in general however, these are at the ‘cost’ of some optimisation, say of processing power, efficiency, speed of response, weight etc.

Change is inevitable, whether through component obsolescence, change of use of system, or in search of improved performance. Good systems engineers will design solutions that can accommodate the most probable causes at low impact, but as system size, complexity and lifetime increase be prepared to invest in system engineering to minimise the total cost of ownership.

___________________________________________________________________________

Let us help you maximise the business potential of your product and its software

Email me on stuart.jobbins@sofintsys.com

Visit our website, or follow us on your preferred Social Media for our latest views.    linkedin twitter (2)___________________________________________________________________________

 

Leave a Reply