Traditionally, requirements specify what the system should do without explaining why. Developers and testers can then only blindly follow the specifications, relying on them to be 100% correct and precise. Without really understanding why something is being done, they cannot even spot problems that are obvious to domain experts, nor can they verify that what they are doing is actually what the customers want.
Defining what the system should do is crucial to communicating the specifications effectively, but explaining why gives developers and testers a much needed framework to understand what the customers really want. This knowledge enables them to spot inconsistencies and functional gaps, incorrect requirements and problems. These issues can then be sorted out during development rather than after the initial delivery.