Overview
v Scope Verification, which is the process of tracking and ensuring that all the requirements outlined in the functional specification document have been met by the end product/deliverables, can be a cumbersome and laborious process without formal traceability procedures in place.
v Traceability Matrix is an industry-accepted format for tracking requirements. It provides a convenient format that helps to visually represent associations between user requirements for the system built and the work products (project artifacts) developed and implemented to verify those requirements.
Requirements Traceability Matrix
Scope Verification:
Scope Verification is the process of obtaining the stakeholder’s formal acceptance of the completed project scope and associated deliverables. Verifying the project scope includes reviewing deliverables to ensure that each is completed satisfactorily. Scope verification occurs at the end of each project phase and as part of the project closeout process.
Tools for Verifying Scope:
¨ Inspection
¨ Requirements Traceability Matrix
Requirements Traceability Matrix:
¨ The Requirements Traceability Matrix (RTM) is a tool that is used to trace each requirement back to a specific business case and then forward to the rest of the scope deliverables (like specific WBS work packages) as well as other parts of the project.
¨ The RTM captures all requirements and their traceability in a single document. It is used to record the relationship between the requirements to the design, development and testing artifacts of the software.
Types of Traceability:
¨ Forward Traceability - Mapping of requirements to design, coding and testing artifacts. Also, customer needs are traced forward to requirements so that it is easy to identify which requirements will be affected if customer needs are changed. A user can trace forward from requirements by defining links between individual requirements and specific product elements.
¨ Backward Traceability - Mapping of testing artifacts back to coding, design and requirements. Also, one can trade backward from requirements to customer needs in order to identify the origin of each software requirement. Specific product elements may be traced backward requirements to identify why each item was created.
Different Fields in RTM
Below are the fields in an AD RTM as per standards:
|
Requirement
Clarification
|
Business
Requirements
|
System
Requirements
|
NFR
Requirements
|
Related
Requirements
|
User
Interface Prototype
|
|
|
Clarification
ID
|
Business
Requirement ID
|
System
Requirement ID
|
System
Use Case ID
|
NFR
Requirements ID
|
Related
Requirement ID
|
Screen/
Wireframe ID
|
|
Identifier
for any clarifications raised mapping to the business requirement
|
Unique
identifier for the business requirement
|
Unique
identifier for the system requirement mapping to the business requirement
|
Unique
identifier for the use case mapping to the system requirement
|
Unique
identifier for the Non Functional Requirement mapping to the system
requirement
|
Requirements
mapping to the high level system requirement
|
Identifier
for the wireframe that cover the specific requirements mapped
|
System Testing
|
Performance Testing
|
Design
| |||||
Document Name (SCI ID)
|
Test Case ID
|
Document Name (SCI ID)
|
Test Case ID
|
Component/ Class Diagram ID
|
Sequence Diagram
|
Use Interface Specification- Screen ID / Name
|
Database Tables
|
System test case document name
|
IDs for the test cases that map back to the specific requirement
|
Performance test case document name
|
IDs for the test cases that map back to the specific requirement
|
Identifier for the design component or class diagram that covers the requirement
|
Identifier for the sequence diagram that covered the requirement
|
Identifier for the screen that covered the requirement
|
Table names that are referred to cover the requirement
|
Coding
|
Unit Testing
|
Integration Testing
| |||
Program / Source Code File Name(s)
|
Method/ Stored Procedures
|
Document Name (SCI ID)
|
Test Case ID
|
Document Name (SCI ID)
|
Test Case ID
|
Code files that cover the mapped requirement
|
Store procedures that are referenced
|
Unit test case document name
|
Test case ID to test the given requirement
|
Integration test case document name
|
Test case ID that are referred as part of the given requirement
|
Workflow & Stakeholders
RTM Workflow:
A Requirements Traceability Matrix is usually created early on in the project lifecycle during the requirement analysis phase. It has to be kept alive throughout the lifecycle with regular updates. Below is a snapshot of the typical activities across phases and stakeholders.
Phase
|
Activities
|
Stakeholder
|
Requirement Analysis
|
1. Assign a unique identifier to every business / system / non-functional requirement.
2. Record every requirement in the RTM |
Business Analyst
|
Design
|
1. Create a design specification document, assign identifiers to class / sequence diagrams, other design artifacts, database tables, user screens, unit / system / performance / integration test case.
2. Record the identifiers for the design artifacts, database tables, user screens, test case document name and test case IDs against the corresponding requirement in RTM |
Solution Architect / Lead Developers / Testers
|
Coding
|
1. Create code files, record the code module details and stored procedures against the corresponding design artifact and requirement in the RTM
|
Developers
|
The regular tracking of RTM helps to identify missed functionalities, control scope creeps, identify impacted items in case of change requests. These ensure complete control over the requirements and its associated work products.
RTM Examples
Example # 1: During the system testing phase, the customer comes up with a change in one of the features. Due to its business criticality, the team decides to go ahead with the change. How does the team easily identify the impacted items?
¨ The existing requirement that is undergoing the change can be forward traced to identify the impacted design artifacts, code files and test cases mapped against it.
Example # 2: The project is currently in UAT and a couple of high priority defects are logged. Before moving the fixed code for retest, how does the team identify the concerned test cases to be executed?
¨ The changed code files can be forward traced to identify unit / system / performance / integration test cases mapped against them.
Example # 3: The customer is doubtful about a particular need being addressed in the finished software, How does RTM help prove that the need is implemented
¨ The functional / non-functional requirements mapped against the business need in an RTM would help to ensure that all needs are addressed.
Example # 4: A project manager decides to enhance a couple of features in a project to exceed customer’s expectations. Is this right? If not, how does RTM help to avoid it?
¨ This is a typical example of ‘Gold Plating’, which should be avoided. Delivering more than what is committed could set wrong expectations with the customer. If there is a low-level element in an RTM without mapping to high-level requirement, then it is apparently because of over engineering.
Benefits / Limitations of RTM
Benefits:
¨ Ideal Scope Verification tool which helps to ensure all requirements are met by the developed software at the end of every phase / during closure.
¨ Detailed mapping of work products to requirements helps to identify the impacted items in case of change request or issues.
¨ It is easy to identify the missed functionalities / scope of creep / ‘Gold Plating using RTM
¨ RTM serves as a guide to test planning
¨ It helps to have a prioritized list of requirements
Limitations:
¨ An RTM, which is not kept alive throughout the lifecycle, does not help. It has to be regularly tracked and updated.
¨ An RTM without unique identifier for requirements will lead to confusion.
¨ Project team with a wrong understanding on the fields and usage of RTM will not be able to leverage its benefits.
Best Practices
¨ An organization must adopt consistent practices in requirements management, including traceability. If all stakeholders and team members buy into a traceability practice, take ownership of it and become accustomed to it, it greatly increases a traceability method’s chances of success.
¨ Unique identifiers must be adopted for requirements and business rules. To permit traceability, each requirement must be uniquely and persistently labeled so that you can refer to it unambiguously through the project.
¨ A responsible party must take ownership of traceability. Whether using a manual method or an automated tool, a knowledgeable analyst must take ownership of the traceability process.
¨ The analyst must practice consistency in updates. This will require a significant commitment on the part of the analyst. “Whenever such changes occur, it is necessary to update the traceability data to reflect these changes.”
¨ When tracing all requirements is simply time-prohibitive, the analyst may be selective based on cost. If the prospect of tracing every requirement is overwhelming, an analyst may choose to only trace the expensive ones.
Quiz
1. Which of the following BEST describes the purpose of an RTM?
o A) RTM describes how WBS Dictionary entries are traced to work packages and how work packages are decomposed from deliverables.
ü B) RTM is used to trace each requirement back to a specific business case and then forward to the rest of the scope deliverables.
o C) RTM is an ideal tool to define code review standards.
o D) RTM visually represents the functional decomposition of customer’s business needs.
2. Your team is nearing the completion of the design phase and the design document is being reviewed. There is a new joiner in the team who is new to software development. He raised a query that few design aspects documented in the detailed design artifact is out of project scope. Which of the following documents will help trace the requirements to design?
o A) Project Plan
o B) Project scope statement
ü C) Requirements traceability matrix
o D) High level design document
3. Which one of the following statement is False?
o A) RTM is created early on in the project life cycle.
o B) RTM is a live document which needs to be tracked and updates regularly through out of the project lifecycle.
ü C) RTM document should be signed off by the customer once the requirements are frozen and should not be updated after that.
o D) RTM have multiple stakeholders updating information in it.
4. Which one of the following statement is False?
ü A) Accepted Deliverables
o B) Project Management Plan
o C) Validated Deliverables
o D) Requirements Traceability Matrix
Note: The INPUTS to Verify Scope process are project management plan, requirements documentation, requirements traceability matrix and validated deliverables. Accepted Deliverables is an OUTPUT of the Verify Scope process.
5. After delivering a release, the customer raises concerns that certain features do not have any business value. Which among the following is the BEST way to prove the business significance of delivered features?
o A) Provide a walkthrough of the project charter to the customer.
ü B) Use the RTM to map the implemented features back to the business needs.
o C) Map the implemented features to the signed off requirements and explain to the customer.
o D) Map the implemented features to the acceptance criteria defined.
6. Which of the following are the advantages of RTM?
o A) RTM helps to assess the impact of change request and identify impacted work products.
o B) RTM helps to identify scope creeps and gold plating.
o C) RTM helps to verify scope during the end of each phase and during project closure.
ü D) All of the above.
