'Defining business requirements and system requirements, removing ambiguity – and clearly defining acceptance criteria'

Having outlined what the program is aiming to achieve and how specific requirements will be delivered, it is necessary to put the detail into a form that can be put out to tender. This involves clearly defining the business requirements.

It is important to note the difference between ‘business requirements’ and ‘system requirements’ that are specified at this phase.

Many different sets of system requirements may be capable of meeting a given set of business requirements. If suppliers are to have maximum opportunity to innovate, and offer differing proposals with potential cost savings then system requirements should only appear in the specification in order to meet mandatory constraints of legacy systems integration, or specific legal obligations.

The key is to find the most effective method of delivery that meets the client's criteria. The Trackpoint solution makes the process of achieving this straight forward and transparent. As a light approach to this problem, Trackpoints method ensures cost effective requirements production and assurance.

At this stage of the process common pitfalls that allow the introduction of exposure and risk are:

• Business requirements not clearly defined leaving items open to interpretation
• Inter-relationship between all system components and how that affects overall system performance not properly defined or clearly understood
• Acceptance criteria not properly documented which can lead to misinterpretation of requirements, protracted sign-off, delayed payment etc.