Requirements and you

Part 1 - Introduction and Description of the problem
Part 2 - Requirements and you
Part 3 - Tracking Features and Bugs
Part 4 - The little black book that could
Part 5 - Your developers - Don’t be a prick
Part 6 - Wrapping up

Part 2 - Requirements and you
When you give away a project to be done by someone else, the first thing that you will have to do is to come up with the requirements.
This seems to be easy, and everyone wonders how their projects become so garbled in the process.
Now, here is a little secret:
Writing requirements is hard.

Writing good requirements takes practice, patience and a little secret.

The secret to a good requirements document:
Treat the requirements document as if it would be the only thing that stands between you and checking off the task on a list.
Because that is what it is.

Someone who would not know your project or anything else about what you are trying to do has to be able to look at the list and see if an item has been done. Because this is what is going to happen the moment you enter a dispute over a project outcome and - ultimately - your money.

As this all seems cut and dry, here is a real-life example.

I was working for one of the top international banks as a project manager at the time when this happened.
One part of the project I was involved in (thank you, I was not involved in the part that went south) had the following requirement written down and sent to India.

Requirement 3465x/b: Implement a print button as seen on graphical mockup 577254b.

What happened?

Well, the print button was implemented as per reuirement and mockup from the graphics department. One tiny thing: It would not do anything when clicked on. Yes, you heard that right: Nothing would happen.

Whose fault?

Although it would be easy to blame the programmer (and it was tried) He did NOTHING wrong.
He implemented the feature exactly as requested and specified.

Yes, you could say “But he should have known that it should print the page when clicking on the button.” But I disagree.

Why? Because there are easily a few dozen questions like this:

• How should the printout look?
• Which print function should I implement? Is there a print function available for this program already?
• Should or could we use a third party library?
• Should it print physically or convert the page into a PDF?
• Which part of the pages am I supposed to print?
• Should a legal notice be attached to the printout?
• Which font should I use for printing?
• Should the logo header be included? Where is the high resolution logo?
• …

This is what happens when you write shitty requirement documents.
Another drawback is insecure and less productive coders, as they are having to guess your intentions along the way.
Time and cost estimates done on bad requirements are also way off.

How to write a good requirements document

• Treat the document as what it is: The only evidence of what you want to have done. Telepathy does not enter the picture at any point.
• Divide the document into sections according to screens / pages
• Divide the sections into features / work packages to be done.Each feature should be described in a way that makes it easy to identify it as “done”. For a bonus, it should be possible to identify a good implementation from a bad one.

In the above, badly done requirement, implementing the button was “done” flawlessly.

Also:
Update the requirements document with every change and communicate this clearly to your programmers.

Another example:
I want a button on my landing page that leads to my affilate offer versus a redirect page.

Bad:
Make a green button, leading to redirect.

Better:
Put a green button on the lower page, leading to redirect.php

Better still:
Put a green button on the lower page, just before the footer.
Clicking the button will lead to redirect.php.

Best:
- At the end of the text container, put a green button. The button should be labeled “Claim your prize NOW!”. The color code for the button is #00FF00. See attached screenshot of layout (layout_mockup_01.jpg).
- When the user clicks the button, he is directed to redirect.php in the same directory. The link opens in the same window.
- Please contact me with any questions.

Drawbacks to this method
I am tempted to say “NONE” but of course there are.
You will be spending more time on your requirements and you will still mess it up sometimes. Live and learn.

Advantages of this method
Your coders will know exactly what is required of them, leading to them being more productive and feeling more secure in what they are doing.
You will get better results and the chance to dispute badly done work.

 

via http://blindapeseo.com/webmaster-life/requirements-and-you