Recently, several people have asked me to explain the difference between systems engineering and software engineering. My answer was rather longer than I expected…
For our purposes, if we define systems engineering as the construction of a system composed of smaller units – some of which contain specialist / bespoke hardware. This hardware will require software to be written or configured for it, so that it makes sense to talk here about this activity as software engineering from a systems-engineering perspective.
Although there are some grey areas, here goes:
Systems Engineering
As previously mentioned, systems engineering involves the construction of a system composed of smaller units, some of which may contain specialist / bespoke hardware.
Examples of products of systems-engineering programmes are: the space shuttle, telecommunications systems, pacemakers and mobile phones. Very large systems will involve other engineering disciplines; such programmes may last decades.
Programmes will often involve demanding non-functional requirements, such as those relating to performance or size.
There are likely to be more stakeholders involved, including additional suppliers and sub-contractors – with correspondingly more contractual interfaces.
The programmes are often plan-driven, with large documentation requirements. Requirements are likely to be specified in a list of “shall” statements (IEEE-830 notation) rather than use cases or scenarios. There may be significant use of formal methods because of the mission-critical nature of the system or the inability to modify the hardware configuration quickly (or at all).
[Note added in 2019: SpaceX seems to be leading the way in incremental systems-engineering approaches]
Software Engineering
Is the design, construction and maintenance of software interfacing with commercial “off-the-shelf” hardware – ie hardware that requires no physical modification.
Examples of software engineering projects would cover the development of popular websites such Amazon, Twitter, (but not Google, see below*); products such as Microsoft Office; and implementation of corporate software systems.
Programmes will be shorter than that of system engineering programmes – with timescales of months or years. Requirements will often be specified in use-case or scenario format and development will increasingly follow an agile approach.
*Google is an interesting exception as this company modifies the hardware in commercial off-the-shelf PCs in order to increase performance. Using the criteria above, Google’s services fall under the category of systems engineering.
General Thoughts
In both software and system engineering, fracture points, inflexibility and dispute often occur at the contractual boundaries – “where contingency budgets congregate.” A radical way forward to minimise these in shown in the recent groundbreaking T5 Contract. A less dramatic way of reducing risk is to use a technique known as Evolutionary or Progressive Acquisition. This technique allows a buyer to acquire services incrementally, allowing both parties to focus on delivery rather than confrontation.
A modelling language that is gaining in popularity that is specifically designed for use in systems engineering projects – the System Modelling Language (SysML). SysML takes the most-commonly used notation in UML [the Unified Modelling Language used in software-engineering projects] and adds additional elements which, for example, allow requirements to be integrated into a model in a way that UML does not.
Even without using the SysML notation, we have found that many systems-engineering programmes include elements of software engineering. In these cases, Agilier has successfully introduced Agile techniques within the overall programme, reducing risk and minimising waste work.