verification and validation of requirements

8/9/2019 verification and validation of requirements

1/34

Helping Government Organizations Buy and Build Software Better

Software Technology Support Center (STSC)

As Of: 5/8/2002 1

Verification &Validation of

RequirementsDavid A. Cook, Ph.D.

STSC/Shim Enterprises


2/34

STSC

As Of: 5/8/2002David A. Cook V&V 2

Here is Edward Bear, comingdownstairs now, bump, bump,

bump on the back of his head,

behind Christopher Robin. It

is, as far as he knows, the only

way of coming downstairs, but

sometimes he feels that there

really is another way, if only hecould stop bumping for a

moment and think if it. And

then he feels that perhaps thereisnt.

From Software Project Survival Guide, Steve McConnell, 1998


3/34

STSC


Improving the Process:

Verification and Validation

Verification

Are we building the product

right?

Validation

Are we building the right

product?


4/34

STSC


And the Difference Is

Verification

Means that each stage

of development followsprocesses and

standards. Quality is the

goal.

Validation

Means that the overall

product and processmeets user needs. User

satisfaction is the goal.


5/34

STSC


There Are Two Prerequisites for V&V

Know who your customers are.

Understand their different agendas.

You want customers who can help you in identifying,

verifying and validating requirements.

Most likely you need end users and funders. Each

helps you in certain key areas.

Know how your organization developssoftware.

Know your process.


6/34

STSC


Have a Process

A process givesstructure to time and

effort.

This permits V&V

activities to occur at

planned times.

Consult your friendly

local pusher ofCMM, CMMI, ISO

9000.

But we DOhave aprocess.We save

every sheet

of paper wecan find!!


7/34

STSC


What I Mean Is

Have a process written down

Follow the process

Update the process as necessary

Make sure the process actually works

Make sure you use a lifecycle

Follow the lifecycle

Update and use alternative lifecycles as needed

In short know what you are ACTUALLY doing

You mean I

should tell the

TRUTH about how Idevelop

software??


8/34

STSC


Verification of Requirements


9/34

STSC


Verification of Requirements

As mentioned earlier you need to know who

your customers are because THEY have to

be involved in the verification

Three components of verification Inspections

Metrics

Configuration management

STSC


10/34

STSC


Verification Part 1 Inspections

I would love to cover inspections and

reviews but time does not permit. If

you are interested, email me and I will

send you a presentation on reviews

and inspections that I co-presented

last year.

If you can only do ONE inspection on

a project, you get the biggest bangfor the buck (ROI) performing

requirements inspections.

STSC


11/34

STSC


Inspection

The problem is that people interpret

requirements in different ways.

To prevent this, you need to address two

different issues. Do we all interpret the requirement the same way?

Are the requirements complete?

STSC


12/34

STSC


Interpretation - Exercise

Count the number of occurrences below of thelettere . No questions just count!!

ANSWER: the lettere occurs ___ times.

Any activity you can perform to reducetesting errors is cost-efficient. Inspections

are very effective, and requirements

inspections provide the the biggest ROI ofany inspection effort.

STSC


13/34

STSC


Are the Requirements Complete?

The best way to determine this is to use

checklists to ensure that you are asking the

right questions at inspection time.

In addition, such things as a trained andprepared inspection team plus adequate

preparation help.

Ada95

STSC


14/34

STSC


What to Inspect:

The software requirements specification (or

however you list the requirements).

The sources or preliminaries for the SRS

(concept of operations) or any documents that

preceded the SRS.

If it is used as a

requirements

reference, theninspect it!

STSC


15/34

STSC


Lets see I have to

pay the grocer,

pay the electricity bill,

pay the mortgage,and make a car payment.

This is an expensive check list!

Sample Checklists

Following are some sample checklists.

These checklists grew out of research with

several customers.

STSC


16/34

S SC


Requirements Review Checklist

Is problem partitioning complete?

Are external and internal interfaces

properly defined?

Can each requirement be tested?

Can each requirement be numbered andeasily identified? (Is the requirement

tracable?)

STSC


17/34


Requirements Review Checklist

(Cont.) Has necessary prototyping been conducted

for users?

Have implied requirements (such as speed,

errors, response time) been stated?

Is performance achievable within constraintsof other system elements?

STSC


18/34


Requirements Review Checklist (Cont.)

Are requirements consistent with schedule,

resources and budget?

Is information to be displayed to the user

listed in the requirements?

Have future issues (upgrades, plannedmigration, long-term use) been addressed in

requirements?

STSC


19/34


Even I cant rememberall of these at once

so I inspect

requirements when I

am finished writing

them!

What You Are Looking For

Are requirements that are

Unambiguous

Complete

Verifiable

Consistent

Modifiable

Traceable

Usable Prioritized (optional)

STSC

M t i f


20/34


Metrics for

Requirements

During the

requirements phase,

there are few metricsthat are very useful.

One simple metric is

simply the % of

requirements thathave been inspected.

STSC


21/34


Metrics for Requirements

Another useful metric

# Of requirements that reviewers

interpreted the same

Total # of requirements reviewed

STSC


22/34


Configuration Management

The most frustrating software problems are

often caused by poor configuration

management. The problems are frustratingbecause they take time to fix. They often

happen at the worst time, and they are totally

unnecessary.

-Watts Humphrey,

Managing The Software Process.

STSC


23/34


Configuration Management

Again, time does not permit a complete

discussion of CM. If you want an intro, email

and Ill send you a presentation.

Requirements require acentralized location and

STRICT configuration

management. If you aresloppy here soon

it all goes downhill.

STSC


24/34


Validation of Requirements

STSC


25/34


Validation Is Difficult for Software

Based on three concepts

Testing

Metrics

Quality assurance teams

Testing is the least important

Difficult to test requirements prior to coding

Most requirement methodologies (prototyping,simulation) rely on many assumptions and

simplifications

STSC


26/34


Metrics for Validation

Metrics can be useful, but

mostly in hindsight.

If you know how many ofyour bugs or how much of

your defect fix time are

requirements-related, youcan adjust inspections and

reviews accordingly.

STSC


27/34


Validation of Requirements

The best way to validate requirements is toinvolve customers in the requirements

inspection process. End-users.

Program office.

User management. End-users are the most effective, but hardest

to include.

End-users typically only see the smallpicture, and requirements are written in thelarge.

STSC


28/34


If Dogs Wrote

Requirements

Validation Typically Occurs Twice

During requirements gathering/analysis/

review.

After coding and during test. This SHOULDbe the function of the QA team.

STSC


29/34


Danger, Danger

QA and testing are

EXTREMELY EXPENSIVE!

Anything you can do to shorten the QA/test

phase is useful. If you rely on QA and testingto find and fix errors your

software is probably

Late Over budget

Still full of errors after you deliver it!!

STSC


30/34


Validation Summary

In summary validation requires a tie-in

between implementers and users. If you cant

involve users as much as you would like, thendesignate people to (ALAC) Act Like A

customer.

I have no checklists for validation, but suggest

that you focus on two areas: External interfaces to systems.

Internal interfaces between modules or sub-systems.

STSC


31/34


STSC

Good Source of Information


32/34


Good Source of Information

Software Verification and Validation forPractitioners and Managers, by Steven R.

Rakitin

STSC

I Sh t Th A S l ti !


33/34


In Short There Are Solutions!

STSC

For Additional Information


34/34


For Additional Information

David A. Cook

STSC/Shim Enterprises(801) 775-3055

DSN 775-3055

[email protected]

International Sign for

Computer User at Work

verification and validation of requirements

Documents

Transcript of verification and validation of requirements