I would walk him though the use case in person. The client must be made to read the documentation at some point or else he's going to be sorry when he sees the first version and it doesn't work the way he expects. This is a client-management issue and one that you need to learn about early in your career.
I always schedule an in-person meeting to walk-through whatever document I have I just delivered to the client. This goes for both internal and external clients. They almost never read the documents on their own. This is coming from my 20+ years of experience. You need to hold them by the hand, walk them through each step and make sure they understand what is written and how the system will function for all alternative cases. Otherwise, you're just setting yourself up for failure down the road.
BA should always have supplementary artifacts such as - flowcharts, wireframes of the screens and so on which explains the entire use case. So even if the stakeholder does not want to read the entire use case, just by having a glimpse of the poictures provided they should understand what is the use case about. Rightly said ' A picture speaks a thosand words'
Simple thing is to have a Use Case Daigram adjacent to the Use Case, the daigram should tell the user what the use case will do, so that by looking into that satkeholder will get to knoe the functionality of the usecase instead of going through the whole shit.
