software requirements engineering lecture # 14

SOFTWARE REQUIREMENTS ENGINEERING

LECTURE # 14

VERIFICATION & VALIDATION

Engr. Ali Javed 22nd July, 2013

Instructor Information

Engr. Ali Javed

2

Course Instructor: Engr. Ali Javed

Assistant Professor

Department of Software Engineering

U.E.T Taxila

Email: [email protected]

Website: http://web.uettaxila.edu.pk/uet/UETsub/perSites/[email protected]

Contact No: +92-51-9047747

Office hours:

Monday, 09:00 - 11:00, Office # 7 S.E.D

Lab Instructor: Engr. Asra, Engr. Sobia

Presentation Outline 3

Verification & Validation

Traceability

Reviews

Inspections

Walkthroughs

Unit Testing

Integration Testing

System Testing

Validation Testing

Verification & Validation 4

Verification: Are we building the product right―

The software should confirm to its specification

Means that each ―stage of development follows processes and

standards

Quality is the goal.

Validation: "Are we building the right

product―

The software should do what the user really requires

Means that the overall product and process meets user needs.

User satisfaction is the goal.

Engr. Ali Javed

Traceability 5

IEEE [1994] provides the following compound definition of traceability.

The degree to which a relationship can be established between two or

more products of the development process; for example, the degree to

which the requirements and design of a given software component match.(IEEE

610.12-1990 )

Engr. Ali Javed

Requirements Traceability 6

Refers the ability to describe and follow the life of a

requirement, in both forward and backward direction.

That is from its origins, through its development and specification,

to its subsequent deployment and use, and through all periods of on-

going refinement and iteration in any of these phases.

Some requirements are volatile

Traceability importance increases where rate of change is high

Engr. Ali Javed

Classifications of Requirements Traceability 7

Forward traceability

requires that each input to a phase must be traceable to an

output of that phase.

Backward traceability

requires that each output of a phase must be traceable to an

input to that phase. Outputs that cannot be traced to inputs are extra, unless it is acknowledged that the inputs themselves were incomplete.

Engr. Ali Javed

Traceability Tables 8

Requirements traceability information can be kept in traceability tables, each table

relating requirements to one or more aspects of the system or its environment

Engr. Ali Javed

Tracing Requirements in the System

Definition Domain 9

Tracing User Needs to Features

Defining the features of a system that meets user needs is the next step after defining needs, and it can be helpful to continually relate how the user needs are addressed by the features of your proposed solution.

We can do so via a simple table, or traceability matrix, similar to the one

shown in Table-1

Table -1. Traceability Matrix: User Needs versus Features

Feature1 Feature2 ………. Featuren

Need1 x

Need2 x

Need….. x x

Needm x x

Engr. Ali Javed


Definition Domain 10

Tracing User Needs to Features

In Table-1, we've listed all the user needs we identified down the left column. In the row across the top, we've listed all the application features .

Once the rows (needs) and columns (features) are defined, we simply put an X in the appropriate cell(s) to record the fact that a specific feature has been defined for supporting user needs.

After you've recorded all known need–feature relationships, examine the traceability matrix for potential indications of error.

If inspection of a row fails to detect any Xs, a possibility exists that no feature is yet defined

to respond to a user need. These potential red flags should be checked carefully. Modern requirements management tools have a facility to automate this type of inspection.

If inspection of a column fails to detect any Xs, a possibility exists that a feature has been included for which there is no defined product need

Engr. Ali Javed



Tracing Features to Use Cases

It is equally important to ensure that the features can be related to the use cases proposed for the system.

Again, we can consider a simple matrix similar to the one shown in Table-2

Table -2. Traceability Matrix: Features versus Use Cases

UseCase1 UseCase2 ………. UseCasen

Feature1 x X

Feature2 x X

Feature... X

Featurem x x

Engr. Ali Javed



Tracing Features to Supplementary (non functional) Requirements

While the use cases carry the majority of the functional behavior, keep in mind that the supplementary requirements also hold valuable system requirements.

These often include the nonfunctional requirements of the system such as

usability, reliability, supportability, and so on.

Table -3. Traceability Matrix: Features versus Supplementary Requirements

SuppReq1 SuppReq2 ………. SuppReqn

Feature1 x X

Feature2 x X

Feature... x X

Featurem x

Engr. Ali Javed



In the same way tracing continues from one phase of software development lifecycle to another phase

Tracing from Requirements to Testing

Finally we approach the last system boundary we must bridge to implement a complete traceability strategy: the bridge from the requirements domain to the testing domain.

one specific approach to comprehensive testing is to assure that every use case is

"tested by" one or more test cases

Engr. Ali Javed



we first had to identify all the scenarios described in the use case itself. This is a one- to-many relationship since an elaborated use case will typically have a variety of possible scenarios that can be tested. From a traceability viewpoint, each use case traces to each scenario of the use case as shown in Figure.

Finally test case should be listed for each scenario as shown in Table 4

Engr. Ali Javed

UseCase ScenarioNumber TestCase

UseCase1 1 1.1

2 2.1

3 3.1

4 4.1

4 4.2

4 4.3

5 5.1

6 6.1

7 7.1

7 7.2

8 8.1

…. …. ….

Table-4. Traceability Matrix for Use Cases to Test Cases



Engr. Ali Javed

Requirements Reviews 16

A group of people analyze the requirements, look for problems, meet and discuss the problems and agree on actions to address these problems

Review is a very formal meeting headed by a leader

Not only to look for errors but also to check conformance to standards

Engr. Ali Javed

Plan review Distribute

documents

Prepare for

review

Hold review

meeting

Follow-up

actions

Revise

documents

Requirements Review Process 17

Engr. Ali Javed

Inspections 18

An inspection is a set of procedures and error-detection techniques for group

reading.

An inspection team usually consists of four people. One of the four

people plays the role of moderator. The moderator is expected to be a

competent programmer, but he or she is not the author of the program.

The duties of the moderator include

Distributing materials for, and scheduling, the inspection session

Leading the session

Recording all errors found

Ensuring that the errors are subsequently corrected

28 Engr. Ali Javed

Inspections 19

The second team member is the programmer.

The remaining team members usually are the program’s designer (if different

from the programmer) and a test specialist.

The moderator distributes the program’s listing and design specification to the other

participants several days in advance of the inspection session. The participants are

expected to familiarize themselves with the material prior to the session.

28 Engr. Ali Javed

Inspection Session Activities 20

During the session, two activities occur:

1. The programmer narrates, statement by statement, the logic of the program. During the discourse, other participants should raise questions, and they should be pursued to determine whether errors exist.

2. The program is analyzed with respect to a checklist of historically common programming

errors.

28 Engr. Ali Javed

Walkthroughs 21

The walkthrough, like the inspection, is a set of

procedures and error-detection techniques for

group reading.

It shares much in common with

the inspection process, but the procedures

are slightly different, and a different

error- detection technique is employed.

Rather than simply reading the program, the

participants ―play computer.

The person designated as the tester comes to the

meeting armed with a small set of paper test

cases for the program or module.

28 Engr. Ali Javed

Walkthroughs 22

During the meeting, each test case is mentally

executed. That is, the test data are

walked through the logic of the program.

The state of the program (i.e., the values

of the variables) is monitored on paper or

whiteboard

Of course, the test cases must be simple in

nature and few in number, because people

execute programs at a rate that is many

orders of magnitude slower than a machine.

The walkthrough should have a follow-up

process similar to that described for the

inspection process.

28 Engr. Ali Javed

Unit Testing 23

Unit testing focuses on verification

effort on the smallest unit of software

design (the software component or

module).

Using the component level design

description as a guide, important

control paths are tested to uncover

errors within the boundary of the

module.

The unit test is white box oriented

28 Engr. Ali Javed

Integration Testing 24

Integration Testing is a systematic technique for constructing a program structure while at the same time conducting tests to uncovers errors associated with interfacing.

There are two main approaches of integration testing

BIG BANG INTEGRATION

INCREMENTAL INTEGRATION

28 Engr. Ali Javed

36

System Testing

Recovery Testing

Security Testing

Load Testing

Stress Testing

Performance Testing

25

Engr. Ali Javed

36

Validation Testing

Acceptance Testing

Alpha Testing

Beta Testing

26

Engr. Ali Javed

For any query Feel Free to ask 27

Engr. Ali Javed

software requirements engineering lecture # 14

Documents