What is the difference between a System Specification and a Software Specification?

Very often we find that companies do not understand the difference
between a System specification and a Software Specification. Important
issues are not defined up front and Mechanical, Electronic and Software
designers do not really know what their requirements are.

The following is a high level list of requirements that should be addressed in a System Specification:

  • Define the functions of the system
  • Define the Hardware / Software Functional Partitioning
  • Define the Performance Specification
  • Define the Hardware / Software Performance Partitioning
  • Define Safety Requirements
  • Define the User Interface (A good user’s manual is often an
    overlooked part of the System specification. Many of our customers
    haven’t even considered that this is the right time to write the user’s
  • Provide Installation Drawings/Instructions.
  • Provide Interface Control Drawings (ICD’s, External I/O)

One job of the System specification is to define the full
functionality of the system. In many systems we work on, some
functionality is performed in hardware and some in software. It is the
job of the System specification to define the full functionality and
like the performance requirements, to set in motion the trade-offs and
preliminary design studies to allocate these functions to the different
disciplines (mechanical, electrical, software).

Another function of the System specification is to specify
performance. For example, if the System is required to move a mechanism
to a particular position accurate to a repeatability of ± 1 millimeter,
that is a System’s requirement. Some portion of that repeatability
specification will belong to the mechanical hardware, some to the servo
amplifier and electronics and some to the software. It is the job of
the System specification to provide that requirement and to set in
motion the partitioning between mechanical hardware, electronics, and
software. Very often the System specification will leave this
partitioning until later when you learn more about the system and
certain factors are traded off (For example, if we do this in software
we would need to run the processor clock at 40 mHz. However, if we did
this function in hardware, we could run the processor clock at 12 mHz).
[This implies that a certain level of research or even prototyping and
benchmarking needs to be done to create a System spec. I think it is
useful to say that explicitly.]

However, for all practical purposes, most of the systems we are
involved with in small to medium size companies, combine the software
and the systems documents. This is done primarily because most of the
complexity is in the software. When the hardware is used to meet a
functional requirement, it often is something that the software wants
to be well documented. Very often, the software is called upon to meet
the system requirement with the hardware you have. Very often, there is
not a systems department to drive the project and the software
engineers become the systems engineers. For small projects, this is
workable even if not ideal. In this case, the specification should make
clear which requirements are software, which are hardware, and which
are mechanical.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s