Business Requirements (BR) and Use Cases (UC) are two different poles of the software development cycle (SDLC).
You have to consider both, but apply them at different times of the SDLC.
Take a look on this diagram (taken from here):
Both documents come from the customer's perspective, but apply differently:
BR essentially define primary objectives (hence the name), e.g. what the software should do. They are usually having top-down, feature-wise nature.
UC define individual cases (hence the name) how the users will interact with the system, or how the components interact with each other.
As soon as both are defined, the development team starts elaborating both by essentially moving towards each other:
- Analysts drill down to SRS and DS;
- QA team elaborate Use Cases into Test Cases;
(skipping the resource planning phase as it is not relevant to your question)
Then, at the very middle of the SDLC, the Developers bring both ends together.
You can't ignore BR as they define what the software will do;
You can't ignore UC as they define how it will be tested (or, if you wish, they define success criteria for telling working software from non-working one)
I've seen quite a few cases when teams failed to keep both documents synchronized, assuming BR are for project start, and UC are for project end. As result, one of these docs becomes too detailed, while another is treated as "it's for the customer, not for the developers". IMHO, having these two synced at all phases lets the team detecting logical gaps early. Too valuable asset to ignore.