What is a system?

A purposeful collection of inter-related components working together to achieve some common objective. A system may include software, mechanical, electrical and electronic hardware and be operated by people. System components are dependent on other system components The properties and behaviour of system components are inextricably inter-mingled

Ian Sommerville 2006

Software Engineering, 8th edition. Chapter 2

Slide 1

Examples of emergent properties

P p t roe r y Vom l e u Rl bi y eia lit S rit ec u y De ipo s t n cr i T he l m of sys (h t t l spac c up re dependhow vo a te t e oa ue m e oc ie va s d) i i ng on t e h c oponen mli aear m t as b es r r angedc s e and onnec t . ed S t meia lit dependsm ys r l bi y e ono ponenab y bue c tr li ilit t un t in rai sc e xpec te c on an ed t c au news ofauea t r f e a ect rli ilt oft e te . s e t ypef il r nd eor ff t hee abi y h sys he m T s rit ft sye (itabi y t r istaa k)sa c o exr t t a heec u o y he stm s ilt o es ttc i ml poperh t p y c anno asymasu . A csm be i t be il e r e ed tt k ay dev t a er noni ip ed by a sed tw e ta t c at h t e h sye d i r and m de t bui ns f s tm e gne s ay f s s o ea lt-i aegua r . ds T s p rt r fl c how its t fi a p l mw t eysm hi r ope e e t y s easy o x r e it h s t onc e been i ob h e ithas ds over t depends b g l t i ic e d. I onei n ab d s t e p l mac c e c m e o agno r e , e h ob s t o ponen s he t s t tae auy and i orr p e ese ponen ha r f lt m fy e l od ac t h co m ts . T s p rt r fl c how its t s thysm It hi r ope e e t y s easy o u es t . depend te hnl i e e s on c i a t he c sye c s tm ompon sopeor andope ng env en e t , it ns rt s a it s r ti a ir m t on .

Rpa ilit e i rab y

Uabi y s ilt

Ian Sommerville 2006

Software Engineering, 8th edition. Chapter 2

Slide 2

Types of emergent property

Functional properties
These appear when all the parts of a system work together to achieve some objective. For example, a bicycle has the functional property of being a transportation device once it has been assembled from its components.

Non-functional emergent properties

Examples are reliability, performance, safety, and security. These relate to the behaviour of the system in its operational environment. They are often critical for computer-based systems as failure to achieve some minimal defined level in these properties may make the system unusable.

Ian Sommerville 2006

Software Engineering, 8th edition. Chapter 2

Slide 3

Influences on reliability

Hardware reliability
What is the probability of a hardware component failing and how long does it take to repair that component?

Software reliability
How likely is it that a software component will produce an incorrect output. Software failure is usually distinct from hardware failure in that software does not wear out.

Operator reliability
How likely is it that the operator of a system will make an error?

Ian Sommerville 2006

Software Engineering, 8th edition. Chapter 2

Slide 4

The shall-not properties

Properties such as performance and reliability can be measured. However, some properties are properties that the system should not exhibit

Safety - the system should not behave in an unsafe way; Security - the system should not permit unauthorised use.

Measuring or assessing these properties is very hard.

Ian Sommerville 2006

Software Engineering, 8th edition. Chapter 2

Slide 5

Systems engineering

Specifying, designing, implementing, validating, deploying and maintaining socio-technical systems. Concerned with the services provided by the system, constraints on its construction and operation and the ways in which it is used.

Ian Sommerville 2006

Software Engineering, 8th edition. Chapter 2

Slide 6

The system engineering process

Usually follows a waterfall model because of the need for parallel development of different parts of the system
Little scope for iteration between phases because hardware changes are very expensive. Software may have to compensate for hardware problems.

Inevitably involves engineers from different disciplines who must work together
Much scope for misunderstanding here. Different disciplines use a different vocabulary and much negotiation is required. Engineers may have personal agendas to fulfil.

Ian Sommerville 2006

Software Engineering, 8th edition. Chapter 2

Slide 7

The systems engineering process

Ian Sommerville 2006

Software Engineering, 8th edition. Chapter 2

Slide 8

Inter-disciplinary involvement
Software eng in eerin g Electr nic o eng in eerin g Mech an ical eng in eerin g

Stru ctu r al eng in eerin g

A s y stems TC eng in eerin g

User in terface d es ig n

Civ il eng in eerin g

Electrical eng in eerin g

Architectu r e

Ian Sommerville 2006

Software Engineering, 8th edition. Chapter 2

Slide 9

System requirements definition

Three types of requirement defined at this stage

Abstract functional requirements. System functions are defined in an abstract way; System properties. Non-functional requirements for the system in general are defined; Undesirable characteristics. Unacceptable system behaviour is specified.

Should also define overall organisational objectives for the system.

Ian Sommerville 2006

Software Engineering, 8th edition. Chapter 2

Slide 10

System objectives

Should define why a system is being procured for a particular environment. Functional objectives
To provide a fire and intruder alarm system for the building which will provide internal and external warning of fire or unauthorized intrusion. To ensure that the normal functioning of work carried out in the building is not seriously disrupted by events such as fire and unauthorized intrusion.

Organisational objectives

Ian Sommerville 2006

Software Engineering, 8th edition. Chapter 2

Slide 11

System requirements problems

Complex systems are usually developed to address wicked problems

Problems that are not fully understood; Changing as the system is being specified.

Must anticipate hardware/communications developments over the lifetime of the system. Hard to define non-functional requirements (particularly) without knowing the component structure of the system.
Software Engineering, 8th edition. Chapter 2 Slide 12

Ian Sommerville 2006

Spiral model of requirements/design

Ian Sommerville 2006

Software Engineering, 8th edition. Chapter 2

Slide 13

System modelling

An architectural model presents an abstract view of the sub-systems making up a system May include major information flows between sub-systems Usually presented as a block diagram May identify different types of functional component in the model

Ian Sommerville 2006

Software Engineering, 8th edition. Chapter 2

Slide 14

Burglar alarm system

Ian Sommerville 2006

Software Engineering, 8th edition. Chapter 2

Slide 15

Sub-system description

S u-sy m b s te M v en e s o em t sn ors D o s n rs o r e so A rm o tro la c n ller S n ire V ice nt e ze o sy h si r T lepo e cll r e hn a e

D scr tion e ip D c mom n inth ro s mn or d yth syse et e ts ve e t e om o it e b e t m D c do o en ginth e ter ald o f th b ildi g et e o r p in ts e x n o rs o e u n C n ls h o e io o h es stem o tro t e p rat n f t y E it sa a di le w rn gwh a in d r is u ec m n u b a in en n tru e ssp ted S n e esav ice e geg in t h lo tio ot h ssp ted tru e y th siz o m ssa iv g e ca n f e u ec in d r Mke ex n l ca on tify s rity th p liceet . a s ter a lls t o ecu , e o , c

Ian Sommerville 2006

Software Engineering, 8th edition. Chapter 2

Slide 16