Software Requirement Engineering

 Traceability
 Reviews
 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 )
 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

 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.
 Requirements traceability information can be kept in
traceability tables, each table relating requirements to one or
more aspects of the system or its environment
  Tracing User Needs to Features
 Defining the features of a system that meets user needs
 Helpful to continually relate how the user needs are
addressed by the features of your proposed solution.
 Traceability matrix

Table -1. Traceability Matrix: User Needs versus Features

Feature1 Feature2 ………. Featuren

Need1 x

Need2 x

Need….. x x

Needm x x
Tracing User Needs to Features
 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.
 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
Tracing Features to Use Cases
 Features can be related to the use cases proposed for the system.
 Simple matrix similar to the one shown in Table-2

Table -2. Traceability Matrix: Features versus Use Cases

UseCase1 UseCase ………. UseCase n

2
Feature1 x X
Feature2 x X
Feature... X
Feature m x x
Tracing Features to Supplementary (non functional) Requirements
 Use cases carry the majority of the functional behavior,
supplementary requirements hold valuable system requirements.
 Include the nonfunctional requirements 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
 Tracing continues from one phase of software development
lifecycle to another phase

 Tracing from Requirements to Testing

 Complete traceability strategy: the bridge from the
requirements domain to the testing domain.
 Every use case is "tested by" one or more test cases
 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
 Table-4. Traceability Matrix for Use Cases to Test Cases

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

…. ….
 Group of people analyze requirements, look for problems, meet
and discuss problems and agree on actions to address problems

 Formal meeting headed by a leader

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

standards
Plan review Distribute
documents

Prepare for Hold review

review meeting

Follow-up Revise
actions documents