Systems Design is probably the hardest aspect of being a systems engineer.
Unless you’ve come from a background in the system that you are designing, then the odds are against you!
In this listicle / article we cover how you can overcome the odds by applying some ISO15288 process and good old logical thinking.
A growing adage of Systems Engineering is that ‘pragmatism overrules process’ and that holds true for developing a systems design description.
We’re a couple of steps through our project when considering it from the perspective of the V Life Cycl. Having defined our Requirements and Architecture, we have a pretty good idea of what a system should do in order to fulfil its mission.
Now we must get down to the nitty gritty detail of design.
The first useful principle in this phase is that not being an expert in the domain topic can be an advantage. Embracing the fact that you know little about the domain means you have the power of a beginners mindset. You’re thinking from an unbiased perspective which can lead to writing thorough and expansive design descriptions. You only have the requirements in your mindset and thus have a clear picture of what needs done. A beginner's mindset is useful because you aren't introducing preconceived ideas of design. Use the power of the beginner mindset when thinking about design. Go back to basics.
The next principle is the complete opposite of a beginner's mindset. IF you aren't a domain expert then you need to work with topic experts to ensure you’re on the right path.
It's easy to go down rabbit holes which are off topic and not needed.
Therefore, producing design description skeleton structures with appropriate headings and bullet points on the content you intend on covering is where to begin. Reviewing this design direction with an expert then validates you’re on the path to success.
It saves time, effort and heartache.
Which leads us to the important question of, What actually should be covered in a design description? Merging ISO15288 with some SOSE lessons learned, we’ve produced a rough skeleton for any aspiring systems designer.
A Design Description should contain the following information:
An allocation of your requirements to system architecture
A justification of design area relating to requirements / architecture
Identification of desirable design characteristics and behaviours
By using design enablers such as models and heuristics
Definition of interfaces being used or ones that have not been identified or need further definition
Identification of system elements
Definition of design characteristics of system elements
An assessment of alternatives for system elements
Specification on how system elements will be implemented
If mechanical
shape, pattern, dimension, volume, surfaces, resistance to forces, distribution of forces, weight, velocity, motion
If software
distribution of processing, data structures, data persistence, procedural abstraction, data abstraction, control, encapsulation, creational patterns (e.g. builder, factory, prototype,) structural patterns, (adapter, bridge, proxy)
An assessment of design to ensure holistic design
Definition of implementation methods for system elements
Inputs (e.g. how data is received / trigger events)
Definition of the functional process
Definition of the key items that must be executed as part of the process
Definition of the system element that will do that process
Definition of the system element attributes (size, shape, style, etc)
Definition of the output / export of information from element
Definition of the interfaces
How the interfaces work
In essence, we are specifying the ‘what's needed’ in order to fulfil the requirements. We may specify some aspects of the ‘how’, but as Systems Engineers, it’s likely we will leave this to subsystem experts.
Once you have begun identifying the content above then adopting the principles of recursion and iteration is necessary for success.
Recursing through layers of design and iterating continuously using design reviews as feedback, ultimately will lead you to a successful design. It is the most important tool in your arsenal as a Systems Engineer.
That's our System Design Description 101!
Interested in learning how to apply this on a real life project?
Sign up to our Applied Systems Engineering Nanodegree where we teach you everything you need to know about Systems Engineering!
Comments