One of the most complicated things in the whole word is to get the business needs that will drive a software project to address or support a company strategy. This whole science has been supported by a new company role named Business Analyst. This person could be the hero or the villain, depending on how happy is the client and how clear are the requirements gathered.
First, you have a nice client -keep in mind you should be starting a project and everybody is happy; you as a provider, are a kind of new toy :-)-. Most of the times clients are confused about their needs or have a lot of needs that are not properly presented to the provider -this could be extremely dangerous. On the other hand you should have as designer/business analyst a team waiting for your directions. So how you deal with this pressure and ensure a good project start? I present you five points that could be helpful.
- Customer is always right! NO, NO, NO, NO. Have you ever seen a woman with a lot of money in a new useless/stuffy store? A little boy in a candy store with 100 dollars? Ok, first of all, bring your expertise and experience, be the mentor of the client, give them what they want but take your time understanding the root causes of those needs. Pay attention to the client, how he/she/they communicate the needs.
- Spend time with your client to know their needs. This is a common item, if you want to know your client needs, you must spend time with them, not in meetings but good quality time -I hate the meetingitis syndrome.
- Bring help. At this point you should be thinking “I’m the man” and your boss should be thinking the same -probably because they don’t want to pay more. However, any doubt during the business needs gathering process will mean hundreds or thousands of hours wasted because that little misconception. There is a lot of ways to bring help, thought expert consultants, through team empowerment -from client and vendor teams- and my favorite: from the community (geek Internet knowledge community -they are not always right but probably will have a lot of help and feedback for free!.
- Share with all (the Wiki model). As certified PMP I know that the key of the leadership is communication. An effective way to delivery quality design documentation -for example, business use cases, use cases, interaction diagrams or even the hated wireframes (a horrible invention of something that is not similar to reality but should represent it… in some how!) - is to involve the team since the beginning. My personal recommendation, use a Wiki software to share with all in a simple way -Does Wikipedia the biggest online dictionary sounds familiar? Do you know you can participate too and improve or add your own definitions?
- Be formal. The previous point was about to share, but you cannot post a letter or send an email every time you have an idea or new requirement defined. Be smart, be formal, keep in mind your work is not only about define needs, is about defined the correct needs in a clear way. So my suggestion is: do not reinvent use templates, spend time customizing your owns or check in the company records. Let the team participate but keep the power and control. TIP: good templates can be found at ReadySET for free.
There is a lot of knowledge that you can use, share and improve. Projects are not always the same, clients are not always the same, success not only depends on how good/excellent you do your work but for sure, you are reducing the risk and increasing the chances to be a hero.

I don’t want to include a detailed example in my own post, so I decided to include my experience as a comment. For a software project I used DokuWiki as the documentation repository linked with Mantis Bug Tracking for requirements tracking and bug tracking. I built my documentation from the ReadySET templates. This implementation makes an amazing improve in the whole development process, putting all together and allowing a simple team sync. If you have more examples, please feel free to share them here.