In reply to haykp:
Soft constraints can be useful in cases where you may need to extend a set of constraints that include error conditions or illegal conditions. There are other situations where soft constraints can come in handy but I've used this one a lot in the past.
For example, perhaps your transaction involves an array of data whose size must be a multiple of two, but the design under test needs to be able to handle cases where the incoming data is of an illegal size.
In this situation, the base class for the transaction would contain a "soft" constraint to keep the size of the data array on an even boundary, but an extended class could produce illegal data sizes by declaring an additional "hard" constraint that make the size end on an odd boundary. Since the original constraint was declared as "soft" it will not be in conflict with the new constraint in the extended class, allowing you to produce illegal stimulus when the need arises.
