Modern Verification Environments rely heavily on System Verilog (SV) constraint solver to generate legal stimulus. Verification engineers write constraints based on design specifications to carve out a feasible region for stimulus that a Design Under Test (DUT) can support. The quality of such constraints often decides the quality of testing that is being done. The definition of legality of stimulus changes during the course of a project as new features get added to the design. It also changes across projects when certain old features are selectively enabled or disabled for a particular chip. Constraints typically get added on top of one another over projects and there is significant burden of legacy code. In unit and integration level TestBenches (TBs), typically the number of such constraints could be anywhere from 1K-20K (or sometimes even larger). Constraints are also added temporarily to prevent tests from hitting known checker issues or known design bugs. These constraints are meant to be removed once the checker issue or RTL bug is fixed. If these constraints are accidentally not removed or if there are constraints which were added due to incorrect understanding of the specifications, the TB can contain over-constraints. Unlike under-constraints, over-constraints do not cause test failures and can silently degrade coverage and possibly impact simulation performance. The question then arises: How do we know if there are constraints which are over-constraining the Feasible Space and degrading quality of the stimulus? How do we identify redundant constraints which do not affect the stimulus, but cause performance degradation? In this paper, we propose Systematic Constraint Relaxation (SCR) – a technique that can potentially identify such over-constraints.