You'll never be asked to LIST constraints because as MJRomeo pointed out - it's more likely that you'll have to identify and explain them.
My tip is yes - those generic constraints often always work - time, money...etc. but just make sure you adapt them to the case study, like, why exactly does time matter - are they a large organisation in which downtime means that they can potentially lose a lot of money? Money might be a constraint for a small home-office sort of scenario where the client does not have the financial muscle to afford large-scale IT solutions.
Essentially you have to ask yourself what is the limits of what can be installed, if everything was good, you could install a state-of-the-art hardware/software system which caters to their every need, but that's not feasible. It's always best, in my opinion, to have both generic and non-generic constraints explained, so if you were asked to explain 3, 2 of 1 and 1 of the other would be good. Some non-generic ones might include:
- Having to be compatible with legacy systems
- Having to compromise with old hardware
- Technically illiterate staff members (so training might be an issue)
- Practical constraints - e.g. wired ethernet is not practical for connecting two buildings (something I remember from a practice exam).