How to: 10 Sure Ways to Blow Your Requirements!

Well, not always. I mean here that the customer don’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 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.

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, your 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.

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.

Take your time, do a great 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 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.

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.

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.

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. 

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.

 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 sooner or later.

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.

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?