Making Difference in Mid-Tier Service testing

Working on mid-tier services testing, I have experienced a couple of challenges that I feel worth noting.

The kind of services I tested included components having a heavy business logic and loosely coupled from UI and some which dint have much logic but were was tightly coupled by UI. On the first case, there were many scenarios that could be easily identified since they are very much, in between, hanging in the air. So the point is that they were not idenified during normal functional testing and there was lot of window for services testing.

Coming on the second scenario of having the services coupled with UI, it was difficult for me to identify quality scenarios since the major ones were taken up by UI functional testing. There was detailed discussion between me and person doing functional testing. It was understood that I was executing the same test cases which the former person was doing. Towards some point of discussion it was felt that doing the same task twice has no relevance. But I gradually comprehended,during course of discussion, that there might be cases where there is some data manipulation between UI and services. Or It could happen that some range of data is not fed as input to services tier as it does not include business requirement(but could logically make sense to have the tier work correctly for that data range). These are two places I feel, there would be some difference in making services tier robust.