I would say you're thinking the wrong way 'round. Requirements first is waterfall design. And it's a surefire way to make something on budget and on time that everyone will hate and noone will use.
Of course, even if you see your first implementation as nothing more than a starting point, you need something to get started. But a list of requirements locks down all of your design before anyone has had a chance to think about it and a feature by name alone means nothing. You have to place things in context.
My advice would be to start with a simple model of what your users are going to be (some personas, user roles, maybe some axes to place you users on) and start writing user stories. Just two or three sentences describing who your user is, and what they want to accomplish. Make no assumptions about what you're going to build or what features will be included. Just who is the user, what does she want?
From the user stories, you'll get a picture of what a minimal application might look like. I'd follow these principles:
- Don't include a feature unless it covers two or more different user stories. Features are easy to add, but difficult to remove.
- Include the client in the design. If you drop a design on someone's desk after four weeks of development they'll never go along with it. All stakeholders need to follow the process and see the reasoning behind it. That means the client, the users and the developers.
- Don't do dead documents. Don't make long technical documents that noone is going to read. Write simple user stories and illustrate how you're going to implement them with low-fi prototypes like wireframes.