+6  A: 

Take whatever notes you can that will best help you understand the use cases and the user requirements. Everything else is just technical details that can be figured out later.

Robert Harvey
That is assuming he is familiar with what Use Cases are...
Justin Niessner
I added a couple of Wikipedia links.
Robert Harvey
+3  A: 

Try to understand that the Team Leader him/herself might not even have all the requirements available right at the beginning. Be prepared to be hunting down people and writing all these requirements down as they come in.

Things will change during development, new problems and new requirements will always be popping up.

Peter D
+3  A: 

Get a list of people who are the intended users. Talking with them will allow you to flesh out the overview that the Team Leader gives you. It is likely that the intended users have a very different understanding of what the app is supposed to do than the TL does. So you'll likely be going back and forth for a while. It's well worth the effort though because you'll do much less re-coding.

dnagirl
+3  A: 

Three things:

  • What: What is the software supposed to do, the more detailed you can manage to get the other person to be, the better.

  • How: Are there any known constraints? For example, if it has to ask for a telephone number, does it have to validate nationally/internationally/not at all. Does it have to run on Windows 2008/2003/all

  • Who: Two sides:

    1. Who will answer any questions you'll have, will you setup weekly progress meetings?
    2. Who will use the software, can you get their early input on your prototypes, can you ask them for opinion/requirements?
Vinko Vrsalovic
+5  A: 

I graduated college two years ago, and up until now programming has only been a hobby of mine.

In that case, my suggestion is:

revel in your ignorance.

Make the most of the fact that you know nothing and you're being given an opportunity to learn - abuse the chance to ask as many questions as possible of the Team Leader in question regarding what type of questions you should be asking and how you should be documenting what you learn.

You only get one chance to be ignorant, once you've wasted it you have to spend the rest of your life as a know-it-all; take the chance to enjoy the learning process.

Steerpike
And there's only one chance to make a first impression. Your advice will make him give an awful one. You can certainly be ignorant and you shouldn't be afraid of it, but you have to do your homework. You can ask for guidance and advice, but you can't sit there and tell the guy: "Well, I haven't a clue about any of this software development thingy, could you ask the questions yourself and answer them for me? I'll go grab a bite and be back in 20"
Vinko Vrsalovic
Oh for god's sake, you just said *exactly* the same thing I did, with more qualifiers. 'You can certainly be ignorant and shouldn't be afraid of it.' and 'You can ask for guidance and advice'. Do you *honestly* think that that's not precisely what I was saying in my answer, just with different language? Stop being so bloody literal.
Steerpike
I think the qualifiers are crucially important in this case: "Ask away, but do your homework". You only said: "ask away."
Vinko Vrsalovic
While the other answers to my question are great suggestions if I were in a meeting with other developers and focusing on one specific project, this answer applied most to my situation. The projects that I will be involved in will introduce me to a myriad of different business process as well as the people in charge of those processes.
Justin R.
+2  A: 

One thing I've found very helpful is carrying a hard-copy of any existing requirements (use cases, wireframes, whatever) or any other potentially useful information in a 3 ring binder to any project meetings I attend. If the meeting strays off topic or questions about previous discussions or documents come up it is very nice to have the information at your fingertips in a format you can make notes on, pass around the table etc.

As a bonus, I find most people don't carry any documents to meetings, so you'll also end up looking like you are a real go-getter who is always prepared, which is never a bad thing.

Main downside to this is that you'll waste paper if the documents are updated and changed frequently.

Millhouse
A: 

Find out the where as well, where are the files you need stored on the network, where is the source control repository for the project, etc.

Since this is your first taste of doing a real world project, please please please make sure you use source control even if you are the only dev on the project. YOur co-workers will thanks you and you will thank you the first time you need to back out a change that didn't work.

HLGEM