A few more thoughts:
who's usually responsible for use case analysis?
It depends. On a small team, often everyone. I've also seen cases where the answer is
problem domain experts who don't write code
senior engineers - so the problem is defined by someone with experienced judgement
junior engineers - as a vehicle for getting their feet wet and communicating about the goals, the problems and the solutions before anyone runs too far down the road into implementation.
Another question might be - is it reasonable for anyone to be doing use case analysis right now. It's "make work" if you already have a decent set of use cases sitting around that need to be implemented. It's not make work if the team either (1) doesn't have a set of decent use cases, (2) is about to start a next release and doesn't have cases for that release.
How usual is it to put a newbie on it?
Not too unusual. You may have appropriate problem domain knowledge that makes you more valuable working with the users.
I agree with S. Lott on this.
The hidden fear I have is: are they trying to keep me away from programming (after two weeks I still haven't SEEN a line of code...)?
Two weeks is early for that particular concern to be justifiable.
A few other questions to ask yourself (or your manager):
what does it take to see the code? Can you just look at it and start learning it? If it takes a special computer, or a special environment, or LAN access or something, it could be that you are doing use cases while the team waits for the buraucracy to do what needs doing.
is there someone free who can go through it with you? If not, this may just be a bad time in the cycle for ramping up the new guy, so they have put you in a place where they know you can achieve some good stuff without much help. This is realistic - I can say as a manager, I don't like the idea of just sending off a new guy (however skilled) with no support from an experienced team member. If I have only two people and it's a crunch, I can't spare the 50% of the time that the senior guy will need to break in the new guy. Seriously, it's usually 30-50% of a senior person's time for 2-4 weeks to get a new person up and going. Learning curves are expensive.
I would say, it is unlikely that you need to be concered if - the team in a crunch, you don't have the tools you need, and/or the next release (for which you are writing use cases) is due to start immanently - they have put you ahead of the curve, so you are prepped and ready for a next release.
If you seem to be coming in in a long-term project where no new release is in sight, and no chaos is ensuing from bad use cases, then you may want to have a sit down with your manager in the next week or two and say "so... explain to me why writing use cases is beneficial?" and "couldn't I be more help testing or writing code?". And then a real discussion of his perception of your skills vs. your perception and what you can do to get to the work you'd like to be doing.
are they trying to keep me away from programming (after two weeks I still haven't SEEN a line of code...)Computer programming is the process of designing, writing, testing, debugging, and maintaining the source code of computer programs. Use cases are part of programming. And it's a lot more useful for noobs to be involved with the design aspects before they get involved with actual code (imho). Code is the final product of the process, you need a lot of stuff before you get there. Code may be the most exciting part of the process, but don't rush yourself, or you'll fail miserably.