The Requirement Pit

tools on the wall
source: smartperks

Perfection is achieved, not when there is nothing left to add, but when there is nothing left to take away….

Don’t Gather Requirements—Dig for Them

When we have given requirement by our user, doesn’t mean he/she mean what we think we mean. There’s could be misinterpreted by us, or maybe the requirement is not detailed enough. So we have to gather our requirements by our self and make sure it’s logged to save our ass.

Documenting Requirement

To create a better requirement, please use case in the documentation. The use case will help us and used to see in the better way the requirements and check if it’s truly its mean.


Requirements are not architecture. Requirements are not design, nor are they the user interface. Requirements are need- pragmatic programmer part 36 (chapter 7)

So don’t overspecify the requirements. Write down exactly what the user wants. Don’t specify the requirements based on what we think will be good to add.

Maintain a Glossary

That would be hard to create a successful project where the coder and the user refer to the same thing by different names or vice versa. Glossary will help us to make sure user and coder are in the same page.





Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.