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?
3
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.
1
Users most times know exactly their daily work and which problems they have to solve. What they typically don’t know is
a) how the software exactly has to look like to support that process.
b) how they can explain their process to you.
So focus on questions to understand what the user really want (their goals, their working process), and not if a button should be blue, red, on the left or the right side of the dialog box. Often it is not so much important too clarify any ambiguity, but the right ambiguities.
Concerning “low level details”: avoid that during the meeting – often there are different solutions for achieving the same goal, with different low level details, different costs / development effort, different feasibility. To my experience, it is much better to think a while over the requirements (after the meeting!), and suggest a feasible solution later on, when you made a thorough analysis of the requirements.
And try to avoid worrying about the potential development effort for specific requirements (at least, not during the meeting). Only writing all the requirements down does not mean they will have to be implemented 1:1. After your meeting, you or the team will get a chance to analyze them, make estimations for the implementation (probably different estimations for different possible solutions for the same requirement), and afterwards the requirements will be prioritized or discussed again. What you should avoid is to tell the people any estimations during the meeting out of your stomach, even if they ask or try to pressure you. Just say “I will give you an answer later”.
What I try to emphasize when doing requirements gathering is that if this is for replacement for an existing system, to not think of how you do things in the existing system but rather what would be the ideal way to accomplish what you need to do.
So often users are stuck with the way things are done they can only describe their needs in that manner.
The most important thing for you as the implementer is to understand what they are truly trying to accomplish. One book that helped me as I was learning how to do business analysis was Software Requirement Patterns this book discusses how to get a deeper understanding of some of the implicit requirements that sometimes get over looked.
Also Domain Driven Design is a good book to study (especially with the concept of Ubiquitous Language which basically says use the terms that the domain experts use don’t translate them to “developer speak” so much gets lost in translation).
Another item that’s important is to become knowledgeable as quickly as possible about your target domain. When I developed for a logistics company, best believe I learned about Shippers, Cosignees, Responsible Parties, Less Than Truckload, Hubs, Docks, and everything else I needed to know to have an intelligent conversation with the business. When I worked for an Oil company I took the time to learn about Bores, Wells, Fields, Output, Saturation, and all that fun stuff that went with that industry.
That is the most valuable piece of advice I can give, learn the industry you’re developing software for and you’ll be able to gather better requirements from the users.