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íazComputer Science Dept.

Faculty of Cooperative Studies

Berlin School of Economics and Law

[email protected]

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

http://dilbert.com/strip/1999-05-09/

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

http://aka.ms/SoftwareReq3E/files


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

https://www.sophist.de/


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

http://iansommerville.com/software-engineering-book/


The traditional software

development process:

Perceptions, communication patterns

and interests…

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

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

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

Elicitation

Requirements

Engineering


Requirements

Development

Requirements

Management

All are topics of lecture:

“A Structured Approach to Requirements Analysis”



Requirements

Engineering

Requirements

Development

Requirements

Management

Elicitation Analysis Specification Validation

Topic of lecture

“Requirements Engineering Techniques for Eliciting Requirements”



Requirements

Engineering

Requirements

Development

Requirements

Management

Elicitation Specification Validation

Topics of (this) lecture

“Requirements Engineering Methods for Documenting Requirements”

Analysis



Requirements

Engineering

Requirements

Development

Requirements

Management


Also topic of lecture

“Modelling Software Requirements. Important diagrams and templates”



Requirements

Engineering

Requirements

Development

Requirements

Management


Topic of lecture

“Methods for Validating and Testing Software Requirements”


A Requirements Development

process framework



Elicitation

Requirements

Engineering


Requirements

Development

Requirements

Management



RD process framework

28

Elicitation

Analysis

Specification

Validationre-evaluate

Adapted from Wiegers & Beatty

identifying, discovering

evaluating,

verifying

documenting, SRS

classifying,

representing,

deriving,

negotiating

RD: Requirements Development

SRS: Software Requirements Specification

See lecture “A Structured Approach to Requirements Analysis” for details!


A structured approach to

Requirements Development


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

CG2CG1

Coarse goals

Define

stakeholders

Define

goals

Define

requirements

DiagramsTemplates

Models

WHO

WHAT

HOW



So far…












Next topics…












Requirements Analysis



35

Elicitation

Analysis

Specification




evaluating,

verifying

documenting, SRS

classifying,

representing,

deriving,

negotiating






36

Elicitation

Analysis

Specification




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

CG2CG1

Coarse goals

Define

stakeholders

Define

goals

Define

requirements

DiagramsTemplates

Models

WHO

WHAT

HOW

classifying,

representing,

deriving,

negotiating


documenting, SRS

+

+

evaluating, verifying+


Key actions in analysis


Key actions (i)

40

Acc. to Wiegers & BeattyA

naly

sis

Analysing the information received from users to

distinguish their task goals from other requirements

information (functional req., business rules, etc.).

According to Wiegers & Beatty


Key actions (i)

41


naly

sis Decomposing high-level requirements into an

appropriate level of detail.






Key actions (i)

42


Deriving functional requirements.An

aly








Key actions (i)

43


Deriving functional requirements.An

aly






Understanding importance of quality attributes.

…



Key actions (ii)

44


naly

sis

Allocating requirements to software components

defined in the system architecture.

…



Key actions (ii)

45


Negotiating implementation priorities.

An

aly

sis



…



Key actions (ii)

46


Negotiating implementation priorities.

An

aly

sis



Identifying gaps in requirements or unnecessary

requirements.

…



So far…












Next topics…












Requirements Specification



50

Elicitation

Analysis

Specification




evaluating,

verifying

documenting, SRS

classifying,

representing,

deriving,

negotiating





51

Elicitation

Analysis

Specification




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

CG2CG1

Coarse goals

Define

stakeholders

Define

goals

Define

requirements

DiagramsTemplates

Models

WHO

WHAT

HOW

classifying,

representing,

deriving,

negotiating


documenting, SRS

+

+



Key actions in specification


Key action

55

Acc. to Wiegers & BeattyS

pec

ific

ati

on

Translating the collected user needs into written

requirements and diagrams suitable for

comprehension, review, and use by their intended

audiences.



Relationships among several types

of requirements information


Origins of / influences from…

Business

requirementsBusiness

rules

User

requirements

Quality

attributes

System

requirements

Functional

requirements

External

interfaces

Constraints




Requirements documents

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

http://www.freedigitalphotos.net/


Requirements are stored in…

Vision and Scope Document

Software Requirements Specification (SRS)

User Requirements Document

Business

requirementsBusiness

rules

User

requirements

Quality

attributes

System

requirements

Functional

requirements

External

interfaces

Constraints



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/

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

valid and current

agreed upon

necessary

understandable

traceable

rated

implementable

consistent

classifiable

testable

unambiguous



comprehensive

correct

valid and current

agreed upon

necessary

understandable

traceable

rated

implementable

consistent

classifiable

testable

unambiguous

72

“Every single requirement must

describe the called-for and

deliverable functionality in full.”



comprehensive

correct

valid and current

agreed upon

necessary

understandable

traceable

rated

implementable

consistent

classifiable

testable

unambiguous

73

“A requirement is correct if it

expresses exactly what the author

was trying to illustrate.”



comprehensive

correct

valid and current

agreed upon

necessary

understandable

traceable

rated

implementable

consistent

classifiable

testable

unambiguous

74

“A requirement must describe the

system’s reality. If one of the

influencing factors changes, all the

requirements affected must be

adapted.”



comprehensive

correct

valid and current

agreed upon

necessary

understandable

traceable

rated

implementable

consistent

classifiable

testable

unambiguous

75

“A requirement can be said to be

agreed upon if all stakeholders

determine it to be correct and valid.”



comprehensive

correct

valid and current

agreed upon

necessary

understandable

traceable

rated

implementable

consistent

classifiable

testable

unambiguous

“A requirement is necessary if – and

only if – it somehow helps meet the

system‘s goals.”

76



comprehensive

correct

valid and current

agreed upon

necessary

understandable

traceable

rated

implementable

consistent

classifiable

testable

unambiguous

77

“The requirement must be

understandable by all stakeholders.

[I]t is of importance to create a

common language for all the

involved.”



comprehensive

correct

valid and current

agreed upon

necessary

understandable

traceable

rated

implementable

consistent

classifiable

testable

unambiguous

78

“Every requirement must be

uniquely identifiable. [The] unique

identifiers [make] it possible to trace

an overall system goal across all

specification levels.”



comprehensive

correct

valid and current

agreed upon

necessary

understandable

traceable

rated

implementable

consistent

classifiable

testable

unambiguous

79

“Once a system becomes

sufficiently complex or large, it is

important to rate requirements

according to their importance or

priority.”



comprehensive

correct

valid and current

agreed upon

necessary

understandable

traceable

rated

implementable

consistent

classifiable

testable

unambiguous

80

“It must be possible to implement

every requirement within the

constraints laid down by current

technology, the systems extent and

its environment.”



comprehensive

correct

valid and current

agreed upon

necessary

understandable

traceable

rated

implementable

consistent

classifiable

testable

unambiguous

81

“Requirements must be consistent

with all other requirements –

independent of their level of

abstraction or type. [T]here are no

contradictory statements.”



comprehensive

correct

valid and current

agreed upon

necessary

understandable

traceable

rated

implementable

consistent

classifiable

testable

unambiguous

82

“Delineate the level of legal

obligation for every single

requirement.”



comprehensive

correct

valid and current

agreed upon

necessary

understandable

traceable

rated

implementable

consistent

classifiable

testable

unambiguous

83

“A requirement must be formulated

in a way that it can be tested. This

means that it should be possible to

prove any functionality requested by

a requirement.”



comprehensive

correct

valid and current

agreed upon

necessary

understandable

traceable

rated

implementable

consistent

classifiable

testable

unambiguous

84

“It ought not to be possible to

interpret [the meaning] differently. All

readers of the requirement should

understand it in a specific,

consistent fashion.”


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

http://dilbert.com/strips/comic/2006-01-29/


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

TAccording to Bill Wakw @ http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/

– Independent

– Negotiable

– Valuable

– Estimable

– Small

– Testable

http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/


Dilbert

Scott Adams

At http://dilbert.com/strip/2007-08-24/


Priorities are important!

95

http://dilbert.com/strip/2007-08-25/


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

https://www.sophist.de/


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.


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)


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.


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)


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.


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


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.


The MoSCoW method

MoSCoW

M

U

S

T

S

H

O

U

L

D

C

O

U

L

D

W

O

N‘

T

Image © Matt Banks @ http://www.freedigitalphotos.net/



Step 4

Fine tune the requirement.

Which objects and complements are missing?

Add them!


with the ability to

verb

<process>

be able to

<process>will

shall

objectadditional details

about the object

118

Acc. to Rupp et al.


Step 4

Fine tune the requirement.

Which objects and complements are missing?

Add them!


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.


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

systemshould

provide <whom>

with the ability to

verb

<process>

be able to

<process>will

shall


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

systemshould

provide <whom>

with the ability to

verb

<process>

be able to

<process>will

shall

Example:If the option “Bill required” has been selected on the mobile device, the system shall provide the receptionist with the ability to print a bill on the network printer.


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

systemshould

provide <whom>

with the ability to

verb

<process>

be able to

<process>will

shall


about the object

When? / Under

what conditions?

129

Adapted from Rupp et al.



the

systemshould

provide <whom>

with the ability to

verb

<process>

be able to

<process>will

shall


about the object

When? / Under

what conditions?

130

1: Determine the process,

identify the functionality




the

systemshould

provide <whom>

with the ability to

verb

<process>

be able to

<process>will

shall


about the object

When? / Under

what conditions?

131



2: Characterise the activity

of the system




the

systemshould

provide <whom>

with the ability to

verb

<process>

be able to

<process>will

shall


about the object

When? / Under

what conditions?

132




of the system

3: Determine legal

obligation




the

systemshould

provide <whom>

with the ability to

verb

<process>

be able to

<process>will

shall


about the object

When? / Under

what conditions?

133




of the system

3: Determine legal

obligation

4: Fine tune the

requirement




the

systemshould

provide <whom>

with the ability to

verb

<process>

be able to

<process>will

shall


about the object

When? / Under

what conditions?

134




of the system

3: Determine legal

obligation

4: Fine tune the

requirement

5: Phrase

conditions




the

systemshould

provide <whom>

with the ability to

verb

<process>

be able to

<process>will

shall


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/

https://bubbl.us/


Use the Rupp’s template!

Construct perfect requirements!

the

systemshould

provide <whom>

with the ability to

verb

<process>

be able to

<process>will

shall


about the object

When? / Under

what conditions?

145


So far…












Next topics…












What comes next?



Requirements

Engineering

Requirements

Development

Requirements

Management


Also topic of lecture

“Modelling Software Requirements. Important diagrams and templates”



150

Elicitation

Analysis

Specification




evaluating,

verifying

documenting, SRS

classifying,

representing,

deriving,

negotiating





Granular goals

CG3

CG2CG1

Coarse goals

Define

stakeholders

Define

goals

Define

requirements

DiagramsTemplates

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

http://www.ireb.org/en/home.html


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

https://www.sophist.de/en/information-pool/downloads/open-download-area/


Conference sites…

21st International Working Conference on

Requirements Engineering: Foundation for Software

Quality (REFSQ 2015), Essen, Germany

http://refsq.org/2015/

157

http://refsq.org/2015/


Conference sites…

23rd IEEE International Requirements Engineering

Conference (RE’15), Ottawa, Canada

http://re15.org/

158

http://re15.org/


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íazComputer Science Dept.

Faculty of Cooperative Studies

Berlin School of Economics and Law

[email protected]

Europe Week, 2nd – 6th March 2015

monettdiaz@dmonett

Requirements Engineering Methods for Documenting Requirements (lecture slides)

Education

Transcript of Requirements Engineering Methods for Documenting Requirements (lecture slides)