Methods for Validating and Testing Software Requirements (lecture slides)

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

Methods for Validating and

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

60 Minutes


Dilbert

Scott Adams

At http://dilbert.com/strip/2014-02-25/

(Educational/Classroom usage permission is granted by Universal Uclick. All Rights Reserved)

Different goals…

2

http://dilbert.com/strip/2014-02-08/

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 validation. Key actions

Reviewing requirements

- Informal and formal approaches

Testing requirements

- Validating with acceptance criteria

Good practices in validation

What’s next? Further reading, sources of inspiration


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


Software Engineering

Ian Sommerville

9th Edition, 792 pp.

Addison-Wesley, 2010

ISBN-13: 978-0137035151

(10th Edition: April 2015. See more at

http://iansommerville.com/software-

engineering-book/)

8

Sommerville

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 10Cartoon http://projectcartoon.com/

http://projectcartoon.com/


Requirements and

Requirements Engineering

– An Overview –


Requirement: A definition

According to Wiegers & Beatty:

“[A requirement is a] statement of a

customer need or objective, or of a condition

or capability that a product must possess to

satisfy such a need or objective. A property

that a product must have to provide value to

a stakeholder.”

See lecture “A Structured Approach to Requirements Analysis” for more on this topic!



Definition according to Wiegers & Beatty:

Requirements engineering is the subdiscipline of

systems engineering and software engineering that

encompasses all project activities associated with

understanding a product's necessary capabilities and

attributes. Includes both requirements development

and requirements management.

14



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 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 (this) lecture

“Methods for Validating and Testing Software Requirements”


A Requirements Development

process framework



Elicitation

Requirements

Engineering


Requirements

Development

Requirements

Management



RD process framework

27

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?


A structured approach to RD

Granular goals

CG3

CG2CG1

Coarse goals

Define

stakeholders

Define

goals

Define

requirements

DiagramsTemplates

Models

WHO

WHAT

HOW

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


So far…












Next topics…












Requirements Validation



34

Elicitation

Analysis

Specification




evaluating,

verifying

documenting, SRS

classifying,

representing,

deriving,

negotiating





35

Elicitation

Analysis

Specification




evaluating,

verifying

documenting, SRS

classifying,

representing,

deriving,

negotiating




Validation and verification

36


“[Validation is the] process of evaluating a project

deliverable to determine whether it satisfies

customer needs.”

‘Are we building the right product?’

“[Verification is the] process of evaluating a

project deliverable to determine whether it satisfies

the specifications on which it was based.”

‘Are we building the product right?’


Key actions in validation


Key actions

38

Acc. to Wiegers & BeattyV

ali

dati

on

Reviewing the documented requirements to correct

any problems before the development group accepts

them.

According to Wiegers & Beatty


Key actions

39


ali

dati

on



them.

Developing acceptance tests and criteria to confirm

that a product based on the requirements would

meet customer needs and achieve the business

objectives.



So far…












Active learning exercise

Image © renjith krishnan at http://www.freedigitalphotos.net/


Quiz

42

Which is an activity in the validation process?

(A) Negotiating.

(B) Discovering.

(C) Evaluating.

(D) Classifying.


Next topics…












Dilbert

Scott Adams

At http://dilbert.com/strip/2013-02-25/

(Educational/Classroom usage permission is granted by Universal Uclick. All Rights Reserved)

Failed feedback…

45

http://dilbert.com/strip/2013-02-14/


Peer review

46

“[A peer review is an] activity in which one or

more persons other than the author of a work

product examine that product with the intent of

finding defects and improvement

opportunities.”



Peer review approaches

47

Peer deskcheck: asking one colleague to look

over your own work product.


Passaround: inviting several colleagues to

examine a deliverable concurrently.

Walkthrough: the author describes a

deliverable and solicits comments on it.

Informal peer reviews:


The inspection process


Inspection: A definition


“[Inspection is a] type of formal peer review

that involves a trained team of individuals

who follow a well-defined process to examine

a work product carefully for defects.”

Originally developed by Michael Fagan at IBM (1976)

Software industry best practice

Best-established type of formal peer review


Inspection

The participants (<7)

The author of the work

product and perhaps

peers of the author

People who are the

sources of information

that fed into the item

being inspected

People who will do

work based on the

item being inspected

People who are responsible

for interfacing systems that

will be affected by the item

being inspected



Inspection roles

Author

They look for defects and improvement opportunities

- Plays passive role during inspection, listens to

comments, answers questions.



Inspection roles

Author

Moderator




- Plans inspection with author, coordinates

activities, facilitates the inspection meeting.



Inspection roles

Author

Moderator

Reader






- Paraphrases requirements and model

elements. The other participants point out

potential defects and issues they see.



Inspection roles

Author

Moderator

Reader

Recorder






- Paraphrases requirements and model

elements. The other participants point out

potential defects and issues they see.

- Documents issues raised and defects found.




55

Initialwork

productPlanning Preparation

InspectionmeetingRework

Follow-up

Baselinedwork

product

Entry

criteria

Exit

criteria



Defect checklist

56

Helps reviewers look for

typical kinds of errors.


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

http://www.freedigitalphotos.net/


Defect checklist

57

Examples of topics to check out:

Completeness Do the requirements address all known customer or system

needs?

Correctness Do any requirements conflict with or duplicate other

requirements?

Organisation and traceability Is each requirement uniquely and correctly labelled?



So far…












Next topics…












Tests

61

Powerful tool for both validating and verifying

requirements.

Evaluate functional requirements, analysis models,

and prototypes.

Should cover normal and alternative flows

identified during elicitation and analysis.



Example of conceptual test

62

Use case:

Test:


“User enters order number to view, order exists,

user had placed the order.

Expected result: show order details.”

View a stored order


Validating with

acceptance criteria


Acceptance criteria

64


“[Acceptance criteria are] conditions that a

software product must satisfy to be accepted

by a user, customer, or other stakeholder.”

From “What do you need to do with the system?”…

…to “How would you judge whether the solution meets

your needs?”


Acceptance Test

65


“[An acceptance test is a] test that evaluates

anticipated usage scenarios to determine the

software's acceptability. Used in agile

development both to express details about a

user story and to determine whether a user

story is fully and correctly implemented.”


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.

(fail)

(pass)



So far…












Next topics…












Good practices:

Requirements validation


Good practices

Review the requirements (peer review, rigorous

inspection, etc.).

Test the requirements for documenting the

expected behaviour under specified conditions.

Define acceptance criteria together with users

and based on their requirements.

Simulate the requirements (simulations with

mock-ups to validate requirements and make

design choices if necessary).

71



To take away…


Key actions

73


ali

dati

on



them.

Developing acceptance tests and criteria to confirm

that a product based on the requirements would

meet customer needs and achieve the business

objectives.




74

Initialwork

productPlanning Preparation

InspectionmeetingRework

Follow-up

Baselinedwork

product

Entry

criteria

Exit

criteria



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.

(fail)

(pass)



So far…












Next topics…












What comes next?


Subdisciplines of Requirements Management

Tracking

Requirements

Engineering

Managing Controlling Tracing

Requirements

Development

Requirements

Management




Other references


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

81

Rupp & The SOPHISTs

https://www.sophist.de/


Other books

82


Other books

83


Further reading

IREB - International Requirements Engineering

Board e.V.

http://www.ireb.org/en/service/downloads.html

84

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


Conference sites…

21st International Working Conference on

Requirements Engineering: Foundation for Software

Quality (REFSQ 2015), Essen, Germany

http://refsq.org/2015/

85

http://refsq.org/2015/


Conference sites…

23rd IEEE International Requirements Engineering

Conference (RE’15), Ottawa, Canada

http://re15.org/

86

http://re15.org/


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 90Adapted from cartoon http://projectcartoon.com/



Done!












Methods for Validating and

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

Methods for Validating and Testing Software Requirements (lecture slides)

Education

Transcript of Methods for Validating and Testing Software Requirements (lecture slides)