by Andre Hollist

It can be often said that one of the main factors causing the failure of projects is the inability to meet the projects requirements. This is usually down to the fact that clients' requirements are not properly gathered or interpreted. The reason for this could range from: clients not knowing what they want, misinterpreting requirements, lack of developer involvement in the process.

Whatever the reason, clear, concise and understandable requirements are no doubt key to the successful implementation of a website.

How you ask, record and disseminate the requirements all affect its quality. Below are 6 tips which could be applied in order to make requirements easier to interpret:

1. Use absolute statements
   Use precise language, 'always', 'never', 'do'. This helps to avoid ambiguity in requirements such as: "Display 'buy now' next to items" vs. "Always display 'buy now' next to items on the results page".
   
   In addition, this helps to realise any exceptions that may arise from a particular requirement an thus define proper prerequisites or new requirements, e.g. "Always display 'buy now' next to items on the results page except where the item is out of stock".
2. Not the opposite
   Force your client to think about requirements in reverse. A requirement that sounds like 'We always want X if there is a Y', can be reversed to 'When no Y, never X'. Getting the client to logically think about this from another angle may help them to realise that in fact it is not correct and they can adjust the requirement.
3. Apply other patterns
   Where businesses may have similar processes or requirements try to draw similarities. Clients may be tempted however to simply say 'Like that, but slightly different'. Where this situation occurs, ask what they understand about that process, why it won't work, what additional steps are required to have it work.
4. Ask for examples
   Have your client give you examples for all requirements if possible. These examples can both exercise something adhering to a business rule as well as not. By putting real life situations into the equation it can be fully tested how suitable the business rule is and if it fully captures the client's requirements.
5. Create examples
   Use your own examples to test how well you understand the requirements. If you have gaps in knowledge of the requirement this will be evident in your example and your client can point it out and address it at that stage.
6. Create Diagrams
   Flow charts, use cases etc all have great benefits in allowing clients to see a visual representation of business rules and work flows. Visual views often trigger other thought processes and help you and your client to pick out flaws.