As always, it depends on context. Early on in my Career, I had issues saying no myself. I guess it's the normal Thing. Nobody has reason to challenge the "yes", so that's usually the path of least resistance in a discussion. Plus if you're not that firm in the topic and issues discussed, any follow up discussion to a No might expose you.
So to me the first step in learning to say No was learning to admit that there are things I don't know. I find that particularly BAs and Requirements Engineers have a hard time with that, which makes it particularly difficult to challenge the requirements from the business side (other issues as well like requirements which are really more BA's assumptions, rather than requirements stated by the business side, but that's a topic for another discussion).
Personally whenever possible, I still try not to actually say No. Instead I either try to refer to contractual documentation (scope agreements of one form or the other) and make liberal use of the term change request. Depending on the discussion it often helps to ask the other side to explain their request in more detail. Working in Data Integration / DWH / BI I use this technique often in the context of reporting requirements. For example instead of me explaining why a drill Operation is not possible if there is no hierarchy / 1:n relationship or similar, I ask them what they expect to see as a sum at the higher Level if an element has more than one parent.
But definitely there are situations when nothing but a No will do - like requirements for a report in a Fixed Price Project, listing something along the lines of 1) Customer 2) Product 3) Average Revenue 4) etc. ... the only way to live with that is by being glad you're only subcontracting on that Project ...