Upload
dagmar-monett-diaz
View
320
Download
1
Embed Size (px)
Citation preview
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
A Structured Approach to
Requirements Analysis
Prof. Dr. Dagmar Monett DíazComputer Science Dept.
Faculty of Cooperative Studies
Berlin School of Economics and Law
Europe Week, 2nd – 6th March 2015
90 Minutes
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Dilbert
Scott Adams
At http://dilbert.com/strip/2003-03-22/
(Educational/Classroom usage permission is granted by Universal Uclick. All Rights Reserved)
Where are the requirements?
2
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 4
Main topics
Where does the major content come from?
Requirements and their relationships
Requirements Engineering
- Definitions. Subdisciplines. Topics of related lectures.
Requirements Development
- Definitions. Subdisciplines. A process framework.
A Structured approach to Requirements Development
Requirements risks
Benefits from a high-quality requirements process
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 and their relationships
Requirements Engineering
- Definitions. Subdisciplines. Topics of related lectures.
Requirements Development
- Definitions. Subdisciplines. A process framework.
A Structured approach to Requirements Development
Requirements risks
Benefits from a high-quality requirements process
What’s next? Further reading, sources of inspiration
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 13Cartoon http://projectcartoon.com/
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 14Cartoon http://projectcartoon.com/
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Some key questions
15
- What are requirements?
- How do stakeholders define requirements?
- How are requirements documented?
- Is there a process we can follow?
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 16
What is a requirement?
– Definitions –
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 17
IEEE-Standard 610.12 (1990)
A requirement is:
(1). „A condition or capability needed by a user (be
it person or system) to solve a problem or
achieve an objective.“
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 18
IEEE-Standard 610.12 (1990)
A requirement is:
(1). „A condition or capability needed by a user (be
it person or system) to solve a problem or
achieve an objective.“
(2). „A condition or capability that must be met or
possessed by a system or system component to
satisfy a contract, standard, specification, or other
formally imposed document.“
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 19
IEEE-Standard 610.12 (1990)
A requirement is:
(1). „A condition or capability needed by a user (be
it person or system) to solve a problem or
achieve an objective.“
(2). „A condition or capability that must be met or
possessed by a system or system component to
satisfy a contract, standard, specification, or other
formally imposed document.“
(3). „A documented representation of a condition or
capability as in (1) or (2).“
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 20
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.”
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 21
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.”
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 22
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.”
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 23
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.”
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 24
Active learning exercise
Image © renjith krishnan at http://www.freedigitalphotos.net/
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Quiz
25
(Taken from the public Examination Questionnaire Set © IREB,
International Requirements Engineering Board e.V.)
Which two of the following statements define the term
“requirement” in accordance to the IEEE standard?
(A) The difference between current state and desired state.
(B) An instruction on how a requirement has to be fulfilled.
(C) A demanded capability of a system.
(D) A problem that has been identified.
(E) A capability that must be met or possessed by a system.
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 26
Relationships among several types
of requirements information
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 27
Levels of software requirements
Business
requirements
User
requirements
Functional
requirements
Adapted from Wiegers & Beatty
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 28
Levels of software requirements
Business
requirements
“A set of information that describes a business
need that leads to one or more projects to deliver a
solution and the desired ultimate business outcomes.
The business requirements include business
opportunities, business objectives, success metrics,
a vision statement, and scope and limitations.”
Example:
“Increase market share in region X by Y percent within Z months.”
Adapted from Wiegers & Beatty
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 29
Levels of software requirements
“A goal or task that specific classes of users must be able to
perform with a system, or a desired product attribute. Use cases, user
stories, and scenarios are common ways to represent user
requirements.”
Example:
“As the lead machine operator, I need to calibrate the pump
controller first thing every morning.”
User
requirements
Adapted from Wiegers & Beatty
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 30
Levels of software requirements
“A description of a behavior that a software system will exhibit under
specific conditions.”
Example:
“The user must be able to sort the project list in forward and reverse
alphabetical order.”
Functional
requirements
Adapted from Wiegers & Beatty
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 31
Several types of requirements
Business
requirements
User
requirements
Functional
requirements
Adapted from Wiegers & Beatty
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 32
Origins of / influences from…
Business
requirementsBusiness
rules
“A policy, guideline, standard,
regulation, or computational
formula that defines or constrains
some aspect of the business.”
Example:
“A new customer
must pay 30% of
travel expenses in
advance.”
Example:
“Capability to enter the
information of a new
customer in an existing
accounting system.”
Adapted from Wiegers & Beatty
“A set of information that
describes a business need.”
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 33
Origins of / influences from…
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 34
Active learning exercise:
“What can be a requirement?
Please mention other concrete
examples!”
Image © renjith krishnan at http://www.freedigitalphotos.net/
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 35
So far…
Where does the major content come from?
Requirements and their relationships
Requirements Engineering
- Definitions. Subdisciplines. Topics of related lectures.
Requirements Development
- Definitions. Subdisciplines. A process framework.
A Structured approach to Requirements Development
Requirements risks
Benefits from a high-quality requirements process
What’s next? Further reading, sources of inspiration
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 36
Next topics…
Where does the major content come from?
Requirements and their relationships
Requirements Engineering
- Definitions. Subdisciplines. Topics of related lectures.
Requirements Development
- Definitions. Subdisciplines. A process framework.
A Structured approach to Requirements Development
Requirements risks
Benefits from a high-quality requirements process
What’s next? Further reading, sources of inspiration
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 37
What is
Requirements Engineering?
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Requirements Engineering
Definition according to the IREB1:
Requirements engineering is a cooperative, itera-
tive, incremental process, aimed at guaranteeing that
38
1: International Requirements Engineering Board e.V. (see further reading at the end)
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Requirements Engineering
Definition according to the IREB1:
Requirements engineering is a cooperative, itera-
tive, incremental process, aimed at guaranteeing that
all relevant requirements are known and
understood with the necessary degree of refinement,
39
1: International Requirements Engineering Board e.V. (see further reading at the end)
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Requirements Engineering
Definition according to the IREB1:
Requirements engineering is a cooperative, itera-
tive, incremental process, aimed at guaranteeing that
all relevant requirements are known and
understood with the necessary degree of refinement,
the stakeholders involved come to a satisfactory
agreement concerning the known requirements,
40
1: International Requirements Engineering Board e.V. (see further reading at the end)
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Requirements Engineering
Definition according to the IREB1:
Requirements engineering is a cooperative, itera-
tive, incremental process, aimed at guaranteeing that
all relevant requirements are known and
understood with the necessary degree of refinement,
the stakeholders involved come to a satisfactory
agreement concerning the known requirements,
all requirements have been documented as defined
by the documentation guidelines or specification
guidelines.
41
1: International Requirements Engineering Board e.V. (see further reading at the end)
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.
42
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 43
Subdisciplines of
Requirements Engineering
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 44
Subdisciplines of Requirements Engineering
Requirements
Engineering
Requirements
Development
Requirements
Management
Acc. to Wiegers & Beatty
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 45
Subdisciplines of Requirements Engineering
Requirements
Engineering
Requirements
Development
Requirements
Management
“The process of defining a project's scope, identifying
user classes and user representatives, and eliciting,
analyzing, specifying, and validating requirements. Its
product is a set of documented requirements that defines
some portion of the product to be built.”
Acc. to Wiegers & Beatty
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 46
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 47
Subdisciplines of Requirements Engineering
Requirements
Engineering
Requirements
Development
Requirements
Management
“The process of working with a defined set of requirements
throughout the product's development process and its
operational life. Includes tracking requirements status,
managing changes to requirements, controlling versions of
requirements specs, and tracing individual requirements.”
Acc. to Wiegers & Beatty
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 48
Subdisciplines of Requirements Management
Tracking
Requirements
Engineering
Managing Controlling Tracing
Requirements
Development
Requirements
Management
Acc. to Wiegers & Beatty
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 49
Topics of other related lectures
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 50
Subdisciplines of Requirements Engineering
Elicitation
Requirements
Engineering
Analysis Specification Validation
Requirements
Development
Requirements
Management
All are topics of (this) lecture:
“A Structured Approach to Requirements Analysis”
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 51
Subdisciplines of Requirements Development
Requirements
Engineering
Requirements
Development
Requirements
Management
Elicitation Specification Validation
Topic of lecture
“Requirements Engineering Techniques for Eliciting Requirements”
Analysis
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 52
Subdisciplines of Requirements Development
Requirements
Engineering
Requirements
Development
Requirements
Management
Elicitation Specification Validation
Topics of lecture
“Requirements Engineering Methods for Documenting Requirements”
Analysis
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 53
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 54
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 55
Active learning exercise
Image © renjith krishnan at http://www.freedigitalphotos.net/
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Quiz
56
Which is not a subdiscipline of requirements development?
(A) Validation.
(B) Managing.
(C) Analysis.
(D) Elicitation.
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 58
Most important requirements skills by expertise levelAdapted from Joy Beatty in
“Five Steps To Building A Strong Requirements Team”
Basics
• Requirements
language
• Software
lifecycle
• Methodology
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 59
Most important requirements skills by expertise levelAdapted from Joy Beatty in
“Five Steps To Building A Strong Requirements Team”
Basics
Intermediate
• Requirements
language
• Software
lifecycle
• Methodology
• Elicitation
methods
• Writing
requirements
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 60
Most important requirements skills by expertise levelAdapted from Joy Beatty in
“Five Steps To Building A Strong Requirements Team”
Basics
Advanced
Intermediate
• Requirements
language
• Software
lifecycle
• Methodology
• Elicitation
methods
• Writing
requirements
• Modelling
• Reviewing
and validating
• Change
management
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 61
Most important requirements skills by expertise levelAdapted from Joy Beatty in
“Five Steps To Building A Strong Requirements Team”
Basics
Advanced
Expert
Intermediate
• Requirements
language
• Software
lifecycle
• Methodology
• Elicitation
methods
• Writing
requirements
• Modelling
• Reviewing
and validating
• Change
management
• Facilitating large
groups
• Decision making
• Resolving conflicts
• Gaining
consensus
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 62
So far…
Where does the major content come from?
Requirements and their relationships
Requirements Engineering
- Definitions. Subdisciplines. Topics of related lectures.
Requirements Development
- Definitions. Subdisciplines. A process framework.
A Structured approach to Requirements Development
Requirements risks
Benefits from a high-quality requirements process
What’s next? Further reading, sources of inspiration
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 63
Next topics…
Where does the major content come from?
Requirements and their relationships
Requirements Engineering
- Definitions. Subdisciplines. Topics of related lectures.
Requirements Development
- Definitions. Subdisciplines. A process framework.
A Structured approach to Requirements Development
Requirements risks
Benefits from a high-quality requirements process
What’s next? Further reading, sources of inspiration
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Dilbert
Scott Adams
At http://dilbert.com/strip/1993-09-08/
(Educational/Classroom usage permission is granted by Universal Uclick. All Rights Reserved)
Missing requirements?
65
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 66
Subdisciplines of Requirements Engineering
Requirements
Engineering
Requirements
Development
Requirements
Management
Acc. to Wiegers & Beatty
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 67
Subdisciplines of Requirements Engineering
Requirements
Engineering
Requirements
Development
Requirements
Management
“The process of defining a project's scope, identifying
user classes and user representatives, and eliciting,
analyzing, specifying, and validating requirements. Its
product is a set of documented requirements that defines
some portion of the product to be built.”
Acc. to Wiegers & Beatty
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 68
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
Requirements development
69
Acc. to Wiegers & Beatty
Elicitation
Analysis
Specification
Validation
“The process of identifying, discovering requirements from various
sources through interviews, workshops, focus groups, observations,
document analysis, and other mechanisms.”
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Requirements development
70
Acc. to Wiegers & Beatty
Elicitation
Analysis
Specification
Validation
“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
Requirements development
71
Acc. to Wiegers & Beatty
Elicitation
Analysis
Specification
Validation
“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
Requirements development
72
Acc. to Wiegers & Beatty
Elicitation
Analysis
Specification
Validation
“The process of evaluating a project deliverable to determine whether it
satisfies customer needs. Often stated as "Are we building the right product?”
(Verification: “Are we building the product right?”)
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 73
A Requirements Development
process framework
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
RD process framework
74
Elicitation
Analysis
Specification
Validation
RD: Requirements Development
SRS: Software Requirements Specification
identifying, discovering
evaluating,
verifying
documenting, SRS
classifying,
representing,
deriving,
negotiating
Adapted from Wiegers & Beatty
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
RD process framework
75
Elicitation
Analysis
Specification
Validation
RD: Requirements Development
SRS: Software Requirements Specification
identifying, discovering
evaluating,
verifying
documenting, SRS
classifying,
representing,
deriving,
negotiating
Adapted from Wiegers & Beatty
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
RD process framework
76
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 77
So far…
Where does the major content come from?
Requirements and their relationships
Requirements Engineering
- Definitions. Subdisciplines. Topics of related lectures.
Requirements Development
- Definitions. Subdisciplines. A process framework.
A Structured approach to Requirements Development
Requirements risks
Benefits from a high-quality requirements process
What’s next? Further reading, sources of inspiration
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 78
Next topics…
Where does the major content come from?
Requirements and their relationships
Requirements Engineering
- Definitions. Subdisciplines. Topics of related lectures.
Requirements Development
- Definitions. Subdisciplines. A process framework.
A Structured approach to Requirements Development
Requirements risks
Benefits from a high-quality requirements process
What’s next? Further reading, sources of inspiration
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 79
A structured approach to
Requirements Development
(Analysis included!)
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Dilbert
Scott Adams
At http://dilbert.com/strip/2001-04-14/
(Educational/Classroom usage permission is granted by Universal Uclick. All Rights Reserved)
How much, how deep?
80
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 81
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?
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 82
A structured approach to RD
Define
stakeholders
WHO
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 83
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?
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 84
A structured approach to RD
Granular goals
CG3
CG2CG1
Coarse goals
Define
stakeholders
Define
goals
WHO
WHAT
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 85
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 86
A structured approach to RD
Granular goals
CG3
CG2CG1
Coarse goals
Define
stakeholders
Define
goals
Define
requirements
DiagramsTemplates
Models
WHO
WHAT
HOW
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 87
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 88
A structured approach to RD
Granular goals
CG3
CG2CG1
Coarse goals
Define
stakeholders
Define
goals
Define
requirements
DiagramsTemplates
Models
WHO
WHAT
HOW
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 89
A structured approach to RD
Granular goals
CG3
CG2CG1
Coarse goals
Define
stakeholders
Define
goals
Define
requirements
DiagramsTemplates
Models
WHO
WHAT
HOW
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 90
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 91
Yet another Requirements
Development Process
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 92
Yet another RD Process
Adapted from “Requirements Engineering Process” (Michael Schenkel, microTOOL 2014)
Define
system’s context
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 93
Yet another RD Process
Adapted from “Requirements Engineering Process” (Michael Schenkel, microTOOL 2014)
Define
system’s context
Analyse
stakeholders
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 94
Yet another RD Process
Adapted from “Requirements Engineering Process” (Michael Schenkel, microTOOL 2014)
Define
system’s context
Analyse
stakeholders
Define
goals
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 95
Yet another RD Process
Adapted from “Requirements Engineering Process” (Michael Schenkel, microTOOL 2014)
Define
system’s context
Analyse
stakeholders
Define
goals
Describe
scenarios
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 96
Yet another RD Process
Adapted from “Requirements Engineering Process” (Michael Schenkel, microTOOL 2014)
Define
system’s context
Analyse
stakeholders
Define
goals
Describe
scenarios
Define requirements
Model the
system
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 97
Yet another RD Process
Adapted from “Requirements Engineering Process” (Michael Schenkel, microTOOL 2014)
Define
system’s context
Analyse
stakeholders
Define
goals
Describe
scenarios
Define requirements
Model the
system
Validate
requirements
Document
requirements
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 98
So far…
Where does the major content come from?
Requirements and their relationships
Requirements Engineering
- Definitions. Subdisciplines. Topics of related lectures.
Requirements Development
- Definitions. Subdisciplines. A process framework.
A Structured approach to Requirements Development
Requirements risks
Benefits from a high-quality requirements process
What’s next? Further reading, sources of inspiration
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 99
Next topics…
Where does the major content come from?
Requirements and their relationships
Requirements Engineering
- Definitions. Subdisciplines. Topics of related lectures.
Requirements Development
- Definitions. Subdisciplines. A process framework.
A Structured approach to Requirements Development
Requirements risks
Benefits from a high-quality requirements process
What’s next? Further reading, sources of inspiration
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 100
Most common
requirements risks
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Requirements risks
Insufficient user involvement.
Inaccurate planning.
Creeping user requirements.
Ambiguous requirements.
Gold plating.
Overlooked stakeholders.
101
According to Wiegers & Beatty
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Problems of Req. Analysis
Stakeholders don’t know what they really want.
Stakeholders express requirements in their own
terms.
Different stakeholders may have conflicting
requirements.
Organisational and political factors may influence
the system requirements.
The requirements change during the analysis
process. New stakeholders may emerge and the
business environment change.
102
According to Ian Sommerville
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 103
Benefits from a high-quality
requirements process
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Benefits, payoff
Fewer defects in requirements and in the
delivered product.
Reduced development rework.
Faster development and delivery.
Fewer unnecessary and unused features.
Lower enhancement costs.
Fewer miscommunications.
Reduced scope creep.
Reduced project chaos.
Higher customer and team member satisfaction.
Products that do what they are supposed to do.104
According to Wiegers & Beatty
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 105
So far…
Where does the major content come from?
Requirements and their relationships
Requirements Engineering
- Definitions. Subdisciplines. Topics of related lectures.
Requirements Development
- Definitions. Subdisciplines. A process framework.
A Structured approach to Requirements Development
Requirements risks
Benefits from a high-quality requirements process
What’s next? Further reading, sources of inspiration
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 106
Next topics…
Where does the major content come from?
Requirements and their relationships
Requirements Engineering
- Definitions. Subdisciplines. Topics of related lectures.
Requirements Development
- Definitions. Subdisciplines. A process framework.
A Structured approach to Requirements Development
Requirements risks
Benefits from a high-quality requirements process
What’s next? Further reading, sources of inspiration
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 107
Active learning exercise
Image © renjith krishnan at http://www.freedigitalphotos.net/
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 110
Subdisciplines of RE and RD
Elicitation
Requirements
Engineering
Analysis Specification Validation
Requirements
Development
Requirements
Management
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
RD process framework
111
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 112
A structured approach to RD
Granular goals
CG3
CG2CG1
Coarse goals
Define
stakeholders
Define
goals
Define
requirements
DiagramsTemplates
Models
WHO
WHAT
HOW
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 114
Subdisciplines of Requirements Development
Requirements
Engineering
Requirements
Development
Requirements
Management
Elicitation Specification Validation
Topic of lecture
“Requirements Engineering Techniques for Eliciting Requirements”
Analysis
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
RD process framework
115
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 116
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
Further reading
IREB - International Requirements Engineering
Board e.V.
http://www.ireb.org/en/service/downloads.html
119
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/
120
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Conference sites…
23rd IEEE International Requirements Engineering
Conference (RE’15), Ottawa, Canada
http://re15.org/
121
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 122
Homework:
“Reflect on the topics that were
covered so far and write down
your own notes and conclusions!”
Image © renjith krishnan at http://www.freedigitalphotos.net/
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 123
The traditional software
development process:
Perceptions, communication patterns
and interests…
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 124Cartoon http://projectcartoon.com/
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 125
The ideal, perfect, still possible
software development process:
Perceptions, communication patterns
and interests…
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 126Adapted from cartoon http://projectcartoon.com/
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 127
Done!
Where does the major content come from?
Requirements and their relationships
Requirements Engineering
- Definitions. Subdisciplines. Topics of related lectures.
Requirements Development
- Definitions. Subdisciplines. A process framework.
A Structured approach to Requirements Development
Requirements risks
Benefits from a high-quality requirements process
What’s next? Further reading, sources of inspiration
D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
A Structured Approach to
Requirements Analysis
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