Requirements Engineering Methods for Documenting Requirements (lecture slides)

D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield
Requirements Engineering
Methods for
Documenting 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
120 Minutes

Dilbert
 Scott Adams
At http://dilbert.com/strip/1999-08-09/
(Educational/Classroom usage permission is granted by Universal Uclick. All Rights Reserved)
Requirements document…
2

D. Monett – Europe Week 2015, University of Hertfordshire, Hatfield 3
Main topics

Main topics
 Where does the major content come from?
 Requirements Engineering and Requirements
Development: An Overview
 Requirements Analysis. Key actions in analysis.
 Requirements Specification. Actions and templates
 What are good requirements? Quality criteria
 How do we construct “perfect” requirements?
- User stories and the Rupp’s template-based approach
 Good practices in analysis and specification
 What’s next? Further reading, sources of inspiration

Next topics…

©

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

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

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

The traditional software
development process:
Perceptions, communication patterns
and interests…

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

Requirements and
– An Overview –

A requirement is…
According to Wiegers & Beatty:
“[A requirement is a] statement of a
customer need or objective, or of a condition
or capability that a product must possess to
satisfy such a need or objective. A property
that a product must have to provide value to
a stakeholder.”
See lecture “A Structured Approach to Requirements Analysis” for more on this topic!

Definition according to Wiegers & Beatty:
Requirements engineering is the subdiscipline of
systems engineering and software engineering that
encompasses all project activities associated with
understanding a product's necessary capabilities and
attributes. Includes both requirements development
and requirements management.
15

Subdisciplines of

Subdisciplines of
Requirements
Engineering
Requirements
Development
Requirements
Management
Acc. to Wiegers & Beatty

Subdisciplines of
Requirements Development
Elicitation
Requirements
Engineering
Analysis Specification Validation
Requirements
Development
Requirements
Management

Subdisciplines of
Requirements Management
Tracking
Requirements
Engineering
Managing Controlling Tracing
Requirements
Development
Requirements
Management

Topics of other related lectures

Subdisciplines of
Elicitation
Requirements
Engineering
Requirements
Development
Requirements
Management
All are topics of lecture:
“A Structured Approach to Requirements Analysis”

Subdisciplines of
Requirements
Engineering
Requirements
Development
Requirements
Management
Elicitation Analysis Specification Validation
Topic of lecture
“Requirements Engineering Techniques for Eliciting Requirements”

Subdisciplines of
Requirements
Engineering
Requirements
Development
Requirements
Management
Elicitation Specification Validation
Topics of (this) lecture
“Requirements Engineering Methods for Documenting Requirements”
Analysis

Subdisciplines of
Requirements
Engineering
Requirements
Development
Requirements
Management
Also topic of lecture
“Modelling Software Requirements. Important diagrams and templates”

Subdisciplines of
Requirements
Engineering
Requirements
Development
Requirements
Management
Topic of lecture
“Methods for Validating and Testing Software Requirements”

A Requirements Development
process framework

Subdisciplines of
Elicitation
Requirements
Engineering
Requirements
Development
Requirements
Management

RD process framework
28
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!

A structured approach to

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?

Granular goals
CG3
CG2
CG1
Coarse goals
Define
stakeholders
Define
goals
Define
requirements
Diagrams
Templates
Models
WHO
WHAT
HOW

So far…

Next topics…

Requirements Analysis

35
Elicitation
Analysis
Specification
Validation
re-evaluate
evaluating,
verifying
documenting, SRS
classifying,
representing,
deriving,
negotiating

36
Elicitation
Analysis
Specification
Validation
re-evaluate
evaluating,
verifying
documenting, SRS
classifying,
representing,
deriving,
negotiating

Analysis: Definition
37
Analysis
“[Analysis is the] process of classifying
requirements information into various categories,
evaluating requirements for desirable qualities,
representing requirements in different forms,
deriving detailed requirements from high-level
requirements, negotiating priorities, and related
activities.”

Granular goals
CG3
CG2
CG1
Coarse goals
Define
stakeholders
Define
goals
Define
requirements
Diagrams
Templates
Models
WHO
WHAT
HOW
classifying,
representing,
deriving,
negotiating
documenting, SRS
+
+
evaluating, verifying
+

Key actions in analysis

Key actions (i)
40
Analysis
Analysing the information received from users to
distinguish their task goals from other requirements
information (functional req., business rules, etc.).
According to Wiegers & Beatty

Key actions (i)
41
Analysis
Decomposing high-level requirements into an
appropriate level of detail.

Key actions (i)
42
Deriving functional requirements.
Analysis

Key actions (i)
43
Deriving functional requirements.
Analysis
Understanding importance of quality attributes.
…

Key actions (ii)
44
Analysis
Allocating requirements to software components
defined in the system architecture.
…

Key actions (ii)
45
Negotiating implementation priorities.
Analysis
…

Key actions (ii)
46
Negotiating implementation priorities.
Analysis
Identifying gaps in requirements or unnecessary
requirements.
…

So far…

Next topics…

Requirements Specification

50
Elicitation
Analysis
Specification
Validation
re-evaluate
evaluating,
verifying
documenting, SRS
classifying,
representing,
deriving,
negotiating

51
Elicitation
Analysis
Specification
Validation
re-evaluate
evaluating,
verifying
documenting, SRS
classifying,
representing,
deriving,
negotiating

Specification: Definition
52
Specification
“[Specification is the] process of documenting a
software application's requirements in a
structured, shareable, and manageable form.
Also, the product from this process.”

Granular goals
CG3
CG2
CG1
Coarse goals
Define
stakeholders
Define
goals
Define
requirements
Diagrams
Templates
Models
WHO
WHAT
HOW
classifying,
representing,
deriving,
negotiating
documenting, SRS
+
+
+

Key actions in specification

Key action
55
Specification
Translating the collected user needs into written
requirements and diagrams suitable for
comprehension, review, and use by their intended
audiences.

Relationships among several types
of requirements information

Origins of / influences from…
Business
requirements
Business
rules
User
requirements
Quality
attributes
System
requirements
Functional
requirements
External
interfaces
Constraints

Requirements documents
Image © Salvatore Vuono @ http://www.freedigitalphotos.net/

Requirements are stored in…
Vision and Scope Document
Software Requirements Specification (SRS)
User Requirements Document
Business
requirements
Business
rules
User
requirements
Quality
attributes
System
requirements
Functional
requirements
External
interfaces
Constraints

Documentation templates

Vision and Scope Template
1. Business Requirements
1.1. Background
1.2. Business Opportunity
1.3. Business Objectives
1.4. Success Metrics
1.5. Vision Statement
1.6. Business Risks
1.7. Business Assumptions and Dependencies
2. Scope and Limitations
2.1. Major Features
2.2. Scope of Initial Release
2.3. Scope of Subsequent Releases
2.4. Limitations and Exclusions
3. Business Context
3.1. Stakeholder Profiles
3.2. Project Priorities
3.3. Deployment Considerations

The SRS
“[The software requirements specification
(SRS) is a] collection of the functional and
non-functional requirements for a software
product.”
 Functions and capabilities that a software must provide.
 Basis for subsequent projects planning, design, coding,
testing and user documentation.

SRS Template
1. Introduction (Purpose. Document conventions. Project Scope.
References)
2. Overall Description (Product perspective. User classes and
characteristics. Operating environment. Design and implementation
constraints. Assumptions and dependencies)
3. System Features (System feature x1. Description. Functional
requirements. System feature x2, …)
4. Data Requirements (Logical data model. Data dictionary. Reports.
Data acquisition, integrity, retention, and disposal)
5. External Interface Requirements (User interfaces. Software
interfaces. Hardware interfaces. Communications interfaces)
6. Quality Attributes (Usability. Performance. Security. Safety. Others)
7. Internationalization and Localization Requirements
8. Other Requirements
Appendix A: Glossary
Appendix B: Analysis Models

So far…

Next topics…

What are good requirements?

Good requirements?
Image © Stuart Miles @ http://www.freedigitalphotos.net/

Quality criteria for requirements
Mind map created with https://bubbl.us/

Active learning exercise:
“First, try to explain what does
each quality criteria intuitively
mean to you!”
Image © renjith krishnan at http://www.freedigitalphotos.net/

70
 comprehensive
 correct
 valid and current
 agreed upon
 necessary
 understandable
 traceable
 rated
 implementable
 consistent
 classifiable
 testable
 unambiguous

71
Definitions according to
Rupp and The SOPHISTs
 comprehensive
 correct
 agreed upon
 necessary
 understandable
 traceable
 rated
 implementable
 consistent
 classifiable
 testable
 unambiguous

 comprehensive
 correct
 agreed upon
 necessary
 understandable
 traceable
 rated
 implementable
 consistent
 classifiable
 testable
 unambiguous
72
“Every single requirement must
describe the called-for and
deliverable functionality in full.”

 comprehensive
 correct
 agreed upon
 necessary
 understandable
 traceable
 rated
 implementable
 consistent
 classifiable
 testable
 unambiguous
73
“A requirement is correct if it
expresses exactly what the author
was trying to illustrate.”

 comprehensive
 correct
 agreed upon
 necessary
 understandable
 traceable
 rated
 implementable
 consistent
 classifiable
 testable
 unambiguous
74
“A requirement must describe the
system’s reality. If one of the
influencing factors changes, all the
requirements affected must be
adapted.”

 comprehensive
 correct
 agreed upon
 necessary
 understandable
 traceable
 rated
 implementable
 consistent
 classifiable
 testable
 unambiguous
75
“A requirement can be said to be
agreed upon if all stakeholders
determine it to be correct and valid.”

 comprehensive
 correct
 agreed upon
 necessary
 understandable
 traceable
 rated
 implementable
 consistent
 classifiable
 testable
 unambiguous
“A requirement is necessary if – and
only if – it somehow helps meet the
system‘s goals.”
76

 comprehensive
 correct
 agreed upon
 necessary
 understandable
 traceable
 rated
 implementable
 consistent
 classifiable
 testable
 unambiguous
77
“The requirement must be
understandable by all stakeholders.
[I]t is of importance to create a
common language for all the
involved.”

 comprehensive
 correct
 agreed upon
 necessary
 understandable
 traceable
 rated
 implementable
 consistent
 classifiable
 testable
 unambiguous
78
“Every requirement must be
uniquely identifiable. [The] unique
identifiers [make] it possible to trace
an overall system goal across all
specification levels.”

 comprehensive
 correct
 agreed upon
 necessary
 understandable
 traceable
 rated
 implementable
 consistent
 classifiable
 testable
 unambiguous
79
“Once a system becomes
sufficiently complex or large, it is
important to rate requirements
according to their importance or
priority.”

 comprehensive
 correct
 agreed upon
 necessary
 understandable
 traceable
 rated
 implementable
 consistent
 classifiable
 testable
 unambiguous
80
“It must be possible to implement
every requirement within the
constraints laid down by current
technology, the systems extent and
its environment.”

 comprehensive
 correct
 agreed upon
 necessary
 understandable
 traceable
 rated
 implementable
 consistent
 classifiable
 testable
 unambiguous
81
“Requirements must be consistent
with all other requirements –
independent of their level of
abstraction or type. [T]here are no
contradictory statements.”

 comprehensive
 correct
 agreed upon
 necessary
 understandable
 traceable
 rated
 implementable
 consistent
 classifiable
 testable
 unambiguous
82
“Delineate the level of legal
obligation for every single
requirement.”

 comprehensive
 correct
 agreed upon
 necessary
 understandable
 traceable
 rated
 implementable
 consistent
 classifiable
 testable
 unambiguous
83
“A requirement must be formulated
in a way that it can be tested. This
means that it should be possible to
prove any functionality requested by
a requirement.”

 comprehensive
 correct
 agreed upon
 necessary
 understandable
 traceable
 rated
 implementable
 consistent
 classifiable
 testable
 unambiguous
84
“It ought not to be possible to
interpret [the meaning] differently. All
readers of the requirement should
understand it in a specific,
consistent fashion.”

Active learning exercise

Quiz
86
You have to design a requirements document in such a
way that is particularly well suited for people who will work
with the document in further phases of the development
process. Choose from the following sentences the correct
combination of role and requirements characteristics!
(A) For the testers, the requirements have to be realisable.
(B) For the maintenance staff, the requirements have to be
testable.
(C) For the developers, the requirements have to be easily
changeable.
(D) For all people involved, the requirements have to be
consistent.
(Taken from the public Examination Questionnaire Set © IREB,
International Requirements Engineering Board e.V.)

So far…

Next topics…

How do we construct
“perfect” requirements?

Dilbert
 Scott Adams
At http://dilbert.com/strips/comic/2006-01-29/
Surely not this way!
90

User stories

User story: Definition
“[A user story is a] format to capture user
requirements on agile projects in the form of
one or two sentences that articulate a user
need or describe a unit of desired
functionality, as well as stating the benefit of
the functionality to the user.”

User story: Definition
According to Cohn:
“[A user story] describes functionality that
will be valuable to either a user or a
purchaser of a system or software.”
“[It is composed of] a written description
used for planning, conversations to flesh out
the details, and tests that convey and
document details.”
Also: Story card

A good user story is…
I
N
V
E
S
T
According to Bill Wakw @ http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
– Independent
– Negotiable
– Valuable
– Estimable
– Small
– Testable

Dilbert
 Scott Adams
At http://dilbert.com/strip/2007-08-24/
Priorities are important!
95

The front of a story card
Acc. to Cohn
Conver-
sations
The
description
A company can pay for a job posting with
a credit card.
Note: Will we accept Discover cards?
Note for UI: Don’t have a field for card
type(it can be derived from first two digits
on the card)

The back of the story card
How to
test the
user story
Test with Visa/MasterCard/American Express.
Acc. to Cohn
Test with Diner’s Club.
Test with good/bad/missing card ID numbers.
Test with expired cards.
Test with over $100 and under $100.

Rupp’s template-based approach
for constructing requirements

Chris Rupp & The SOPHISTs
© https://www.sophist.de/
Consulting and training
company
Specialists for Requirements
Engineering, Requirements
Management, Object-
oriented Analysis, Object-
oriented Design and Agile.
99

Requirements template
Definition according to Chris Rupp:
“A requirements template is a blueprint
which delineates the syntactic structure
of a requirement”.
…quality assurance of unambiguous,
complete and testable requirements!
100

Constructing perfect requirements
in six steps

 Identify the desired functionality!
 Use process words to describe the process!
 Reduce the number of process words to the
words actually relevant to the system!
Step 1
Determine the process which the requirement
will denote as a requisite.
102
Acc. to Rupp et al.

Step 1
Examples:
print, save, transmit, calculate
103
Acc. to Rupp et al.

Step 1
104
Acc. to Rupp et al.

Step 1
Examples:
insert – The SYSTEM inserts new data.
select – The USER selects one element of a finite set.
105
Acc. to Rupp et al.

Step 1
106
Acc. to Rupp et al.

Step 1
Examples:
Do “enter,” “input” and “insert” should have the same
semantic within the requirements or not?
107
Acc. to Rupp et al.

Step 2
Characterise the activity of the system.
 Is it an independent system activity?
(The system executes the process independently)
The system …
provide <whom>
with the ability to
verb
<process>
be able to
<process>
108
Acc. to Rupp et al.

Step 2
 Is it an independent system activity?
(The system executes the process independently)
Example:
The system … prints.
The system …
provide <whom>
with the ability to
verb
<process>
be able to
<process>
109
Acc. to Rupp et al.

Step 2
 Is it a user interaction?
(The system provides the user with the ability to
use the process functionality)
The system …
provide <whom>
with the ability to
verb
<process>
be able to
<process>
110
Acc. to Rupp et al.

Step 2
 Is it a user interaction?
(The system provides the user with the ability to
use the process functionality)
Example:
The system provides the receptionist with the ability to print.
The system …
provide <whom>
with the ability to
verb
<process>
be able to
<process>
111
Acc. to Rupp et al.

Step 2
 Is it an interface requirement?
(The system executes a process dependent upon a
third party, is passive and requires an external event)
The system …
provide <whom>
with the ability to
verb
<process>
be able to
<process>
112
Acc. to Rupp et al.

Step 2
 Is it an interface requirement?
(The system executes a process dependent upon a
third party, is passive and requires an external event)
Example:
The system … is able to receive data from the library.
The system …
provide <whom>
with the ability to
verb
<process>
be able to
<process>
113
Acc. to Rupp et al.

Step 3
Determine the degree of legal obligation.
 Which is the legal relevance of the requirement?
 Use modal verbs!
The system should
provide <whom>
with the ability to
verb
<process>
be able to
<process>
will
shall
114
Acc. to Rupp et al.

Step 3
Determine the degree of legal obligation.
 Which is the legal relevance of the requirement?
 Use modal verbs!
The system should
provide <whom>
with the ability to
verb
<process>
be able to
<process>
will
shall
Example:
The system shall provide the receptionist with the ability to
print.
115
Acc. to Rupp et al.

Step 3
Legal obligation = degree of obligation
stakeholders attach to the statements.
Degree of obligation Keyword
Binding shall
Nice to have should
Aim will
116
fulfilment
mandatory
implementation
suggestion
intention, future
developments
Acc. to Rupp et al.

Step 4
Fine tune the requirement.
 Which objects and complements are missing?
 Add them!
The system should
provide <whom>
with the ability to
verb
<process>
be able to
<process>
will
shall
object
additional details
about the object
118
Acc. to Rupp et al.

Step 4
Fine tune the requirement.
 Which objects and complements are missing?
 Add them!
The system should
provide <whom>
with the ability to
verb
<process>
be able to
<process>
will
shall
Example:
The system shall provide the receptionist with the ability to
print a bill on the network printer.
object
additional details
about the object
119
Acc. to Rupp et al.

Step 5
Phrase logical and temporal conditions.
 Which conditions and prerequisites need to be met
before for your requirement to be valid?
 Place them in front of the requirement!
the
system
should
provide <whom>
with the ability to
verb
<process>
be able to
<process>
will
shall
object
additional details
about the object
When? / Under
what conditions?
120
Acc. to Rupp et al.

Step 5
Phrase logical and temporal conditions.
 Which conditions and prerequisites need to be met
before for your requirement to be valid?
 Place them in front of the requirement!
the
system
should
provide <whom>
with the ability to
verb
<process>
be able to
<process>
will
shall
Example:
If the option “Bill required” has been selected on the mobile
device, the system shall provide the receptionist with the
ability to print a bill on the network printer.
object
additional details
about the object
When? / Under
what conditions?
121
Acc. to Rupp et al.

Step 6
Use the SOPHIST-Rulebook to ensure
completeness of the semantic meaning.
 Apply the rules and tests from the SOPHIST set
of REgulations!
 Avoid incomplete information (deletion)!
 Avoid statements falsifying reality (distortion)!
 Avoid erroneous generalisations (generalization)!
122
Acc. to Rupp et al.

Step 6
of REgulations!
(A bad) Example:
Customers who are not authorised are displayed.
(What is to be displayed? To whom? How? When?)
123
Acc. to Rupp et al.

Step 6
of REgulations!
124
Acc. to Rupp et al.

Step 6
of REgulations!
(A bad) Example:
The system shall allow for archiving.
(Which exact process is meant by the noun?)
125
Acc. to Rupp et al.

Step 6
of REgulations!
 Avoid erroneous generalisations (generalisation)!
126
Acc. to Rupp et al.

Step 6
of REgulations!
 Avoid erroneous generalisations (generalisation)!
(A bad) Example:
The data has to be graphically displayed to the user.
(Which data exactly? To which users exactly?)
127
Acc. to Rupp et al.

Summarising…

Rupp’s template – Six steps
the
system
should
provide <whom>
with the ability to
verb
<process>
be able to
<process>
will
shall
object
additional details
about the object
When? / Under
what conditions?
129
Adapted from Rupp et al.

the
system
should
provide <whom>
with the ability to
verb
<process>
be able to
<process>
will
shall
object
additional details
about the object
When? / Under
what conditions?
130
1: Determine the process,
identify the functionality

the
system
should
provide <whom>
with the ability to
verb
<process>
be able to
<process>
will
shall
object
additional details
about the object
When? / Under
what conditions?
131
2: Characterise the activity
of the system

the
system
should
provide <whom>
with the ability to
verb
<process>
be able to
<process>
will
shall
object
additional details
about the object
When? / Under
what conditions?
132
of the system
3: Determine legal
obligation

the
system
should
provide <whom>
with the ability to
verb
<process>
be able to
<process>
will
shall
object
additional details
about the object
When? / Under
what conditions?
133
of the system
3: Determine legal
obligation
4: Fine tune the
requirement

the
system
should
provide <whom>
with the ability to
verb
<process>
be able to
<process>
will
shall
object
additional details
about the object
When? / Under
what conditions?
134
of the system
3: Determine legal
obligation
4: Fine tune the
requirement
5: Phrase
conditions

the
system
should
provide <whom>
with the ability to
verb
<process>
be able to
<process>
will
shall
object
additional details
about the object
When? / Under
what conditions?
135
of the system
3: Determine legal
obligation
4: Fine tune the
requirement
5: Phrase
conditions
6: Use SOPHIST-
Rulebook

So far…

Next topics…

Good practices:
Requirements analysis

Good practices
 Model the application environment, define its
boundaries and external entities.
 Create user interface and technical prototypes.
 Analyse requirements feasibility and their risks.
 Prioritize the requirements.
 Create a consistent data dictionary.
 Model the requirements using diagrams.
 Analyse interfaces between your system and the
outside world.
 Allocate requirements to subsystems.
139

Good practices:
Requirements specification

Good practices
 Adopt requirement document templates for
documenting requirements.
 Identify requirement origins to ensure that all
stakeholder know why every requirement is
needed.
 Uniquely label each requirement for later
management.
 Record business rules separately from project’s
requirements.
 Specify non-functional requirements to satisfy the
users’ quality expectations.
141

Trello.com

To take away…

Mind map created with https://bubbl.us/

Use the Rupp’s template!
Construct perfect requirements!
the
system
should
provide <whom>
with the ability to
verb
<process>
be able to
<process>
will
shall
object
additional details
about the object
When? / Under
what conditions?
145

So far…

Next topics…

What comes next?

Subdisciplines of
Requirements
Engineering
Requirements
Development
Requirements
Management
Also topic of lecture
“Modelling Software Requirements. Important diagrams and templates”

150
Elicitation
Analysis
Specification
Validation
re-evaluate
evaluating,
verifying
documenting, SRS
classifying,
representing,
deriving,
negotiating

Granular goals
CG3
CG2
CG1
Coarse goals
Define
stakeholders
Define
goals
Define
requirements
Diagrams
Templates
Models
WHO
WHAT
HOW
classifying,
representing,
deriving,
negotiating
documenting, SRS
+
+
+

Other references

Other books
153

Other books
154

Further reading
 IREB - International Requirements Engineering
Board e.V.
http://www.ireb.org/en/service/downloads.html
155

Further reading
 Ch. Rupp, R. Joppich, Ch. Wünch (2010): “Molecular
Requirements Engineering: The Blueprint of a Perfect
Requirement”.
 Ch. Rupp (2010): “In medias RE”.
 Ch. Rupp, E. Wolf (2011): “The SOPHIST Set of
REgulations”.
 Ch. Rupp, R. Joppich (2010): “Templates – Construction
Plans for Requirements and for More”.
All available at https://www.sophist.de/en/information-
pool/downloads/open-download-area/
156

Conference sites…
 21st International Working Conference on
Requirements Engineering: Foundation for Software
Quality (REFSQ 2015), Essen, Germany
http://refsq.org/2015/
157

Conference sites…
 23rd IEEE International Requirements Engineering
Conference (RE’15), Ottawa, Canada
http://re15.org/
158

Homework:
“Apply the Rupp’s template to
construct perfect requirements
for one of your current course
projects!”

The traditional software
development process:
and interests…

The ideal, perfect, still possible
software development process:
and interests…

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

Done!

Methods for
Documenting 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
monettdiaz@dmonett

Requirements Engineering Methods for Documenting Requirements (lecture slides)

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Requirements Engineering Methods for Documenting Requirements (lecture slides)

Similar to Requirements Engineering Methods for Documenting Requirements (lecture slides) (20)

More from Dagmar Monett

More from Dagmar Monett (20)

Recently uploaded

Recently uploaded (20)

Requirements Engineering Methods for Documenting Requirements (lecture slides)