Subscribe by Email


Showing posts with label Traceability table. Show all posts
Showing posts with label Traceability table. Show all posts

Thursday, April 7, 2011

Requirements Traceability Matrix (RTM) - A tool for managing requirements

The Requirements Traceability Matrix is a tool for managing requirements. It is not only used in requirements engineering but through out the software engineering process. The white box approach refers to the development of system requirements without
considering the technical implementation of those requirements.

Components of Requirements Traceability Matrix


- RTM ID: A unique identification number for a specific requirement.
- Requirements: This is a structured sentence describing the requirements in a "shall" format.
- Notes: These are additional notes of requirements.
- Requestor: This is the person who requested the requirement.
- Date: This is the date and time the requirement was requested by requestor.
- Priority: This is the priority given to the requirements.

While the above elements are the initial RTM, one can customize the matrix to tie the requirements with other work products or documents. It can be done by:

- Relative to RTM ID: It specifies if the current RTM is directly or indirectly related to other requirements.
- Statement of Work (SOW): This is a description that relates the requirements directly back into a specific paragraph within the Statement of Work. It is a document that specify the nature of the engagement of the development team with their clients.

The components and the use of the RTM should be adapted to the needs of the process, project and product. It grows as the project moves along.


Friday, December 3, 2010

What comprises Test Ware Development : Test Strategy Continued...

Test ware development is the key role of the testing team. Test ware comprises of:

Test Strategy


Before starting any testing activities, the team lead will have to think a lot and arrive at a strategy.The following areas are addressed in the test strategy document:
- Test Groups: From the list of requirements, we can identify related areas, whose functionality is similar. These areas are the test groups. We need to identify the test groups based on the functionality aspect.

- Test Priorities: Among test cases, we need to establish priorities. While testing software projects, certain test cases will be treated as the most important ones and if they fail, the product cannot be released. Some other test cases may be treated like cosmetic and if they fail, we can release the product without much compromise on the functionality. This priority levels must be clearly stated.

- Test Status Collections and Reporting:
When test cases are executed, the test leader and the project manager must know where exactly we stand in terms of testing activities. To know where we stand, the inputs from the individual testers must come to the test leader. This will include, what test cases are executed, how long it took, how many test cases passed and how many failed etc. Also, how often we collect the status is to be clearly mentioned.

- Test Records Maintenance: When the test cases are executed, we need to keep track of the execution details like when it is executed, who did it, how long it took, what is the result etc. This data must be available to the test leader and the project manager, along with all the team members, in a central location.This may be stored in a specific directory in a central server and the document must say clearly about the locations and the directories.

- Requirements Traceability Matrix: Ideally, each software developed must satisfy the set of requirements completely. So, right from design, each requirement must be addressed in every single document in the software process. The documents include the HLD, LLD, source codes, unit test cases, integration test cases and the system test cases. In this matrix, the rows will have the requirements. For every document, there will be a separate column. So, in every cell, we need to state what section in HLD addressed in every single document, all the individual cells must have valid section ids or names filled in.

- Test Summary: The senior management may like to have a test summary on a weekly or monthly basis. If the project is very critical, they may need it on a daily basis also. It addresses what kind of test summary reports will be produced for the senior management along with the frequency.


Thursday, November 12, 2009

Requirements Management

Requirements management involves communication between the project team members and stakeholders, and adjustment to requirements changes throughout the course of the project. To prevent one class of requirements from overriding another, constant communication among members of the development team is critical. For example, in software development for internal applications, the business has such strong needs that it may ignore user requirements, or believe that in creating use cases, the user requirements are being taken care of. The purpose of requirements management is to assure the organization documents, verifies and meets the needs and expectations of its customers and internal or external stakeholders.

Requirements traceability is concerned with documenting the life of a requirement. It should be possible to trace back to the origin of each requirement and every change made to the requirement should therefore be documented in order to achieve traceability. Even the use of the requirement after the implemented features have been deployed and used should be traceable.

The purpose of the Requirements Traceability Matrix is to help ensure the object of the requirements conforms to the requirements by associating each requirement with the object via the traceability matrix.
A traceability matrix is used to verify that all stated and derived requirements are allocated to system components and other deliverables.

- Features Traceability Table : It shows how requirements relate to important customer observable system/product features.
- Source Traceability Table : It identifies the source of each requirement.
- Dependency Traceability Table : It indicates how requirements are related to one another.
- Subsystem Traceability Table : it categorizes requirements by the subsystem that they govern.
- Interface Traceability Table : It shows how requirements relate to both internal and external system interfaces.


Facebook activity