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 newcomers, 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 solid and complete skeleton of your work product: the requirements document.

So, here’s a list with some basics you can start with 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?

Well, not always. I mean here that the customer doesn’t always has a clear idea of what he wants, but working without a document you and your customer agreed by contract to commit to, is always a bad idea. Of course, there will be changes, maybe even a lot more features, but you need a fixed starting outcome, so you can show clear results. This will save your entire team a lot of trouble and buy some self-respect.

2. Ignore your developers: they don't understand your vision, don't see the complete picture, so how could they advise?

But they surely see their part much better than you do. It’s not really wise to impose unnecessary constraints, or reject a much simpler, elegant solution coming from your specialist. After all, you're working with experts in different domains, it’s more than recommendable to ask for their opinion, even if, in the end, you’re the one deciding what and why to implement.

3. Silence your testers.

Who are these guys anyway? Are you working with professional test engineers? Do you think their input is important? Shortly, I’m coming from the testing area. And I’m glad for that, as I feel this is giving me some kind of advantage. Have you thought about writing requirements for testing? Meaning taking the testability feature for requirements seriously? I think this simple aspect is weighing greatly from the quality point of view of your requirements.

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.

Take your time, do an excellent job. After all, how can any member of your team perform if you don’t perform. They will realise your stuff, so what you deliver must be great.

Not really! Perfectionism is never a great companion. Especially in such a fast-paced role, when changes and improvement occur at any step. You must 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 finish 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.

You’ve invested a lot of work and energy to finally produce the document. It should now be available for everybody, and you can relax. But people want to change, colleagues want improvements, testers want clarity and specificity, the customer wants changes also. You are not happy. You don’t like removing features being your brainchild, which you think you can be proud of. And they want it out, what a world!

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.

They all should wait until you’re done, right? Why are they always bothering you with questions, they will see it all anyway.

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.

Do you never make mistakes? You’re always right? Let’s be honest: always, always? Then let’s keep an open hear and an open mind to peers' feedback and suggestions.

You know, ignorance does not excuse your mistakes. 

8. Never say No.

Accept anything. Take all responsibility. Help anyone. If a team member is unsure, show him, even complete his job.

It’s the sure way your job doesn’t get completed. And nobody else will do it.

9. Hide your knowledge, don't share.

 That applies for all those not sure of themselves. They think that keeping know-how private will keep them safe on their job.

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 eventually.

10. Be slothful, avoid questions.

Do you like to answer questions? A lot of questions. How about people questioning your judgement? How are you handling feedback? How do you react at people suggesting alternatives? Possibly better ones. Do you even take them into account, even implement?

You should. Put vanity aside, complete your job faster and more complete, all feedback incorporated.

11. Add more features than required. Like me, now

That’s my favorite. Let’s build something extraordinary, something we can be proud of. All with the budget of an egg cooker. You’ve been asked for a baby cycle, and you design an aggressive and powerful motorbike. Can you convince the customer to pay for it?

Of course, this is not a complete list, some other items could be also appended to it. These were the first things crossing my mind.

What important is we recognize the productivity traps that might appear during the way. Because seeing the trouble is the basis for avoidance, right?