1. Computer-based system engineering is introduced by Sommerville as a discipline sitting above software
engineering and encompassing hardware systems to take a whole system perspective. The introduction
of hardware systems bring in a number of aspects such as the physical environment of the system,
which need to be considered and controlled. Another key aspect is the consideration of system
properties which exist within the system as a whole (emergent properties). Sommerville provides some
examples these emergent properties, such as the overall weight of a system (which could be computer
from the weights of all the subsystems), and the usability of the system (which would have complex
dependencies on the hardware, software the system’s environment and indeed the system’s users).
Though it’s not actually relevant, I’ll wander off on that last point as I’ve always been quite interested
in usability (being a Mac user). Simplistic views of usability have always really frustrated me. I
remember once reading a really high level requirements specification written by a client which said
something along the lines of ‘The system should be user friendly – what more is there to say?’.
Actually, there’s a lot. Who are these users? Can we assume they can use a computer? If not, maybe I
should be getting out of the way so someone can design a paper based system. What are the usage
patterns in the system? A system which users will work on without any training needs to be designed
very differently to a system people will use day in and day out. In the end, what the client really
meant here was that usability was an important factor for the system, which I would agree with whole
heatedly, but downplaying the complexity of usability just makes it more difficult to allocate the time
it requires.
Emergent system properties
Somerville begins by dividing emergent properties into functional and non functional. Functional
emergent properties are defined as those which appear when the system is assembled as a whole (like
a properly assembled bike becoming a transportation device) as opposed to non-functional properties
like safety and reliability which are not directly related to the system’s function.
The focus of this section seems to be to get the reader to accept that emergent properties are
complex, but to be honest anyone who has ever tracked down a subtle bug knows that interrelating
systems can be almost impossible to anticipate.
Reliability is the key example put forward by Somerville, and three key influences are introduced,
specifically hardware reliability, software reliability and operator reliability. These three factors are
also described as interrelated, with hardware failures potentially causing further software failures, and
stress caused by failures causing operator errors etc. This interrelationship can cause initially minor
failures to become more problematic. Personally I can attest in at least system administration

2. problems, that the stress of failed systems can very rapidly lead you to take ill-considered actions
which make the situation worse (and leave you stuck there until 3 am).
The groundwork for the next section is also put in place here, with a discussion or the reliability of a
system being affected by context in which the system is used. The example provided is of some system
designed to operate in a certain temperature range which might be exceeded due to a broken air-
conditioner system. This sort of relationship, when unanticipated, can easily bring down otherwise very
reliable systems.
Air-conditioner problems are usually a nightmare for those in charge of computer server rooms. I
remember being onsite with one of my old customers had the power in their server room fail. They had
managed to get at least the critical servers back up by running extension cords across the corridor, and
more amusingly, placing a large number of fans at the door to the server room. Quite impressive,
albeit a gross violation of OH&S guidelines.
Sommerville finishes this section with a brief mention of security and safety as being particularly
complex emergent properties because they define things which should not happen rather than things
which should. This makes assessing these properties particularly difficult since there is no finite list to
test against.
Systems and their environment
We being this section by expanding on the air conditioner example, looking at how systems tens to
exist in an environment hierarchy. The building is in a street, which is in a town and so on, and
problems and trickle down (or sometimes up) that hierarchy. In addition to being affected by the
environment, it is also important to understand the affect a system is intended to have on its
environment. Once again, we can go back to the air conditioner, which is designed to decrease the
environment’s temperature, and so can only be properly assessed in this context.
Sommerville next approaches the organisational environment of a system, where it intersects with
human factors. Specifically highlighted are cases where a system might change work processes, de-skill
workers or change an organisation’s power structure. In each of these cases, the ‘environment’ may
actively resist the system, which opens out to the whole field of change management (which back in
the day I always used to confuse as just another name for configuration management).
Electromagnetic radiation is an interesting environment example raised at the very end of the section.
Being a software guy I don’t have much exposure to it, but it always amazes me when hardware guys
start worrying about interference between different bits inside a computer case etc. I guess it’s just

3. one of those things that never even crosses my mind, but must absorb a great deal of time for those
working on it.
System modelling
System modelling is introduced basically as the use of a block diagram to progressively break a system
down into sub components until it reaches a level of functional components (which are defined as
providing a single function). I guess if you have never seen a block diagram before this might be
insightful, but it really seems very obvious to me. There is also a brief discussion about using this
breakdown to make decisions about implementing various sub-systems in hardware vs software, which
presumably makes sense.
Functional system components
Somerville provides some clasifications for functional components by the type of work they perform.
Sensor components collect environmental information
Actuator components create some change in the environment
Communication components facilitate communication between the different sub-systems
Co-ordination components (surprisingly enough) co-ordinate the activities of other components
Interface components translate between other components
The key point at the end of this system is that most systems should include components of each type,
and if you find one is conspicuously missing from your design, you may well have missed something in
the design.
The system engineering process
The system engineering process described is roughly analogous to the standard waterfall software
process (which is apparently discussed further in the next chapter). The key differences between the
system process and the software process are listed as interdisciplinary involvement (meaning increased
scope for misunderstanding) and the increased difficulty/expense of rework (with software being very
valuable because of its relative flexibility).
Software is also presented, in this section, as ‘glue’ holding systems together, and being used to patch
up unforeseen problems which would be too expensive to solve at the hardware level. Sommerville
attributes changing system engineering requirements as the actual cause of many ’software failures’,
in particular the fairly famous Denver airport baggage system.
The rest of the section is basically a whirlwind tour of the components of the process itself, so I won’t
repeat the individual components here.

4. System requirements definition
Somerville breaks out three classes of requirements, abstract functional requirements (high level
specification of the functions of the system), system properties (non-functional requirements like
safety which affect all sub-systems) and the clumsily named but fairly obvious ‘characteristics which
the system must not exhibit’.
One key aspect of this process brought out by Somerville is to capture the underlying requirements at a
high level without presupposing a particular solution. You tend to see this done very poorly in a lot of
software RFTs and I assume it’s similar in system engineering. At the same time, Somerville also notes
that many problems to be solved as sufficiently complex that it’s practically impossibly to solve them
completely in advance (i.e. Wicked problems).
System design
Somerville breaks down the system design process into the following steps.
Partition requirements
Identify sub-systems
Assign requirements to sub-systems
Specify sub-system functionality
Define sub-system interfaces
These steps are ordered, but there is expected to be feedback between the steps with a view towards
iterating towards a final design, with significant rework expected in the early stages.
Somerville also highlights non-technical factors which may have an affect this process, including
organisational and political factors.
Sub-system development
The sub-system development level is where we may drop into a software engineering process to
develop the subsystem. This, of course, has it’s own requirements, design, etc phases.
Sommerville also mentions that subsystems may, in many cases, be ‘implemented’ through commercial
off the shelf software (COTS). This may require changes to the original design to accommodate a COTS
systems which does not exactly meet the original requirements.
Given that the sub-systems will generally be developed in parallel to reduce the overall system
development time, problems in one may require changes or work-arounds in another. Often software is

5. used here in a ‘glue’ capacity because it is generally less expensive to change (which is why it is
considered important to design software for change in these cases).
System integration
System integration is the process of joining all the separately developed sub-systems to create a single
working system. This is sometimes done in a single process at the end of the project (the ‘big bang’
approach), however Somerville recommends an incremental approach to reduce the scheduling
difficulty and identify problems earlier (and simplify tracking the problem down to a particular
module).
One key issue Sommerville raises here is the possibility of disputes between developers (or sub-
contractors) about the responsibility for problems which occur between sub-systems due to incorrect
assumptions. This is, obviously, more likely to occur in cases where the original design does not define
sub-system responsibilities in sufficient details.
System installation
Hopefully it’s pretty clear what this phase involves (although remember we’re talking systems which
would usually have a hardware component). Somerville lists a number of factors which can cause
system installation to be problematic/take longer than expected.
The system’s final environment may not match the assumed environment, and so may not operate as
expected.
Hostility from the users may cause problems (likely where the system changes the nature or reduces
the number of jobs in an organisation).
The system may need to work alongside an existing system (although hopefully this would be
anticipated and planned for). This introduces problems in cases where the new system can not be fully
installed without removing the old one.
Physical problems may become a factor, especially in buildings with limited space or restrictions
(historic buildings etc.)
The limit of my experience in installing hardware systems is at the server and network equipment
level, which never really exhibited any of these problems, so I don’t really have much else to add.
System operation
Somerville defines this system operation phase as the initial phase of operation, including training the
users, identifying and fixing where the specified requirements do not meet the business requirements,
and generally getting things up and running. With any system there is likely to be an initial transition

6. period with increased problems as users become accustomed to the new system etc, but this should
hopefully be minimised by appropriate planning and training.
System evolution
Most systems, and especially large ones, tend to be evolved over time rather than being repeatedly
replaced for cost reasons. That said, Somerville presents a number of reasons why system evolution
tends to be expensive.
Proposed changes must be carefully analysed from a technical and business perspective (I’m not really
convinced by this – how it is different to the initial system development)
Changes in one sub-system tend to have an effect on others, meaning that changes are usually required
to multiple sub-systems.
In cases where original design decisions were not appropriately documented and kept updated, the
team responsible for the changes may have to try to reverse engineer the reasons behind these
decisions.
As changes are made over time, the architecture of the system tends to become more complex, making
changes increasingly expensive over time.
Once again, I haven’t got much to add here, although I’ve worked on a number of legacy software
systems, I’ve never really been involved in evolution of anything with a hardware aspect beyond some
server hardware infrastructure.
System decommissioning
Systems with hardware component have a number of interesting considerations in the decommissioning
phase. Some sub-systems may need special disposal procedures for environmental reasons, but
hopefully these considerations are planned for in the original design. Software sub-systems don’t have
these considerations, however the migration of any data which needs to be retained into some other
system may require significant effort.
System procurement
The initial process for purchasing existing software systems is very similar to the engineering process
just presented, but obviously deviates at the sub-system design/development phases. The top level
requirements and design must still be undertaken to allow decisions between purchasing and building
to be made, and the integration and subsequent steps are also very similar.
Large systems are almost always composed of a range of existing and custom built components, and
software ‘glue’ is often used to allow the sub-systems to be integrated as required (which may increase
the total cost of purchasing components).

7. In cases where custom built sub-systems are required, this development is often contracted out, which
creates an issue request to tender, select tender, negotiate contract process to allow the contractor to
begin development. In many cases, this contact is then split into sub-systems and subcontracted to
other organisations, the results of which are then integrated by the prime contractor.
Conclusion
So, there we go. This one took a lot longer than the last, probably because the whole system level
perspective doesn’t interest me a great deal, making the motivation harder to find. I guess it is
important to have this perspective when working as a sub-contractor on projects of this sort of scale,
simply to understand how your work fits into the larger picture.
No Comments Yet