How to: 10 Sure Ways to Blow Your Requirements!
What do you achieve when you don’t know what you want?
Sometimes the best way to perform is not to know what to do, but what not to do. This is best start not only to new comers, but also to experienced Requirement Engineer who takes over a new challenge. Experience and project specificity will of course add and tailor features and work process, but you already have a pretty solid and complete skeleton of your work product: the requirements document.
So, here’s a list with some basics you can start with in order to fail:
1. Start working on phone/email basis: don't ask for a frozen and stable customer document, he's already told you what he needs, right?
2. Ignore your developers: they don't understand your vision, don't see the complete picture, so how could they advice?
3. Silence your testers.
It makes it much easy to understand and implement. Here’s why:
- it’s clear and concise
- it’s specific, tells exactly what, where and when. More, it only specifies quantified values for everything. e.g.: your developer may live with: “The result of the function shall be delivered as soon as possible”, but the tester will react to this temporal unspecificity, which will force you to define what ‘as soon as possible’ means in a concrete fashion. Timing uncertainty is then solved, which will lead to a much better requirement.
Of course, this will add you more work by analysis for defining everything, but then you’ll have much easier job in support phase.
4. Write perfect requirements.
Not really! Perfectionism is never a great companion. Especially in such a fast paced role, when changes and improvement occur at any step. You have to keep up. But you must have always the material to manage, which, of course, have to be created pretty early and quickly. You already feel the pressure of the first release, and you didn’t even finished with the very basic functionalities, because you feel it’s not good enough, not complete enough, or you fear you will be corrected? Is your team waiting in distress and urge you they need your input? Because now they cannot work. Wouldn’t it be better if they had an incomplete and faulty document to start working with. Even a draft one, that you can manage and update, informing your team if changes occur on the fly? After all, rarely is this the last version, the last release, and everything can be fixed at the next iteration. Furthermore, you will rarely achieve the project end still having an unimproved or incomplete document.
So then, why worry to make everything perfect from the beginning. Just go ahead! Things will fall into place anyhow, with a much less effort required from your side, but with a much higher efficiency.
5. Be faithful to the initial form, change nothing.
Changes always occur, you better accept that now. After all, the requirements specification is a living document.
6. Silence is golden: tell no one what you're doing.
The software world is an extremely dynamic one, development scarcely starts just after all requirements are frozen. I never saw that happen. So start working with your team as soon as possible. And keep them informed.
7. You're the architect, you know best. Your judgement is unquestionable.
You know, ignorance does not excuse your mistakes.
8. Never say No.
It’s the sure way your job doesn’t get completed. And nobody else will do it.
9. Hide your knowledge, don't share.
But, there are some news: no one is irreplaceable. The ones not sharing are holding back the team, not helping at all. And that will be seen sooner or later.
10. Be slothful, avoid questions.
You should. Put vanity aside, complete your job faster and more complete, all feedback incorporated.
11. Add more features than required. Like me, now
What important is we recognize the productivity traps that might appear during the way. Because seeing the trouble is the basis for avoidance, right?