As a Software Engineer I was faced with a many challenging tasks in this industry. Often its a over head for a PL to manage change requests from the customer. We may have implemented the requirements in the right way. But the customer may need it to be in their style.
RTM-Requirement Traceability Matrix is good way to manage these kind of change requests. A traceability matrix is a document, usually in the form of a table, that correlates any two baselined documents that require a many-to-many relationship to determine the completeness of the relationship. It is often used with high-level requirements (these often consist of marketing requirements) and detailed requirements of the product to the matching parts of high-level design, detailed design, test plan, and test cases.
An RTM usually contains table with coloumns like,
Requirement traceability Matrix traces requirement to the test plans/test cases.
We should break down each and every requirement as small as we can. Let’s say, we have a News module in the project. We should split down the requirements like,
- RQ-001 : Each page will list 10 news
- RQ-002 : News list will be sorted in ascending order of the posted date.
- RQ-003 : Each news item should have the following properties
- RQ-004 : New title (string)
- RQ-005: New Description (Rich Text)
- RQ-006: … so on.
Identify each and every minute requirement possibilities of the project. It takes time, but it can save lots of time in the end.
Once the RTM in fully identified, you have to get it concurred by the customer. This will ensure no change requests will pop up in the project in a later stage.
To be continued…