14-Lecture XIV

(1)

COMSATS Institute of Information Technology, Attock

1 _{Farhan Aadil}

Farhan Aadil

Assistant Professor

COMSATS Institute of Information Technology

Lecture 14

Requirement Validation

(2)

2 _{Farhan Aadil}

2

Today’s Topics

(3)

3 _{Farhan Aadil}

3

Requirements Engineering Process

(4)

4 _{Farhan Aadil}

4

Validation Objectives

•

Certifies that the requirements document is an

acceptable description of the system to be

implemented

•

Checks a requirements document for

– Completeness and consistency – Conformance to standards

– Requirements conflicts – Technical errors

(5)

5 _{Farhan Aadil}

5

Analysis and Validation

• Analysis

works with raw requirements as

elicited from the system stakeholders

– “Have we got the right requirements” is the

key question to be answered at this stage

• Validation

works with a final draft of the

requirements document i.e., with

negotiated and agreed requirements

(6)

6 _{Farhan Aadil}

6

Validation Inputs and Outputs

Requirements

Validation

Requirements

document

Organizational

knowledge

Organizational

standards

List of problems

(7)

7 _{Farhan Aadil}

7

Requirements Document

(8)

8 _{Farhan Aadil}

8

Organizational Knowledge

(9)

9 _{Farhan Aadil}

9

Organizational Standards

(10)

10 _{Farhan Aadil}

10

List of Problems

(11)

11 _{Farhan Aadil}

11

Agreed Actions

• List of agreed actions in response to requirements

(12)

12 _{Farhan Aadil}

12

Requirements Reviews

(13)

13 _{Farhan Aadil}

13

Requirements Review Process

Plan review Distribute documents

Prepare for review

Hold review meeting

Follow-up actions

(14)

14 _{Farhan Aadil}

14

Review Activities - 1

• Plan review

– The review team is selected and a time and place for the review meeting is chosen

• Distribute documents

(15)

15 _{Farhan Aadil}

15

Review Activities - 2

• Prepare for review

– Individual reviewers read the requirements to find conflicts, omissions, inconsistencies, deviations from standards and other problems

• Hold review meeting

(16)

16 _{Farhan Aadil}

16

Review Activities - 3

• Follow-up actions

– The chair of the review checks that the agreed actions have been carried out

• Revise document

(17)

17 _{Farhan Aadil}

17

Problem Actions

• Requirements clarification • Missing information

(18)

18 _{Farhan Aadil}

18

Requirements Clarification

(19)

19 _{Farhan Aadil}

19

Missing Information

• Some information is missing from the requirements document. It is the responsibility of the requirements

(20)

20 _{Farhan Aadil}

20

Requirements Conflict

(21)

21 _{Farhan Aadil}

21

Unrealistic Requirement

(22)

22 _{Farhan Aadil}

22

Pre-review Checking - 1

• Reviews are expensive because they involve a number of people spending time reading and checking the

(23)

23 _{Farhan Aadil}

23

Pre-review Checking - 2

• This expense can be reduced by using pre-review checking where one person checks the document and looks for

straightforward problems such as missing requirements, lack of conformance to standards, typographical errors, etc.

(24)

24 _{Farhan Aadil}

24

Pre-review Checking Stages

(25)

25 _{Farhan Aadil}

25

Review Team Membership

•

Reviews should involve a number of stakeholders

drawn from different backgrounds

– People from different backgrounds bring different skills and knowledge to the review

– Stakeholders feel involved in the RE process and develop an understanding of the needs of other stakeholders

(26)

26 _{Farhan Aadil}

26

Validation Techniques

– Review checklists – Prototyping

– User manual development – Model validation

(27)

27 27 _{Farhan Aadil}

Review Checklists - 1

• Understandability

– Can readers of the document understand what the requirements mean?

• Redundancy

(28)

Review Checklists - 2

• Completeness

– Does the checker know of any missing requirements or is there any information missing from individual requirement

(29)

•

Ambiguity

– Are the requirements expressed using terms which are clearly defined? Could readers from different backgrounds make

different interpretations of the requirements?

•

Consistency

– Do the descriptions of different requirements include

(30)

• Organization

(31)

•

Conformance to standards

– Does the requirements document and individual requirements conform to defined standards? Are departures from the

standards, justified?

•

Traceability

– Are requirements unambiguously identified, include links to related requirements and to the reasons why these

(32)

Checklist Questions & Quality Attributes - 1

• Is each requirement uniquely identified?

– Traceability, conformance to standards

• Are specialized terms defined in the glossary

– Understandability

• Does a requirement stand on its own or do you

have to examine other requirements to

understand what it means?

(33)

Checklist Questions & Quality Attributes - 2

• Do individual requirements use the terms consistently

– Ambiguity

• Is the same service requested in different requirements?

Are there any contradictions in these requests?

(34)

Checklist Questions & Quality

Attributes - 3

• If a requirement makes reference to some

other facilities, are these described

elsewhere in the document?

– Completeness

• Are related requirements grouped

together? If not, do they refer to each

other?

(35)

35 _{Farhan Aadil}

Assignment 5

(36)

Prototyping

• Prototypes for requirements validation

demonstrate the requirements and help

stakeholders discover problems

• Validation prototypes should be complete,

reasonably efficient and robust. It should

be possible to use them in the same way

as the required system

(37)

Prototyping for Validation

Choose prototype

testers

Develop test scenarios

Execute scenarios

Document problems

(38)

Prototyping Activities - 1

• Choose prototype testers

– The best testers are users who are fairly experienced and who are

(39)

Prototyping Activities - 2

• Develop test scenarios

(40)

Prototyping Activities - 3

•

Execute scenarios

– The users of the system work, usually on their own, to try the system by executing the planned scenarios

•

Document problems

– Its usually best to define some kind of electronic or paper

(41)

User Manual Development - 1

(42)

User Manual Development - 2

• Information in the user manual

– Description of the functionality and how it is implemented – Which parts of the system have not been implemented – How to get out of trouble

(43)

System Models

• For some projects, system models may be developed based on the agreed set of requirements

• These models may be data-flow models of the system’s

(44)

Model Validation

• Validation of system models is an

essential part of the validation process

• Some checking is possible with automated

tools

(45)

Objectives of Model Validation

• To demonstrate that each model is

self-consistent

• If there are several models of the system,

to demonstrate that these are internally

and externally consistent

• To demonstrate that the models accurately

reflect the real requirements of system

(46)

Data-flow Diagram for Issue

(47)

Paraphrased Description

Check user

Inputs and sources User’s library card from end-user Transformation function Checks that the user is a valid library

user

Transformation outputs The user’s status

Control information User details from the database

Check item

Inputs and sources The user’s status from Check user Transformation function Checks if an item is available for issue Transformation outputs The item’s status

Control information The availability of the item

Issue item

Inputs and sources None

Transformation function Issues an item to the library user. Items are stamped with a return date.

Transformation outputs The item issued to the end user Database update details

(48)

Requirements Testing - 1

• Each requirement should be testable i.e.,

it should be possible to define tests to

check whether or not that requirement

has been met

• Inventing requirements tests is an

effective validation technique as missing

or ambiguous information in the

(49)

Requirements Testing - 2

(50)

Test Case Definition - 1

• What usage scenario might be used to

check the requirement?

(51)

Test Case Definition - 2

• Is it possible to test the requirement using a single test or are multiple test cases required?

(52)

Hard-to-Test Requirements

• System requirements • Exclusive requirements

(53)

System requirements

• Requirements which apply to the system as a whole. In

general, these are the most difficult requirements to

(54)

Exclusive Requirements

• These are requirements which exclude specific behavior.

For example, a requirement may state that system

(55)

Some Non-Functional Requirements

(56)

56 _{Farhan Aadil}

56

Summary - 1

• Requirements validation should focus on checking the final draft of the requirements document for conflicts, omissions and deviations from standards

• Inputs to the validation process are the requirements document, organizational standards and implicit

organizational knowledge. The outputs are a list of

(57)

57 _{Farhan Aadil}

57

Summary - 2

• Reviews involve a group of people making a detailed analysis of the requirements

• Review costs can be reduced by checking the requirements before the review for deviations from organizational

(58)

Summary - 3

• Checklists of what to look for may be used to drive a requirements review process

• Prototyping is effective for requirements validation if a prototype has been developed during the requirements elicitation stage

• Systems models may be validated by paraphrasing them. This means that they are systematically translated into a natural language description

• Designing tests for requirements can reveal problems with the

(59)

14-Lecture XIV

Requirement Validation

acceptable description of the system to be

– “Have we got the right requirements” is the

Requirements

Organizational Standards

Requirements Review Process

Plan review Distribute documents

Review Activities - 1

• Hold review meeting

Problem Actions

Requirements Conflict

Pre-review Checking - 2

Pre-review Checking Stages

Validation Techniques

Review Checklists - 2

Consistency

Traceability

• Are specialized terms defined in the glossary

• Is the same service requested in different requirements?

• Are related requirements grouped

stakeholders discover problems

Choose prototype

Prototyping Activities - 1

Prototyping Activities - 3

User Manual Development - 2

Model Validation

to demonstrate that these are internally

Paraphrased Description

Check user

Issue item

Requirements Testing - 1

Requirements Testing - 2

Hard-to-Test Requirements

Exclusive Requirements

Summary - 1

Summary - 2

References