Reacibility Requirement Matrix

1. What is the Requirements traceability Matrix (RTM)?

       The Requirements traceability Matrix (RTM) is a document that shows the relationship between requirements and other artifacts. It is used to prove that the requirements have been met. And it usually documents requirements, tests, test results, and problems.
 

2. What is Traceability?  

    Requirements traceability is the ability to link requirements to other artifacts such as various jenis pengujian perangkat lunak or bugs. It is used to track requirements and prove that requirements have been met.
 

3. Why Requirement Traceability is Important
 

•       Meet the Goals

     ensure that your requirements meet your initial goals. For example, it gives you proof that you meet the compliance requirements.
 

•       Running the Right Tests

     helping your quality assurance (QA) team understand what needs to be tested. This increases test coverage by mapping test cases back to each requirement.
 

•       Making decisions

         Can be used for decision-making during product development

•       Managing Projects

         You'll know exactly how far you've come. And you will be able to manage the scope of your needs.

4. How to Create an RTM

      You can create an RTM in Microsoft Excel. Or you can use a special tool to speed up the process.

There are three basic steps — ?? no matter what tool you're using:

• Define your goals.
• Assign your artifact (and its relationship)...
• Fill out the traceability matrix.

5. Benefits of Using a Traceability Matrix

There are six main benefits of using a traceability matrix.

• Gain visibility across development.
• Make better decisions (for example, on changes in requirements).
• Accelerate the release cycle.
• Don't worry knowing your needs are met.
• Prove compliance faster.
• Pass audits without fear.

6. Types of Traceability Matrix

• Forward traceability

In the 'Pass Traceability' requirement to the test case. This ensures that the project develops in the desired direction and that each requirement is thoroughly tested.

• Backward traceability

            Test Cases are mapped with Requirements in 'Traceability Backwards'. The main goal is to ensure that the product that is currently being developed is on the right track. It also helps to specify that no additional unspecified functionality is added and thus the scope of the project is affected.

• Bi-directional traceability

            (Forward + Backward): A Good Traceability Matrix has a reference from test case to requirement and vice versa (requirement to test case). This is referred to as 'Two-Way' traceability. This ensures that all Test cases can be traced to the requirements and each specified requirement has an accurate and valid Test case for them.

7 . Type Requirement specification

• Business requirements

           The actual customer requirements are listed in a document known as a Business Requirements Document (BRS). This BRS is a carefully derived list of high-level requirements, after a brief interaction with the client.

           It is usually prepared by the project's 'Business Analyst' or 'Architect' (depending on the organization or structure of the project). The 'Software Requirements Specification' (SRS) document is derived from the BRS.

• Software Requirements Specification Document 

           It is a detailed document that contains all the meticulous details of all the functional and non-functional requirements. This SRS is the basis for designing and developing software applications.

• Project Requirements Document

           A PRD is a Reference Document for all team members in a project to tell them what a product should do. Some aspects that can be grouped include product objectives, product features, launch criteria, as well as project budgets and schedules.

Use Case Documents

           It is a document that helps in designing and implementing software as per business requirements. It describes the relationship between actors and events, as well as the roles that must be performed to achieve the goal. This is a detailed step-by-step description of how the task needs to be done.

For example,

Actor: Customer

Role: Download Games

The game download was successful.

Use Cases can also be included in SRS documents according to the organization's work processes.

• Defect Verification Documents

           It is documented containing all the details related to the defect. Teams can maintain 'Defect Verification' documents to correct and retest defects. Testers can refer to the 'Defect Verification' document, when they want to verify whether the defect has been fixed or not, retest the defect on different OS, device, different system configuration, etc.

           The 'Defect Verification' document is useful and important when there is a specific phase of defect repair and verification.

• User Stories

           KUser stories are mainly used in 'Agile' development to describe software features from the end-user's perspective. User stories determine the type of user and in what way and why they want a particular feature. Requirements are simplified by creating user stories.

Today, all software industries even us moving towards the use of Agile User Stories and Development and appropriate software to record requirements.