How to Create a Requirements Traceability Matrix(RTM)

How to Create a Requirements Traceability Matrix

Introduction
A successful project cannot be achieved without the project manager having an excellent organizational skill set. Information must be readily available upon demand. A good project manager will be able to identify what works and what is broken in an instant. Having a requirements traceability matrix is an invaluable tool to accomplish this.

Things You'll Need
· Project deliverables
· Business requirements catalog
· Use cases

Steps:

Step One:
Create a template. There are many on the web from which to choose. The project manager, sponsor and decision makers will thank you when they are receiving information in a consistent and logical format.

Step Two:
Transfer data from your Business Requirements Catalog. You will need, at bare minimum, the exact requirement identified from the Business Requirements Catalog that you need to have already created.

Step Three:
Identify the requirement with a unique ID. The business requirements document should have already assigned an identifier that you will use in this matrix. If not, you will create one now and insert it next to the applicable requirement.

Step Four:
Copy the Use Case ID into the traceability matrix. You may or may not have used use cases to develop your requirements. If you did, you will have an identifier on your use case. You must transfer the ID to this matrix in order to see out of what data or scenario this requirement was born.

Step Five:
Insert the System Requirements Specification (SRS) ID into the traceability matrix. You might not be the actual author of the SRS, but there must be a line on the matrix to trace the business requirement to the corresponding system requirement needed.

Step Six:
Insert the testing data into the traceability matrix. There are many different testing methods and procedures that can be used in any project. The traceability matrix must account for the types of tests used in this project. This should clearly indicate the specific test type, the date tested and the outcome of pass/fail.

Step Seven:
Review your data. Your matrix should now clearly show the specific deliverable requirements from conception clearly through testing. This will ensure that nothing gets moved into production haphazardly and when asked, the Project Manager now has this information at the ready.


Sample Example:

Psychology of Software Testing

Software Testing-Psychology of Software Testing

The purpose of this section is to explore differences in perspective between tester and developer (buyer & builder) and explain some of the difficulties management and staff face when working together developing and testing computer software in Software Testing.

Different mindsets?
We have already discussed that none of the primary purposes of testing is to find faults in software i.e., it can be perceived as a destructive process. The development process on the other hand is a naturally creative one and experience shows that staff working in development has a different mindset to that of testers.We would never argue that one group is intellectually superior to another, merely that they view systems development from another perspective. A developer is looking to build new and exciting software based on user's requirements and really wants it to work (first time if possible). He or she will work long hours and is usually highly motivated and very determined to do a good job.A tester, however, is concerned that user really does get a system that does what they want, is reliable and doesn't do thing it shouldn't. He or she will also work long hours looking for faults in software but will often find the job frustrating as their destructive talents take their tool on the poor developers. At this point, there is often much friction between developer and tester. Developer wants to finish system but tester wants all faults in software fixed before their work is done.

In summary
Developers
-Are perceived as very creative - they write code without which there would be no system! .
-Are often highly valued within an organization.
-Are sent on relevant industry training courses to gain recognized qualifications.
-Are rarely good communicators (sorry guys)!
-Can often specialize in just one or two skills (e.g. VB, C++, JAVA, SQL).

Testers
-Are perceived as destructive - only happy when they are finding faults!
-Are often not valued within the organization.
-Usually do not have any industry recognized qualifications, until now
-Usually require good communication skills, tack & diplomacy.
-Normally need to be multi-talented (technical, testing, team skills).

Communication b/w developer and tester
It is vitally important that tester can explain and report fault to developer in professional manner to ensure fault gets fixed. Tester must not antagonize developer. Tact and diplomacy are essential, even if you've been up all night trying to test the wretched software