Chapter 3: System Engineering

1
Chapter 3 System Engineering

• 3.1 Introduction
• Software does not usually operate in isolation
  it is usually part of a computer based system.
• A computer based system can include the
  following
• Software computer programs in a variety of
  languages for a variety of purposes (e.g. OS),
  data files
• Hardware CPU, memory, standard I/O devices,
  specific I/O devices (card reader, sensors,
  motors, electro-magnetic switches, pumps etc.)
• People the users (with a variety of roles and
  competencies)
• Legacy Databases usually large and which cannot
  be modified because used by many other systems
• and must operate in a given environment with
  specific constraints
• e.g. banking procedures, security guidelines,
  safety-critical requirements
• and must be developed following certain
  procedures

2

• e.g. quality standards (e.g. ISO 9001), industry
  specific requirements (safety, security
  procedures and guidelines)
• Given a problem, a solution might include many
  elements which will probably interact with each
  other in a complex manner.
• A System Engineer helps to translate a customer's
  needs into a model of the future system that
  makes use of many elements (e.g. people, SW, HW,
  safety procedures for a railway signalling
  system)
• Computer based system engineering is a very
  complex problem solving activity which requires a
  high level of expertise.
• The desired systems functions must be uncovered,
  analysed and allocated to the individual system
  elements (e.g. to SW or HW?)
• The computer based system engineer (AKA system
  analyst) begins with the customer's defined
  goals and constraints and derives a model of
  function, performance, interfaces and information
  structures that can be allocated to each element.

3

• As always, the problem is initially rarely well
  defined the boundaries of the system are unclear
  (what is part of the system, what is not?) and
  the functionalities, performance required and
  constraints must be uncovered by the system
  analyst.
• Uncovering the exact requirements of the system
  in a system specification can take a very long
  time. It is essential that this task be performed
  very well (avoid nasty surprises later on).
• For example, from a vague requirements that, in
  an automatic manufacturing system (assembly line
  robot) the system should
• 'respond quickly if a tray of components is
  empty'
• the system engineer must clarify the following
• what will indicate an empty tray to the robot?
  (if, as is likely, a sensor is used what if the
  sensor fails, consequences (safety, damage?), how
  to prevent failure (double system, fail safe,
  maintenance guidelines etc.)
• what does 'quickly' means? This is very ambiguous
  and can impact cost hugely (5s, 1s, 0.1s, 0.01s?
  on average or always? what is the worst allowed
  case?)

4

• What should the response be? (stop everything?
  alarm who, how? Log keeping?)
• How do resume normal operation from this state?
  (automatically?HW or SW? human intervention?)
• The list of questions to be answered for a large
  system can be very, very long. Then the system
  analyst must assign responsibilities to the
  sub-systems (HW, SW, people etc.) and design the
  interfaces between the sub-systems...
• 3.2 System Modelling
• By modelling the system under consideration the
  system analyst hopes to
• obtain a better understanding of the problem
• be able to communicate better with all concerned
  (users/customers, hardware/software people,
  safety/security experts, team members)
• Modelling is the central activity in all
  engineering disciplines.
• To construct a model of the intended system, the
  system analyst should consider
• Assumptions are needed to reduce the complexity
  of the overall model and eventual system. All
  assumptions must be documented.

5

• Abstraction the model is abstract, not all
  details are shown, ease of communication
• Limitations the scope of the system must be
  limited in accordance with the customer's needs
  (e.g. performance, functionality, security
  limitations)
• Constraints HW, SW, people, databases,
  procedures constraints
• Preferences the customer may have a fair idea
  on how the system should implemented or design
  (e.g. initial internal investigation by the
  customer)
• All these aspects must be taken into account to
  construct a model of the intended system.
• Models are a mixture of diagrams and accompanying
  documentation using technical notations and
  terminology.
• Of course, system model, while central, is not
  the only activity during system analysis, other
  task include
• identifying the customer's needs
• evaluate the system concept for feasibility
• economic analysis
• allocate functionalities to sub-systems (HW, SW,
  people?)
• establish estimates and schedules
• produce a detailed system specification

6

• 3.3 Identification of Needs
• Remember the customer and users are likely to
  be different both parties must be consulted
  (e.g. automatic nationwide public train booking
  system)
• Trying to understand what it is that is required
  and determine what will be the responsibilities
  of the individual sub-systems
• Can be performed concurrently with initial system
  modelling
• 3.4 Feasibility Study
• Is part of risk analysis.
• Different types of feasibility must be
  considered
• financial feasibility 'can we afford it?'
• technical feasibility 'can it be done?'
• legal feasibility 'any legal problems?'
• Alternatives to the proposed system must be
  listed and evaluated.
• Typical technical feasibility matters are
• development risk can the system be
  designed/implemented with the necessary functions
  and performance within the identified constraints?

7

• resource availability skilled staff shortages,
  physical resources
• technology is the technology proven? are we not
  reaching the limits of what can be done?
• Misjudgement at the feasibility stage can be
  disastrous (embarking on the development of a
  large system which subsequently is found to be
  infeasible for economical or technical reasons
  can be very, very costly)
• 3.5 Economic Analysis
• Cost-benefits Analysis an assessment of the
  economic justification of a computers based
  system.
• 3.6 Responsibilities Allocation
• Enormous scope for choice, responsibilities can
  be allocated to people, HW or SW for example.
• Has complex costs implication.
• Performance requirements must be taken into
  account.

8

• 3.7 Scheduling and Estimating
• Even more difficult for complex systems composed
  of various disparate entities.
• 3.8 System Specification Document
• The main document of the system analysis phase.
• The system specification is the starting point
  for
• hardware engineering
• software engineering
• 'human' engineering (e.g. recruiting, training)
• The specification should
• detail the context in which the system will
  operate
• detail the intended functions
• specify the performance and constraints attached
  to the system
• allocate responsibilities to each sub-system and
  their interfaces
• give schedule and costs estimates

9

• The actual format, and level of details, of the
  system specification will vary according to
• customer's wishes
• tradition
• industry requirements
• The model of the intended system will be given
  using diagrams and specific notation.
• 3.9 Summary
• System engineering is an interdisciplinary
  activity.
• System engineering is a crucial step if the
  initial solution is found not to work down the
  line it will be difficult to correct.
• System engineering may, itself, be composed of
  many cycles around the Spiral model.
• Risk analysis and formal technical reviews are
  all very important at this stage.

10

• The system specification is unlikely to be
  totally unchanged as the project progress. We
  must
• monitor changes
• study the impact of change (notably with respect
  to initial assumptions)
• document the approved changes
• communicate changes to all concerned
• Sometimes introducing computer based systems to
  new areas is difficult (social issues, e.g.
  e-voting system)
• For the rest of the course we focus on technical
  software engineering issues only