software requirements engineering lecture # 14
Post on 23-Nov-2021
6 Views
Preview:
TRANSCRIPT
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: ali.javed@uettaxila.edu.pk
Website: http://web.uettaxila.edu.pk/uet/UETsub/perSites/mySite.asp?frmEmail=ali.javed@uettaxila.edu.pk
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
Tracing Requirements in the System
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 Requirements in the System
Definition Domain 11
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 Requirements in the System
Definition Domain 12
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
Tracing Requirements in the System
Definition Domain 13
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
Tracing Requirements in the System
Definition Domain 14
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
Tracing Requirements in the System
Definition Domain 15
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
top related