1. Requirements
Engineering
Werkcollege
Spring
2012
Session
4:
SpecificaDon
&
DocumentaDon
Christoph Johann Stettina (stettina@liacs.nl)
Leiden
University.
The
university
to
discover.

2. Session
4:
Requirements
SpecificaDon
Today:
• Business
process
modeling
• Tayloris3c
knowledge
sharing
• Requirements
specifica3on
templates
Why
is
it
important?
• Documenta3on
of
elicited
requirements
• Traceability,
Accountability
• Acceptance
criteria
Leiden
University.
The
university
to
discover.

3.
Part
1
–
SpecificaDon
Business
Process
Modeling
Leiden
University.
The
university
to
discover.

4. What
is
a
business
process?
“A
collec3on
of
ac3vi3es
that
takes
one
or
more
kinds
of
input
and
creates
an
output
that
is
of
value
to
the
customer”
(Hammer
&
Champy,
1993)
Real
life
examples:
- E-­‐payment
process
- Visa
applica3on
- Hotel
reserva3on
- etc.
Leiden
University.
The
university
to
discover.

5. What
is
business
process
modeling?
Convergence
of
two
modeling
domains:
Process
modeling
l Abstract
representa3on
of
a
process
architecture
Enterprise
or
business
modeling
l Documen3ng
an
organiza3on
from
a
holis3c
perspec3ve
Leiden
University.
The
university
to
discover.

6. Why
modeling
business
processes?
- To
have
a
formal
documenta3on
(as
point
of
reference)
- To
allow
process
analysis
(e.g.,
reengineering)
- To
communicate
processes
- To
generate
executable
process
language
(e.g.,
BPEL)
Leiden
University.
The
university
to
discover.

7. Examples:
BPM
Supply
fulfillment,
Informal
&
Formal
Leiden
University.
The
university
to
discover.

8. How
to
Model
Business
Processes?
We
need
a
formal
way
to
model
BP,
so
that:
l Widely
understood
(using
standard
nota3on)
l Avoid
ambiguity,
inconsistency,
etc.
in
expressing
concepts
l Allow
automated
assessments
Leiden
University.
The
university
to
discover.

9. CreaDng
an
AcDvity
Diagram
- Iden3fy
the
scope
of
the
ac3vity
diagram
(e.g.,
a
use
case)
- Add
start
and
end
points
- Add
ac3vi3es
- Add
transi3ons
from
the
ac3vi3es
- Add
decision
points
(if
any)
- Iden3fy
opportuni3es
for
parallel
ac3vi3es
Leiden
University.
The
university
to
discover.

10. CreaDng
an
AcDvity
Diagram
Another
Example
Leiden
University.
The
university
to
discover.

11. The
Swimlanes
- Add
a
dimension
to
visualize
roles
- Separate
the
diagram
into
parallel
lanes
- Each
lane
presents
ac3vi3es
performed
by
each
role
- Transi3ons
can
take
across
swimlanes
Leiden
University.
The
university
to
discover.

12. Case
Study:
In-­‐class
assignment
- Analyze
&
model
the
current
business
process
of
the
OV-­‐chipkaart
from
the
customer
perspec3ve
- Use
ac3vity
diagrams
to
support
your
model
- What
are
the
differences?
Example:
Strippenkaart
Process
Leiden
University.
The
university
to
discover.

13.
Part
2
–
Knowledge
Sharing
Tayloris3c
&
Direct
Knowledge
Sharing
Leiden
University.
The
university
to
discover.

14. to press development teams to produce multitude of
documents throughout a software project.
Knowledge
Sharing:
TaylorisDc
Way
TaylorisDc
Knowledge
Sharing
(Melnik
and
Maurer,
2009)
10% communication error !
• Division
of
labor
and
long
chains
of
transfer
(90%)5 = 59% info gets to developer
• 5%
communica3on
errors
pro
transfer
5% communication error !
→
only
77%
of
informa3on
reaches
developer
5
(95%) = 77% info gets to developer
• Projects
suffer
from
less
direct
links
(Keil
and
Carmel,
1995)
Figure 1. Knowledge Sharing: Tayloristic Way.
Leiden
University.
The
university
to
discover.

15. process.
Knowledge
Sharing:
Direct
Way
Agile
Knowledge
Sharing
(Melnik
and
Maurer,
2009)
10% communication error !
• Encourage
con3nuous
realignment
of
goals
90% info gets to developer
and
customer
feedback
5% communication error ! process
• Knowledge
sharing
a
highly
social
95% info gets to developer
Leiden
University.
The
university
to
discover.

16. Knowledge
Sharing
Exercise
(Melnik
and
Maurer,
2009)
Knowledge
Sharing
Exercise
(Melnik
and
Maurer,
2009)
• Simula3on
of
Tayloris3c
knowledge
sharing
• Form
small
teams
of
3-­‐6
people
• Goal:
Reproduce
a
Drawing,
Time:
20
mins
Roles
• Analyst
Describes
requirements
in
prose
on
paper
• Messenger
Carries
notes
from
developers
and
back
• Developer
Implement
the
specifica3on
Leiden
University.
The
university
to
discover.

17. Knowledge
Sharing
Exercise
(Melnik
and
Maurer,
2009)
Examples
(Melnik
and
Maurer,
2009)
Industry Team 1: Original IndustryTeam 1: Original
SAIT Team 1: Product Industry Team 2: Original
SAIT Team 1: Product S
Ind
Industry Team 1: Original Industry Team 1: Product Industry Team 2: Original In
(a) (a) (b)
(a) (b)
Leiden
University.
The
university
to
discover.

18.
Part
3
–
DocumentaDon
Requirements
Specifica3on
Templates
Leiden
University.
The
university
to
discover.

19. So[ware
Requirement
SpecificaDon
SRS
Templates
• Help
to
structure
requirements
Standards
• IEEE
830-­‐1998
• IEEE
1362-­‐1998
• VOLERE
Template
Leiden
University.
The
university
to
discover.

20. Requirement
SpecificaDon
Templates
• Introduc3on
• General
descrip3on
(overview
&
scope)
• Specific
requirements
Leiden
University.
The
university
to
discover.

21. Requirement
SpecificaDon
Templates
IEEE
Recommended
PracDce
for
So[ware
Design
DescripDons
(IEEE
830,
1998)
1. Introduction
1.1 Purpose of the document
1.2 Scope of the product
1.3 Definitions, acronyms and abbreviations
1.4 References
2. General description
2.1 Product perspective
2.2 Product functions
2.3 User characteristics
2.4 General constrains
2.5 Assumptions and dependencies
3. Specific requirements
3.1 Functional requirements
3.2 External interface requirements
3.3 Performance requirements
3.4 Design constraints
3.5 Software quality attributes
Appendices
Index
Leiden
University.
The
university
to
discover.

22. FuncDonal
Requirements
Most
common
requirement
form
• What
system
must
do
according
to
project
goal
• Ac3ons
the
systems
takes:
Input
→
Behavior
→
Output
• “System
must
do
<requirement>”
Measurable:
• Criterion
in
terms
of
predicted
outcomes
Leiden
University.
The
university
to
discover.

23. Non-­‐FuncDonal
Requirements
SomeDmes
also
called
Quality
Requirements
• System
performance,
throughput,
3ming
• Look
and
feel,
usability,
security,
reliability
• “System
must
be
<>”
Measurable:
• Throughput,
3ming
and
stress
tests
• Usability
tes3ng
with
users
Leiden
University.
The
university
to
discover.

24. Requirements
≠
SoluDons
SoluDons
1. Users
shall
be
able
to
pay
train
fares
via
OV-­‐chipkaart
2. The
system
shall
be
password
protected
Requirements
1. The
system
shall
allow
payment
of
mul3ple
transporta3on
systems
2. The
system
shall
provide
access
only
to
authorized
users
Leiden
University.
The
university
to
discover.

25. Volere
Template
(Volere,
2010)
Requirement #:X Requirement Type: _ Event/use case: _
Description: Natural language statement in stakeholder
words, describing the intent of the requirement
Rationale: Reason behind the requirement. Help
understanding the context.
Originator: Person or stakeholder group
Fit Criterion: Acceptance criteria defined in a quantified
manner. To be used for acceptance testing.
Customer Satisfaction: 1-5 Customer Dissatisfaction: 1-5
Dependencies: other Req. Conflicts: ___
Supporting Materials: Link to further references
History: Creation dates and authors for traceability.
Leiden
University.
The
university
to
discover.

26. Templates:
In-­‐class
assignment
TranslaDon
of
requirements
• Form
groups
of
2-­‐3
people
• Groups
receive
VOLERE
and
SRS
Examples
• Groups
A:
Translate
Volere
-­‐>
SRS
• Groups
B:
Translate
SRS
-­‐>
VOLERE
• 10mins,
then
groups
switch
ar3facts
EvaluaDon
• What
did
you
learn/experience?
Leiden
University.
The
university
to
discover.

27. Assignment:
Req.
SpecificaDon
Propose
requirements
and
a
business
process
for
a
fic3onal
OV-­‐chipkaart
without
logging
out.
You
can
use
other
technologies
(e.g.
RFID)
Deliverables
Your
requirements
in
a
SRS
(IEEE
Std-­‐830,
as
PDF),
include
• 1
Ac3vity
diagram
• 2
VOLERE
sheets
• Provide
sufficient
textual
descrip3ons
Hand
in
via
email
Subject:
RE
assignment
–
Assignment
4
–
Specifica3on
Naming
conven3on
for
the
file:
stnumber_lastname.pdf.
Use
PDF.
One
solu3on
per
person.
• Send
to:
stepna@liacs.nl
• Deadline:
April
19,
2012
Leiden
University.
The
university
to
discover.

28. Bibliography
• Fowler,
M.
(2004),
UML
dis3lled:
a
brief
guide
to
the
standard
object
modeling
language
(3
ed.),
Addison-­‐
Wesley,
p.
131,
ISBN
9780321193681
• Hammer,
M.
&
Champy,
J.
(1994).
Reengineering
the
corpora3on:
A
manifesto
for
business
revolu3on.
New
York:
Harper.
• IEEE,
Sosware
Engineering
Commitee
(1998)
IEEE
Recommended
Prac3ce
for
Sosware
Design
Descrip3ons.
ANSI/IEEE
Std
830,
October
1998
• Keil,
M.,
Carmel,
E.
Customer-­‐Developer
Links
in
Sosware
Development.
Communica3ons
of
the
ACM,
38
(5):
33–44,
1995.
• van
Lamsweerde,
A.
(2009)
Requirements
Engineering:
From
System
Goals
to
UML
Models
to
Sosware
Specifica3ons.
Wiley,
March
2009.
• Melnik,
G.
and
Maurer,
F.
“Direct
verbal
communica3on
as
a
catalyst
of
agile
knowledge
sharing,”
in
Proceedings
of
the
Agile
Development
Conference.
Washington,
DC,
USA:
IEEE
Computer
Society,
2004,
pp.
21–31.
• Taylor,
F.
Principles
of
Scien3fic
Management.
Norton,
New
York,
NY,
1967.
• Volere
(2010)
Volere
Requirements
Specifica3on
Template.
Edi3on
15
—
2010.
Retrieved
2012-­‐04-­‐11.
htp://
www.volere.co.uk/template.htm
Leiden
University.
The
university
to
discover.