How to write a Systems Design Description

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
  • If mechanical
    • shape, pattern, dimension, volume, surfaces, resistance to forces, distribution of forces, weight, velocity, motion
    • 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)
    • 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!