Many thanks for your reply David, I really appreciate everyone's thoughts.

I certainly agree that different organisations do things in different ways. I guess I'm a stickler for always trying to drive "best" or "better" practice, rather than just going with the flow. I know that there's no one size fits all approach/method to software development, but I'm convinced of having at least a loose framework to make sure everything is covered in a consistent manner.

In response to your questions:

"The customer may also want to see more detail of the actual solution at a high-level".  Why? Because they don't believe the list of requirements is correct or complete?

No, but because a list of funtional requirement statements isn't a "solution" per se. The functional requirements have not been "realised" until they are defined as part of a high-level design. Or at least, that's what my organisation likes to think.

Next, are you then saying that having use case replaces functional requirement statements, so a high-level design isn't needed? Because the customer will see the use cases and then believe all of their requirements have been captured?

Yes to the above. My feeling is that Use Cases can replace functional requirements statements. Supplementary requirements (non-functional requirements and business rules) can be documented as statements, but the bulk of the functional requirements can be captured in Use Cases. Since Use Cases go further than functional requirements statements in capturing behaviour independent of technology or platform, they should be sufficient as an agreement with the customer for the basis of the system. Additional User Inteface wireframes may be useful in more complex systems.

I follow an approach that creates use cases in order to derive functional requirement statements, so I have both to show that the requirements are complete and correct.

I don't write out functional requirements statements, but I know that some people do. I document the "Business Needs" and trace these to the Use Cases and non-functional requirements and Business rules. I also include higher level "feature" statements to summarise the functionality of the system, although I know that this is contentious.