Scribd
Upload
255 views

Requirement Traceability Matrix

The document discusses requirement traceability, which involves tracking who suggested requirements, why they exist, related requirements, and how they relate to system design. Good traceability helps with change management, validation, and understanding stakeholder needs. Traceability can be backward from requirements to previous stages of development or forward to spawned documents. Different types of traceability links can be shown using matrices or relationships between element pairs.

Uploaded by

Ridho Annabil Ghazy
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
255 views

Requirement Traceability Matrix

The document discusses requirement traceability, which involves tracking who suggested requirements, why they exist, related requirements, and how they relate to system design. Good traceability helps with change management, validation, and understanding stakeholder needs. Traceability can be backward from requirements to previous stages of development or forward to spawned documents. Different types of traceability links can be shown using matrices or relationships between element pairs.

Uploaded by

Ridho Annabil Ghazy
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 12

Amna Shifia Nisafani

A requirement is traceable if you can discover:


 who suggested the requirement,
 why the requirement exists,
 what requirements are related to it and
 how it relates to other information such as systems design, implementation and
documentation.
Traceability helps in:
 Requirements change management
 Validation and reuse of requirements
 Understanding how and why the system meets the needs of the stakeholders
 Type of the system
 Estimated system lifetime
 Number of requirements
 Size of the project team
 Level of organizational maturity
 Specific customer requirements
 Backward traceability
 To previous stages of development
 Depends upon each element explicitly referencing its source in earlier documents

 Forward traceability
 To all documents spawned by a document
 Depends upon each element in the document having a unique name or reference number

Business plan Requ irements Document Design Specification


Forward-to traceability Forward-from traceability
Backward-from traceability Backward-to traceability
Top to bottom from requirements’ point of view
 Forward-to traceability
 Links other documents (which may have preceded the requirements document) to
relevant requirements
 Help validation
 Help evaluate which requirements are affected by changes to users’ needs

 Forward-from traceability
 Links requirements to the design and implementation components
 Help assure that all requirements have been satisfied
Bottom to top from requirements’ point of view
 Backward-to traceability
 Links design and implementation components back to requirements
 Help determine why each item is designed/implemented

 Backward-from traceability
 Links requirements to their sources in other documents or people
 Help validation
 Help evaluate how changes to requirements impact stakeholders needs
 Requirements – source traceability
 Links requirements with a person or document

 Requirements – rationale traceability


 Requirements – requirements traceability
 Links requirements with other requirements which are, in some way, dependent on them

 Requirements – architecture traceability


 Links requirements with the subsystems where these requirements are implemented
(particularly important where subsystems are being developed by different
subcontractors)
 Requirements – design traceability
 Links requirements with specific hardware or software components in the system which
are used to implement the requirement
 Requirements – interface traceability
 Links requirements with the interfaces of external systems which are used in the provision
of the requirements
 Requirements – feature traceability
 Requirements – tests traceability
 Links requirements with test cases verifying them (used to verify that the requirement is
implemented)
 Requirements – code traceability
 Generally not directly established, but can be inferred
 Show the relationships between requirements or between requirements and other
artifacts
 Table can be set up to show links between several different elements
 Backward and forward traceability
 Difficult to capture different types of links
 Define links between pairs of elements
 E.g., requirements to requirement, use case to requirement, requirement to test case…

 Can be used to defined relationships between pairs


 E.g., specifies/is specified by, depends on, is parent of, constrains…

 More amenable to automation than traceability table


Depends -on
R1 R2 R3 R4 R5 R6
R1 * *
R2 * *
R3 * *
R4 *
R5 *
R6
 Traceability matrices become more of a problem when there are hundreds or
thousands of requirements as the matrices become large and are sparsely
populated
 A simplified form of a traceability matrix may be used where, along with each
requirement description, one or more lists of the identifiers of related requirements
are maintained
Requirement Depends -on
R1 R3, R4
R2 R5, R6
R3 R4, R5
R4 R2
R5 R6

You might also like