requirements engineering methods for documenting requirements (lecture slides)
TRANSCRIPT
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Requirements Engineering
Methods for
Documenting Requirements
Prof. Dr. Dagmar Monett DíazComputer Science Dept.
Faculty of Cooperative Studies
Berlin School of Economics and Law
Europe Week, 2nd – 6th March 2015
120 Minutes
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Dilbert
Scott Adams
At http://dilbert.com/strip/1999-08-09/
(Educational/Classroom usage permission is granted by Universal Uclick. All Rights Reserved)
Requirements document…
2
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 3
Main topics
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 4
Main topics
Where does the major content come from?
Requirements Engineering and Requirements
Development: An Overview
Requirements Analysis. Key actions in analysis.
Requirements Specification. Actions and templates
What are good requirements? Quality criteria
How do we construct “perfect” requirements?
- User stories and the Rupp’s template-based approach
Good practices in analysis and specification
What’s next? Further reading, sources of inspiration
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 5
Next topics…
Where does the major content come from?
Requirements Engineering and Requirements
Development: An Overview
Requirements Analysis. Key actions in analysis.
Requirements Specification. Actions and templates
What are good requirements? Quality criteria
How do we construct “perfect” requirements?
- User stories and the Rupp’s template-based approach
Good practices in analysis and specification
What’s next? Further reading, sources of inspiration
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 6
©
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Software Requirements
Karl Wiegers and Joy Beatty
3rd Edition, 672 pp.
Microsoft Press, 2013
ISBN-13: 978-0-7356-7966-5
(See more at
http://aka.ms/SoftwareReq3E/files)
7
Wiegers & Beatty
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Requirements-Engineering
und -Management: Aus der
Praxis von klassisch bis agil
Chris Rupp & die SOPHISTen
6th Edition, 570 pp.
Carl Hanser Verlag München, 2014
ISBN-13: 978-3-446-43893-4
In German
(Chapters and related topics in English are
available for free at https://www.sophist.de/)
8
Rupp & The SOPHISTs
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Software Engineering
Ian Sommerville
9th Edition, 792 pp.
Addison-Wesley, 2010
ISBN-13: 978-0137035151
(10th Edition: April 2015. See more at
http://iansommerville.com/software-
engineering-book/)
9
Sommerville
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 10
The traditional software
development process:
Perceptions, communication patterns
and interests…
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 11Cartoon http://projectcartoon.com/
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 12Cartoon http://projectcartoon.com/
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 13
Requirements and
Requirements Engineering
– An Overview –
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 14
A requirement is…
According to Wiegers & Beatty:
“[A requirement is a] statement of a
customer need or objective, or of a condition
or capability that a product must possess to
satisfy such a need or objective. A property
that a product must have to provide value to
a stakeholder.”
See lecture “A Structured Approach to Requirements Analysis” for more on this topic!
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Requirements Engineering
Definition according to Wiegers & Beatty:
Requirements engineering is the subdiscipline of
systems engineering and software engineering that
encompasses all project activities associated with
understanding a product's necessary capabilities and
attributes. Includes both requirements development
and requirements management.
15
See lecture “A Structured Approach to Requirements Analysis” for more on this topic!
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 16
Subdisciplines of
Requirements Engineering
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 17
Subdisciplines of Requirements Engineering
Requirements
Engineering
Requirements
Development
Requirements
Management
Acc. to Wiegers & Beatty
See lecture “A Structured Approach to Requirements Analysis” for more on this topic!
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 18
Subdisciplines of Requirements Development
Elicitation
Requirements
Engineering
Analysis Specification Validation
Requirements
Development
Requirements
Management
Acc. to Wiegers & Beatty
See lecture “A Structured Approach to Requirements Analysis” for more on this topic!
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 19
Subdisciplines of Requirements Management
Tracking
Requirements
Engineering
Managing Controlling Tracing
Requirements
Development
Requirements
Management
Acc. to Wiegers & Beatty
See lecture “A Structured Approach to Requirements Analysis” for more on this topic!
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 20
Topics of other related lectures
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 21
Subdisciplines of Requirements Engineering
Elicitation
Requirements
Engineering
Analysis Specification Validation
Requirements
Development
Requirements
Management
All are topics of lecture:
“A Structured Approach to Requirements Analysis”
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 22
Subdisciplines of Requirements Development
Requirements
Engineering
Requirements
Development
Requirements
Management
Elicitation Analysis Specification Validation
Topic of lecture
“Requirements Engineering Techniques for Eliciting Requirements”
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 23
Subdisciplines of Requirements Development
Requirements
Engineering
Requirements
Development
Requirements
Management
Elicitation Specification Validation
Topics of (this) lecture
“Requirements Engineering Methods for Documenting Requirements”
Analysis
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 24
Subdisciplines of Requirements Development
Requirements
Engineering
Requirements
Development
Requirements
Management
Elicitation Analysis Specification Validation
Also topic of lecture
“Modelling Software Requirements. Important diagrams and templates”
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 25
Subdisciplines of Requirements Development
Requirements
Engineering
Requirements
Development
Requirements
Management
Elicitation Analysis Specification Validation
Topic of lecture
“Methods for Validating and Testing Software Requirements”
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 26
A Requirements Development
process framework
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 27
Subdisciplines of Requirements Development
Elicitation
Requirements
Engineering
Analysis Specification Validation
Requirements
Development
Requirements
Management
Acc. to Wiegers & Beatty
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
RD process framework
28
Elicitation
Analysis
Specification
Validationre-evaluate
Adapted from Wiegers & Beatty
identifying, discovering
evaluating,
verifying
documenting, SRS
classifying,
representing,
deriving,
negotiating
RD: Requirements Development
SRS: Software Requirements Specification
See lecture “A Structured Approach to Requirements Analysis” for details!
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 29
A structured approach to
Requirements Development
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 30
A structured approach to RD
(1) Define stakeholders!
Who is interested in the system?
Who makes decisions?
Who are the users, managers, developers, etc.?
In other words, WHO has influence on the software requirements?
(2) Define goals!
Stakeholders have goals (define coarse goals!)
These goals can be divided into more specific goals (define granular goals!)
In other words, WHAT should be implemented or achieved?
(3) Define requirements!
Goals can be derived into concrete requirements
How to get to the requirements? (goal-based!)
Model those requirements using diagrams, templates, etc.
In other words, HOW will the goals be achieved?
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 31
A structured approach to RD
Granular goals
CG3
CG2CG1
Coarse goals
Define
stakeholders
Define
goals
Define
requirements
DiagramsTemplates
Models
WHO
WHAT
HOW
See lecture “A Structured Approach to Requirements Analysis” for details!
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 32
So far…
Where does the major content come from?
Requirements Engineering and Requirements
Development: An Overview
Requirements Analysis. Key actions in analysis.
Requirements Specification. Actions and templates
What are good requirements? Quality criteria
How do we construct “perfect” requirements?
- User stories and the Rupp’s template-based approach
Good practices in analysis and specification
What’s next? Further reading, sources of inspiration
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 33
Next topics…
Where does the major content come from?
Requirements Engineering and Requirements
Development: An Overview
Requirements Analysis. Key actions in analysis.
Requirements Specification. Actions and templates
What are good requirements? Quality criteria
How do we construct “perfect” requirements?
- User stories and the Rupp’s template-based approach
Good practices in analysis and specification
What’s next? Further reading, sources of inspiration
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 34
Requirements Analysis
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
RD process framework
35
Elicitation
Analysis
Specification
Validationre-evaluate
Adapted from Wiegers & Beatty
identifying, discovering
evaluating,
verifying
documenting, SRS
classifying,
representing,
deriving,
negotiating
RD: Requirements Development
SRS: Software Requirements Specification
See lecture “A Structured Approach to Requirements Analysis” for details!
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
RD process framework
36
Elicitation
Analysis
Specification
Validationre-evaluate
Adapted from Wiegers & Beatty
identifying, discovering
evaluating,
verifying
documenting, SRS
classifying,
representing,
deriving,
negotiating
RD: Requirements Development
SRS: Software Requirements Specification
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Analysis: Definition
37
Acc. to Wiegers & Beatty
Analysis
“[Analysis is the] process of classifying
requirements information into various categories,
evaluating requirements for desirable qualities,
representing requirements in different forms,
deriving detailed requirements from high-level
requirements, negotiating priorities, and related
activities.”
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 38
A structured approach to RD
Granular goals
CG3
CG2CG1
Coarse goals
Define
stakeholders
Define
goals
Define
requirements
DiagramsTemplates
Models
WHO
WHAT
HOW
classifying,
representing,
deriving,
negotiating
identifying, discovering
documenting, SRS
+
+
evaluating, verifying+
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 39
Key actions in analysis
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Key actions (i)
40
Acc. to Wiegers & BeattyA
naly
sis
Analysing the information received from users to
distinguish their task goals from other requirements
information (functional req., business rules, etc.).
According to Wiegers & Beatty
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Key actions (i)
41
Acc. to Wiegers & BeattyA
naly
sis Decomposing high-level requirements into an
appropriate level of detail.
Analysing the information received from users to
distinguish their task goals from other requirements
information (functional req., business rules, etc.).
According to Wiegers & Beatty
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Key actions (i)
42
Acc. to Wiegers & Beatty
Deriving functional requirements.An
aly
sis Decomposing high-level requirements into an
appropriate level of detail.
Analysing the information received from users to
distinguish their task goals from other requirements
information (functional req., business rules, etc.).
According to Wiegers & Beatty
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Key actions (i)
43
Acc. to Wiegers & Beatty
Deriving functional requirements.An
aly
sis Decomposing high-level requirements into an
appropriate level of detail.
Analysing the information received from users to
distinguish their task goals from other requirements
information (functional req., business rules, etc.).
Understanding importance of quality attributes.
…
According to Wiegers & Beatty
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Key actions (ii)
44
Acc. to Wiegers & BeattyA
naly
sis
Allocating requirements to software components
defined in the system architecture.
…
According to Wiegers & Beatty
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Key actions (ii)
45
Acc. to Wiegers & Beatty
Negotiating implementation priorities.
An
aly
sis
Allocating requirements to software components
defined in the system architecture.
…
According to Wiegers & Beatty
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Key actions (ii)
46
Acc. to Wiegers & Beatty
Negotiating implementation priorities.
An
aly
sis
Allocating requirements to software components
defined in the system architecture.
Identifying gaps in requirements or unnecessary
requirements.
…
According to Wiegers & Beatty
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 47
So far…
Where does the major content come from?
Requirements Engineering and Requirements
Development: An Overview
Requirements Analysis. Key actions in analysis.
Requirements Specification. Actions and templates
What are good requirements? Quality criteria
How do we construct “perfect” requirements?
- User stories and the Rupp’s template-based approach
Good practices in analysis and specification
What’s next? Further reading, sources of inspiration
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 48
Next topics…
Where does the major content come from?
Requirements Engineering and Requirements
Development: An Overview
Requirements Analysis. Key actions in analysis.
Requirements Specification. Actions and templates
What are good requirements? Quality criteria
How do we construct “perfect” requirements?
- User stories and the Rupp’s template-based approach
Good practices in analysis and specification
What’s next? Further reading, sources of inspiration
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 49
Requirements Specification
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
RD process framework
50
Elicitation
Analysis
Specification
Validationre-evaluate
Adapted from Wiegers & Beatty
identifying, discovering
evaluating,
verifying
documenting, SRS
classifying,
representing,
deriving,
negotiating
RD: Requirements Development
SRS: Software Requirements Specification
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
RD process framework
51
Elicitation
Analysis
Specification
Validationre-evaluate
Adapted from Wiegers & Beatty
identifying, discovering
evaluating,
verifying
documenting, SRS
classifying,
representing,
deriving,
negotiating
RD: Requirements Development
SRS: Software Requirements Specification
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Specification: Definition
52
Acc. to Wiegers & Beatty
Specification
“[Specification is the] process of documenting a
software application's requirements in a
structured, shareable, and manageable form.
Also, the product from this process.”
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 53
A structured approach to RD
Granular goals
CG3
CG2CG1
Coarse goals
Define
stakeholders
Define
goals
Define
requirements
DiagramsTemplates
Models
WHO
WHAT
HOW
classifying,
representing,
deriving,
negotiating
identifying, discovering
documenting, SRS
+
+
evaluating, verifying+
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 54
Key actions in specification
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Key action
55
Acc. to Wiegers & BeattyS
pec
ific
ati
on
Translating the collected user needs into written
requirements and diagrams suitable for
comprehension, review, and use by their intended
audiences.
According to Wiegers & Beatty
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 56
Relationships among several types
of requirements information
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 57
Origins of / influences from…
Business
requirementsBusiness
rules
User
requirements
Quality
attributes
System
requirements
Functional
requirements
External
interfaces
Constraints
Adapted from Wiegers & Beatty
See lecture “A Structured Approach to Requirements Analysis” for details!
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 58
Requirements documents
Image © Salvatore Vuono @ http://www.freedigitalphotos.net/
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 59
Requirements are stored in…
Vision and Scope Document
Software Requirements Specification (SRS)
User Requirements Document
Business
requirementsBusiness
rules
User
requirements
Quality
attributes
System
requirements
Functional
requirements
External
interfaces
Constraints
Adapted from Wiegers & Beatty
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 60
Documentation templates
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 61
Vision and Scope Template
1. Business Requirements
1.1. Background
1.2. Business Opportunity
1.3. Business Objectives
1.4. Success Metrics
1.5. Vision Statement
1.6. Business Risks
1.7. Business Assumptions and Dependencies
2. Scope and Limitations
2.1. Major Features
2.2. Scope of Initial Release
2.3. Scope of Subsequent Releases
2.4. Limitations and Exclusions
3. Business Context
3.1. Stakeholder Profiles
3.2. Project Priorities
3.3. Deployment Considerations
Acc. to Wiegers & Beatty
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 62
The SRS
According to Wiegers & Beatty:
“[The software requirements specification
(SRS) is a] collection of the functional and
non-functional requirements for a software
product.”
Functions and capabilities that a software must provide.
Basis for subsequent projects planning, design, coding,
testing and user documentation.
Acc. to Wiegers & Beatty
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 63
SRS Template
1. Introduction (Purpose. Document conventions. Project Scope.
References)
2. Overall Description (Product perspective. User classes and
characteristics. Operating environment. Design and implementation
constraints. Assumptions and dependencies)
3. System Features (System feature x1. Description. Functional
requirements. System feature x2, …)
4. Data Requirements (Logical data model. Data dictionary. Reports.
Data acquisition, integrity, retention, and disposal)
5. External Interface Requirements (User interfaces. Software
interfaces. Hardware interfaces. Communications interfaces)
6. Quality Attributes (Usability. Performance. Security. Safety. Others)
7. Internationalization and Localization Requirements
8. Other Requirements
Appendix A: Glossary
Appendix B: Analysis Models
Acc. to Wiegers & Beatty
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 64
So far…
Where does the major content come from?
Requirements Engineering and Requirements
Development: An Overview
Requirements Analysis. Key actions in analysis.
Requirements Specification. Actions and templates
What are good requirements? Quality criteria
How do we construct “perfect” requirements?
- User stories and the Rupp’s template-based approach
Good practices in analysis and specification
What’s next? Further reading, sources of inspiration
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 65
Next topics…
Where does the major content come from?
Requirements Engineering and Requirements
Development: An Overview
Requirements Analysis. Key actions in analysis.
Requirements Specification. Actions and templates
What are good requirements? Quality criteria
How do we construct “perfect” requirements?
- User stories and the Rupp’s template-based approach
Good practices in analysis and specification
What’s next? Further reading, sources of inspiration
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 66
What are good requirements?
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 67
Good requirements?
Image © Stuart Miles @ http://www.freedigitalphotos.net/
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 68
Quality criteria for requirements
Mind map created with https://bubbl.us/
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 69
Active learning exercise:
“First, try to explain what does
each quality criteria intuitively
mean to you!”
Image © renjith krishnan at http://www.freedigitalphotos.net/
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Quality criteria for requirements
70
comprehensive
correct
valid and current
agreed upon
necessary
understandable
traceable
rated
implementable
consistent
classifiable
testable
unambiguous
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Quality criteria for requirements
71
Definitions according to
Rupp and The SOPHISTs
comprehensive
correct
valid and current
agreed upon
necessary
understandable
traceable
rated
implementable
consistent
classifiable
testable
unambiguous
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Quality criteria for requirements
comprehensive
correct
valid and current
agreed upon
necessary
understandable
traceable
rated
implementable
consistent
classifiable
testable
unambiguous
72
“Every single requirement must
describe the called-for and
deliverable functionality in full.”
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Quality criteria for requirements
comprehensive
correct
valid and current
agreed upon
necessary
understandable
traceable
rated
implementable
consistent
classifiable
testable
unambiguous
73
“A requirement is correct if it
expresses exactly what the author
was trying to illustrate.”
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Quality criteria for requirements
comprehensive
correct
valid and current
agreed upon
necessary
understandable
traceable
rated
implementable
consistent
classifiable
testable
unambiguous
74
“A requirement must describe the
system’s reality. If one of the
influencing factors changes, all the
requirements affected must be
adapted.”
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Quality criteria for requirements
comprehensive
correct
valid and current
agreed upon
necessary
understandable
traceable
rated
implementable
consistent
classifiable
testable
unambiguous
75
“A requirement can be said to be
agreed upon if all stakeholders
determine it to be correct and valid.”
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Quality criteria for requirements
comprehensive
correct
valid and current
agreed upon
necessary
understandable
traceable
rated
implementable
consistent
classifiable
testable
unambiguous
“A requirement is necessary if – and
only if – it somehow helps meet the
system‘s goals.”
76
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Quality criteria for requirements
comprehensive
correct
valid and current
agreed upon
necessary
understandable
traceable
rated
implementable
consistent
classifiable
testable
unambiguous
77
“The requirement must be
understandable by all stakeholders.
[I]t is of importance to create a
common language for all the
involved.”
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Quality criteria for requirements
comprehensive
correct
valid and current
agreed upon
necessary
understandable
traceable
rated
implementable
consistent
classifiable
testable
unambiguous
78
“Every requirement must be
uniquely identifiable. [The] unique
identifiers [make] it possible to trace
an overall system goal across all
specification levels.”
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Quality criteria for requirements
comprehensive
correct
valid and current
agreed upon
necessary
understandable
traceable
rated
implementable
consistent
classifiable
testable
unambiguous
79
“Once a system becomes
sufficiently complex or large, it is
important to rate requirements
according to their importance or
priority.”
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Quality criteria for requirements
comprehensive
correct
valid and current
agreed upon
necessary
understandable
traceable
rated
implementable
consistent
classifiable
testable
unambiguous
80
“It must be possible to implement
every requirement within the
constraints laid down by current
technology, the systems extent and
its environment.”
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Quality criteria for requirements
comprehensive
correct
valid and current
agreed upon
necessary
understandable
traceable
rated
implementable
consistent
classifiable
testable
unambiguous
81
“Requirements must be consistent
with all other requirements –
independent of their level of
abstraction or type. [T]here are no
contradictory statements.”
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Quality criteria for requirements
comprehensive
correct
valid and current
agreed upon
necessary
understandable
traceable
rated
implementable
consistent
classifiable
testable
unambiguous
82
“Delineate the level of legal
obligation for every single
requirement.”
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Quality criteria for requirements
comprehensive
correct
valid and current
agreed upon
necessary
understandable
traceable
rated
implementable
consistent
classifiable
testable
unambiguous
83
“A requirement must be formulated
in a way that it can be tested. This
means that it should be possible to
prove any functionality requested by
a requirement.”
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Quality criteria for requirements
comprehensive
correct
valid and current
agreed upon
necessary
understandable
traceable
rated
implementable
consistent
classifiable
testable
unambiguous
84
“It ought not to be possible to
interpret [the meaning] differently. All
readers of the requirement should
understand it in a specific,
consistent fashion.”
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 85
Active learning exercise
Image © renjith krishnan at http://www.freedigitalphotos.net/
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Quiz
86
You have to design a requirements document in such a
way that is particularly well suited for people who will work
with the document in further phases of the development
process. Choose from the following sentences the correct
combination of role and requirements characteristics!
(A) For the testers, the requirements have to be realisable.
(B) For the maintenance staff, the requirements have to be
testable.
(C) For the developers, the requirements have to be easily
changeable.
(D) For all people involved, the requirements have to be
consistent.(Taken from the public Examination Questionnaire Set © IREB,
International Requirements Engineering Board e.V.)
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 87
So far…
Where does the major content come from?
Requirements Engineering and Requirements
Development: An Overview
Requirements Analysis. Key actions in analysis.
Requirements Specification. Actions and templates
What are good requirements? Quality criteria
How do we construct “perfect” requirements?
- User stories and the Rupp’s template-based approach
Good practices in analysis and specification
What’s next? Further reading, sources of inspiration
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 88
Next topics…
Where does the major content come from?
Requirements Engineering and Requirements
Development: An Overview
Requirements Analysis. Key actions in analysis.
Requirements Specification. Actions and templates
What are good requirements? Quality criteria
How do we construct “perfect” requirements?
- User stories and the Rupp’s template-based approach
Good practices in analysis and specification
What’s next? Further reading, sources of inspiration
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 89
How do we construct
“perfect” requirements?
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Dilbert
Scott Adams
At http://dilbert.com/strips/comic/2006-01-29/
(Educational/Classroom usage permission is granted by Universal Uclick. All Rights Reserved)
Surely not this way!
90
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 91
User stories
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 92
User story: Definition
According to Wiegers & Beatty:
“[A user story is a] format to capture user
requirements on agile projects in the form of
one or two sentences that articulate a user
need or describe a unit of desired
functionality, as well as stating the benefit of
the functionality to the user.”
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 93
User story: Definition
According to Cohn:
“[A user story] describes functionality that
will be valuable to either a user or a
purchaser of a system or software.”
“[It is composed of] a written description
used for planning, conversations to flesh out
the details, and tests that convey and
document details.”
Also: Story card
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 94
A good user story is…
I
N
V
E
S
TAccording to Bill Wakw @ http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
– Independent
– Negotiable
– Valuable
– Estimable
– Small
– Testable
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Dilbert
Scott Adams
At http://dilbert.com/strip/2007-08-24/
(Educational/Classroom usage permission is granted by Universal Uclick. All Rights Reserved)
Priorities are important!
95
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 96
The front of a story card
Acc. to Cohn
Image © Stuart Miles @ http://www.freedigitalphotos.net/
Conver-
sations
The
description
A company can pay for a job posting with
a credit card.
Note: Will we accept Discover cards?
Note for UI: Don’t have a field for card
type(it can be derived from first two digits
on the card)
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 97
The back of the story card
Image © Stuart Miles @ http://www.freedigitalphotos.net/
How to
test the
user story
Test with Visa/MasterCard/American Express.
Acc. to Cohn
Test with Diner’s Club.
Test with good/bad/missing card ID numbers.
Test with expired cards.
Test with over $100 and under $100.
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 98
Rupp’s template-based approach
for constructing requirements
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Chris Rupp & The SOPHISTs
© https://www.sophist.de/
Consulting and training
company
Specialists for Requirements
Engineering, Requirements
Management, Object-
oriented Analysis, Object-
oriented Design and Agile.
99
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Requirements template
Definition according to Chris Rupp:
“A requirements template is a blueprint
which delineates the syntactic structure
of a requirement”.
…quality assurance of unambiguous,
complete and testable requirements!
100
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 101
Constructing perfect requirements
in six steps
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Identify the desired functionality!
Use process words to describe the process!
Reduce the number of process words to the
words actually relevant to the system!
Step 1
Determine the process which the requirement
will denote as a requisite.
102
Acc. to Rupp et al.
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Identify the desired functionality!
Use process words to describe the process!
Reduce the number of process words to the
words actually relevant to the system!
Step 1
Determine the process which the requirement
will denote as a requisite.
Examples:
print, save, transmit, calculate
103
Acc. to Rupp et al.
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Identify the desired functionality!
Use process words to describe the process!
Reduce the number of process words to the
words actually relevant to the system!
Step 1
Determine the process which the requirement
will denote as a requisite.
104
Acc. to Rupp et al.
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Identify the desired functionality!
Use process words to describe the process!
Reduce the number of process words to the
words actually relevant to the system!
Step 1
Determine the process which the requirement
will denote as a requisite.
Examples:
insert – The SYSTEM inserts new data.
select – The USER selects one element of a finite set.
105
Acc. to Rupp et al.
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Identify the desired functionality!
Use process words to describe the process!
Reduce the number of process words to the
words actually relevant to the system!
Step 1
Determine the process which the requirement
will denote as a requisite.
106
Acc. to Rupp et al.
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Identify the desired functionality!
Use process words to describe the process!
Reduce the number of process words to the
words actually relevant to the system!
Step 1
Determine the process which the requirement
will denote as a requisite.
Examples:
Do “enter,” “input” and “insert” should have the same
semantic within the requirements or not?
107
Acc. to Rupp et al.
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Step 2
Characterise the activity of the system.
Is it an independent system activity?
(The system executes the process independently)
The system …provide <whom>
with the ability to
verb
<process>
be able to
<process>
108
Acc. to Rupp et al.
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Step 2
Characterise the activity of the system.
Is it an independent system activity?
(The system executes the process independently)
Example:
The system … prints.
The system …provide <whom>
with the ability to
verb
<process>
be able to
<process>
109
Acc. to Rupp et al.
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Step 2
Characterise the activity of the system.
Is it a user interaction?
(The system provides the user with the ability to
use the process functionality)
The system …provide <whom>
with the ability to
verb
<process>
be able to
<process>
110
Acc. to Rupp et al.
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Step 2
Characterise the activity of the system.
Is it a user interaction?
(The system provides the user with the ability to
use the process functionality)
Example:
The system provides the receptionist with the ability to print.
The system …provide <whom>
with the ability to
verb
<process>
be able to
<process>
111
Acc. to Rupp et al.
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Step 2
Characterise the activity of the system.
Is it an interface requirement?
(The system executes a process dependent upon a
third party, is passive and requires an external event)
The system …provide <whom>
with the ability to
verb
<process>
be able to
<process>
112
Acc. to Rupp et al.
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Step 2
Characterise the activity of the system.
Is it an interface requirement?
(The system executes a process dependent upon a
third party, is passive and requires an external event)
Example:
The system … is able to receive data from the library.
The system …provide <whom>
with the ability to
verb
<process>
be able to
<process>
113
Acc. to Rupp et al.
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Step 3
Determine the degree of legal obligation.
Which is the legal relevance of the requirement?
Use modal verbs!
The system shouldprovide <whom>
with the ability to
verb
<process>
be able to
<process>will
shall
114
Acc. to Rupp et al.
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Step 3
Determine the degree of legal obligation.
Which is the legal relevance of the requirement?
Use modal verbs!
The system shouldprovide <whom>
with the ability to
verb
<process>
be able to
<process>will
shall
Example:The system shall provide the receptionist with the ability to print.
115
Acc. to Rupp et al.
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Step 3
Legal obligation = degree of obligation
stakeholders attach to the statements.
Degree of obligation Keyword
Binding shall
Nice to have should
Aim will
116
fulfilment
mandatory
implementation
suggestion
intention, future
developments
Acc. to Rupp et al.
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 117
The MoSCoW method
MoSCoW
M
U
S
T
S
H
O
U
L
D
C
O
U
L
D
W
O
N‘
T
Image © Matt Banks @ http://www.freedigitalphotos.net/
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Step 4
Fine tune the requirement.
Which objects and complements are missing?
Add them!
The system shouldprovide <whom>
with the ability to
verb
<process>
be able to
<process>will
shall
objectadditional details
about the object
118
Acc. to Rupp et al.
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Step 4
Fine tune the requirement.
Which objects and complements are missing?
Add them!
The system shouldprovide <whom>
with the ability to
verb
<process>
be able to
<process>will
shall
Example:The system shall provide the receptionist with the ability to print a bill on the network printer.
objectadditional details
about the object
119
Acc. to Rupp et al.
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Step 5
Phrase logical and temporal conditions.
Which conditions and prerequisites need to be met
before for your requirement to be valid?
Place them in front of the requirement!
the
systemshould
provide <whom>
with the ability to
verb
<process>
be able to
<process>will
shall
objectadditional details
about the object
When? / Under
what conditions?
120
Acc. to Rupp et al.
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Step 5
Phrase logical and temporal conditions.
Which conditions and prerequisites need to be met
before for your requirement to be valid?
Place them in front of the requirement!
the
systemshould
provide <whom>
with the ability to
verb
<process>
be able to
<process>will
shall
Example:If the option “Bill required” has been selected on the mobile device, the system shall provide the receptionist with the ability to print a bill on the network printer.
objectadditional details
about the object
When? / Under
what conditions?
121
Acc. to Rupp et al.
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Step 6
Use the SOPHIST-Rulebook to ensure
completeness of the semantic meaning.
Apply the rules and tests from the SOPHIST set
of REgulations!
Avoid incomplete information (deletion)!
Avoid statements falsifying reality (distortion)!
Avoid erroneous generalisations (generalization)!
122
Acc. to Rupp et al.
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Step 6
Use the SOPHIST-Rulebook to ensure
completeness of the semantic meaning.
Apply the rules and tests from the SOPHIST set
of REgulations!
Avoid incomplete information (deletion)!
Avoid statements falsifying reality (distortion)!
Avoid erroneous generalisations (generalization)!
(A bad) Example:Customers who are not authorised are displayed.
(What is to be displayed? To whom? How? When?)
123
Acc. to Rupp et al.
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Step 6
Use the SOPHIST-Rulebook to ensure
completeness of the semantic meaning.
Apply the rules and tests from the SOPHIST set
of REgulations!
Avoid incomplete information (deletion)!
Avoid statements falsifying reality (distortion)!
Avoid erroneous generalisations (generalization)!
124
Acc. to Rupp et al.
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Step 6
Use the SOPHIST-Rulebook to ensure
completeness of the semantic meaning.
Apply the rules and tests from the SOPHIST set
of REgulations!
Avoid incomplete information (deletion)!
Avoid statements falsifying reality (distortion)!
Avoid erroneous generalisations (generalization)!
(A bad) Example:The system shall allow for archiving.
(Which exact process is meant by the noun?)
125
Acc. to Rupp et al.
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Step 6
Use the SOPHIST-Rulebook to ensure
completeness of the semantic meaning.
Apply the rules and tests from the SOPHIST set
of REgulations!
Avoid incomplete information (deletion)!
Avoid statements falsifying reality (distortion)!
Avoid erroneous generalisations (generalisation)!
126
Acc. to Rupp et al.
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Step 6
Use the SOPHIST-Rulebook to ensure
completeness of the semantic meaning.
Apply the rules and tests from the SOPHIST set
of REgulations!
Avoid incomplete information (deletion)!
Avoid statements falsifying reality (distortion)!
Avoid erroneous generalisations (generalisation)!
(A bad) Example:The data has to be graphically displayed to the user.
(Which data exactly? To which users exactly?)
127
Acc. to Rupp et al.
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 128
Summarising…
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Rupp’s template – Six steps
the
systemshould
provide <whom>
with the ability to
verb
<process>
be able to
<process>will
shall
objectadditional details
about the object
When? / Under
what conditions?
129
Adapted from Rupp et al.
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Rupp’s template – Six steps
the
systemshould
provide <whom>
with the ability to
verb
<process>
be able to
<process>will
shall
objectadditional details
about the object
When? / Under
what conditions?
130
1: Determine the process,
identify the functionality
Adapted from Rupp et al.
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Rupp’s template – Six steps
the
systemshould
provide <whom>
with the ability to
verb
<process>
be able to
<process>will
shall
objectadditional details
about the object
When? / Under
what conditions?
131
1: Determine the process,
identify the functionality
2: Characterise the activity
of the system
Adapted from Rupp et al.
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Rupp’s template – Six steps
the
systemshould
provide <whom>
with the ability to
verb
<process>
be able to
<process>will
shall
objectadditional details
about the object
When? / Under
what conditions?
132
1: Determine the process,
identify the functionality
2: Characterise the activity
of the system
3: Determine legal
obligation
Adapted from Rupp et al.
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Rupp’s template – Six steps
the
systemshould
provide <whom>
with the ability to
verb
<process>
be able to
<process>will
shall
objectadditional details
about the object
When? / Under
what conditions?
133
1: Determine the process,
identify the functionality
2: Characterise the activity
of the system
3: Determine legal
obligation
4: Fine tune the
requirement
Adapted from Rupp et al.
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Rupp’s template – Six steps
the
systemshould
provide <whom>
with the ability to
verb
<process>
be able to
<process>will
shall
objectadditional details
about the object
When? / Under
what conditions?
134
1: Determine the process,
identify the functionality
2: Characterise the activity
of the system
3: Determine legal
obligation
4: Fine tune the
requirement
5: Phrase
conditions
Adapted from Rupp et al.
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Rupp’s template – Six steps
the
systemshould
provide <whom>
with the ability to
verb
<process>
be able to
<process>will
shall
objectadditional details
about the object
When? / Under
what conditions?
135
1: Determine the process,
identify the functionality
2: Characterise the activity
of the system
3: Determine legal
obligation
4: Fine tune the
requirement
5: Phrase
conditions
6: Use SOPHIST-
Rulebook
Adapted from Rupp et al.
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 136
So far…
Where does the major content come from?
Requirements Engineering and Requirements
Development: An Overview
Requirements Analysis. Key actions in analysis.
Requirements Specification. Actions and templates
What are good requirements? Quality criteria
How do we construct “perfect” requirements?
- User stories and the Rupp’s template-based approach
Good practices in analysis and specification
What’s next? Further reading, sources of inspiration
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 137
Next topics…
Where does the major content come from?
Requirements Engineering and Requirements
Development: An Overview
Requirements Analysis. Key actions in analysis.
Requirements Specification. Actions and templates
What are good requirements? Quality criteria
How do we construct “perfect” requirements?
- User stories and the Rupp’s template-based approach
Good practices in analysis and specification
What’s next? Further reading, sources of inspiration
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 138
Good practices:
Requirements analysis
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Good practices
Model the application environment, define its
boundaries and external entities.
Create user interface and technical prototypes.
Analyse requirements feasibility and their risks.
Prioritize the requirements.
Create a consistent data dictionary.
Model the requirements using diagrams.
Analyse interfaces between your system and the
outside world.
Allocate requirements to subsystems.
139
Acc. to Wiegers & Beatty
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 140
Good practices:
Requirements specification
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Good practices
Adopt requirement document templates for
documenting requirements.
Identify requirement origins to ensure that all
stakeholder know why every requirement is
needed.
Uniquely label each requirement for later
management.
Record business rules separately from project’s
requirements.
Specify non-functional requirements to satisfy the
users’ quality expectations.
141
Acc. to Wiegers & Beatty
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 142
Trello.com
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 143
To take away…
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 144
Quality criteria for requirements
Mind map created with https://bubbl.us/
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Use the Rupp’s template!
Construct perfect requirements!
the
systemshould
provide <whom>
with the ability to
verb
<process>
be able to
<process>will
shall
objectadditional details
about the object
When? / Under
what conditions?
145
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 146
So far…
Where does the major content come from?
Requirements Engineering and Requirements
Development: An Overview
Requirements Analysis. Key actions in analysis.
Requirements Specification. Actions and templates
What are good requirements? Quality criteria
How do we construct “perfect” requirements?
- User stories and the Rupp’s template-based approach
Good practices in analysis and specification
What’s next? Further reading, sources of inspiration
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 147
Next topics…
Where does the major content come from?
Requirements Engineering and Requirements
Development: An Overview
Requirements Analysis. Key actions in analysis.
Requirements Specification. Actions and templates
What are good requirements? Quality criteria
How do we construct “perfect” requirements?
- User stories and the Rupp’s template-based approach
Good practices in analysis and specification
What’s next? Further reading, sources of inspiration
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 148
What comes next?
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 149
Subdisciplines of Requirements Development
Requirements
Engineering
Requirements
Development
Requirements
Management
Elicitation Analysis Specification Validation
Also topic of lecture
“Modelling Software Requirements. Important diagrams and templates”
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
RD process framework
150
Elicitation
Analysis
Specification
Validationre-evaluate
Adapted from Wiegers & Beatty
identifying, discovering
evaluating,
verifying
documenting, SRS
classifying,
representing,
deriving,
negotiating
RD: Requirements Development
SRS: Software Requirements Specification
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 151
A structured approach to RD
Granular goals
CG3
CG2CG1
Coarse goals
Define
stakeholders
Define
goals
Define
requirements
DiagramsTemplates
Models
WHO
WHAT
HOW
classifying,
representing,
deriving,
negotiating
identifying, discovering
documenting, SRS
+
+
evaluating, verifying+
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 152
Other references
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Other books
153
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Other books
154
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Further reading
IREB - International Requirements Engineering
Board e.V.
http://www.ireb.org/en/service/downloads.html
155
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Further reading
Ch. Rupp, R. Joppich, Ch. Wünch (2010): “Molecular
Requirements Engineering: The Blueprint of a Perfect
Requirement”.
Ch. Rupp (2010): “In medias RE”.
Ch. Rupp, E. Wolf (2011): “The SOPHIST Set of
REgulations”.
Ch. Rupp, R. Joppich (2010): “Templates – Construction
Plans for Requirements and for More”.
All available at https://www.sophist.de/en/information-
pool/downloads/open-download-area/
156
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Conference sites…
21st International Working Conference on
Requirements Engineering: Foundation for Software
Quality (REFSQ 2015), Essen, Germany
http://refsq.org/2015/
157
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Conference sites…
23rd IEEE International Requirements Engineering
Conference (RE’15), Ottawa, Canada
http://re15.org/
158
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 159
Homework:
“Apply the Rupp’s template to
construct perfect requirements
for one of your current course
projects!”
Image © renjith krishnan at http://www.freedigitalphotos.net/
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 160
The traditional software
development process:
Perceptions, communication patterns
and interests…
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 161Cartoon http://projectcartoon.com/
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 162
The ideal, perfect, still possible
software development process:
Perceptions, communication patterns
and interests…
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 163Adapted from cartoon http://projectcartoon.com/
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 164
Done!
Where does the major content come from?
Requirements Engineering and Requirements
Development: An Overview
Requirements Analysis. Key actions in analysis.
Requirements Specification. Actions and templates
What are good requirements? Quality criteria
How do we construct “perfect” requirements?
- User stories and the Rupp’s template-based approach
Good practices in analysis and specification
What’s next? Further reading, sources of inspiration
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Requirements Engineering
Methods for
Documenting Requirements
Prof. Dr. Dagmar Monett DíazComputer Science Dept.
Faculty of Cooperative Studies
Berlin School of Economics and Law
Europe Week, 2nd – 6th March 2015
monettdiaz@dmonett