This document outlines a lecture on requirements engineering. It begins by defining requirements engineering as an iterative cooperative process aimed at guaranteeing that all relevant requirements are known, understood, and agreed upon by stakeholders. The document then discusses the main subdisciplines of requirements engineering including requirements development and requirements management. For requirements development, it identifies the key processes of elicitation, analysis, specification and validation. For requirements management, it discusses tracking, managing, controlling and tracing requirements. The document provides definitions and examples to explain these concepts at a high level.

1. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
A Structured Approach to
Requirements Analysis
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
90 Minutes

2. 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

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 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

5. 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

6. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 6
©

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
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

9. 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

10. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 10
The traditional software
development process:
Perceptions, communication patterns
and interests…

11. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 11Cartoon  http://projectcartoon.com/

12. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 12Cartoon  http://projectcartoon.com/

13. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 13Cartoon  http://projectcartoon.com/

14. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 14Cartoon  http://projectcartoon.com/

15. 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?

16. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 16
What is a requirement?
– Definitions –

17. 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.“

18. 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.“

19. 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).“

20. 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.”

21. 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.”

22. 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.”

23. 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.”

24. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 24
Active learning exercise
Image © renjith krishnan at http://www.freedigitalphotos.net/

25. 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.

26. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 26
Relationships among several types
of requirements information

27. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 27
Levels of software requirements
Business
requirements
User
requirements
Functional
requirements
Adapted from Wiegers & Beatty

28. 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

29. 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

30. 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

31. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 31
Several types of requirements
Business
requirements
User
requirements
Functional
requirements
Adapted from Wiegers & Beatty

32. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 32
Origins of / influences from…
Business
requirements
Business
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.”

33. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 33
Origins of / influences from…
Business
requirements
Business
rules
User
requirements
Quality
attributes
System
requirements
Functional
requirements
External
interfaces
Constraints
Adapted from Wiegers & Beatty

34. 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/

35. 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

36. 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

37. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 37
What is
Requirements Engineering?

38. 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)

39. 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)

40. 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)

41. 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)

42. 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

43. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 43
Subdisciplines of
Requirements Engineering

44. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 44
Subdisciplines of
Requirements Engineering
Requirements
Engineering
Requirements
Development
Requirements
Management
Acc. to Wiegers & Beatty

45. 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

46. 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

47. 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

48. 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

49. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 49
Topics of other related lectures

50. 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”

51. 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

52. 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

53. 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”

54. 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”

55. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 55
Active learning exercise
Image © renjith krishnan at http://www.freedigitalphotos.net/

56. 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.

57. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 57
Requirements “skills”

58. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 58
Most important requirements
skills by expertise level
Adapted from Joy Beatty in
“Five Steps To Building A Strong Requirements Team”
Basics
• Requirements
language
• Software
lifecycle
• Methodology

59. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 59
Most important requirements
skills by expertise level
Adapted from Joy Beatty in
“Five Steps To Building A Strong Requirements Team”
Basics
Intermediate
• Requirements
language
• Software
lifecycle
• Methodology
• Elicitation
methods
• Writing
requirements

60. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 60
Most important requirements
skills by expertise level
Adapted 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

61. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 61
Most important requirements
skills by expertise level
Adapted 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

62. 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

63. 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

64. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 64
Requirements Development

65. 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

66. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 66
Subdisciplines of
Requirements Engineering
Requirements
Engineering
Requirements
Development
Requirements
Management
Acc. to Wiegers & Beatty

67. 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

68. 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

69. 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.”

70. 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.”

71. 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.”

72. 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?”)

73. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 73
A Requirements Development
process framework

74. 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

75. 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

76. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
RD process framework
76
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

77. 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

78. 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

79. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 79
A structured approach to
Requirements Development
(Analysis included!)

80. 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

81. 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?

82. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 82
A structured approach to RD
Define
stakeholders
WHO

83. 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?

84. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 84
A structured approach to RD
Granular goals
CG3
CG2
CG1
Coarse goals
Define
stakeholders
Define
goals
WHO
WHAT

85. 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?

86. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 86
A structured approach to RD
Granular goals
CG3
CG2
CG1
Coarse goals
Define
stakeholders
Define
goals
Define
requirements
Diagrams
Templates
Models
WHO
WHAT
HOW

87. 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?

88. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 88
A structured approach to RD
Granular goals
CG3
CG2
CG1
Coarse goals
Define
stakeholders
Define
goals
Define
requirements
Diagrams
Templates
Models
WHO
WHAT
HOW

89. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 89
A structured approach to RD
Granular goals
CG3
CG2
CG1
Coarse goals
Define
stakeholders
Define
goals
Define
requirements
Diagrams
Templates
Models
WHO
WHAT
HOW

90. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 90
A structured approach to RD
Granular goals
CG3
CG2
CG1
Coarse goals
Define
stakeholders
Define
goals
Define
requirements
Diagrams
Templates
Models
WHO
WHAT
HOW
classifying,
representing,
deriving,
negotiating
identifying, discovering
documenting, SRS
+
+
evaluating, verifying
+

91. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 91
Yet another Requirements
Development Process

92. 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

93. 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

94. 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

95. 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

96. 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

97. 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

98. 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

99. 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

100. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 100
Most common
requirements risks

101. 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

102. 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

103. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 103
Benefits from a high-quality
requirements process

104. 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

105. 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

106. 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

107. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 107
Active learning exercise
Image © renjith krishnan at http://www.freedigitalphotos.net/

108. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 108
The content so far

109. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 109
To take away…

110. 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

111. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
RD process framework
111
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

112. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 112
A structured approach to RD
Granular goals
CG3
CG2
CG1
Coarse goals
Define
stakeholders
Define
goals
Define
requirements
Diagrams
Templates
Models
WHO
WHAT
HOW

113. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 113
What comes next?

114. 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

115. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
RD process framework
115
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

116. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 116
A structured approach to RD
Granular goals
CG3
CG2
CG1
Coarse goals
Define
stakeholders
Define
goals
Define
requirements
Diagrams
Templates
Models
WHO
WHAT
HOW
classifying,
representing,
deriving,
negotiating
identifying, discovering
documenting, SRS
+
+
evaluating, verifying
+

117. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 117
Other references

118. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Other books
118

119. 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

120. 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

121. 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

122. 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/

123. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 123
The traditional software
development process:
Perceptions, communication patterns
and interests…

124. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 124Cartoon  http://projectcartoon.com/

125. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 125
The ideal, perfect, still possible
software development process:
Perceptions, communication patterns
and interests…

126. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 126Adapted from cartoon  http://projectcartoon.com/

127. 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

128. D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
A Structured Approach to
Requirements Analysis
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
monettdiaz@dmonett