To my way of thinking you could start defining the database (maybe with
the aid of something like uml) and the rest should be straightforward
from that.
Another approach would be to define what you want each part of the user
interface to look and work like and then create the system to work with
that. I am an advocate of thinking about the system before implementing
it.
So, I’m going to get my plug in here for “Behaviour Driven Development”.
Start with the sorts of things you want your application users to be
doing. You have a brief start there: register, book, pay, etc, but
there’s obviously much more.
When you have a reasonable set of stories, aka scenarioes, you can
start to write up your features a la cucumber/gherkin and use them to
drive your development, following the red/green/refactor concept in
BDD/TDD.
BigDesignUpFront followed by DoTheSimplestThingYouCanThinkOf is
typically the way to go. In addition, building the application from
the core stories out works best, keeping in mind that you always want
to have a working application, even if it’s just very minimal set of
features. (Pragmatic Programmer calls this “Firing Tracer Bullets”).