Value of Requirements to Test Case Mapping

Updated: Jan 18

So often in COTS (commercial off the shelf) solution implementations we see customers and vendors at odds with fulfillment of requirements. Typically, when a customer goes to the RFP stage, they will publish a list (sometimes in the 1000’s) of business requirements that the proponent system needs to satisfy. The successful bidder then is typically contracted to implement their solution, whether it be custom or COTS in order to meet the documented requirements. Normally the satisfaction of these requirements is a contractual obligation, so it is always a good idea as the vendor to ensure that the customer is able to use and test your solution against each and every one of the documented requirements. Here are the key reasons on why you need to map requirements to your testing plans.

Ensuring 100% Testing Coverage

Making sure that not only your team but the customer tests the solution fully is a key element to a successful cut over. Making sure that all known requirements have been tested and are functional is the core reason for why we do such extensive testing in our projects. Through this testing there may be occurrences where the customer’s business requirements could evolve and potentially see scope changes.

Delivery of Scoped Work

Contractually it is important to prove that your solution meets the needs specified by the customer. Often times, the contract will include a reference or appendix of the documented requirements that were published with the RFP. As a vendor it’s important that if there is the contractual obligation to meet all of the documented requirements that you ensure that those requirements have been properly mapped to test cases as part of your overall testing strategy to prove to the customer that the functionality has been tested and that it maps back to the requirements originally specified by the customer.

Product Compliance

Another reason to get behind mapping requirements to test cases is to ensure that your product is fully compliant with what the customer’s requirements are. Not only does this help contractually as noted above but it also can help the customer as well when defending their decision to go with your product. This is especially true with customers who serve the public (ex. municipalities or utilities purchasing solutions that directly impact the public such as billing or financial solutions). By being able to produce a record of successful testing against documented requirements, this can prove that your solution is fully compliant with the needs of the customer.

Recent Posts

See All

Professional Services Automation (PSA) systems are designed – well, intended – to help us do our day-to-day jobs better in the professional services sector. This isn’t always the case and a lot of tim

Escalations are inevitable on every project. Things can be planned to the nth degree but there will still be escalations – and that’s ok. There are foundational pieces that you as a leader and project

Project Director is a role that not a lot of organizations give a lot of thought or attention towards. The Project Manager and Project Sponsor roles are very well defined and utilized but what about a