Page 2
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),
•...
Page 7
– 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