SYSTEMS ENGINEERING

MOOC 6 PRELIMINARY AND DETAILED DESIGN

PART 1
The previous stage (conceptual design) has resolved
what the business stakeholders want from the
system and what the key stakeholders think the
system needs to be able to do in order to deliver that
capability to the business.
The key stakeholders have articulated their
understanding of the system level requirements in
order to explain what the system needs to be able to
do, how well it needs to be able to do it, under what
conditions it needs to perform and what other
systems are involved in its performance of those
functions. Additionally, the key stakeholders have
decided how the function and performance of the
system will be proven by describing verification
approaches for each of the requirements.
The stakeholders will have identified viable systems
level solutions to their requirements and weighed up
the pros and cons of each of the options. It is critical
to remember that the pros and cons will include not
only the solutions ability to meet function and
performance requirements. Considerations need to
take account of procurement issues such as cost,
schedule and risk, lifecycle issues such as
sustainment and disposal costs, and capability
considerations such as training, personnel and
organisational issues. Based on this complex and
interrelated set of considerations, the stakeholder
group will have made a decision and chosen a
preferred solution.
If this solution is being provided by an external
organisation, a contract will have been negotiated
between the organisations. To differentiate, we will
refer to the organisation who needs a solution as the
customer and the organisation providing the solution
as the contractor. The contract can be thought of as a
description of respective responsibilities and risk
allocation.
If the solution is being provided by in-house
resources, systems engineering practise would still
highly recommend a contract-like agreement
between the in-house customer and the in-house
solution provider (in order to document the
requirements for the solution and agreement

between the parties).

Either way, once we have the agreement sorted out,
we concluded conceptual design with a review of
requirements and proposed solution just to confirm
our readiness to commence the more detailed design
activities.

We are about to embark on a process that will see

our logical solution (that is, a thorough
understanding of what we want to achieve)
translated into a physical solution (that is, a real and
usable solution). It it important to note that I am not
suggesting that the solution needs to be physical in
the true sense of the word. A piece of software, for
example, is not something we can touch or weigh or
feel but it may be a usable solution to a problem.
In this module, we will continue to use the house
example so this will be a physical solution in the true
sense of the word and in a systems engineering
context.

At the conclusion of the conceptual design phase, it

is highly likely (probably essential) that the designers
of the preferred solution would have at least a
preliminary idea of what the proposed solution was
going to look like.
They would have a good idea of how the system will
be broken down into system elements (or
subsystems), roughly how each of those elements
will contribute to the overall solution and how those
elements need to interact (or interface) with one
another.

For example, we would expect the designers of our

house to know that it will have an electrical
subsystem and will require a plumbing & drainage
subsystem. We would also expect to know that the
house would have bedrooms, living areas, a kitchen
and bathrooms. We probably also expect to have
draft drawings and plans available at this stage to
show us the conceptual design for the house.
The aim of preliminary design is to look in more
detail at each of those subsystems and determine
what each of the subsystems needs to do in order to
collectively satisfy our stakeholders (or, in this case,
the people who will own and/or live in the finished

product).
To perform preliminary design, we perform a
requirements analysis and allocation process. We
tend to start with an understanding of the
subsystems (as discussed above) and then look to
understand what requirements each of those
subsystems needs to meet in order for the system to
achieve its requirements. We will end up with a
hierarchy of requirements; system requirements
leading to subsystem requirements. Lets look at an
example. Assume we have a requirement at the
system level that promotes environmental
friendliness of our design. It is likely that this system
level requirement would lead directly to a
requirement for rain water to be collected and used
within the house system. Logically, rain water
harvesting, storage and use would be allocated to the
plumbing and drainage subsystem. The same system
level requirement may lead to the need to convert
sunlight into electrical energy for storage and use in
the house or even sale back to our energy company.
This set of subsystem requirements would be
allocated to the electrical subsystem (and may lead
to previously unknown requirements such as the
need to interface to the energy company in a certain
way.
As we are going through this process, we maintain
traceability within the requirements hierarchy so that
we always know where our requirements have come
from. In systems engineering, people often talk
about forward traceability and backward traceability
to give a feel for which direction within the hierarchy
we are talking about. Forward traceability is from the
system level requirements to the subsystem level
requirements. By ensuring forward traceability exists,
we can show our stakeholders that we have listened
to all of their requirements and all of their
requirements are being accounted for somewhere
within our design. Forward traceability is also very
important when trying to deal with changing
requirements. For example, using the previous
example, if the stakeholders decided that
environmental friendliness was no longer required,
we would be able to trace that requirement to the
rain water harvesting requirements in the plumbing
and drainage system (and equivalent electrical
requirements) and remove them from our
consideration.
Backward traceability is used to show how particular
subsystem requirements relate to system level
requirements. Backwards traceability helps us to
show that all of our subsystem requirements are
there for a reason (i.e. to contribute to system-level
function or performance). It helps us avoid what is

often called requirements creep where our

requirements progressively get more and more
capable than they need to be. Although this sounds
like a good thing, requirements creep progressively
takes our system away from where it was intended to
be. It can end up costing more than it needs to and
taking longer to realise. Also, when subsystems are
competing with the same finite resources,
requirements creep can cause some subsystems to
exceed their requirements whilst others are left
struggling. In these cases, we may end up with a
system that exceeds some function and performance
requirements whilst failing others. In systems
engineering, we are interested in meeting all of our
requirements, not exceeding some and failing others.
An example might be the design of a motor car and
the finite resource might be power from the engine.
If we let the air-conditioning subsystem requirements
creep so that the air-conditioner ends up having
requirements that far exceed what it needs to do, we
may end up with an air conditioner that uses more
than its fair share of energy from the car. We may
end up with the engine needing to work harder and
therefore using more fuel. In this case, we will have a
car with a fantastic air conditioner and terrible fuel
economy where what we were really after was a car
with an adequate air-conditioner and acceptable fuel
economy.
Backward traceability is important in protecting us in
these sorts of situations. Backward traceability also
helps us if we discover that one of our subsystems is
not able to meet its requirements. We are then able
to use traceability to find out what system level
requirements are at risk.
Another task that we need to perform during this
process is the identification of interfaces that need to
exist within our system and between our system and
its external environment. Remember these external
systems are outside our boundary but we still need
to interface with them if we are to be successful. For
example, our plumbing and drainage subsystem will
need to receive an input from the domestic water
supply and provide an output to the domestic
sewerage system. These are examples of external
interfaces. We identified these during conceptual
design. During preliminary design, we also need to
identify internal interfaces. For example, we may
designate the kitchen as a subsystem. The kitchen
subsystem will need interfaces from the electrical
subsystem and the plumbing and drainage subsystem
in order to perform its functions as a kitchen.
Interfaces come in many forms. For example we...

...might need to define physical interfaces like pipes

and wires, electrical interfaces like voltage levels,
hydraulic interfaces like water pressures and
electronic interfaces such as communications signals.
These interface requirements are critical to us and
will place additional constraints on our subsystems so
they are identified and defined during preliminary
design so we can take account for them when we
perform detailed design.
By the end of all of this work, we will know what all
of our subsystems are, what each of those
subsystems needs to be able to do and how those
subsystems interface or relate to one another. It is
now time to make some design decisions.

PART 2
When we look at each of the subystems in our
system, we will need to make some decisions on how
we are going to proceed in order to realise them.
Broadly speaking, we have 3 options. In some cases,
we may be able to go to the market and purchase the
subsystem off the shelf, sometimes an off the shelf
option needs to be modified in some way before
being suitable and in other cases there are no off the
shelf solutions and we need to develop a solution
from scratch.
Lets start by looking at off the shelf solutions. Using
our car example from earlier, if the engine was a
subsystem in our car design and we knew exactly
what the engine needed to be able to do from a
function, performance and interface perspective,
chances are, there would be some commercially
available engines that would fit the bill.
Commercially available subsystems offer a number of
advantages to us. They are likely to be known in
terms of their function and performance. That is,
there is likely to be some objective evidence in
existence that the subsystem does, in fact, perform in
accordance with the claims. Off the shelf items are
likely to be immediately available or available with
some known lead time making planning much easier.
Their costs are also going to be a known quantity.
Thinking lifecycle for a minute, they are likely to have
existing support systems such as tooling, test
equipment, spares, training and maintenance

support in place. These are all advantages of off the

shelf options, however there are some other things
to think about. The technical documentation
associated with Off the shelf systems is, in my
experience, something to look out for. If we are going
to use off the shelf subsystems, we must have access
to appropriate levels of technical detail to allow us to
integrate the subsystems, test and operate them and
train people in their use. If the documentation is
unsatisfactory, then this must be considered when
making design decisions. We also need to watch out
for obsolescence. We need to take account of the
technology used in the off the shelf items, market
size and technology stability. It is quite possible (in
fact I have experienced it) for off the shelf
subsystems to become unsupportable if they become
obsolete or the commercial market disappears for
some reason.
In some cases, we may come across an off the shelf
option that is almost suitable for consideration but
lacks one or two key attributes. If an off the shelf
option is close to meeting our requirements, it may
be possible to consider using the off the shelf option
and developing a modification to make it more
suitable. Modified off the shelf items have many of
the same advantages as pure off the shelf options
but we need to be careful about things like warranty
and support agreements. Making changes to an item
after it has been procured may render agreements
invalid. If we are to modify an item, we will need to
consider the modification a detailed design task and
develop the modification in a controlled manner. We
will discuss detailed design next. One other point to
note about modifying off the shelf items. In my
experience, people tend to drastically underestimate
the effort associated with modifying off the shelf
items. They also tend to assume that critical enablers
like detailed design data for the item will be
available. The point is the be careful not to
underestimate how much time, money and effort will
be involved and ensure that enablers like detailed
design data is available prior to making decisions
about modifying off the shelf items.
If there are no off the shelf items available to us, we
may need to consider designing and developing the
subsystems from the ground up. Naturally, this will
be an involved process which we will discuss soon
but remember also that we will need to think about
lifecycle issues and ensure that we establish throughlife support for anything that we design Systems
engineers need to work closely with our integrated
logistics support colleagues during this period to
ensure that our design is manufacturable,
supportable and disposable. More on that later. A key
advantage for the developmental approach is that

theoretically we should end up with the perfect

solution to our requirements. Unfortunately, I have
some bad news about that. Another observation
from my experience is that sometimes people will
reject an off the shelf option that is not quite perfect
and go down the developmental path. After a long
time and a lot of money, they may end up with a
developmental solution that is further away from
perfect than the off the shelf option they rejected a
long time before. Apart from the function and
performance shortfall, it would have taken them (and
their stakeholders) a lot of time and a lot of money to
find out. Please be sure that the developmental
approach is definitely the way to go before
proceeding down that path.
When we are looking at our subsystem design, it is
rare that we will happen on the best answer straight
away when it comes to how to design our
subsystems. We need to make sure that our
subsystems are going to perform in accordance with
the requirements that have been allocated to them
but we also have to make sure that when all of these
compliant subsystems are plugged together that we
will end up with a system that meets all of the
system level requirements. We need to explore and
exploit any room to move with respect to our
subsystems so that we arrive at the best possible
answer. Sometimes this process is referred to as
making optimal use of any design space available to
us.
Please note carefully that just because we refer to
this as design space does not mean that the
concept is applied only to trade-offs involving
physical space. The space we are referring to is room
to move. It might relate to bandwidth in a
communications system, processing power in a realtime computer system, electrical power, physical
space, weight and so on.
Lets go back to the car and the air-conditioner to
illustrate this point. Lets say the weight of the car
needs to be no greater than 1,225 kg. This may be a
system level requirement in the form of a constraint.
During the preliminary design, the systems guys will
make some decisions about how much of this 1225
kg each of the subsystems will be given. For example,
we might allocate 200 kg to the engine, 25 kg to the
aircon and 1,000kg distributed amongst the rest of
the subystems on the car. There will be other systemlevel constraints assigned to these two subsystems
such as physical size constraints but for this example,
the weight constraint is enough. Naturally the engine

will have a whole lot of other system level

requirements allocated to it that will result in derived
requirements. For example, a derived requirement
for the engine might specify how much power the
engine needs to be capable of delivering (to power
the car but also to power other systems like the airconditioner). Similarly, the air-conditioner will have
other requirements allocated to it such as how much
power it is allowed to consume in keeping the car at
a certain temperature under certain environmental
conditions.
If we give the air-conditioning experts all of their
requirements and we give the engine experts all of
their requirements and leave them to it, they will
develop their own subsystems independently of each
other. The air-conditioning people will come up with
a great design that is able to use all of the power and
weight allocated to them to create an air-conditioner
design that may exceed their requirements. The
engine people will do their best to do the same. This
sounds good because we will end up with a car that
meets it air-conditioning and engine requirements as
well as the overall weight requirement.
But what if the engine designers are struggling. They
might be able to build an engine that meets all of the
requirements but it is too heavy or fails to deliver
quite enough power. It would not make sense to
allow this to happen if the air-conditioning team
were able to meet their requirements with room to
spare. Consider for example if the air-conditioner
could be designed to be slightly lighter than the
allowed 25kg and still meet all other requirements. If
the air-conditioner could be designed to be only
20kg, the systems engineer could allocate that spare
5kg to the engine team and allow them to design an
engine that is 205 kg. Overall, the car will still weigh
1225kg but we will end up with an adequate airconditioner and an adequate engine in the process.
What if the air-conditioner design was not only
lighter by 5kg but also consumed less power from the
engine than initially thought. Now the engine does
not need to produce as much power as previously
and can weigh 205kg. By using some of the design
space available from the air-conditioner, we have
given the engine designers much needed room to
move.
What we end up with is an adequate air-conditioner
and an adequate engine that when integrated
together are able to deliver the required system level
performance. If we are not careful, we could have
ended up with a fantastic air-conditioner coupled

with a marginally compliant engine which integrate

to deliver a car that is underpowered and
overweight.
In systems engineering, we would much prefer to
deliver a system that meets all of its requirements
rather than a system that exceeds some
requirements and fails others. To do this, we must
keep an eye on any design space available to us and
make sure we are making best use of that space.

Eventually, after a lot of work, we will have decided

what all of the subsystems are, what they need to do,
how they will interrelate with each other and how
we will go about designing them. We will also be able
to show how the subsystem design contributes to
and supports system level requirements. We will
have thoroughly explored design options and any
available design space.
We will document all of this information in the form
of subsystem specifications and design decisions and
rationales. Once this has been completed, we will
stop, draw breathe and have a design review. This
design review is normally called the Preliminary
Design Review or PDR. At this review we look at all of
this information and confirm that we are ready to
proceed to detailed design. We will also ask the
decision makers to justify some of their decisions by
asking questions like When you came up with this
option, what other options did you look at? What
were the relative merits of the different options?
Have you considered lifecycle issues like
manufacturability, maintainability and disposability in
your decision making. These are all good questions
that are simply looking to confirm that the design
decisions made during preliminary design are robust
and defendable decisions. After all we are spending a
lot of time and effort on this exercise and will want to
make sure (as best we can) that we are going in the
best possible direction.
Once the design review is completed for each of the
subsystems, we can move onto detailed design.

From our PDR we have confirmed decisions about

how each of the subsystems will be realised. Some
will be procured off the shelf, others will be modified
and others will be designed from scratch. The
subsystems that are to be modified or developed
from the ground up will need to go through detailed
design activities. Even those subsystems that are
procured off the shelf will need to be integrated to...

...form the system. That integration effort is also part

of the detailed design process.
At the end of the detailed design process, we need to
be certain that we have a design that meets all of the
requirements set for the system by our stakeholders,
can be manufactured/produced/constructed, can be
supported or sustained throughout its operational
life and can be disposed of when the lifecycle comes
to an end. We have a lot of work to do.

If we considered the next phase in our lifecycle which

is the production and construction phase, we get a
hint as to what needs to be done during detailed
design and development. If we are dealing with
hardware (which is defined here as anything that is
not purely software) we have to come up with the
detailed design of the subsystem but we also need to
be able to specify how it is to be built. This
description includes parts lists, materials descriptions
and specifications, and construction and fabrication
processes. After all, the parts, materials and
construction processes will impact heavily on the
function and performance of the system and
therefore need to be carefully considered, designed
and specified.
Detailed design is a tough job and is the job that is
traditionally associated with professional engineers.
Professional engineers are expected to be able to
take a specification and determine a solution that
meets those requirements.
We will not cover professional engineering here but
it is important to emphasise that detailed design is
an iterative process. We design, build, test, learn and
repeat the process. We do this over and over until we
are satisfied with the result. Professional engineers
will use plenty of tools to help them do this. Some of
the common tools used include prototyping,
modelling, simulations, and reusing similar designs
that exist elsewhere.
For example, consider that we are trying to come up
with the detailed design of our kitchen. It is unlikely
that this design will be done only on paper. We will
need to consider the work flow in a kitchen so that
the kitchen works as a kitchen. For example, we
would not want to put the fridge on the opposite
side of the kitchen from where we prepare food. We
would not want to put the dishwasher a long way
from where our cutlery and crockery is stored. We
need to consider where services from our other
subsystems such as cold water, hot water, gas,

10

drainage and power can be provided. Should the

kitchen design constrain the electrical and plumbing
subsystems or should the kitchen be constrained? In
all likelihood, it will be a bit of both but these are the
sorts of things we are thinking about in detailed
design.

Coming back to the kitchen, we will go and see other

kitchens in showrooms and display homes, we will
probably make use of software tools to produce
layout drawings to explore things like workflow, we
will select major components in the kitchen such as
stoves, ovens, sinks, dishwashers and so on.
We go through this process with all of the
subsystems in our design and confirm that the
integration of all of the subsystems is going to work
for us at the system level.
Once we have completed this process and
documented the results, we are ready to do a final
review prior to construction and production. We will
call this review the Critical Design Review or CDR.
The role of CDR is to confirm that the detailed design
is complete and has been appropriate documented.
We will ask similar questions to what we asked at
PDR albeit at a different level of focus. We will be
looking for evidence that the design process has
been rigorous such as consideration of design
alternatives, selection of preferred approaches for
sound reasons, solid documentation discipline and
readiness for construction and production.

11