Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Po
w e
r Wa te
r
cyu m
rtems
yL y
t
isy
g
h m
item
nsy m
gsytsem
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 Slide 15
Human and organisational factors
● Process changes
• Does the system require changes to the work
processes in the environment?
● Job changes
• Does the system de-skill the users in an environment or
cause them to change the way they work?
● Organisational changes
• Does the system change the political power structure in
an organisation?
S V
iren sy
noi
c
e T
e
lph
o
n
e
thszr carc
oE
x
t
e
r
n
a
n
o
l
cl
t
r
e
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 Slide 18
Component types in alarm system
● Sensor
• Movement sensor, door sensor
● Actuator
• Siren
● Communication
• Telephone caller
● Co-ordination
• Alarm controller
● Interface
• Voice synthesizer
C
o
nt
r
o
l
e
r C
o
n
t
ro
l
e
r
architecture
Ac
sy o u
n
et
i
n
g
m A i
n
f
.s
y
tmc
tiv
tsy
le
o
g
im
n
g c
ss
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 31. Slide ##
Functional system components
● Sensor components
● Actuator components
● Computation components
● Communication components
● Co-ordination components
● Interface components
Sy
v
o lu
Sub-
de Sys
veinteg
lopm
inst
tion
Syst
ation
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 Slide 26
Softw
ar
e Elec
onic
enginM
engi
en
Inter-disciplinary involvement
Struct
alA
T
C
enginUs
sy
engi
de
Ci
vilElec
enginAr
ch
e
engi
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 Slide 27
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
sA S
p
e
c
i
f
u
ny
s
u
b
-
t
o
n
ay
s
t
e
m
l
iD
e
f
i
ns
u
b
-
t
e
r
f
a
cy
s
t
em
©Ian Sommerville 2004
stoignrbe-qsuyirtem
nts
Software Engineering, 7th edition. Chapter 2 Slide 32
System design problems
● Requirements partitioning to hardware,
software and human components may involve a
lot of negotiation
● Difficult design problems are often assumed to
be readily solved using software
● Hardware platforms may be inappropriate for
software requirements so software must
compensate for this
mptn s C
syh otmse I
s
u
f
oe r
biqdu es
t sCuh
p o l s
e
ir
xBeisstpronqgkuesirysydtem smIstuoernqduest Stenldctr N
ecgnortiaceLedtvcolntpram
cenfotr
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 2 Slide 41
Procurement issues
● Requirements may have to be modified to match
the capabilities of off-the-shelf components
● The requirements specification may be part of
the contract for the development of the system
● There is usually a contract negotiation period to
agree changes after the contractor to build a
system has been selected
r l
r
S
u
b
-co
n
tracto
r1S
u
b
-con
tracto
r2S
u
b
-co
©Ian Sommerville 2004
n
tracto
r3
Software Engineering, 7th edition. Chapter 2 Slide 44
Key points
● System engineering involves input from a range
of disciplines
● Emergent properties are properties that are
characteristic of the system as a whole and not
its component parts
● System architectural models show major sub-
systems and inter-connections. They are usually
described using block diagrams