Prof. Dr. Computer Science (Artificial Intelligence, Software Engineering), Co-Founder AGISI.org um Computer Science Dept., Berlin School of Economics and Law
8. Mar 2015•0 gefällt mir•4,472 views
1 von 92
Methods for Validating and Testing Software Requirements (lecture slides)
8. Mar 2015•0 gefällt mir•4,472 views
Downloaden Sie, um offline zu lesen
Melden
Bildung
Online lecture at the School of Computer Science, University of Hertfordshire, Hatfield, UK, as part of the 11th Europe Week from 2nd to 6th March 2015.
Prof. Dr. Computer Science (Artificial Intelligence, Software Engineering), Co-Founder AGISI.org um Computer Science Dept., Berlin School of Economics and Law
Methods for Validating and Testing Software Requirements (lecture slides)
1. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Methods for Validating and
Testing Software Requirements
Prof. Dr. Dagmar Monett Díaz
Computer Science Dept.
Faculty of Cooperative Studies
Berlin School of Economics and Law
dagmar@monettdiaz.com
Europe Week, 2nd – 6th March 2015
60 Minutes
2. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Dilbert
Scott Adams
At http://dilbert.com/strip/2014-02-25/
(Educational/Classroom usage permission is granted by Universal Uclick. All Rights Reserved)
Different goals…
2
3. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 3
Main topics
4. 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 validation. Key actions
Reviewing requirements
- Informal and formal approaches
Testing requirements
- Validating with acceptance criteria
Good practices in validation
What’s next? Further reading, sources of inspiration
5. 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 validation. Key actions
Reviewing requirements
- Informal and formal approaches
Testing requirements
- Validating with acceptance criteria
Good practices in validation
What’s next? Further reading, sources of inspiration
7. 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
8. 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/)
8
Sommerville
9. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 9
The traditional software
development process:
Perceptions, communication patterns
and interests…
10. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 10Cartoon http://projectcartoon.com/
11. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 11Cartoon http://projectcartoon.com/
12. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 12
Requirements and
Requirements Engineering
– An Overview –
13. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 13
Requirement: A definition
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!
14. 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.
14
See lecture “A Structured Approach to Requirements Analysis” for more on this topic!
15. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 15
Subdisciplines of
Requirements Engineering
16. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 16
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!
17. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 17
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!
18. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 18
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!
19. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 19
Topics of other related lectures
20. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 20
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”
21. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 21
Subdisciplines of
Requirements Development
Requirements
Engineering
Requirements
Development
Requirements
Management
Elicitation Analysis Specification Validation
Topic of lecture
“Requirements Engineering Techniques for Eliciting Requirements”
22. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 22
Subdisciplines of
Requirements Development
Requirements
Engineering
Requirements
Development
Requirements
Management
Elicitation Specification Validation
Topics of lecture
“Requirements Engineering Methods for Documenting Requirements”
Analysis
23. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 23
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”
24. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 24
Subdisciplines of
Requirements Development
Requirements
Engineering
Requirements
Development
Requirements
Management
Elicitation Analysis Specification Validation
Topic of (this) lecture
“Methods for Validating and Testing Software Requirements”
25. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 25
A Requirements Development
process framework
26. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 26
Subdisciplines of
Requirements Development
Elicitation
Requirements
Engineering
Analysis Specification Validation
Requirements
Development
Requirements
Management
Acc. to Wiegers & Beatty
27. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
RD process framework
27
Elicitation
Analysis
Specification
Validation
re-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!
28. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 28
A structured approach to
Requirements Development
29. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 29
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?
30. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 30
A structured approach to RD
Granular goals
CG3
CG2
CG1
Coarse goals
Define
stakeholders
Define
goals
Define
requirements
Diagrams
Templates
Models
WHO
WHAT
HOW
See lecture “A Structured Approach to Requirements Analysis” for details!
31. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 31
So far…
Where does the major content come from?
Requirements Engineering and Requirements
Development: An Overview
Requirements validation. Key actions
Reviewing requirements
- Informal and formal approaches
Testing requirements
- Validating with acceptance criteria
Good practices in validation
What’s next? Further reading, sources of inspiration
32. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 32
Next topics…
Where does the major content come from?
Requirements Engineering and Requirements
Development: An Overview
Requirements validation. Key actions
Reviewing requirements
- Informal and formal approaches
Testing requirements
- Validating with acceptance criteria
Good practices in validation
What’s next? Further reading, sources of inspiration
33. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 33
Requirements Validation
34. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
RD process framework
34
Elicitation
Analysis
Specification
Validation
re-evaluate
Adapted from Wiegers & Beatty
identifying, discovering
evaluating,
verifying
documenting, SRS
classifying,
representing,
deriving,
negotiating
RD: Requirements Development
SRS: Software Requirements Specification
35. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
RD process framework
35
Elicitation
Analysis
Specification
Validation
re-evaluate
Adapted from Wiegers & Beatty
identifying, discovering
evaluating,
verifying
documenting, SRS
classifying,
representing,
deriving,
negotiating
RD: Requirements Development
SRS: Software Requirements Specification
36. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Validation and verification
36
Acc. to Wiegers & Beatty
“[Validation is the] process of evaluating a project
deliverable to determine whether it satisfies
customer needs.”
‘Are we building the right product?’
“[Verification is the] process of evaluating a
project deliverable to determine whether it satisfies
the specifications on which it was based.”
‘Are we building the product right?’
37. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 37
Key actions in validation
38. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Key actions
38
Acc. to Wiegers & Beatty
Validation
Reviewing the documented requirements to correct
any problems before the development group accepts
them.
According to Wiegers & Beatty
39. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Key actions
39
Acc. to Wiegers & Beatty
Validation
Reviewing the documented requirements to correct
any problems before the development group accepts
them.
Developing acceptance tests and criteria to confirm
that a product based on the requirements would
meet customer needs and achieve the business
objectives.
According to Wiegers & Beatty
40. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 40
So far…
Where does the major content come from?
Requirements Engineering and Requirements
Development: An Overview
Requirements validation. Key actions
Reviewing requirements
- Informal and formal approaches
Testing requirements
- Validating with acceptance criteria
Good practices in validation
What’s next? Further reading, sources of inspiration
42. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Quiz
42
Which is an activity in the validation process?
(A) Negotiating.
(B) Discovering.
(C) Evaluating.
(D) Classifying.
43. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 43
Next topics…
Where does the major content come from?
Requirements Engineering and Requirements
Development: An Overview
Requirements validation. Key actions
Reviewing requirements
- Informal and formal approaches
Testing requirements
- Validating with acceptance criteria
Good practices in validation
What’s next? Further reading, sources of inspiration
44. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 44
Reviewing requirements
45. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Dilbert
Scott Adams
At http://dilbert.com/strip/2013-02-25/
(Educational/Classroom usage permission is granted by Universal Uclick. All Rights Reserved)
Failed feedback…
45
46. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Peer review
46
“[A peer review is an] activity in which one or
more persons other than the author of a work
product examine that product with the intent of
finding defects and improvement
opportunities.”
According to Wiegers & Beatty:
47. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Peer review approaches
47
Peer deskcheck: asking one colleague to look
over your own work product.
According to Wiegers & Beatty
Passaround: inviting several colleagues to
examine a deliverable concurrently.
Walkthrough: the author describes a
deliverable and solicits comments on it.
Informal peer reviews:
48. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 48
The inspection process
49. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 49
Inspection: A definition
According to Wiegers & Beatty:
“[Inspection is a] type of formal peer review
that involves a trained team of individuals
who follow a well-defined process to examine
a work product carefully for defects.”
Originally developed by Michael Fagan at IBM (1976)
Software industry best practice
Best-established type of formal peer review
50. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 50
Inspection
The participants (<7)
The author of the work
product and perhaps
peers of the author
People who are the
sources of information
that fed into the item
being inspected
People who will do
work based on the
item being inspected
People who are responsible
for interfacing systems that
will be affected by the item
being inspected
According to Wiegers & Beatty
51. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 51
Inspection roles
Author
They look for defects and improvement opportunities
- Plays passive role during inspection, listens to
comments, answers questions.
According to Wiegers & Beatty
52. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 52
Inspection roles
Author
Moderator
They look for defects and improvement opportunities
- Plays passive role during inspection, listens to
comment