You should generally design around functionality.
The reasoning behind this is that your customer will have an idea for a system in mind, and yet they won't really have all of the details worked out. These are things you will need to tease out over time, and they are things that could - and most likely will - change. When you start with the GUI, you are asking the customer to put all of their ideas onscreen, and yet you've missed the opportunity to get an unbiased view of the processes and functionality that the customer needs. Sure, they might have many of their needs defined with how they might like a screen to look, but without understanding critical workflow and data management issues, you only get a small part of the picture up front. GUI's can be finicky things to get right, and you can find yourself spending a lot of time on them, which may risk running out of time to do the serious back-end stuff, and by relying on the GUI to dictate the overall design, you risk creating a dependency between the UI and the back-end.
Starting the other way around seems less intuitive to many people (including the customer), but it can save you a great deal of heart-ache later on. While on the one hand you want ot put of major decisions until the last possible moment, having as much information as possible up front will allow you a little flexibility in how you go about implementing a system. You'll need to know early on whether you will be handling large volumes of data, and whether you will be communicating that data beyond the confines of the user's local PC. Will you need a distributed system, N-Tier, Web-Based, etc? Knowing this stuff up front gives you time to research your options while you are encoding your business rules in libraries that could exist in nearly any configuration.
Something else to ponder, is that you may wish to deliver a whole system at the end, or schedule major milestone releases, or release incrementally in the Agile style. When you begin with the GUI, you lock your customer into a particular mode of thinking, that is, in how the software will be perceived. If you start with the back-end and release incrementally, you can build a rudimentary interface and tell your customer that it is simply to provide a means to conduct a controlled test of functionally, so that the customer can decide how best to present that functionality to their users, maintain their branding, and so on. Starting with the GUI will kind of limit everybody's thinking in terms of presentation possibilities to be biased towards whatever everybody sees first.