Do you find it hard to say no to unreasonable requests for your software team? How do you frame your “no” so it doesn’t cause problems with the team making requests?

Priority , Business Case and what if scenarios. It looking at the backlog , before something gets added something falls off. We have a very important decision making criteria that will help us make those decisions.

If a request is truly unreasonable -- no business, product, or technology case makes sense -- then it should be easy to qualify and say "No."
However, I generally take the view that technology makes almost anything possible. As others have said, making use of a decision framework and being transparent about your teams' capacity, workload, and objectives makes it easier to justify putting something on the backlog for later assessment and development, or outright rejecting the work completely. 

I have said No. This is important, right now we are at capacity to own it. We can provide support if needed.

Make sure you have a good decision making framework that helps you to determine and explain which are 'reasonable' and 'unreasonable' requests. You can leverage dimensions like 'does this fit to the strategic roadmap', 'what's the impact to company revenue and software sales', 'is this a single customer request or a generic one', 'what's the ROI to develop this feature request' etc. If this framework is well communicated, you have a very good basis to explain why the answer is 'no' in certain cases for certain requests. And teams will also feel that you did not reject the request randomly but there's a decision template that is reasonable, objective and make sense.