As a mid-level developer on my team, I participate in requirements gathering/scope planning meetings of projects that I will be part of. I have been finding it difficult to come up with the questions that add value to the discussion or to my knowledge. After some self analysis, I found that knowing that there is a senior engineer in charge of the project who would lead the discussion, has caused me to be laid back in some of these discussions. But I do want to get to a point where I am entrusted with more responsibility and gain skills to handle projects on my own. Though mindset is a bit abstract term to ask about, I would like to get some advice on few things listed below:What kind of preparation will I need to gain most out of these meetings. From observations from team members, I noticed that understanding what all systems that the project is going to impact, What business decisions will majorly impact the project design etc. are some of them.Do I need to avoid thinking about low level implementation details for every requirement. On one hand, I feel it's important to consider them because I will know about the feasibility but I also understand it hinders considering all choices.Finally, as a developer, what is something that I should not be worried about?
What is the ideal mindset for a developer participating in a requirements gathering meeting?
requirements;communication
Answering your questions in order:The mindset going into this in terms of preparation, is to ask the right questions so that the user knows exactly what they want. This is much more difficult than it seems. I need to emphasize asking the right questions. Be specific, if there is any ambiguity, ask another question. Usually during these meetings one answer from the client spawns 3 new questions. Once you know what they want, then it is your job to figure out how it impacts the different systems, not theirs.If there is anything that the client wants in terms of requirements that are impossible, then tell them (my professors used to call it wings on a car). Sometimes clients just don't know software well enough to know the capabilities. Work around that.No, that comes during the design phase. If it can't work, the requirements are revisited.Don't worry about getting it right the first time, because you most definitely won't. Requirements get screwed up all the time by feature creep, clients wanting new things but never telling you, etc. Over prepare then go with the flow.