lecture 05: requirements engineering...– 05 – 2015-05-11 – main – softwaretechnik /...
TRANSCRIPT
– 05 – 2015-05-11 – main –
Softw
aretech
nik
/Softw
are-E
ngin
eering
Lectu
re05:
Req
uirem
ents
Engin
eering
20
15
-05
-11
Prof.Dr.Andreas
Podelski,
Dr.
BerndW
estp
hal
Albert-L
udwigs-U
niversitat
Freib
urg,
Germ
any
Yo
uA
reH
ere
– 05 – 2015-05-11 – main –
2/90
Co
urse
Co
nten
t(O
rigin
al
Pla
n)
– 05 – 2015-05-11 – main –
3/90
L1:
20.4.,Mo
Intro
ductio
nT
1:
23.4.,
Do
L2:
27.4.,Mo
L3:
30.4.,
Do
L4:
4.5.,Mo
Develo
pment
Process,
Metrics
T2:
7.5.,
Do
L5:
11.5.,Mo
-14.5.,
Do
L6:
18.5.,Mo
L7:
21.5.,
Do
-25.5.,Mo
-28.5.,
Do
Requirem
ents
Engineerin
g
T3:
1.6.,Mo
-4.6.,
Do
L8:
8.6.,Mo
L9:
11.6.,
Do
L10:
15.6.,Mo
Desig
nModellin
g&
Analysis
T4:
18.6.,
Do
L11:
22.6.,Mo
L12:
25.6.,
Do
L13:
29.6.,Mo
Implem
entatio
n,
Testin
gT
5:
2.7.,
Do
L14:
6.7.,Mo
L15:
9.7.,
Do
L16:
13.7.,Mo
Form
alVerifi
cation
T6:
16.7.,
Do
L17:
20.7.,Mo
TheRest
L18:
23.7.,
Do
Co
nten
ts&
Go
als
– 05 – 2015-05-11 – Sprelim –
4/90
Last
Lectu
re:
•process
models:
V-M
odell
XT,ag
ile(X
P,Scru
m);
process
metrics:
CMMI,SPICE
This
Lectu
re:
•Educa
tionalObjective
s:Capabilities
forfollow
ingtasks/q
uestion
s.
•What
isreq
uirem
ents
engineerin
g(R
E)?
•Whyisitim
portan
t,whyisithard
?
•What
arethetw
o(th
ree)most
relevantartefacts
produced
byREactivities?
•What
isadictio
nary?
•What
aredesired
properties
ofreq
uirem
ents
specifi
cation(documents)?
•What
arehard
/soft/
open/tacit/
functio
nal/
non-fu
nctio
nal
requirem
ents?
•What
isreq
uirem
ents
elicitation?
•Which
analysis
techniquewould
youreco
mmendin
which
situatio
n?
•Content:
•motivatio
nan
dvo
cabulary
ofreq
uirem
ents
engineerin
g,
•thedocuments
ofreq
uirem
ents
analysis,
anddesired
properties
ofRE,
•guidelin
esfor
requirem
ents
specifi
cationusin
gnatu
rallan
guag
e
– 05 – 2015-05-11 – Sreintro –
6/90
Thehard
estsin
glepart
ofbuildingasoftw
aresystem
isdecid
ingprecisely
what
tobuild.Nooth
erpart
ofthecon
ceptual
work
isas
diffi
cultas
establish
ingthedetailed
technical
requirem
ents
...Nooth
erpart
ofthe
work
socrip
ples
theresu
ltingsystem
ifdon
ewron
g.Nooth
erpart
isas
diffi
cultto
rectifylater.
F.P.Brooks
( Brooks,
1995)
Req
uirem
ents
an
dR
equ
iremen
tsA
na
lysis
– 05 – 2015-05-11 – Sreintro –
7/90
require
ment–(1)
Acon
dition
orcap
ability
need
edby
auser
tosolve
aprob
lemor
achieve
anob
jective.(2)
Acon
dition
orcap
ability
that
must
bemet
orpossessed
byasystem
orsystem
compon
entto
satisfyacon
tract,stan
dard
,specifi
cation,or
other
formally
imposed
documents.
(3)Adocumented
representation
ofacon
dition
orcap
ability
asin
(1)or
(2).
IEEE
610.12( 1990)
require
ments
analysis
–(1)
Thepro
cessof
studyin
guser
need
sto
arriveat
adefinition
ofsystem
,hard
ware,
orsoftw
arereq
uirem
ents.
(2)Thepro
cessof
studyin
gandrefi
ningsystem
,hard
ware,
orsoftw
arere-
quirem
ents.
IEEE
610.12(1990)
Th
eR
equ
iremen
tsE
ng
ineerin
gP
rob
lem
– 05 – 2015-05-11 – Sreintro –
8/90
(Σ×A)ω
allco
mputatio
npathsover
Σand
A,aka
.ch
aos
require
ments,
all
these
computatio
npathsare
allo
wed
onesoftw
arewhich
satisfi
esthe
requirem
ents
•Require
ments
engineerin
g:
Describ
e/specify
theset
oftheallo
wedcom
putation
path
s.
•Softw
aredeve
lopment:
Create
onesoftw
areS
whose
computation
path
sJS
Kare
allallow
ed.
•Note:differen
tprogram
sin
differen
tprogram
minglan
guag
esmay
alsodescrib
eJS
K.
•Ofte
nallo
wed:an
yrefinementof
(→later;
e.g.allow
interm
ediate
transitio
ns).
Pu
rpo
seso
fth
eR
equ
iremen
tsS
pecifi
catio
n
– 05 – 2015-05-11 – Sreintro –
10/90
•co
ordinatio
nwith
thecusto
mer
(orthemarketin
gdepartm
ent,
or...)
•notproperly
clarified
/specifi
edreq
uirem
ents
arehard
tosatisfy
—mism
atch
eswith
custo
mer’s
need
sturn
outin
opera
tionthelatest
→additio
naleffort
•desig
nan
dim
plementatio
n,
•programmers
may
use
differen
tinterp
retatio
nsofunclear
requirem
ents
→diffi
cult
integratio
n
•theuser’s
manual,
•iftheuser’s
manualauthoris
notdevelo
per,
he/
shecanonly
describ
ewhatthesystem
does,
notwhatitshould
do( “nomore
bugs,
eve
ryobserva
tionis
afeature”)
•prep
arationoftests,
•with
outadescrip
tionofallo
wed
outco
mes,
testsare
randomly
searchingforgen
ericerro
rs(like
crashes)
→syste
matic
testin
gim
possib
le
•acce
ptance
bycusto
mer,
resolvinglater
objectio
nsor
regress
claims,
•atdelivery
timeunclear
wheth
erbeh
avio
uris
anerro
r(develo
per
need
sto
fix)
orcorrect
(custo
mer
need
sto
accep
tandpay)
→nasty
disp
utes,
additio
naleffort
•re-use,
•re-u
sebased
onre-rea
dingtheco
de→
riskofunexp
ecte
dch
anges
•later
re-im
plementatio
ns.
•thenew
softw
aremay
need
toadhere
toreq
uirem
ents
oftheold
softw
are;ifnotproperly
specifi
ed,thenew
softw
areneed
sto
bea1:1
re-implem
entatio
noftheold
→additio
naleffort
An
dW
ha
t’sH
ard
Ab
ou
tT
ha
t?
– 05 – 2015-05-11 – Sreintro –
11/90
On
ceA
ga
in:
Th
eS
oftw
are
Peo
ples’
View
on
Req
uirem
ents
– 05 – 2015-05-11 – Sreintro –
12/90
Exa
mple:children
’sbirth
day
presentreq
uirem
ents
(birth
day
onMay,
27th).
•“Ich
will’n
Pony!”
(“Iwantapony!”)
•Commonsense
understa
nding:
http://pixabay.com/en/pony-horse-animal-ride-pasture-368975/ — CC0Public Domain✔
“Ford Mustang on Felixstowe beach” bySteve Arnold — CC BY 2.0✘
Thatis:
we’re
lookin
gfor
onesm
allhorse
-likeanim
al;wemay
(guided
byecon
omic
concern
s,taste,
etc.)ch
oose
exactbreed
,size,
color,shap
e,gen
der,
age(m
aynot
evenbeborn
today,
only
need
sto
bealive
onbirth
day)...
•Softw
areEngineerin
gundersta
nding:
Wemay
giveeve
rythingas
longas
there’s
aponyin
it:
•aherd
ofponies,
•awhole
zoo(if
ithas
apon
y),
•...
AB
itM
ore
Ab
stract:
So
ftwa
revs.
‘Rea
lW
orld
’R
equ
iremen
ts
– 05 – 2015-05-11 – Sreintro –
13/90
Inotherwords:
•co
mmonsense
understa
nding:choose
from“∅
∪req
uire
ments”
•softw
areengineerin
gundersta
nding:
choose
from“chaos∩req
uire
ments”
•S
=“xisalw
ays0”
isa(sem
i-inform
al)softw
aresp
ecifi
catio
n.
•It
denotes
allim
aginable
softw
areswith
anxwhich
isalw
ays0:
JS
K=
{S|∀σ0
α1
−−→σ1
α2
−−→σ2···
∈JS
K∀i∈N
0•σi|=
x=
0}
•Thesoftw
arespecifi
cation“tru
e”(“I
don
’tcare
atall”)
denotes
chaos.
•Writin
gareq
uirem
ents
specifi
cationmean
sco
nstra
iningch
aos,
ordescrib
ing(a)
subset(s)
ofchaos.
•Desig
n/Im
plementatio
nmean
s:choosin
gfrom
theob
tained
subset(s)
ofchaos.
An
dW
ha
t’sH
ard
Ab
ou
tT
ha
t?
– 05 – 2015-05-11 – Sreintro –
14/90
Exa
mple:custom
ersays
“Ineed
acom
putation
ofsquare
numbers,
i.e.f:x7→
x2”
•W
e’ve
gotoptio
nsto
choose
from:
1int
sq(
int
x)
{2
return
x∗
x;
3}
1unsigned
int
2sq
(unsigned
short
x)
{3
return
x∗
x;
4}
1#in
clu
de
<gm
p.h>
2void
sq(
mpzt
x)
{3
mpzmul(
x,
x,
x);
4}
→1h,100e
→2h,200e
→4h,400e
with
erro
rs:sq
(231−
1)
=1
notdefinedfor216
usagenon-triv
ial:
1mpzt
x;
2mpz
init(x);
3mpz
set
si(
x,
2147483647
);
4sq
(x);
5fprin
tf(
std
out,
6”%
i−>
”,
2147483647
);
7mpz
outstr
(std
out,
10,
x);
8fprin
tf(
std
out,
”\n”
);
•Okay,
custo
mersaid:inputvalu
esare
from{0,...,27}.
•Still,
we’ve
gotop
tions...:
1unsigned
int
sq(
unsigned
short
x)
{2
unsigned
int
r=
0,
n;
3fo
r(n
=x;
n;−−n)
{4
r+=
x;
sle
ep(1);
5}
6return
r;
7}
AF
irstS
um
ma
ry
– 05 – 2015-05-11 – Sreintro –
15/90
Agoodreq
uirem
ents
specifi
cation
(i)avo
idsdisp
uteswith
thecustom
erat
(mileston
esor)
delivery
time,
(ii)preven
tsusfrom
doin
gtoolittle
/toomuch
work,
(iii)isecon
omic
(seebelow
).
There’s
atra
deoffbetw
eennarro
wness
andopenness:
•theop
timum
wrt.
(i)and(ii)
isthecom
plete,
perfect
software
product
asneed
edby
thecustom
er(m
ostnarrow
):
•nodisp
utes;
amountofwork
need
edisclear.
Draw
back
:hard
/expensive
toget,
that’s
bad
for(iii).
•Thecheap
est(not:
most
econom
ic)req
uirem
ents
specifi
cationis“d
owhat
youwant”
(most
open).
Draw
back
:high
riskvalu
efor
not
doin
g(i)
and(ii).
•Bein
gtoonarro
whas
anoth
ersevere
draw
back
...
...N
am
ely:R
equ
iremen
tsS
pecifi
catio
nvs.
Desig
n
– 05 – 2015-05-11 – Sreintro –
16/90
•Idealised
viewsadvocate
astrict
separa
tionbetw
eenrequire
ments
(“what
isto
bedon
e?”)anddesig
n(“h
oware
things
don
e?”).
•Ratio
nale:Fixin
gtoomuch
ofthe“h
ow”tooearly
may
unnecessarily
narrow
dow
nthedesign
space
andinhibitnew
ideas.
There
may
bebette
r(easier,
cheap
er,...)
solution
sthan
theon
eim
agined
first.
•In
practice,thissep
arationisoften
neith
erpossib
lenor
advisab
le:
•Existin
gcomponents
should
beconsid
ered.(→
re-use)
•Custo
mer,
(safety)reg
ulatio
ns,
norm
s,etc.
may
require
aparticu
larsolutio
nan
yway.
•It
isoften
usefu
lto
reflect
real-w
orld
structu
resin
thesoftw
are.
•In
some(low
risk)cases
itmay
bemore
eco
nomica
lto
skip
requirem
ents
analysis
and
directly
code(an
ddocument!)
aproposal.
•Complex
systemsmay
need
aprelim
inary
syste
mdesig
nbefore
bein
gab
leto
understan
dan
ddescrib
ereq
uirem
ents.
•Oneway
toch
eck
areq
uirem
ents
specifi
cationfor
consisten
cy(realisab
ility)isto
think
throughat
leastonepossib
lesolutio
n.
•Thereq
uirem
ents
specifi
cationshould
answ
erquestio
nsarisin
gdurin
gdevelo
pment.
Req
uirem
ents
En
gin
eering
:B
asics
– 05 – 2015-05-11 – main –
17/90
Req
uirem
ents
An
alysis
Ba
sics
– 05 – 2015-05-11 – Sre –
18/90
•Note:an
alysisin
thesen
seof“findingoutwhattheexact
require
ments
are”.
“Analysin
gan
existingreq
uirem
ents/
feature
specifi
cation”→
later.
Inthefollow
ingweshall
discu
ss:
(i)docu
ments
ofthereq
uirem
ents
analysis:
•dictio
nary,
•req
uirem
ents/
feature
specifi
cation.
(ii)desired
propertie
sof
•req
uirem
ents
specifi
cations,
•req
uirem
ents
specifi
cationdocuments,
(iii)kindsof
requirem
ents
•hard
andsoft,
•open
andtacit,
•functio
nal
andnon-fu
nctio
nal,
*sigh*
(iv)(a
selectionof)
analysis
tech
niques
Do
cum
ents
of
the
Req
uirem
ents
An
alysis:
Dictio
na
ry
– 05 – 2015-05-11 – Sre –
19/90
•Requirem
ents
analysis
should
bebased
onadictio
nary
.
•A
dictio
nary
comprises
defi
nitio
nsan
dclarifi
cationsofterm
sthat
arerelevan
tto
the
project
andofwhich
differen
tpeople
(inparticu
larcusto
mer
anddevelo
per)
may
have
differen
tunderstan
dingsbefore
agreein
gonthedictio
nary.
•Each
entry
inthedictio
nary
should
provid
ethefollow
inginform
ation:
•term
andsyn
onym
s(in
thesen
seofthereq
uirem
ents
specifi
catio
n),
•meaning(defi
nitio
n,exp
lanatio
n),
•delim
inatio
ns(w
here
notto
use
this
terms),
•va
lidness
(intim
e,in
space,
...),
•denotatio
n,uniqueiden
tifiers,
...,
•openquestio
nsnotyet
resolved
,
•relatedterm
s,cro
ssreferen
ces.
Note:entries
forterm
sthat
seem
“crystal
clear”at
first
sightare
notunco
mmon.
•Allwork
onreq
uirem
ents
should,as
faras
possib
le,bedoneusin
gterm
sfro
mthe
dictio
nary
consisten
tlyan
dconseq
uently.
Thedictio
nary
should
inparticu
larbenegotia
tedwith
thecu
stomeran
dused
incommunicatio
n(if
notpossib
le,at
leastdevelo
pers
should
stickto
dictio
nary
terms).
•Note:donotmix
upreal-w
orld
/domain
termswith
ones
only
“livin
g”in
thesoftw
are.
Dictio
na
ryE
xam
ple
(With
Ro
om
for
Imp
rovem
ent)
– 05 – 2015-05-11 – Sre –
20/90
(Aren
iset
al.,
2014)
Example:W
ireless
Fire
Alarm
Syste
m
•Durin
gaproject
ondesig
ningahighly
reliable,
EN-54-25conform
ingwireless
communicatio
nprotocol,wehad
tolearn
that
therelevan
tcomponents
ofafire
alarmsystem
are
•term
inalparticip
ants
(wireless
sensors
andmanualindica
tors),
•ace
ntra
lunit
(notaparticip
ant),
•andrepeaters
(anon-term
inalparticip
ant).
•rep
eatersan
dcen
tralunitare
technically
verysim
ilar,butneed
tobedistin
guish
edto
understan
dreq
uirem
ents.
Thedictio
nary
explain
sthese
terms.
Dictio
na
ryE
xam
ple
(With
Ro
om
for
Imp
rovem
ent)
– 05 – 2015-05-11 – Sre –
20/90
(Aren
iset
al.,
2014)
Example:W
ireless
Fire
Alarm
Syste
m
•Durin
gaproject
ondesig
ningahighly
reliable,
EN-54-25conform
ingwireless
communicatio
nprotocol,wehad
tolearn
that
therelevan
tcomponents
ofafire
alarmsystem
are
•term
inalparticip
ants
(wireless
sensors
andmanualindica
tors),
•ace
ntra
lunit
(notaparticip
ant),
•andrepeaters
(anon-term
inalparticip
ant).
•rep
eatersan
dcen
tralunitare
technically
verysim
ilar,butneed
tobedistin
guish
edto
understan
dreq
uirem
ents.
Thedictio
nary
explain
sthese
terms.
Excerptfro
mthedictio
nary
(ca.50entries):
Part
Apart
ofafire
alarm
systemis
either
apar-
ticipantorace
ntra
lunit.
RepeaterArep
eater
isaparticip
antwhich
accep
tsmessa
ges
forthece
ntra
lunit
from
other
partici-
pants ,
ormessa
ges
from
thece
ntra
lunitto
other
particip
ants.
Arep
eater
consists
ofthefollo
wing
device
s:wireless
communica
tionmodule
(1to
4,
here
fixed
to2),
[...]
Centra
lUnit
Acen
tralu
nitisapart
which
receivesmessa
ges
from
differen
tassig
ned
particip
ants,
as-
sessesthemessa
ges,
andrea
cts,e.g
.byforw
arding
toperso
nsoroptica
l/acu
sticsig
nallin
gdevices.
Acen
tralunitco
nsist
ofthefollo
wingdevice
s:[...]
Term
inalParticip
antA
terminalparticip
antis
aparticip
antwhich
isnota
repeater.
Each
ter-minalparticip
antco
nsists
ofexa
ctlyonewireless
communica
tionmodule
anddevices
which
provid
esen
sorand/orsig
nallin
gfunctio
nality.
Do
cum
ents
of
the
Req
uirem
ents
An
alysis:
Sp
ecifica
tion
s
– 05 – 2015-05-11 – Sre –
21/90
•Reca
ll:
Laste
nheft
(Require
ments
Specifi
catio
n)Entire
dem
andsondeliverab
lesan
dser-
vicesofadevelo
per
with
inacontracted
develo
pment,
createdbythecu
stomer.
Pflich
tenheft
(Feature
Specifi
catio
n)Specifi
cationofhow
torealise
agiven
re-
quirem
ents
specifi
cation,cre
atedbythedeveloper.
DIN
69901-5
(2009)
•Reco
mmendatio
n:
Iftherequire
ments
specifi
catio
nisnotgivenbycusto
mer
(butneed
sto
be
develo
ped),
focusonan
dmain
tainonly
theco
llectio
nofrequire
ments
(possib
lysketch
yan
dunsorted
)an
dmain
tainthefeature
specifi
catio
n.
(Ludew
igandLich
ter,2013)
•Note:In
thefollow
ing(unless
otherw
isenoted
),wediscu
ssthefeature
specifi
catio
n,i.e.
thebasis
ofthesoftw
aredevelo
pment.
Tomaxim
iseconfusio
n,wemay
occasio
nally
(inconsisten
tly)call
itrequire
ments
specifi
catio
nor
just
specifi
catio
n—
should
beclear
from
context...
Req
uirem
ents
on
Req
uirem
ents
Sp
ecifica
tion
s
– 05 – 2015-05-11 – Sre –
22/90
Arequire
ments
specifi
catio
nshou
ldbe
•co
rrect
—itcorrectly
represen
tsthewish
es/need
softhecusto
mer,
•co
mplete
—all
requirem
ents
(existingin
someb
ody’s
head
,or
adocument,
or...)
should
be
presen
t,
•relevant
—thingswhich
arenotrelevan
tto
theproject
should
notbeconstrain
ed,
•co
nsiste
nt,
freeofco
ntra
dictio
ns
—each
requirem
entiscompatib
lewith
allother
requirem
ents;
otherw
isethereq
uirem
ents
arenotrealisa
ble,
•neutra
l,abstra
ct—
areq
uirem
ents
specifi
cationdoes
notconstrain
therealisatio
nmore
than
necessary,
•tra
ceable,co
mprehensib
le—
thesources
ofreq
uirem
ents
aredocumented
,req
uirem
ents
areuniquely
identifi
able,
•testa
ble,objectiv
e—
thefinal
product
canobjectiv
ely
bechecked
forsatisfyin
gareq
uirem
ent.
Req
uirem
ents
on
Req
uirem
ents
Sp
ecifica
tion
Do
cum
ents
– 05 – 2015-05-11 – Sre –
24/90
Therepresentatio
nandform
ofareq
uirem
ents
specifi
cationshou
ldbe:
•easily
understa
ndable,notunnecessarily
complica
ted—
allaff
ectedpeople
areab
leto
understan
dthereq
uirem
ents
specifi
cation,
•precise
—thereq
uirem
ents
specifi
cationdoes
notintro
duce
new
unclarities
orroomsfor
interp
retation(→
testable,
objective),
•easily
maintainable
—creatin
gan
dmain
tainingthereq
uirem
ents
specifi
cationshould
beeasy
andshould
not
need
unnecessary
effort,
•easily
usable
—storag
eofan
daccess
tothereq
uirem
ents
specifi
cationshould
notneed
significan
teff
ort.
Note:Once
again,it’s
abou
tcom
promises.
•A
veryprecise
objectiv
ereq
uirem
ents
specifi
cationmay
notbeeasily
understan
dab
leby
everyaff
ectedperso
n.
→provid
ered
undan
texp
lanatio
ns.
•It
isnoteasy
tohave
both,low
main
tenan
ceeff
ortan
dlow
accesseff
ort.
→valuelow
acce
sseffort
higher,
areq
uirem
ents
specifi
cationdocumentismuch
more
often
readthan
changedor
writte
n(m
ost
chan
ges
require
readingbeforeh
and).
Kin
ds
of
Req
uirem
ents
– 05 – 2015-05-11 – Sre –
25/90
Kin
ds
of
Req
uirem
ents:
Ha
rda
nd
So
ftR
equ
iremen
ts
– 05 – 2015-05-11 – Sre –
26/90
•Exa
mple
ofahard
require
ment:
•Cash
ingachequeover
Ne
must
resultin
anew
balan
cedecreased
byN;there
isnot
amicro
-centoftoleran
ce.
•Exa
mplesof
soft
require
ments:
•Iftheven
dingmach
inedisp
enses
theselected
itemwith
in1s,
it’sclearly
fine;
ifittakes
5min.,it’s
clearlywrong—
where’s
theboundary?
•A
carentertain
mentsystem
which
produces
“noise”
(dueto
limited
busban
dwidth
orCPU
pow
er)in
averageonce
per
hourisaccep
table,
once
per
minute
isnotaccep
table.
Theborderbetw
eenhard
/softis
diffi
cult
todraw
:
•Asdeveloper,
wewan
treq
uirem
ents
specifi
cationsto
be“ashard
aspossib
le”,i.e.
we
wan
taclear
right/wrong.
•Ascu
stomer,
weoften
cannotprovid
ethisclarity;
weknow
what
is“cle
arlywrong”an
dweknow
what
is“cle
arlyrig
ht”,butwedon’thave
asharp
boundary.
→intervals,
rates,etc.
canserve
asprecise
specifi
catio
nsof
soft
require
ments.
Kin
ds
of
Req
uirem
ents:
Op
ena
nd
Ta
cit
– 05 – 2015-05-11 – Sre –
27/90
•open:custom
erisaw
areof
andable
toexp
licitlycom
municate
thereq
uirem
ent,
•(se
mi-)ta
cit:custom
ernot
aware
ofsom
ethingbeingareq
uirem
ent(ob
viousto
thecustom
er,not
consid
eredrelevan
tby
thecustom
er,not
know
nto
berelevan
t).
Exa
mples:
•butto
ns
and
screenof
amobile
phoneshould
beonthesam
esid
e,
•im
portan
tweb-sh
opitem
sshould
be
ontherig
htsid
ebecau
seourmain
users
aresocialised
with
right-to
-leftread
ingdirectio
n,
•theECU
(embedded
contro
lunit)
may
only
use
acertain
amountof
buscap
acity.
•distin
guish
don’t
care:
inten
tionally
leftto
bedecid
edby
develo
per.
Analyst
know
sdomain
new
todomain
Customer/Client
explicit
requirem
ents
disco
veredreq
uirem
ents
disco
verable
semi-tacit
requirem
ents
disco
verable
requirem
ents
disco
verable
with
diffi
culties
tacit
hard
/im
possib
leto
disco
ver
(Gacitu
aet
al.,
2009)
Kin
ds
of
Req
uirem
ents:
Fu
nctio
na
la
nd
No
n-F
un
ction
al
– 05 – 2015-05-11 – Sre –
28/90
•*sigh*
•Reca
lldefinitio
nofsoftw
are:
Afinite
descrip
tionof
aset
ofcom
putation
path
sof
theform
π=
σ0
α1
−→
σ1
α2
−→
σ2···
Note:states
σmay
belab
elledwith
timestam
ps,
orenerg
yconsumptio
nso
far,...
•Anothervie
w:softw
areisafunction
which
mapsinputto
outputseq
uences:
S:σi0
αi1
−→
σi1
αi2
−→
σi2···
7→
(
σi0
σo0
)
αi1
−−→αo1
(
σi1
σo1
)
αi2
−−→αo2
···
•Eve
ryco
nstra
inton
things
observa
ble
inthecom
putation
path
sisafunctio
nal
require
ment(becau
seitreq
uires
someth
ingfor
thefunction
S).
Thustim
ing,energyco
nsumptio
n,etc.
may
besubject
tofunctio
nal
requirem
ents.
•Clearly
non-fu
nctio
nalreq
uirem
ents:
program
minglan
guag
e,codingconven
tions,
process
model
requirem
ents,
portab
ility...
Req
uirem
ents
An
alysis
Tech
niq
ues
– 05 – 2015-05-11 – Sre –
29/90
(AS
election
of)
An
alysis
Tech
niq
ues
– 05 – 2015-05-11 – Sre –
30/90
Focu
scurren
tdesired
innovatio
n
Analysis
Tech
nique
situatio
nsitu
ation
conseq
uences
Analysis
ofexistin
gdata
anddocuments
Observatio
n
Questio
nningwith
(
closed
structu
redopen
)
questio
ns
Interview
Modellin
g
Exp
eriments
Prototyp
ing
Particip
ativedevelo
pment
(Ludew
igandLich
ter,2013)
Req
uirem
ents
Elicita
tion
– 05 – 2015-05-11 – Sre –
31/90
•Observa
tion:
Custom
ersare
typically
not
trained
instatin
g/communicatin
greq
uirem
ents.
They
livein
the“Iwantapony”
-world
—in
multip
lesen
ses...;-)
•Itisthetask
oftheanalyst
to:
•ask
what
iswanted
,ask
what
isnot
wanted
,
•estab
lishprecisio
n,
look
outfor
contrad
ictions,
•anticip
ate
exception
s,diffi
culties,
corner-cases,
•have
technical
backgrou
ndto
know
technical
diffi
culties,
•co
mmunica
te(form
al)specifi
cationto
custom
er,
•“test”
ownunderstan
dingby
askingmore
question
s.
→i.e.
toelicit
thereq
uirem
ents.
Amadeupdialogu
e:
Analyst:
Soin
themorning,youopen
thedoorat
themain
entra
nce?
Custo
mer:
Yes,
asItold
you.
A:Every
morning?
C:Ofco
urse.
A:Also
ontheweeken
ds?
C:No,onweeken
ds,
theen
trance
staysclo
sed.
A:Anddurin
gco
mpanyholid
ays?
C:Then
italso
remainsclo
sedofco
urse.
A:Andifyouare
illoronva
catio
n?
C:Then
Mr.
Mopen
sthedoor.
A:AndifMr.
Mis
notava
ilable,
too?
C:Then
thefirst
clientwill
knock
onthewindow.
A:Okay.
Now
whatexa
ctlydoes
“morning”mean?
...(Ludew
igandLich
ter,2013)
Ho
wC
an
Req
uirem
ents
En
gin
eering
Lo
ok
InP
ractice?
– 05 – 2015-05-11 – Sre –
32/90
•Set
upaco
reteam
foranalysis
(3to
4peo
ple),
inclu
deexp
ertsfro
mthedomain
anddeve
lopers.
Analysis
ben
efits
from
highest
skills
andstro
ngexp
erie
nce
.
•Durin
ganalysis,
talk
todecisio
nmake
rs(m
anagers),
domain
exp
erts,
andusers.
Users
canbe
interview
edbyatea
mof2analysts,
ca.90min.
•Theresu
lting“raw
materia
l”is
sorted
andassessed
inhalf-
orfull-d
ayworkshopsin
atea
mof
6-10peo
ple.
Onesearch
esfor,e.g
.,co
ntra
dictio
nsbetw
eencu
stomer
wish
es,andforprio
risatio
n.
Note:Thecu
stomerdecid
es.
Analysts
may
make
proposals
(differen
toptio
nsto
choose
from),
butthecu
stomer
chooses.
(Andthech
oice
isdocu
men
ted.)
•The“raw
materia
l”is
basis
ofaprelim
inary
require
ments
specifi
catio
n(audien
ce:the
develo
pers)
with
open
questio
ns.
Analysts
need
toco
mmunica
tethereq
uirem
ents
specifi
catio
nappropria
tely
(explain,give
examples,
pointoutparticu
larcorner-ca
ses).Custo
mers
with
outstro
ngmaths/co
mputer
science
backgroundare
often
ove
rstrainedwhen
“left
alone”
with
aform
alreq
uirem
ents
specifi
catio
n.
•Result:
dictio
nary,
specifi
edrequire
ments.
•Man
ycusto
mers
donotwan
t(ra
dica
l)ch
ange,butim
provement.
•Goodquestio
ns:
How
’rethingsdonetoday?
What
should
beim
proved
?
Sp
ecifica
tion
La
ng
uages
– 05 – 2015-05-11 – main –
33/90
Req
uirem
ents
Sp
ecifica
tion
La
ng
uage
– 05 – 2015-05-11 – Sspeclang –
34/90
specifi
catio
n—
Adocumentthat
specifi
es,in
acom
plete,
precise,verifi
able
manner,
thereq
uirem
ents,
design
,behavior,
oroth
ercharacteristics
ofasys-
temor
compon
ent,and,often
,thepro
cedures
fordeterm
iningwheth
erthese
provisionshave
been
satisfied.
IEEE
610.12(1990)
specifi
catio
nlanguage—
Alan
guage,
oftenamach
ine-pro
cessiblecom
bina-
tionof
natu
ralandform
allan
guage,
used
toexpress
thereq
uirem
ents,
design
,behavior,
oroth
ercharacteristics
ofasystem
orcom
pon
ent.
For
example,
adesign
langu
ageor
requirem
ents
specifi
cationlan
guage.
Con
trastwith
:pro-
gramminglan
guage;
query
langu
age.IEEE
610.12( 1990)
require
ments
specifi
catio
nlanguage—
Aspecifi
cationlan
guage
with
spe-
cialcon
structs
and,som
etimes,
verification
protocols,
used
todevelop
,ana-
lyze,anddocumenthard
ware
orsoftw
arereq
uirem
ents.
IEEE
610.12(1990)
softw
arerequire
ments
specifi
catio
n(S
RS)—
Documentation
oftheessen
-tial
requirem
ents
(function
s,perform
ance,
design
constrain
ts,andattrib
utes)
ofthesoftw
areandits
external
interfaces.
IEEE
610.12( 1990)
Na
tura
lL
an
gu
age
Sp
ecifica
tion
– 05 – 2015-05-11 – Sspeclang –
35/90
(Ludew
igandLich
ter,2013)based
on(R
uppanddie
SOPHISTen
,2009):
rule
explanatio
n,example
R1
State
eachreq
uirem
entin
activ
evoice
.
Nam
etheactors,
indicate
wheth
ertheuser
orthe
systemdoes
someth
ing.Not“theitem
isdeleted
”.
R2
Express
processes
byfullverbs.
Not“is”
,“has”
,but“read
s”,“creates”
;fullverb
sreq
uire
inform
ationwhich
describ
etheprocess
more
precisely.
Not“when
data
isconsisten
t”but“after
program
Phas
checked
consisten
cyofthedata”
.
R3
Disco
verinco
mpletely
definedverbs.
In“thecomponentraises
anerror”
,ask
whom
the
messag
eisad
dressed
to.
R4
Disco
verinco
mplete
conditio
ns.
Conditio
nsoftheform
“if-else”
need
descrip
tionsofthe
if-an
dthethen-case.
R5
Disco
veruniversa
lquantifi
ers .
Are
senten
ceswith
“never”
,“alw
ays”,“each
”,“an
y”,
“all”
reallyuniversally
valid?Are
“all”
reallyall
orare
there
exceptio
ns.
R6
Check
Nounslike
“reg
istration”often
hidecomplex
processes
– 05 – 2015-05-11 – Sspeclang –
36/90
quantifi
ers.
“all”
reallyuniversally
valid?Are
“all”
reallyall
orare
there
exceptio
ns.
R6
Check
nominalisa
tions.
Nounslike
“reg
istration”often
hidecomplex
processes
that
need
more
detailed
descrip
tions;
theverb
“reg
ister”raises
appropriate
questio
ns:
who,where,
forwhat?
R7
Reco
gnise
and
refineuncle
arsubsta
ntiv
es.
Isthesubstan
tiveused
asageneric
termor
does
itdenote
someth
ingspecifi
c?Is
“user”
generic
orisa
mem
ber
ofaspecifi
cclasses
mean
t?
R8
Clarify
resp
onsib
ilities.
Ifthespecifi
cationsays
that
someth
ingis“possib
le”,
“im
possib
le”,or
“may”
,“should”,“must”
hap
pen,
clarifywhoisenforcin
gor
prohibitin
gthebehavio
ur.
R9
Identify
implicit
assu
mptio
ns.
Term
s(“thefirew
all”)that
arenotexp
lained
furth
eroften
hintto
implicit
assumptio
ns(here:
there
seemsto
beafirew
all).
Na
tura
lL
an
gu
age
Pa
tterns
– 05 – 2015-05-11 – Sspeclang –
37/90
Natu
rallan
guage
requirem
ents
canbewritten
usin
gA,B,C,D,E,F
where
Aclarifi
eswhen
andunder
what
conditio
nstheactivity
takesplace
BisMUST
(oblig
ation),
SHOULD
(wish
),or
WILL(in
tentio
n);
also:MUST
NOT
(forbidden)
Ciseith
er“thesystem
”or
theconcrete
nam
eofa(su
b-)system
Doneofthree
possib
ilities:
•“does”
,descrip
tionofasystem
activity,•
“offers”
,descrip
tionofafunctio
noffered
bythesystem
tosomeb
ody,
•“isab
leif”
,usag
eofafunctio
noffered
byathird
party,
under
certainconditio
ns
Eexten
sions,
inparticu
laran
object
Ftheactu
alprocess
word
(what
hap
pens)
(Ruppanddie
SOPHISTen
,2009)
Exa
mple:
After
office
hours
(=A),
thesystem
(=C)should
(=B)offer
totheoperator
(=D)aback
up(=
F)ofall
new
registratio
nsto
anextern
almedium
(=E).
Oth
erP
attern
Exa
mp
le:R
FC
21
19
– 05 – 2015-05-11 – Sspeclang –
38/90
Network Working Group S. Bradner
Request for Comments: 2119 Harvard University
BCP: 14 March 1997
Category: Best Current Practice
Key words for use in RFCs to Indicate Requirement Levels
Status of this Memo
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Abstract
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
Note that the force of these words is modified by the requirement
level of the document in which they are used.
1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the
definition is an absolute requirement of the specification.
2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the
definition is an absolute prohibition of the specification.
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful, but the full
implications should be understood and the case carefully weighed
before implementing any behavior described with this label.
Bradner Best Current Practice [Page 1]
RFC 2119 RFC Key Words March 1997
5. MAY This word, or the adjective "OPTIONAL", mean that an item is
truly optional. One vendor may choose to include the item because a
particular marketplace requires it or because the vendor feels that
it enhances the product while another vendor may omit the same item.
An implementation which does not include a particular option MUST be
prepared to interoperate with another implementation which does
include the option, though perhaps with reduced functionality. In the
same vein an implementation which does include a particular option
MUST be prepared to interoperate with another implementation which
does not include the option (except, of course, for the feature the
option provides.)
6. Guidance in the use of these Imperatives
Imperatives of the type defined in this memo must be used with care
and sparingly. In particular, they MUST only be used where it is
actually required for interoperation or to limit behavior which has
potential for causing harm (e.g., limiting retransmisssions) For
example, they must not be used to try to impose a particular method
on implementors where the method is not required for
interoperability.
7. Security Considerations
These terms are frequently used to specify behavior with security
implications. The effects on security of not implementing a MUST or
SHOULD, or doing something the specification says MUST NOT or SHOULD
NOT be done may be very subtle. Document authors should take the time
to elaborate the security implications of not following
recommendations or requirements as most implementors will not have
had the benefit of the experience and discussion that produced the
specification.
8. Acknowledgments
The definitions of these terms are an amalgam of definitions taken
from a number of RFCs. In addition, suggestions have been
incorporated from a number of people including Robert Ullmann, Thomas
Narten, Neal McBurnett, and Robert Elz.
– 05 – 2015-05-11 – Sspeclang –
39/90
The In
stitu
te o
f Ele
ctric
al a
nd E
lectro
nic
s E
ngin
eers
, Inc.
345 E
ast 4
7th
Stre
et, N
ew
York
, NY
10017-2
394, U
SA
Copyrig
ht ©
1998 b
y th
e In
stitu
te o
f Ele
ctric
al a
nd E
lectro
nic
s E
ngin
eers
, Inc.
All rig
hts
reserve
d. P
ublis
hed 1
998. P
rinte
d in
the U
nite
d S
tate
s o
f Am
eric
a.
ISB
N 0
-7381-0
332-2
No p
art o
f this
public
atio
n m
ay b
e re
pro
duced in
any fo
rm, in
an e
lectro
nic
retrie
val s
yste
m o
r oth
erw
ise, w
ithout th
e p
rior
writte
n p
erm
issio
n o
f the p
ublis
her.
IEE
E S
td 8
30-1
998
(Revis
ion o
f
IEE
E S
td 8
30-1
993)
IEE
E R
eco
mm
en
ded
Pra
ctic
e fo
r S
oftw
are
Req
uire
men
ts
Sp
eciÞ
catio
ns
Sponsor
So
ftware
En
gin
eerin
g S
tan
dard
s C
om
mitte
eo
f the
IEE
E C
om
pu
ter S
ocie
ty
Appro
ved 2
5 J
une 1
998
IEE
E-S
A S
tan
dard
s B
oard
Ab
stra
ct:
Th
e c
on
ten
t an
d q
ua
lities o
f a g
oo
d s
oftw
are
req
uire
me
nts
sp
ecific
atio
n (S
RS
) are
de
-
scrib
ed
an
d s
eve
ral s
am
ple
SR
S o
utlin
es a
re p
rese
nte
d. T
his
reco
mm
en
de
d p
ractic
e is
aim
ed
at
sp
ecify
ing
req
uire
me
nts
of s
oftw
are
to b
e d
eve
lop
ed
bu
t als
o c
an
be
ap
plie
d to
assis
t in th
e s
ele
c-
tion
o
f in
-ho
use
a
nd
co
mm
erc
ial
so
ftwa
re p
rod
ucts
. G
uid
elin
es fo
r co
mp
lian
ce
w
ith IE
EE
/EIA
12
20
7.1
-19
97
are
als
o p
rovid
ed
.
Ke
yw
ord
s:
co
ntra
ct, c
usto
me
r, pro
toty
pin
g, s
oftw
are
req
uire
me
nts
sp
ecific
atio
n, s
up
plie
r, syste
m
req
uire
me
nts
sp
ecific
atio
ns
Stru
cture
of
aR
equ
iremen
tsD
ocu
men
t:E
xam
ple
– 05 – 2015-05-11 – Sspeclang –
40/90
1IN
TRODUCTIO
N
1.1
Purpose
1.2
Acro
nym
san
dDefi
nitio
ns
1.3
Referen
ces1.4
User
Characteristics
2FUNCTIO
NALREQUIREMENTS
2.1
Functio
nSet
12.2
etc.
3REQUIREMENTSTO
EXTERNALIN
TERFACES
3.1
User
Interfaces
3.2
Interfaces
toHard
ware
3.3
Interfaces
toSoftw
areProducts
/Softw
are/Firm
ware
3.4
Communicatio
nInterfaces
4REQUIREMENTSREGARDIN
GTECHNICALDATA
4.1
VolumeRequirem
ents
4.2
Perform
ance
4.3
etc.
5GENERALCONSTRAIN
TSAND
REQUIREMENTS
5.1
Stan
dard
san
dRegulatio
ns
5.2
Strateg
icConstrain
ts5.3
Hard
ware
5.4
Softw
are5.5
Compatib
ility5.6
Cost
Constrain
ts5.7
Tim
eConstrain
ts5.8
etc.
6PRODUCT
QUALITY
REQUIREMENTS
6.1
Availab
ility,Reliab
ility,Robustn
ess6.2
Secu
rity6.3
Main
tainab
ility6.4
Portab
ility6.5
etc.
7FURTHER
REQUIREMENTS
7.1
System
Operatio
n7.2
Custo
misatio
n7.3
Requirem
ents
ofIntern
alUsers
( Ludew
igan
dLich
ter,2013)based
on(IE
EE,1998)
Referen
ces
– 05 – 2015-05-11 – main –
89/90
