So it is the start of a release cycle, you finally got your juicy project. You are going to develop your heart out and
all those users
heaven bless them
they will look up to you
Well you are right till the "coding your heart out" step, but then .....
QA comes in and massacres your stable codes reputation. Somehow you convince them, they are not testing exactly the feature you implemented, but something related which you did not work on.
And then comes the bombshell. User declares, you did something they did not ask for.
What went wrong?
Well possibly a lot of things. But lets start at the very beginning (it IS usually a very good place to start). Are you really really sure you understood what user wanted from your tool? What are the magical steps you must follow make sure you are on the same page as user?
I have a few steps I follow, though not full proof, it has saved me more time, whenever I can follow them. I will jot them down here, and welcome you all to add your thoughts here as well.
Ask Why
Often you will have users who will tell you how to do your project, rather than what they want. This is (dare I say?) a problem specially when your user is a technically savvy person. They have solved the problem in their head, and they want you to implement it.
Theoretically there is nothing wrong with that process (says the developer after gulping few times). Some times the solution proposed is the best one and you should implement it. But you are not earning your keep as a competent R&D engineer if you don't make everyone stop and ask why & what & who?
Why is this project created?
Who is asking for it? (and in my next point I will explain why "who" is important)
What is the problem we are trying to solve? No really what really is the problem?
Why do you need it? What debug flow it would facilitate? Where is the user stuck today in your tool? How will your new feature solve the user?
Why are the current features available not enough to solve the problem in hand?
Why this project gets priority over other projects?
What is a reasonable limitation?
You will be termed as the pesky engineer in the beginning of the cycle, but you might end up achieving that holy grail of requirement spec, that brings the three warring tribes of PEs & R&Ds and QAs in the same page.
I would rather be called pesky than spending a lot of time doing clever code to implement a clever solution that no one asked for. What about you?
Know Your Users
It is very important to understand who you are implementing the feature for. If your feature is to be used by all users of your tool, well then you have to take care of possible hurdles with same priority. But more often than not it is not the case.
Some users don't care about the performance but you have to be 100% functionally correct, for others performance is be all and end all, and to achieve that if you are approximating it is acceptable. Figuring out exactly who are you dealing with early in the cycle is crucial to get your best product ready earliest for your FOU.
Don't make assumptions about who your user is, or that they are waiting for you to get it 100% right for 100% cases. Ask.
Also there is a caveat. It is not easy to know your user. Usually your user does not know your user.
So whenever you ask questions like are all the n projects equally critical ? or do you need both accuracy and performance? answer is always yes.
It is up to the developer to push for a prioritization, really bug your user till you understand their requirement. Find your minimum viable project requirement.
One other way to make sure your feature is well delivered, is to be in touch with your user throughout your development cycle. Show them your proof of concept before allocating months productizing it. Which brings me to my next step
Fail Early, Fail Fast
Show your prototype early to your primary user.
Show your prototype early to other users, who has not asked for this project, but you feel they might use it.
Get all their feedback, see how and if you can improve your initial RQ
As I already stated, your user does not know your user. So once they actually see what they ask for, they might actually clarify some points that are obvious to them and is absolutely essential for their project, which was not present in initial RQ and was not at all obvious to you.
Create Clear Success Criteria
This is a direct outcome from our first 2 steps.
If you know your user, know why you are doing the project and you have a minimum viable project requirement, then you already know your success criteria.
Now it is only the small job of putting in the writing and bringing PE & QA org on same page about it. Mind you, now you are the user. And whatever is obvious for you, is probably not for QA and PE. Clear out all doubts, be captain obvious, be redundant and dumb.
Mind you that does not necessarily mean 10000 word confluence. One can be redundant, obvious and concise. 
Is There a Long Term Implication?
When doing a requirement analysis, always think from a overall tool point of view.
Yes your users are super smart user, but then, so are you. You have been toying with your tool for last <fill in the blank here> years. You know how the features work, how they are interrelated. And features are interrelated both in code base and in debug flow.
When you are getting feature requests, try visualize how it fits in your tool. Is it something that affects other features? is it breaking tool philosophy? can this be useful for other users who has similar but not exactly same requirement?
There are other many many rules veteran developers swear by. Of course reading up, remembering and following everyone of them has never worked out quite well for me. Some rules I did read from books, they resonated with me and stayed. But most I have acquired by literally doing the opposite, getting burned and vowing never to do them again.
A disclaimer, more stringent you are about following these rules in the beginning of development cycle, more unliked you will become among your fellow workers. And unless you are Cruella de vil it wont be a pleasant experience.
However, once the process starts working, you might actually end up starting a trend. A process of reliable and predictable project delivery. And that is the dream, isn't it?
