All technical people should be ready to participate fully in requirements definition. When no technical people are consulted you get requirements that are too vague to be useful in developing code or requirements to do something specific when it won't solve the actual problem they have or all sorts of other things.
What you bring to the table is twofold, your knowledge of how programming in general works, what is and isn't feasible from a purely technical standpoint and your knowledge of how the current system the project is being integrated into works or your knowledge of the system that is being replaced. Both are invaluable in determining requirements. You can keep them from going down a wrong path.
But there are other reasons to be there and to participate as well. IF you have ever played the childhood game of telephone, you know that the message deteriorates the more people it passes through. By being in on the meeting, you know what was actually said and how others in the room interpreted it. This keeps you from getting a poorly passed on message. You also start to see the business reasons why things are being asked for and start to develop an understanding of the business domain and can start to think of how you can solve the actual problems they have rather than what they said in the formal requirement.
If things are unclear to you, then you can get the information from the source not passed through 12 people when you ask a question later while you try to implement. This helps prevent deterioration of the information so that Client A wants problem B solved but by the time the message gets to you it has morphed into problem ZQ. This greatly increases your chances of building what they need instead of what was told to you after passing through many people. If you are developer, you should be fighting to be included in these meetings. Any place where devs are excluded is doing it wrong and will have many more bugs than they need to have You don't want to waste time solving the wrong problem.
Next you have a chance at this stage to influence the direction of the project which is also invaluable. Ask any very experienced dev how often they have been forced to build something stupid because no one could clearly communicate with the ultimate users.
You can stop account managers and BAs and other people from promising what can't be delivered in the timeframe. It is often too late to protest the schedule after it has been agreed on in a meeting like this. You can point out all the things they haven't thought of that this will involve so they understand why the timeline doesn't work.
I have seen a group of people think that a change must be simple because how hard can it be to add a button to a form. It never occurs to these people that the button won't do anything unless someone defines what it will do and then builds the underlying structure and code to make that thing happen.
Having devs in a requirements meeting to explain how difficult some task might be can often prevent you having to work the next 12 weekends in row and 14 hours days for weeks on end to meet a deadline designed around the idea that this was something easy to do.
You also get to ask questions abut the less common paths through the software. For instance, they say they want to institute an approval process and then define how that works. I have never seen a group of non-programmers define what to do in that process if the approval is turned down, yet most competent devs will need to know that has to be defined because every dev knows that when you have an IF branch, you should be handling more than one case.
From a career perspective it is important for you to actively particulate as well. The people in these meetings are often the people who have input into raises and promotions and bonuses. You want them to have a good impression of your professionalism and your technical ability based on the things you bring up. Remember most of these people will never see a line of code and they are part of the process that allocated limited budgets for pay and bonuses. The only thing they will know about you is what they learned in these meetings and any emails you send and anything they hear about you.
If they only thing they heard was you built the part of the project where there was a bug they found painful (but you saw as minor because it took minutes to fix) then they will think you are incompetent if they have no other way to judge. They have no basis for determining how good a dev you are except these meetings and any issue that gets escalated. Don't make the escalations be the only thing they know about you.