You have defined a situation with no escape.
I'm sure there are real life situations where you have a block of complicated functionality which can't be split. But the usual case is that you can break down a requirement into sub requirements which do have some benefit of themselves.
Say for example my requirement is to validate UK credit card billing addresses. This is pretty complicated, we want to ensure as best as possible that the address is the residential address of the person named on the card so that if they default on a payment we can chase them up.
There are potentially hundreds of validations and checks we can do to improve the reliability of the check, but each one individually is testable and offers a real decrease in fraud risk.
- address has a house number and a post code
- postcode is valid format
- postcode lookup with external api succeeds
- postcode is a geographic postcode
- address is validated with credit card supplier
If push came to shove, the customer would be able to make money with only a subset of the rules implemented. Either the extra risk could be accepted or manual work arounds could be added to the workflow to mitigate the situation.
Scrum and agile methodologies are designed with this in mind. They try to avoid failure of the whole project by ensuring that some missing requirements do not cause the entire solution to be worthless.
But they cant change reality, if you have a space rocket which definitely needs X, Y and Z to fly. Then you need all three!
The trick is to recognise that generally in line of business applications this is not the case, despite what the customer might say.